Decentralized Rollup Sequencing as a Service via Interchain Security

[nick]

TL;DR

• Launching a rollup with decentralized sequencing requires gathering a set of sequencers and issuing a new token, which is high overhead.
• Interchain security enables you to use the validator set and stake of one chain to secure new chains.
• Using interchain security, you could spin up a new rollup with decentralized sequencing by using an existing set of sequencers and stake, reducing overhead.
• Potential benefits: soft commits for fast-finality, atomic cross-rollup composability, cross-rollup MEV.

Overview
Decentralized sequencing is a common approach for rollups to achieve censorship resistance but it incurs large overhead to launch a new rollup.

I propose using interchain security to build a decentralized sequencer network as a service, which would make it possible to launch a new rollup with censorship resistance (and fast finality) with minimal overhead.

Current Problem
Decentralized sequencing requires gathering a set of sequencers and (likely) issuing a new coin to stake for leader election. Though this set of sequencers can be much smaller and the value of stake need not be as large as for an L1, this still represents significant overhead for someone seeking to launch a new rollup.

Proposed Solution
Interchain security enables one blockchain network to reuse its stake and validator set to launch and secure new chains. For example, the Cosmos hub will use its stake and validator set to launch and secure at least 5 new “consumer chains” in 2023.

This same mechanism could be to launch new rollups without needing to recruit a new set of sequencers or issue a new staking token, dramatically reducing overhead. A common sequencer network would act as “sequencers as a service”, ready to spin up new nodes for new rollups that want to launch.

These rollups still post their data to a data availability layer and use fraud or validity proofs to ensure execution validity.

Potential Benefits

1. Fast Finality: This sequencer network could make slashable soft commits on new blocks to provide fast finality for better UX.
2. Atomic Composability: The fact that multiple rollups share a common network of sequencers may enable mechanisms for atomic cross-rollup composability.
3. Cross-Rollup MEV These sequencers would also be well positioned to apportion cross-rollup MEV.

Notes
This is still a very high-level idea and as we all know, the devil is in the details. Furthermore, I don’t know the details of how Interchain Security works.

Also note, there are other ways of providing censorship resistance for rollups like inboxes or leaderless rollups.

Feedback is much appreciated!

[jtremback]

As I understand it, with ICS v1, this would result in every validator in the Cosmos Hub validator set running the sequencer. I’m curious what the advantages would be in that case over the validators just running the app directly as a consumer chain?

[nick]

From what I understand about how ICS works, adding new chains equates to a block size increase. This causes centralization because each additional chain makes it more expensive to verify the overall system.

The key difference here is that anyone can verify the overall system using data availability sampling and fraud/validity proofs. Hence no matter how many chains there are, the system is still decentralized & secure.

In this case you’re just using the hub validators for censorship resistance and soft-commits, rather than the security of the chain. So having every validator run every sequencer is probably overkill.

I’m curious if ICS v2 will have an “opt-in” design, so that validators choose which consumer chains they want to support?

[mpoke]

ICSv2 it’s problematic and may not work: It’s hard to guarantee that a subset of a decentralized validator set is also decentralized.

However, I could see this idea work with ICSv1. Basically, having a consumer chain that provide sequencing as a service for multiple rollups. For every rollup, the sequencer is elected from the consumer validator set in a round robin fashion (similarly to deciding on the proposer). Since we expect a large number of rollups, it’s not a problem having a large pool from where to select sequencers. The question is, how computational intensive is to run a sequencer for a rollup? Can a validator node on the consumer chain act as a sequencer for 100 rollups?

[nick]

ICSv2 it’s problematic and may not work: It’s hard to guarantee that a subset of a decentralized validator set is also decentralized.

I’m curious what the definition of “decentralized” is here, as the required decentralization threshold for a rollup sequencers is significantly lower than for validators of an L1. So ICSv2 might work for rollups.

For every rollup, the sequencer is elected from the consumer validator set in a round robin fashion (similarly to deciding on the proposer)

Do you mean to do something similar to sharding where you assign a subset of the validators to each rollup and then shuffle them each epoch? That’s an interesting idea that I hadn’t thought of before. Maybe there could be a big beacon chain with a bunch of rollup sequencers who register and then they get assigned to a particular rollup.

The question is, how computational intensive is to run a sequencer for a rollup? Can a validator node on the consumer chain act as a sequencer for 100 rollups?

Same as for an L1 - it could be high or low depending on the design of the rollup. However, generally speaking I’d say that the node requirements for a rollup will be equivalent to a typical L1 node. So the answer is no, a single validator node could not act as a sequencer fro 100 rollups

[jtremback]

I’m wondering what the benefit is of using sequencers that come out of an existing validator set. Are they any better than any other sequencer?

[mpoke]

I’m curious what the definition of “decentralized” is here, as the required decentralization threshold for a rollup sequencers is significantly lower than for validators of an L1. So ICSv2 might work for rollups.

By decentralized I mean that the total stake should be well distributed to avoid centralization, i.e., a majority of the total stake should not be owned by a single organization. For example, if we assume that the Hub validator set is decentralized (a decent assumption), taking 30% of that set you may end up choosing a large validator (with 10% power on the Hub) and a bunch of tiny validators. The large validator will be able to halt the consumer by itself. Even worst, it will be able to censor transactions.

Even if the required decentralization threshold for a rollup sequencers is significantly lower, you don’t want the consumer chain to be controlled by a single organization. Whatever service is running on the consumer chain (e.g., leader election), you don’t want it centralized.

Do you mean to do something similar to sharding where you assign a subset of the validators to each rollup and then shuffle them each epoch? That’s an interesting idea that I hadn’t thought of before. Maybe there could be a big beacon chain with a bunch of rollup sequencers who register and then they get assigned to a particular rollup.

Something like that. There should be a way though to be able to punish sequencers that misbehave. This can be done though via the consumer chain native coin: Sequencers need to lock a deposit that can be slash in case of evidence of misbehavior.

[nick]

I’m wondering what the benefit is of using sequencers that come out of an existing validator set. Are they any better than any other sequencer?

The advantage here is similar to ICS - lower overhead. You don’t need to gather a new set of sequencers and you don’t have to deal with issuing a token.

Even if the required decentralization threshold for a rollup sequencers is significantly lower, you don’t want the consumer chain to be controlled by a single organization. Whatever service is running on the consumer chain (e.g., leader election), you don’t want it centralized.

Indeed. The difference between a rollup and a normal chain is that the security is not derived from the sequencers. You just need enough decentralization to get censorship resistance, which is a significantly lower threshold.

There should be a way though to be able to punish sequencers that misbehave. This can be done though via the consumer chain native coin: Sequencers need to lock a deposit that can be slash in case of evidence of misbehavior.

Yes exactly. This is one of the benefits of using an ICS-like model. You already have an asset that can be staked and slashed.

[LanreIge]

Interesting idea! I think the main concern for me is uncertainty over what makes a good decentralized sequencer election algo w/o just relying on something that degrades scalability of the given rollup + how much freedom one has in designing this / ICSv1. Since ideally for a decentralized sequencer leadership election you would maybe just rotate sequencers once a day or something. And then maybe have a fallback function where if the sequencer doesn’t post a state root (or whatever ) on the DA chain then the next sequencer is rotated to automatically, though I think there’s a bit of complexity here.

imo I’m more interested in just having a consumer chain attached to Celestia’s that supports rollup settlement as a priority.

[nick]

Agreed on the rollup settlement chain. Been thinking about something along these lines and will share more when it’s ready!

[Spaydh]

Funny how life has its ways sometimes - found this conversation while researching the topic from the perspective of the potential settlement layer for this kind of implementation! Early in research right now, so may be missing some technical context, but:

I’m working on Neutron - an ICS chain - and also came to the idea of an “on-demand” roll-up framework that’d leverage IBC, either the L1’s or Celestia’s for DA, and ICS to enable dApps on the L1 to easily migrate to their dedicated roll-up with full support for existing tooling, baked-in interop via IBC + potentially some degree of atomic composability through a shared DA layer and interface + overlaps between sequencers and validators.

Happy to discuss further if you’d like!

[nick]

Glad to see you here and intrigued to learn that you’re thinking about this problem too. Would love to talk more about this with you some time!

[IBCGuy]

Any reason why a subset of Celestia validators and TIA couldn’t be used to spin up a decentralized sequencer set? You could have all the benefits you mentioned + ‘trust reduced’ bridging / IBC between the Celestia chain and the roll up, which could provide economic network effects to the roll-up ecosystem.