Uniting rollups with shared sequencers

Rollups provide a lot of nice properties around scaling, but they come with some critical trade-offs. When applications are split across multiple rollups, complexities arise around composability, liquidity, and user experience. Many of these problems can be minimized by introducing the notion of a shared set of sequencers that operate on many rollups.

Since these problems are most apparent in the paradigm of app-specific rollups, I’m going to refer to those types of rollups as rollapps for short.

The rollapp problem

There are multiple benefits of having an application on its own rollup instead of sharing a rollup with many other applications. The main trade-off that rollapps experience is two-fold:

  1. It breaks synchronous composability. Though not completely broken, two rollapps can enjoy asynchronous composability between each other via an expressive bridge – one that enables arbitrary data passing. But asynchronous composability doesn’t offer the same level of seamless features that synchronous composability does. In addition, implementing synchronous composability between two rollapps with unique sequencer sets is very difficult, and in many cases impractical.
  2. It requires bootstrapping a decentralized set of sequencers. The main hurdle for a rollapp to ensure it’s required level of censorship resistance is to source a decentralized set of sequencers. In the scenario of many rollapps with their own sequencer sets, there is a high probability that of a large overlap in validator sets will exist (cosmos app chains have overlapping validator sets of up to 67%). At that point there’s negligible gains in decentralization, and potentially security, for a rollapp to bootstrap its own decentralized sequencer set.

With a shared sequencer set, rollapps can solve for both trade-offs. Using a shared sequencer set removes the burden for a rollapp to source its own set of sequencers. It can become decentralized on day one with access to the security and censorship resistance that the shared sequencer set has built up.

Two rollapps can have synchronous composability when they share sequencers. For example, if a sequencer operates on two rollapps, it can provide synchronous composability when it produces a block on both chains simultaneously. If a network of rollapps can compose in the same way two smart contracts can on the same chain, then the boundaries between chains blurs. They can effectively operate like a unified network of applications.

What are some other benefits of shared sequencers?

Aside from fixing the two main problems of independent rollups, shared sequencers provide a couple other notable benefits.

  • Shared security: Rollapps already receive shared security by publishing their block data to L1. In most cases, rollups must build their own decentralized sequencer set to provide any guarantees of liveness and censorship resistance. When a rollapp uses shared sequencers, it receives shared security for all aspects of its chain. The benefits of this are twofold. 1) the rollapp gets to utilize the economic security of an existing set of staked sequencers, which may be more secure than what they could bootstrap on their own. 2) It significantly reduces the overhead to bootstrap and maintain a rollapp. Lower barrier to entry enables more communities to coordinate using their own chain.
  • Reduced liquidity fragmentation: Liquidity gets siloed when there is high friction to move between chains. A network of rollapps with shared sequencers gets synchronous composability, so moving liquidity between any given rollup is as frictionless as moving funds between two applications on the same rollup. The reduction in friction for cross-rollapp interaction should result in tighter spreads and better execution prices for trades.

What are the trade-offs of shared sequencing?

Shared sequencing changes the dynamic of how rollups operate, introducing new trade-offs.

  • Scaling: Each operator in the sequencer set needs to run a sequencer for every rollapp they are securing. The question is, what is the limit on the number of rollapps we could expect them to reasonably operate on? Is it 50? 100? I highly doubt it could go past 200.
  • Sovereignty: A rollapp doesn’t truly lose sovereignty with shared sequencers, but the sequencers hold power so long as the rollapp wants to continue using their services. If they choose to fork, the sequencers also need to agree to follow the new fork. Does governance get conducted off-chain or through on-chain voting? In the on-chain scenario, misalignment between the shared sequencers and a rollapp’s community can result in undesirable outcomes. At any point the rollapp could fork away completely from the shared sequencers to procure its own set. But some rollapps may face considerable challenges in doing so (token requirement, security requirement, etc).

For scaling, its obvious that we can’t expect one single shared sequencer set for all rollapps. That will lead to multiple networks of rollapps with shared sequencers. How those individual networks connect to each other will become important – likely mirroring the difficulty in connecting L1s.

How rollapps can utilize the shared sequencer service is another important question. Will it be permissionless or permissioned? A permissionless service could become problematic because it forces the sequencer operators to run another sequencer node for each additional chain that joins the service. If it is permissioned, how frictionless is the process? One potential solution is for the decision to be made via off-chain governance with some method of input from the community. There should be enough positive input such that there is rough alignment for a new rollapp to join the shared sequencer service. How long the governance process takes, and the process of agreement could become a large source of friction, dependent on the size and set of governance stakeholders.