L2 Sequencing

A centralized model where a single entity (often the L2 project team) has exclusive rights to order transactions and produce blocks. This is the most common model for early-stage rollups.

• Pros: Maximum performance and simplicity.
• Cons: Creates a single point of failure and potential censorship. Users must trust the sequencer's liveness and honesty.
• Examples: Most Optimistic Rollups (Arbitrum, Optimism) and ZK-Rollups (zkSync Era, Starknet) in their initial phases.

A permissioned or permissionless set of nodes that take turns or use a consensus mechanism (e.g., PoS) to order transactions. This distributes trust and reduces censorship risk.

• Mechanism: Sequencers may be selected via staking, voting, or a rotating schedule.
• Pros: Improved liveness guarantees and censorship resistance compared to a single sequencer.
• Cons: Adds latency and complexity; the set may still be permissioned.
• Examples: Arbitrum's planned decentralization, Metis's hybrid sequencer pool.

A model where the Layer 1 (e.g., Ethereum) block proposers directly act as the sequencers for the L2. Transactions are ordered in the L1 block they are included in.

• How it works: L2 transactions are submitted to a dedicated mempool or contract on L1. The L1 block builder orders them as part of L1 block construction.
• Pros: Inherits Ethereum's decentralization and censorship resistance. Eliminates the need for a separate L2 sequencer network.
• Cons: Higher latency and cost, as every transaction must be sequenced via L1.
• Examples: Optimism's "Superchain" vision with based rollups.

A neutral, external network that provides sequencing services for multiple, independent L2 rollups. It enables atomic cross-rollup transactions and shared liquidity.

• Core Idea: Decouples sequencing execution from rollup state execution.
• Pros: Enables seamless interoperability (atomic composability) across rollups. Can be more economically secure than individual sequencer sets.
• Cons: Introduces a new trust assumption in the shared sequencer network.
• Examples: Espresso Systems, Astria, Radius.

A critical safety mechanism that allows users to bypass a censoring or offline sequencer by submitting transactions directly to the L1 contract.

• Process: A user submits a transaction to an L1 "force include" portal. After a delay (e.g., 24 hours), it must be included in the L2 chain.
• Purpose: Ensures the L2 cannot be permanently censored, as the L1 acts as a final backstop.
• Limitation: High cost (L1 gas fees) and long delay make it impractical for regular use, but vital for security.
• Implementation: A standard feature in rollup designs like Arbitrum and Optimism.

A single, trusted entity (often the L2 project team) controls the sole right to order transactions before they are submitted to the L1. This model is common in early-stage rollups and provides:

• High efficiency and low latency for transaction processing.
• MEV capture by the sequencer operator.
• A centralization risk, creating a single point of failure and potential censorship. Examples: Many Optimistic Rollups in their initial phases, like early versions of Arbitrum One and Optimism, used this model.

A permissioned or permissionless set of nodes that collectively order transactions, often using a consensus mechanism like Proof-of-Stake. This model aims to:

• Eliminate single points of failure and reduce censorship risk.
• Distribute MEV among a broader set of participants.
• Introduce some latency and complexity compared to a single sequencer. Examples: Starknet plans to decentralize its sequencer, and Arbitrum has a Sequencer RPC open to multiple providers as a step towards decentralization.

Transaction ordering is delegated directly to the underlying Layer 1 (e.g., Ethereum) by using its block builders/proposers as the sequencer. This model:

• Maximizes credibly neutrality and censorship resistance by inheriting Ethereum's security properties.
• Eliminates L2-native MEV, as ordering occurs on L1.
• Can result in higher latency and costs as every transaction batch must contend for L1 block space. Examples: Optimism's "Based Rollups" initiative and Arbitrum's BOLD dispute protocol are key implementations of this concept.

A standalone network that provides sequencing services to multiple, independent L2 rollups (e.g., within a "Superchain"). This enables:

• Atomic composability across different rollups, allowing transactions to interact seamlessly in a single block.
• Efficiency gains through shared infrastructure and liquidity.
• Potential for new cross-chain MEV opportunities. Examples: Espresso Systems is building a shared sequencer, and the Optimism Superchain envisions using a shared sequencing layer for its OP Chains.

An architecture that separates the roles of transaction ordering (proposer) from block construction (builder), similar to Ethereum's PBS. This design:

• Allows for a permissionless marketplace of block builders who compete to create the most valuable batches.
• Aims to mitigate centralized MEV extraction and promote fair ordering.
• Is a complex, forward-looking design for maximizing decentralization. Examples: Proposed in research for future rollup designs, such as Espresso's HotShot consensus, which integrates with rollup provers.

A model where the right to order transactions is permissionless and determined by a decentralized protocol, such as proof-of-stake. This eliminates a single point of failure and censorship, aligning with Ethereum's trust-minimized ethos.

• Examples: Networks with a native token and validator set for sequencing (e.g., some optimistic and ZK rollup designs).
• Security Benefit: Removes reliance on a single operator, making the network censorship-resistant and liveness-fault tolerant.

A model where a single entity (often the core development team) has exclusive control over transaction ordering. This is the most common initial setup for L2s due to its simplicity.

• Trust Assumption: Users must trust the sequencer operator to include their transactions fairly and not to censor them.
• Risk: Creates a single point of failure; if the sequencer goes offline, users cannot submit transactions to the L2 without falling back to a slower, more expensive forced inclusion via L1.

The entity controlling sequencing can extract Maximal Extractable Value (MEV) by reordering, including, or excluding transactions within a block. This represents a significant economic and security consideration.

• Centralized Risk: A single sequencer captures all MEV, which can be a source of revenue but also a centralizing force.
• Decentralized Mitigation: Protocols like MEV-Boost on Ethereum or shared sequencer networks aim to democratize MEV extraction and redistribute proceeds.

A paradigm where an L2 (a 'based rollup') uses the underlying L1's block proposers (e.g., Ethereum validators) as its sequencers. Transactions are ordered directly in L1 blocks, inheriting the L1's full decentralization and censorship resistance.

• Mechanism: L1 proposers include L2 transaction batches in their blocks, eliminating a separate sequencing layer.
• Trade-off: Sacrifices some speed and cost efficiency for maximal alignment with L1 security and simplicity.