---
# System prepended metadata

title: 'Sequencing Series Part 1: Sequencing Overview'

---


<!-- # Abbreviations


| **Abbr** | Meaning                     |
| -------- | --------------------------- |
| **RU**   | Rollup                      |
| **ORU**  | Optimistic Rollup           |
| **ZRU**  | zkRollup                    |
| **L1**   | Layer 1                     |
| **L2**   | Layer 2                     |
| **DA**   | Data Availability           |
| **MEV**  | Maximum-Extractable Value   |
| **PBS**  | Proposer-Builder Separation |
| **Preconf**  | Preconfirmation | -->

# Sequencing Series Part 1: Sequencing Overview

Written by [Sam Battenally](https://x.com/sam_battenally), CEO at [RISE Labs](https://twitter.com/rise_chain), published 29 April 2024.



## Rollup Overview
Rollups are a way of reducing the resources and time required to validate transactions by reducing the amount of data each node needs to process. Rollups scale Ethereum by moving computations off-chain and only posting a summary of transaction data on-chain.

Rollup systems consist of several distinct components designed to deliver scaling benefits to blockchains.
* **Mempools.** Mempools are where users' transactions are sent to. Users can send their L2 transactions to the Sequencers' mempool or interact with L1 contracts for depositing, withdrawing or forced inclusion of their transactions.
* **Sequencers.** Sequencers are parties who continually fetch and finalize the order of incoming transactions from mempools into blocks (think block proposers in regular blockchains). Sequencers also create L2 checkpoints by posting the lastest state commitment (Merkle root) to the L1 rollup contract. 
* **Batchers.** Batchers roll up (i.e, compress) L2 transactions into batches and publish the batches to the L1 for data availability. A sequencer can also take the rollup of a batcher himself.
* **Proving System.** A Proving system is used to ensure invalid state transitions can be detected and prevented. Rollups are categorized based on different approaches to implement their proving system.
    * **Optimisitic Rollups.** The Proving system in optimistic rollups work in an optimistic way. Optimistic rollups assume state transitions are valid when published to L1, and impose a period in which anyone can challege the validity of the transitions. After the period, the transitions are finalized.
    * **zkRollups.** In zkRollups, the Proving system generates validity proofs for state transitions and submits these proofs to L1 along with new states.
* **Verifiers.** Verifiers dispute invalid state transitions when needed. 
    * In a ZRU, verifiers are incorporated into the Proving system. Verifiers are smart contracts on L1 which validate the correctness of validity proofs when new state are published.
    * In an optimistic rollup, verifiers can be anyone. They are incentivized to initiate dispute phases when they find an inconsistency in transaction batches. In return, they receive rewards for correct disputes.
* **L1 Rollup Contracts.** L1 Rollup Contracts function as a trust-minimized bridge between the L1 and the L2. Deposits, withdrawals and state changes are acknowledged and finalized in these contracts.


## The Power of Sequencers
[*Sequencers can be seen as the air traffic controller for the specific L2 ecosystem that they serves. So when Alice and Bob attempt to make a transaction at the same time, who comes first? That’s decided by the sequencers*](https://www.coindesk.com/tech/2023/09/06/everybody-in-blockchains-talking-about-sequencers-heres-why-theyre-misunderstood/). This is to say that sequencers are the most powerful role in a rollup design.


* **Provide fast preconfirmations.** Sequencers can provide their users fast soft confirmations on their transactions. Soft confirmations are promises such as users' transactions will be included, or promises on specific post-execution states.
* **Extract MEV.** Maximal Extractable Value (MEV) is defined as the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by arbitrarily reordering, including, excluding transactions in a block[^1]. Because the sequencers are the sole parties who can order transactions, they have unfair advantages over others in extracting MEVs. MEV has a significant impact on the Ethereum economy. In fact, solving the MEV issue remains a crucial part of the Ethereum roadmap[^2].
* **Front-run users’ transactions.** Sequencers can order the users’ transactions in such a way that their can profit themselves (e.g, front-running, sandwiching).
* **Increase rollup costs.** As sequencers are sole entities who can create blocks, they can rationally adjust the price for including users’ transactions. At some points, this price could be reasonably high.
* **Censor users’ transactions.** Sequencers can go offline completely, or refuse to produce blocks that include certain transactions in them. If an exploit occurs, all transactions processed by the sequencer could be compromised. The only thing users can do is to withdraw their funds out of RUs and stop using the services. If there are *multiple independent* sequencers, the risk of censorship should reduce.
* **Produce invalid states.** This is only possible within an optimistic rollup. Because optimistic rollups assume off-chain transactions are correct, sequencers may publish an invalid state transition to L1. If this goes unnoticed, the sequencers can steal users’ funds. This is the main reason why current these rollups impose a long challenge period for fraud detection.

# Types of Sequencing
## Centralized vs Decentralized Sequencing
Most of rollups on Ethereum today have centralized sequencers. These sequencers are ofter operated by the rollups' team or reputable organizations. Centralized sequencers offer high performance, high throughput, low latency, and fast preconfirmation to users. However, they serve as a single point-of-failure, the rollups will stop progressing if their sequencers are offline. Furthermore, operating in a centralized manner means that these sequencers might have comply with governments' rules, sanctions, etc,. Therefore, they might compulsorily censor users' transactions. 
* In fact, despite being the most decentralized blockchain, Ethereum is also censoring users' transactions at some degree due to its highly centralized PBS.
![image](https://hackmd.io/_uploads/BJF-CgUW0.png)
***Figure.** OFAC Compliance State of Ethereum's PBS (snapshot on Apr 24th 2024). Given these numbers, a transaction from a sanctioned entity only has around 20% of being included in blocks[^4]. (source: https://censorship.pics/)* 
* A centralized sequencer usually takes all of these roles. Thus, the chance of censorship is relatively high.

One way to improve censorship resistance is to replace the centralized sequencers with a decentralized sequencers. Instead of whitelisting sequencers, decentralized sequencing allows anyone to become a sequencer. Transaction ordering is guaranteed by a consensus among sequencers.

* **Siloed Sequencers.** A siloed sequencer orders and executes transactions as a centralized sequencer. States are then agreed by other sequencers via consensus before publishing to L1. This requires heavy sequencer nodes, slower consensus (and thus slower preconfirmations).
* **Modular Sequencers.** A modular sequencer orders transactions but does not executes them. Separating ordering and execution allows for lightweight sequencer nodes, faster consensus (and thus faster perconfirmations). However, because modular sequencers do not execute transactions, they cannot provide complex promises such as post-execution state preconfirmations.

Either way, decentralized sequencing offers better liveness and censorship resistance.

***Table.** A comparison of centralized and decentralized sequencing*
|  | Centralized  |Decentralized   |
| -------- | -------------|-------------- |
| **Performance**   | Higher|Lower|
| **Liveness**   | Lower|Higher|
| **Censorship Resistance**   | Lower|Higher|
| **Complexity**   | Lower|Higher|
| **Preconfirmation**   | Faster but weaker guarantee|Slower (due to consensus between sequencers) but stronger guarantee|

## Shared vs Non-shared Sequencing
In the architecture of today L2s, sequencing is specific for one specific rollup. Different rollups only share the same L1 infrastructure. Outside of this, different rollups have different sequencing strategy, different execution environments. Communications between rollups are done in an asynchronous way, in which rollup A must talk to L1 first, and then L1 will relay the message to rollup A later. Note that the process might not be atomic (e.g, the message from A -> L1 succeeded but the message L1 -> B failed). Another issue is fragmentation. Because there are multiple rollups, liquidity must be spread accoss rollups making it inefficient. A dApp must also run its services across rollups leading to high infrastructure costs. 

Shared sequencing, [introduced by Espresso](https://hackmd.io/@EspressoSystems/EspressoSequencer), flips this. Shared sequencing allows multiple rollups to share the same set of sequencers eliminating the hassle of rollups figuring out how to instantiate their sequencers. Shared sequencers usually operate on a decentralized network of nodes which requires consensus between them.

![image](https://hackmd.io/_uploads/Skt7yMLZ0.png)
***Figures.** An example of shared sequencing. Users from different rollups can send transactions to the same set of sequencers. Sequencers then order these transactions into a block a publish it to the data availability layer. The block might contain transactions from different rollups. Each rollup execution client, upon seeing new blocks, derives its related transactions and executes them. (source: https://docs.astria.org)*

Shared sequencing operates in a modular way in which sequencers order transactions but not execute them. Instead, execution is performed by rollups themselves. Shared sequencers collaborate to order and batch transaction data. Each batch is labeled with the corresponding rollup it's designated for. After the shared sequencers commit to a batch, the data undergoes execution by rollup execution clients.

Joining a shared sequencing ecosystem offers rollups some great benefits.
* **Free Decentralization.** Rollups can dedicate their resource to optimize their execution clients without worrying about bootstrapping their sequencers. Decentralize the sequencers is a complicated and difficult task that Arbitrum and Optimism still choose to keep their sequencers in-house.
* **Synchronous Composability.** Because sequencers order transactions from different rollups, they have the power to include or not to include transactions from these rollups in the same block. This is called ***atomic-inclusion***. Therefore, cross-rollup messages are made easier and more efficient. For example, one could buy ETH on rollup A using USDT on rollup B in a synchronous way. This is a promosing solution to the growth in fragmentation across the rollup ecosystem today. 

Rollups also have reasons not to join a shared sequencing network.
* Joining a shared sequencing network means that the rollup itself must give up the MEV to the shared sequencers.
* Existing, prominent rollups with large engineering teams, they may explore other ways to decentralize on their own sequencer in order to preserve the maximum amount of fees.
* There might be conflicts of interest between rollups when using the same shared sequencers.
* A few large parties to control sequencing creates centralization and the potential for exploitation. If these parties collude, they could hold all rollups in the ecosystem hostage.
* Global composability requires global sequencers and provers to simulate and fit everything together.
    * Atomic inclusion ensures that cross-rolup messages are guaranteed to fully be included or neither gets included in blocks. However, it makes little sense in most cases. What we ultimately want is the guarantee that these messages are either successfully processed or neither gets processed (***atomic execution***). The naive solution is to have the sequencers run full nodes on both rollups.
    * Consider the swap example above where one buys ETH on rollup A using USDT on rollup B. Atomic inclusion promises that transaction burning USDT on B and transaction buying ETH on A are either both included or none gets included; however, there are cases where both transactions are included, but the transaction on B is successful while the one on A reverts. Atomic execution promises that both transactions are either sucessfully processed or both revert. The later promise is stronger.

Rollups should ask themselves whether they should share the sequencers and argues that diversity and independence are better for the rollup ecosystem and their economics. 

***Table.** A comparison of shared and non-shared sequencing*
|  | Non-shared  |Shared   |
| -------- | -------------|-------------- |
| **Execution Layer**   | Sequencer| Rollup Execution Client|
| **Consensus Layer**   | Sequencer|PoS of Shared Sequencers|
| **Settlement Layer**   | Lower|Higher|
| **Composability**   | Asynchronous|Synchronous|
| **Preconfirmation**   | Easier, support complex preconfirmations|Harder, complex preconfirmations not supported|

## Based vs Non-based Sequencing
It is also possible to engage the validators of the L1 to sequencer a rollup to increase the sequencer’s decentralization and shared security with the L1. *A rollup is said to be based-sequenced, when its sequencing is driven by the base L1*[^3]. Based-rollups use the L1 as sequencers eliminates the need for additional security assumptions and ensures the same security strength for all components involved.


Ethereum currently provides settlement and data availability layers to rollups. These layers lay the foundation for rollups to operate effectively on Ethereum’s decentralized platform. Based-sequencing aims at complementing the existing ones, offering a new resource that rollups can leverage to further optimize their operations. Based-sequencing enables [*"United Chains of Ethereum"*](https://www.youtube.com/watch?v=4v_nSddO-24), where users can move between different rollups with ease.

<!-- Ethereum nowadays functions as a shared sequencer for all applications and rollups, allowing for atomic execution promises and more value from shared infrastructure. However, Ethereum's shared sequencing is not optimized and operates on a delay.  -->

Following are some advantages of based-sequencing. 
* **Decentralization.** Based-sequencing inherits the decentralisation of the L1 and naturally reuses L1 searcher-builder-proposer infrastructure. L1 searchers and block builders are incentivised to extract rollup MEV by including rollup blocks within their L1 bundles and L1 blocks. This then incentivises L1 proposers to include rollup blocks on the L1.
* **Liveness.** Based-sequencing enjoys the same liveness guarantees as the L1.
* **Simplicity.** Based-sequencing is maximally simple; significantly simpler than even centralised sequencing. Based-sequencing requires no sequencer signature verification, no escape hatch, and no external PoS consensus.
* **Censorship Resistance.** Based-rollups are sequenced by L1 validators, therefore, they inherit the level of censorship resistance of L1.
* **Cost.** Based-sequencing enjoys zero gas overhead—no need to even verify signatures from centralised or decentralised sequencers. The simplicity of base-sequencing reduces development costs, shrinking time to market and collapsing the surface area for sequencing and escape hatch bugs.
* **L1 Economic Alignment.** MEV originating from based-rollups naturally flows to the base L1. These flows strengthen L1 economic security and, in the case of MEV burn, improve the economic scarcity of the L1 native token. This tight economic alignment with the L1 may help based-rollups build legitimacy.
* **Synchronous Composability.** Based-sequencing is usually shared sequencing. Therefore, it offers synchronous composability between rollups.

Interestingly, [in a recent discussion](https://youtu.be/lN5t3L3YDsI?t=639) about based and non-based sequencing, Justin Drake mentioned that Ethereum initially started with native based-sequencing but it did not work out so well, so they moved to non-based (centralized) sequencing. The shift from based to non-based sequencing was driven by three key reasons.
* **The ability to provide preconfirmations.** Based-sequencing at the time did not offer preconfirmations. Today, we have *(naive and on research)* [solutions](https://ethresear.ch/t/based-preconfirmations/17353) to preconfirmations, which is a major unlock.
* **The lack of MEV-protection**. Right now on Ethereum L1, we do not have MEV protection, users' transactions can easily be sandwiched. Centralized sequencing can provide MEV-protection for free (assuming that the sequencers are acting honestly).
* Centralized sequencing provided an additional layer of security.

The revival of based-sequencing is expected to introduce new paradigms for rollups and chain interactions, emphasizing seamless transitions and enhanced user experiences. While the path to based-sequencing is non-trivial and requires considerable R&D efforts, the Ethereum community is actively working towards this direction. We will dive deeply into the progress, technicalities, and challenges of based-sequencing in subsequent posts.

# Conclusion
Sequencing plays a vital role in rollup infrastructure, which is essential for the growing Web3 ecosystem. While many current rollups use centralized sequencing, there is ongoing exploration into decentralized, shared, and based-sequencing methods. Given the design space for sequencing is vast, we expect many experiments while the industry filters for the viable solution. 

# RISE Labs
RISE Labs is a research-first team committed to building the future of Ethereum scaling. The goal of the RISE Layer 2 stack is to build the most performant and interoperable EVM rollup. Follow us for more updates at [@rise_chain](https://twitter.com/rise_chain).


# References
[^1]: [Maximal Extractable Value (MEV)](https://ethereum.org/en/developers/docs/mev/) 
[^2]: [Ethereum Roadmap](https://twitter.com/VitalikButerin/status/1741190491578810445)
[^3]: [Based rollups—superpowers from L1 sequencing](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016)
[^4]: In the PBS design, transactions are first sent to Builders, then sent to Relays and finally broadcast to Proposers. Within this path, the probability that a transaction from a sanctioned entity goes through is $0.3702 \times 0.5513 \times 0.9225 \approx 18.82\%$.
Of course the sanctioned entity can run a validator himself and adds his transactions to his proposed block, we do not consider this case here.