Namespace Staking to Mitigate Spam Attacks on Rollups

Research
1

Introduction

Spamming a rollup network by posting invalid blocks to its namespace is an issue in Celestia due to the fact that in the data availability layer + rollup paradigm, block production is cheap (just pay transaction fees) as opposed to costly in PoW or PoS networks (perform work or stake tokens and get slashed for misbehavior).

This leads to various spamming attacks that we’ve been discussing since the Kyiv offsite including the Woods Attack on light clients and another against full nodes pointed out by @mattdf. The TL;DR on this second attack is that someone can post a bunch of blocks that take a long time to verify and only include fraud at the very end. Hence rollup full nodes would be forced to waste a lot of time processing these blocks before they could find out that they are invalid.

Staking may be the only way to mitigate certain kinds of spam attacks

While I think we have a good solution to the Woods Attack, I think the only way to combat the spam attack on full nodes is by having a staking mechanism that limits who is “allowed” to post blocks for a given rollup and which can penalize any allowed person who spams or produces invalid blocks.

Of course anyone is allowed to post blocks to any namespace on the Celestia chain, but a rollup could use the a staking mechanism to agree on a set of keys who are “allowed” to produce blocks in their namespace. Blocks posted by anyone who is not on that list are ignored out of hand by looking at their signature. This does not prevent someone on the “allowed” list from spamming however, so there needs to be some kind of punishment like that detects misbehavior and removes them from the list.

Why a rollup-specific token may not always be the best solution

In order for a rollup’s staking mechanism to function, it needs a token with value to stake. I can see 2 scenarios for choosing a token to use as staking.

  1. the rollup mints its own token to stake
  2. the rollup agrees to use a third party token as its staking currency

While 1 works well and might even be preferred by some rollups, it also has problems. Not every rollup will want to bootstrap a new token, imbue it with value and ensure that it is liquid. Part of Celestia’s value proposition is that you don’t have to go through this consuming process if you don’t want to.

For 2, the question becomes which token to use and how to bridge that token into the rollup in order to stake it. Below I propose a way in which the Celestia token “TIA” can be used for this purpose.

My proposal: namespace staking and blacklisting

I propose that the Celestia main-chain support a transaction type that allows people to stake TIA tokens to a particular namespace. Using this on-chain stake as a reference, a rollup can build an off-chain staking mechanism that effectively prevents spam attacks.

I know what you’re thinking–“you can’t slash on-chain stake from the rollup, so how can you punish misbehavior?” Drawing inspiration from John’s post we can use blacklisting rather than slashing as punishment.

Here’s how it would work:

  1. the rollup sets a minimum threshold of TIA tokens that must be staked to the rollup’s namespace in order for an address to be considered an “approved” block producer
  2. any block posted to that namespace by an address not on the “approved” list is ignored (which prevents random people from spamming)
  3. if any approved block producer “misbehaves” they are blacklisted and no longer considered on the list of approved block producers so there future blocks are ignored. Here “misbehavior” is defined by the rollup and could be something like “posts an invalid block”.
  4. once blacklisted the misbehaving block producer would have to wait for an unbonding period (set by the celestia main-chain) until rebonding and being allowed to post blocks again.

Why this would work
This is an effective spam mitigation strategy because it makes it expensive to spam the rollup with invalid blocks. You can only “misbehave” once before being blacklisted, so the cost of executing n misbehaviors scales as n*min_stake. Rollups can calibrate their own values for min_stake and their own definitions of “misbehavior” according to their security thresholds.

Some advantages of staking TIA rather than a different coin

Here are some reasons why it makes sense to use TIA for to prevent spam in a rollup rather than other third party coins.

  1. TIA may solve an underlying issue in seeding a new rollup with 3rd party staking tokens. How do you bridge the 3rd party tokens into the rollup to stake them before the rollup even exists? Bonding TIA does not have this problem as it is native to Celestia itself.
  2. TIA tokens and TIA wallets can serve as a standard staking mechanism for aggregators. That way Celestia aggregators can stake and produce blocks on many rollups with less overhead.
  3. It adds a new use case for the TIA token potentially driving more value into the network.

Bonus point: this may also be useful to mitigate MEV

While the motivation of this post was to use namespace staking to prevent spam, I believe this mechanism could also be used for leader selection within a rollup which might be necessary to mitigate Miner Extractable Value (MEV).

To generalize this further, namespace staking may be a useful primitive for any rollup to create a permissionless set of block producers which potentially has many other useful applications beyond just spam and MEV mitigation. Worth looking into more deeply!

2 Likes
2

Are there really that many cases where a rollup would not have its own token? No matter what the rollup is, at the end of the day, posting blocks of that rollup back to Celestia has a cost, meaning that any individual action in the rollup has a cost that is at least a fraction of that cost.

How would the cost of these actions be accounted and paid for on the rollup without the rollup having a value-bearing token of some kind?

Even if the rollup is not actually minting tokens out of thin air, it basically will always need a “core” token like TIA or ETH that is the fee source for the transition function. If I make a Celestia rollup and to instantiate that rollup, I lock 10,000 DAI on ETH in a smart contract that will only unlock those DAI after a certain time and how they are transferred would be only as a result of some merkle proof signed by said rollup’s validators, then I’ve created a rollup whose “core” token is effectively DAI but transparently integrated into the consensus of the rollup.

So I’ve not minted anything new and don’t need to worry about liquidity or all that. The “I don’t want to make my own token” problem is easily solved this way.

1 Like
3

Good point. However solving the problem in that way requires that rollup to run a bridge to another chain that the tokens are being bridged from e.g. ETH. Not all rollups may want to have this (some may not even have the functionality to support a bridge). TIA can serve as this asset without having to operate a bridge.

That still leaves the question of what asset will serve for the payment of fees though. I could see TIA fulfilling this function too.

Aside from the discussion of whether or not this is useful, do you agree that it would work?

1 Like
4

TIA can’t be used to pay for fees unless you pay for the fees you plan to use ahead of time by sending transactions individually on Celestia to “enter” into the rollup. But then that introduces trust assumptions that a rollup with a smart-contract entry point doesn’t have: the owner of that TIA address could do whatever they want with the TIA, and also it makes it impossible to swap out the validator for a rollup if that TIA address goes offline, because it would hold all the pre-committed balances. Using multisig or committee-backed TIA addresses can solve some of these problems but with high overhead compared to just having a smart-contract-backed entry.

Also, the rollup would not have to support a bridge necessarily, if assets can only enter the contract during the “bootstrap” period, and can only exit the contract once the rollup “finalizes” (or every epoch of some blocks N), from the rollup execution environment’s point the communication is basically one-way, and the rollup actually exists as a series of chained state channels with validator-set signed committments.

Entering into a rollup with TIA alone with the rollup not having its own token has heavy limitations, and I think we have to accept that there will be limitations to certain types of rollups that we shouldn’t try to solve on L1.

Note also that rollups can also be value-bootstrapped by other Celestia-backed rollups that support smart-contract environments, and so in that case then you are not introducing dependence on other chains, and “bridging” would be easier since the blocks are on the same chain, with the same security assumptions, overlapping P2P networks etc.

On whether the bonding scheme works - for the purpose of spam reduction alone, it does, but again it only provides value to rollups that have no ability to stake anything on the rollup itself. Even then, if we are going through the strategy of using a priori information to decide who to ignore, why not just have the rollup nodes keep a whitelist of addresses that are allowed to submit rollup blocks?

Rollups with tokenless fee mechanics are exotic enough to me that they likely wouldn’t be using open validator sets anyway - can you imagine a scenario that makes sense enough to make it worth implementing this mechanic on L1 to support it?

2 Likes
5

All very good points. I’m quite convinced you’re right now. I think I was drawn by the allure of the pumpanomics of another staking mechanism for TIA.

I sometimes wish we had some way to bridge the TIA tokens into rollups, but I’m not sure that would be worth the tradeoff of adding more complexity to the celestia app… what do you think?

6

The only thing I can really think of that doesn’t end up adding some sort of VM into Celestia is TIA addresses controlled by a key that is generated by Distributed Key Generation, and creating the rollup such that, as part of the output of a valid (rollup) block, a signature is also generated over a valid Celestia transaction with the TIA DKG key, which when submitted to Celestia would alter the TIA balance according to what happened in the rollup.

However in this case validator set collusion has more devastating effects, since the validators together could just sign any arbitrary TIA transfer transaction, so even in this case it would be necessary that byzantine behavior would cause a loss on the rollup greater than the balance of the TIA-backed-DKG (or even cause a loss elsewhere, if proof of collusion can be submitted to some other contract/chain/whatever, in case the rollup can’t recover from total validator set collusion).

1 Like
7

You can only “misbehave” once before being blacklisted, so the cost of executing n misbehaviors scales as n*min_stake.

I might be missing something obvious here, but can’t the block producer misbehave using the same stake, by moving the coins to a different address after the unbonding period?

BTW, I wouldn’t necessarily call this namespace staking, but namespace bonding, as the rollup isn’t necessarily using proof-of-stake in a round robin mechanism.

2 Likes
8

Thanks for the feedback! Do you think this feature might be useful?

Yes the block producer can misbehave using the same stake but has to wait for the unbonding period before doing so. So the cost per misbehavior would be the cost of capital which scales as min_stake*t_unbonding.

I agree that it should be called namespace bonding instead of staking. The idea kind of evolved as I wrote the post.

9

I think it has merits, subject to comparison with other bonding strategies. There’s probably a way to achieve this without making changes to L1 though. You could have a dedicated “namespace bonding” rollup that maintains a mapping between stake delegations and namespace IDs. Within that rollup, stakers can assign or unassign their stake to specific rollups.

This is also somewhat similar to Cosmos Hub’s Interchain Staking idea, but rather it’s Interchain Bonding.

1 Like
10

Actually, yes, the result that this proposal aims for can be achieved without making any changes to L1 by just reversing the time dimension of the mechanism.

Instead of making it so that you “lock” or bond TIA for some duration d to a namespace, which allows you to be in the set that will be listened to when messages are posted, you can instead make it so that someone has to move an amount of TIA to an address they propose, and only after duration d can they start being listened to when posting messages.

It has the same effect: if blacklisted due to misbehavior, they can move their TIA instantly, but they’ll still have to wait another d time before they can be whitelisted again. If they ever move their funds in any case they are instantly removed from the set, also.

2 Likes
11

@mattdf genius idea! I think that would work just the same as the bonding scheme.

@musalbas I’m curious if you could expand on this interchain bonding idea and the rollup that would help manage this.

In the end I’m still not convinced this will be more useful than other staking strategies for rollups but if we already have it for free without changing the L1 it’s up to the rollup builders to decide. We should just make sure people are aware of this strategy in the future.