Translated by LC

Table of Contents

Intro

1. The State of Rollups and Open Challenges: Decentralizing the Sequencer

1-1. Centralization of Sequencers in Existing Rollups

1-2. Current Structure Poses Problems in terms of Censorship Resistance, MEV, Interoperability, and Composability

2. Exploring Solutions and Approaches to Decentralize Sequencers

2-1. PoA (Arbitrum) and PoS-based Consensus (StarkNet) Adopted by Major L2s

2-2. Emergence of New Alternatives: Based Rollups and Lazy Rollups

3. The Rise of Lazy Rollups and Shared Sequencer Networks

3-1. The Shared Sequencer Network: Middleware Blockchain for Transaction Ordering

3-2. Advancing the L2 Ecosystem with Shared Sequencer Networks

4. Key Projects: Espresso Sequencer, Metro, SUAVE, Radius

4-1. Espresso Sequencer: EigenLayer-Based Network Backed by Sequoia and Polychain Capital

4-2. Metro: Leveraging Celestia as a Decentralized Application (DA) Layer for Shared Sequencer Network 

4-3. SUAVE: A Universal Plug-and-Play Mempool and Decentralized Block Builder Solution by Flashbots 

4-4. Radius: Pioneering Korea's First Shared Sequencer Network

Closing

 

 

 

 

 

 

Intro

Arbitrum and Optimism have successfully demonstrated the potential of rollups as a viable solution for enhancing Ethereum's scalability. However, the next critical step is to decentralize the sequencer. While those outside the crypto industry might perceive us as a group of individuals fixated on decentralization for the sake of it, the practical advantages of decentralized networks are evident. This report aims to provide a pragmatic perspective by addressing 1) the challenges associated with centralized sequencing structures, 2) various types of decentralized sequencer systems, 3) the underlying principles and impact of shared sequencer networks, and 4) an overview of the leading projects currently engaged in their development.

1. The State of Rollups and Open Challenges: Decentralizing the Sequencer

1-1. Centralization of Sequencers in Existing Rollups

Before delving into the issue of decentralizing the sequencer, let's briefly recap the key components of a rollup. While there may be slight variations across different solutions, rollups generally consist of client software, an execution environment (VM), a mempool, an attestation system (for ZKRollup), and rollup contracts that reside on Layer 1 (L1). These components work harmoniously together to facilitate rollup operations.

To provide some context, let's examine the transaction flow within a rollup. When a user initiates a transaction using MetaMask, it is transmitted to the mempool, where a sequencer examines the transactions within that mempool. Currently, all rollups rely on a single sequencer, with the network's operating entity temporarily serving as the sequencer (e.g., Arbitrum - Offchain Labs, Optimism - OptimismPBC, and StarkNet - Starkware).

The subsequent steps vary based on the type of rollup employed. In the case of ZK rollup, a validity proof is generated (which triggers a state transition within the VM), followed by submitting the proof, along with the state root and calldata, to the L1 contract. L2 blocks are then produced. Once the data within the L1 contract is validated, the transaction is finalized.

In the case of Optimistic Rollup, after the sequencer selects the transactions, it generates an L2 block and publishes the state root and calldata to the L1 contract. Subsequently, a dispute time delay (DTD) period is introduced, allowing challengers to validate the transactions, which typically span 7-14 days. During this period, challengers attempt to execute the transactions off-chain and raise disputes if any issues arise. Conversely, if no issues are found, they proceed to write the state transition to L1 and finalize it.

1-2. Current Structure Poses Problems in terms of Censorship Resistance, MEV, Interoperability, and Composability

As previously discussed, the current structure of rollups involves each solution running its own client software, VMs, mempools, proof system (specific to ZK Rollup), sequencer, and L1 contract, with the sequencer role solely performed by the operating entity of the network. While this design offers notable scalability benefits, it also presents challenges in various areas:

• Censorship Resistance and Single Point of Failure (SPOF): Direct interaction with the L1 contract is costly and inefficient, leading to the use of sequencers to compress and batch the transactions in L1 contracts. Consequently, users rarely record their transactions directly in L1 contracts, except when transferring assets from L1 to L2. However, the situation differs when assets are bridged to L2. Since L1 does not track the state of L2, users moving assets from L2 to L1 must provide proof to ensure the validity of the transaction, and this cannot be accomplished by users alone. The sequencer is responsible for state transitions, such as withdrawals; hence, if the sequencer is unavailable, users are unable to withdraw their assets and L2 blocks stop generating (SPOF issues arise). ZK Rollups, including Starknet, are developing escape hatches to enable asset withdrawals even in the absence of the sequencer, albeit at a higher cost. While rollup sequencers cannot arbitrarily seize users' assets, it remains true that centralized sequencers are less resistant to censorship.
• MEV Monopoly: The presence of a single sequencer responsible for ordering transactions and generating L2 blocks creates a potential monopoly on Miner Extractable Value (MEV). This concentration of power exposes users to MEV attacks, where the sequencer can manipulate transaction ordering to its advantage.
  
• Interoperability and Composability: Rollups exhibit poor interoperability and composability due to their reliance on independent infrastructures, including sequencers, provers, and execution environments. Although they share L1 as a Data Availability (DA) layer, rollups exhibit limited interoperability and composability. Users often face the complexity and expense of using cross-sequencer bridges, while DeFi services struggle with fragmented liquidity.

To tackle these challenges, Optimism has introduced the Superchain structure. Within a Superchain, OPChains (L2) are interconnected, allowing for seamless interoperability and composability. This is achieved through the adoption of a shared cross-chain messaging protocol and OPStack, an open-source module. Moreover, the use of a shared sequencer among OPChains provides enhanced security, which is appealing to new L2 projects. However, it's important to note that limitations remain, particularly regarding interoperability and composability between Superchains and non-Superchains, indicating that this solution is not without its drawbacks.