Sequencing Introduction
Sequencing in blockchain refers to the process of determining the order of transactions, which was traditionally handled together with execution within the execution layer. However, as rollup networks are rapidly growing and transaction volume and TVL increase, concerns about centralized sequencers are intensifying within the community, and projects specializing in sequencing are starting to attract a lot of interest.
Contrary to L1, L2 relies on the base layer for security, so even if the sequencer is centralized, significant issues such as fund exploits are not likely to occur from a network safety perspective. However, the biggest problem with a centralized sequencer arises regarding liveness. If a single sequencer goes offline due to hardware failure or a software bug, users cannot use the rollup network.
Of course, problems arising from liveness can be resolved by forcing transactions from L1 to L2 or by users submitting a Merkle proof through an escape hatch. However, these systems greatly compromise UX, and also many rollup networks still have not yet implemented such systems. Additionally, using a single sequencer could centralize MEV and undermine censorship resistance.
Various concepts and projects are being proposed to address these issues. These range from utilizing the participants involved in Ethereum block building (e.g., searchers, builders, etc.) for L2 sequencing as in 'based rollup' to introducing a new shared sequencing layer and employing a cryptographic scheme to sequence with a single sequencer or introducing a consensus mechanism for sequencing with multiple sequencers.
If a separate sequencing layer is introduced to the existing modular stack, transactions submitted by users will be turned into ordered blocks by the sequencer(s). Once this block is stored in the Data Availability (DA) layer, full nodes of the rollup network will verify and execute it (transaction lifecycle varies slightly by project). To expedite the process, a soft commitment method, which allows rollup's full nodes to retrieve blocks directly from the sequencing layer before the ordered block is finalized in the DA layer, could be also supported.
Here are some benefits of introducing a separate sequencing solution to the execution layer:
- Resolving liveness issues caused by a single point of failure
- Eliminating malicious MEV
- Enabling atomic composability across multiple rollups
- Providing soft finality guarantees
Of course, introducing a sequencing solution comes with certain tradeoffs. There is latency in executing transactions after waiting for the sequenced block to be finalized in the DA layer (which is why soft commitment exists), and inevitably, scalability may decrease if a consensus mechanism is introduced among multiple sequencers.
If you want to explore more about the concept of sequencing, here are some recommended reads:
- The Shared Sequencer by Maven11
- Sharing a Sequencer Set by Separating Execution from Aggregation by Evan
- The Definitive Guide to Sequencing by James Prestwich
- SUAVE, Anoma, Shared Sequencers, & Super Builders by Jon Charbonneau
- Shared Sequencing: Defragmenting the L2 Rollup Ecosystem by Espresso Systems
- Redefining Sequencers: Understanding the Aggregator and the Header Producer by NashQ
Template of Sequencing​
In the Modular Docs, we have described various sequencing projects according to the following points:
- Transaction Lifecycle
- Sequencing: How transactions are ordered, who produces a block, how sequencers reach consensus, etc...
- Data Availability: DA layers
- Use Cases: Examples of rollups that utilized the sequencing solution