Today’s major rollups still rely on centralized sequencers. This is a problem. Granting a single entity all transaction ordering authority enables a range of attacks. Users make significant trade-offs trusting a single actor to act altruistically.

At Astria, we believe rollups should be decentralized by default.

Here’s why we need decentralized sequencers.

The Role of Rollup Sequencers

Rollups do not require sequencers to function, and many of today's rollup designs did not initially use them. They were introduced over time to provide a more responsive rollup user experience. Sequencers are used to order transactions, providing guarantees to users that their transactions have been included and won't be reversed ("soft commitments") without waiting for the transaction to be batched and submitted to the L1.

When using a sequencer, a rollup’s liveness, which is the guarantee that the network is processing transactions, becomes dependent on the sequencer. To circumvent this dependency, there has been recent interest in based (or L1-sequenced) rollups as a simpler rollup design, which function without a sequencer and inherit the L1’s liveness and decentralization. However, based rollups don’t have a clear way to provide users with fast confirmations as a sequencer would, resulting in a less responsive user experience.

It is clear that sequencers are a design improvement for rollups, but today’s major rollups still rely on centralized sequencers.

Transaction Order Flow

The typical transaction flow for a validity rollup has 4 distinct steps:

1. Unordered transactions, or a comparable analog such as an intent, are signed and submitted by end users to one or more RPC endpoints which either store them in their private mempool or broadcast them to a public mempool.
   
   

2. A sequencer reviews and takes these transactions (or intents) from whichever sources it has access to and sequences them, creating an ordered block. The sequencer then makes a cryptographic commitment to the block (soft commitment).
   
   

3. This ordered block is then sent to, or retrieved by, a full node which has an up-to-date copy of the chain’s state immediately prior to the current block. The full node passes the block through its deterministic state transition function, resulting in an updated view of the chain’s state and a corresponding state root.
   
   

4. The execution trace for this block, created in (3), can be passed to a prover network. This prover network will generate a succinct zero knowledge proof (ZKP) showing that the execution trace is valid according to the rules of the rollup’s state machine.
   
   

For simplicity, and because we are focusing on sequencers, this diagram intentionally omits how and when batches of transactions or blocks are posted to a L1.

Drawbacks of Relying on Centralized Sequencers

A centralized sequencer is where a single entity proposes all blocks for the rollup. The sequencer may consist of multiple physical (or virtual) nodes, but all nodes are controlled by a single entity; this is how Arbitrum, Base, Optimism, and zkSync operate today. Rollup users have become comfortable trusting soft commitments given by centralized sequencers, disregarding crypto’s “Don’t Trust, Verify” motto.

Although centralized sequencers provide fast and efficient soft confirmations for end users, it is possible that the sequencer sends an invalid commitment, due to either a bug or malicious behavior. Ideally, if the sequencer is found to have given an invalid commitment to a user, they should be slashed. But presently, proving or challenge mechanisms are controlled by the same entity that controls the sequencer, if they exist at all, and there is no way for an outside party to challenge the sequencer’s commitments.

MEV and Censorship Resistance

It could be argued that since there has not been evidence of malicious centralized sequencers, the need to decentralize is not as urgent. However, the absence of explicit rugs does not imply the absence of transaction manipulation.

Because the rollup operator has utmost discretion on transaction inclusion and ordering, they can order transactions to maximize their own arbitrage opportunities, delay a user’s transaction, or censor a user altogether. Unfortunately, it is impossible to know what transactions a sequencer sees, in what order, and whether it is censoring or injecting new transactions into the block it creates. While the censored user is still able to force their transaction onto L1, this is an expensive alternative, sometimes prohibitively so. Rollup users are at the mercy of the centralized sequencer and have to trust that it fairly includes their transactions.

Granting a single entity all transaction ordering authority enables a range of attacks that are difficult, if not impossible, to execute in a decentralized system. One such concern arises because the sequencer is in control of ordering multiple blocks in a row, which easily enables multi-block MEV (MMEV) strategies in order to carry out larger-scale attacks.

Towards Decentralized Sequencers

A rollup can decentralize its sequencer in two ways — the first is through a simple form of leader rotation. Through some election process, the rollup can define a set of actors who take turns being responsible for ordering transactions in a block such that a single actor doesn’t have a persistent monopoly. Although the current leader maintains a monopoly on transaction ordering for their respective block, allowing them to censor or reorder transactions, they are unable to persistently censor the chain or reorder transactions across concurrent blocks.

The second way to decentralize a sequencer is by using a Byzantine Fault Tolerant (BFT) consensus algorithm. Similar to a simple leader rotation system, a single actor defines the order of transactions for a given block, but now a two-thirds majority of sequencers in the leader set must come to consensus on this ordering. Importantly, consensus must be achieved prior to the block’s header being broadcast to nodes outside the leader set.

Both of these options have their pros and cons. Using a simple leader rotation mechanism allows for faster block times, potentially as fast as a centralized sequencer, because the leader for a given block does not need to communicate with any other party before publishing their block during their turn. The trade-off is that a malicious sequencer is able to publish a block without any other leader double checking it, even if the block has an invalid state transition. This makes it much more likely that the rollup will need to reorg out a bad block.

In comparison, using a BFT consensus algorithm means that publishing a block with an invalid state transition would require a two-thirds majority of sequencers in the leader set to be malicious. This comes at the cost of much slower block times as a sequencer must wait for multiple rounds of consensus voting, and the corresponding network latency, before publishing their block.

MEV and Censorship Resistance

In both of these configurations, the use of a pseudonymous sequencer set makes it impossible for a user to trust that all sequencers will act altruistically. The economics of the system must be designed assuming that sequencers will select and order transactions which maximize their profit. This makes the economic design and trust assumptions of decentralized rollups look very similar to L1s. As is already the case on L1s, we assume sequencers won’t order transactions themselves and will outsource this function via an auction to a 3rd party block builder, otherwise known as proposer-builder separation (PBS).

The censorship resistance properties of networks which rely on PBS for a majority of their block production is an active area of research. In any case, these networks will be much more usable and sustainable in the long-term than relying on a single, centralized actor.

Decentralization is The Rollup Endgame

Rollups should be decentralized by default.

Although rollups with a centralized sequencer are efficient, users make a significant trade-off trusting a single actor to act altruistically. Centralized rollups have achieved volumes that often exceed L1, and users have become accustomed to the UX and trust assumptions of centralized sequencers.

Today’s trusted sequencers have kept user funds safe despite opacity around the transaction lifecycle, but as the long-tail of rollups grows fatter, putting blind trust in less reputable parties will become highly risky. Decentralizing sequencers, sooner rather than later, is a necessary step towards alleviating this risk.

To continue this conversation, we will follow up with a piece on shared sequencers.