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.

2. Exploring Solutions and Approaches to Decentralize Sequencers

Rollups, while utilizing a single sequencer, face challenges in terms of censorship resistance and single point of failure (SPOF) issues. Additionally, interoperability between rollups is hindered by each having its own sequencer and development environment. To address these concerns, the Ethereum and L2 communities are actively exploring potential solutions, and we will highlight some of the solutions that most standout.

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

Prominent rollup projects like Arbitrum and StarkNet have proposed different approaches to achieve sequencer decentralization, as outlined in their respective roadmaps:

• PoA (Proof of Authority): This method involves the formation of a group of reputable individuals/entities who take turns generating blocks. The specifics of how sequencing order is determined may vary across projects. While PoA offers more censorship resistance and is relatively easier to implement compared to a single sequencer model, it still falls short of complete decentralization. For instance, Arbitrum utilizes PoA and employs mechanisms such as the AnyTrust DAC or Validator Set for fraud validation. In this setup, the Sequencer Committee comprises reputable entities within the industry, and the power to elect and remove sequencers is vested in a DAO. Optimism has announced its plans to use a Multiple Sequencer module approach for sequencing OPChains within the SuperChain.
• PoS-based L2 Consensus + Leader Selection: This method combines permissionless PoS with rollups to achieve consensus on sequencer selection and local consensus, providing increased censorship resistance and network liveness compared to a single sequencer. It also improves the reliability of pre-confirmation (soft-confirmation) by going through L2 consensus before finalization on L1. However, due to its reliance on local consensus, interoperability and compatibility with other L2 solutions that do not participate in the consensus may be limited. The transaction flow in this type of rollup is as follows: 1) The leader proposes a block. 2) Sequencers participating in the L2 consensus protocol agree on the block. 3) Proof generation (specific to ZK rollups). 4) Writing of state root, calldata, and proof to L1. This approach is employed by StarkNet, where participants can stake $STRK to participate in consensus, similar to how Ethereum validators stake ETH. Malicious behavior or failure to produce a block can result in slashing risks, similar to Ethereum. Further details can be found in the "Starknet Decentralized Protocol" series. Alternatively, PoS protocols that select leaders without local consensus, such as Cosmos' Dymension, can also be designed.
• MEV Auction (MEVA): While no rollups have currently adopted this approach, it presents an intriguing concept. MEV Auction, or MEVA, was initially introduced in January 2020 at Ethresearch. The idea behind MEVA is to establish an auction system open to anyone, where the ordering of transactions is delegated to the auction winner, and the execution and creation of transactions are handled by L1 validators. This concept shares similarities with Ethereum's Proposer Builder Separation (PBS), which aims to separate block creation tasks into proposers and builders to decentralize MEVs. By utilizing MEVA, there is no need to build a sequencer, and MEVs are decentralized. The auction is transparently conducted through MEVA contracts executed by the block producers, with block construction (the opportunity to extract MEVs) prioritized for participants with the highest bid price. 

Source: Karl, "MEV Auction: Auctioning transaction ordering rights as a solution to Miner Extractable Value"

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

In addition to PoA and PoS-based local consensus, the Ethereum community is actively exploring new solutions to decentralize sequencers. Two notable alternatives that have recently gained attention are based rollups and lazy rollups.

• Based Rollups (L1-sequenced rollups): Justin Drake, a researcher at the Ethereum Foundation, introduced based rollups in his article "Based rollups—superpowers from L1 sequencing." Unlike traditional rollups that rely on separate sequencers, based rollups delegate the sequencing task to L1 proposers, builders, and searchers, hence the name L1-sequenced rollups. L1 searchers and builders include the rollup block in the L1 transaction bundle, while the proposer incorporates it into the L1 (refer to the figure below). Based rollups eliminate the need for signature verification, escape hatches, and PoS local consensus, making them easier to deploy, cost-effective, and enhancing liveness and decentralization to L1 levels. However, one significant drawback of this approach is that the pre-confirmation time for transactions, which is a key advantage of L2 solutions (around 1 second for Arbitrum), becomes equal to the L1 finality time (12 seconds for Ethereum), thus failing to address the scalability challenge. Therefore, while based rollups present an intriguing concept, their practical adoption is unlikely.

Source: Vitalik Buterin, Single-slot PBS using attesters as distributed availability oracle

• Lazy Rollups (Shared Sequencing): The concept behind lazy rollups is to take a more "passive" approach, where a block is initially created in the base layer or DA layer. In lazy rollups, the full nodes store the block's history, optionally apply a fork-choice rule*, execute a random transaction, and update the rollup state accordingly. Once the transaction is executed, the block header is generated and sent to light clients. Unlike other rollup types, lazy rollups do not have a separate mempool and sequencer. Instead, they share these components with other rollups. It is important to note that shared sequencers in lazy rollups do not validate transactions. As a result, lazy rollups need to establish a distinct mechanism for validating state transitions. Further details on this topic will be covered later.

*Fork selection rule: This algorithm ensures that nodes follow a canonical chain with a history of valid transactions. For example, in Bitcoin, the rule dictates that nodes follow the chain with the highest total difficulty.

Source: Evan, Celestia Forum, "Sharing a Sequencer Set by Separating Execution from Aggregation"

3. The Rise of Lazy Rollups and Shared Sequencer Networks

Lazy rollups have gained traction in the Ethereum community due to their long-term scalability advantages. To achieve widespread adoption and establish "on-chain is the new online," we will need hundreds of thousands or millions of rollups. For this to happen, rollups must be decentralized, cost-effective to build, and user-friendly. Additionally, the future of L2 solutions relies on enabling synchronization and collaboration between L2s to act as a single chain. The shared sequencer network used by lazy rollups makes this possible.

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

A shared sequencer network serves as an L2 middleware blockchain, comprising a decentralized community of sequencers. Rollups have the option to participate in this network and delegate sequencing tasks to external shared sequencers. These shared sequencers receive user transactions, organize them into batches (blocks), and record them in the base layer or DA layer. A transaction refers to the collective set of rollup and L2 transactions utilizing the shared sequencer network. Once a transaction is written to the base layer, each rollup follows these steps: 1) checks the fork selection rules of the shared sequencer network, 2) filters other rollup transactions, and 3) extracts and executes only the transactions relevant to its own rollup, validating them through validity proofs or fraud proofs and transitioning the state accordingly. After updating the state root, a header is generated and transmitted to the light client (refer to the figure below).

It is worth noting that this process operates in reverse order compared to existing rollups, where transactions are executed first and then written to the base layer. Such an arrangement becomes possible by decoupling transaction ordering and execution: the shared sequencer network focuses on block construction, similar to PBS's builder, while the actual transaction execution occurs within each rollup unit. As mentioned earlier in the context of lazy rollups, the shared sequencer network does not validate transactions. Consequently, rollups utilizing the shared sequencer network must establish a separate mechanism to validate state transitions.

Source: Evan, Celestia Forum, "Sharing a Sequencer Set by Separating Execution from Aggregation"

While some express concerns about introducing an additional layer to the modular stack, it is important to note that separating transaction execution from consensus significantly enhances the speed of consensus and is unlikely to introduce substantial latency in practice. The primary bottleneck for transaction finality resides in the computation phase, as nodes can bypass this process and solely agree on the transaction order. Furthermore, this structure also reduces the time required for pre-confirmation, resulting in an improved user experience for blockchain participants, as they receive a soft confirmation once their requested transaction is recorded in the base layer.

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

Shared sequencer networks have the potential to improve the L2 ecosystem by overcoming the limitations of rollups and introducing several key advantages:

• Enhanced interoperability between L2 solutions: With a shared sequencer network, cross-chain messaging and bridging become more cost-effective, efficient, and secure. By concurrently sequencing transactions from multiple chains to create a unified block, shared sequencers enable seamless cross-chain atomic swaps and the consolidation of fragmented liquidity across chains. This opens up new possibilities, such as cross-rollup DEX arbitrage, which are currently challenging to achieve. Unlike the current approach of building light clients and synchronizing with multiple consensus protocols, a shared sequencer network simplifies cross-rollup bridging. Moreover, shared sequencers enhance the security of bridging by simultaneously finalizing transactions between rollups. In the long run, the greatest competitive advantage of shared sequencers lies in their interoperability, potentially enabling the bridging of thousands or even tens of thousands of rollups.
•  Improved shared security and censorship resistance: When 10 rollups share a hundred sequencers, the overall network security and resistance to censorship improve significantly compared to a scenario where each rollup has only 10 sequencers.
• Simplified rollup development process: Establishing a decentralized sequencing layer poses substantial challenges for new rollups. Bootstrapping and managing sequencers can be time-consuming and costly. Furthermore, building a local consensus for sequencing further complicates the development process. However, by opting for a shared sequencer network, these hurdles can be circumvented. This approach, often referred to as "sequencing as a service" (SaaS) by Jon Charbonneau, streamlines the rollup development process.

DBA, a prominent crypto investment firm based in New York, has created an informative diagram highlighting the pros and cons of different sequencer solutions (refer to the diagram below). While centralized sequencers excel in scalability, they require trust in a third party. On the other hand, L1-sequenced rollups provide trustlessness and liveliness but face latency limitations. Arbitrum's decentralized PoA structure falls somewhere in between. In contrast, a shared network of sequencers maximizes efficiency with minimal trust. By allowing multiple sequencers to focus on arranging transactions rather than executing them, this approach offers robust security and fast pre-confirmation for users.

Source: DBA

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

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

Espresso Sequencer is an innovative shared sequencer network currently in development by Espressosys, a startup founded by Stanford University Computer Science PhDs Ben Fisch, Benedikt Bünz, and Charles Lu. With impressive support from renowned venture capital firms including Sequoia (AUM: $85B), Polychain Capital (AUM: $6.6B), and Greylock (AUM: $3.5B), the project has raised a substantial $32M in funding. The distinguishing feature of Espresso Sequencer lies in its utilization of ETH re-stakers as sequencers within the EigenLayer framework (for detailed information on EigenLayer, refer to Xangle Original, "EigenLayer, the Open Marketplace for Decentralized Trust"). This setup allows ETH validators to generate additional revenue on top of their L1 staking rewards by participating in Espressosys' Actively Validated Services (AVS). In return, Espressosys gains access to a large pool of ETH validators right from the outset, establishing a mutually beneficial relationship. On November 28, 2022, Espressosys successfully launched its initial Espresso sequencer testnet, Americano. 

The Espresso Sequencer encompasses the following:

• Hotshot: Espresso Sequencer's consensus protocol, based on the renowned Hotstuff protocol popularized by Aptos. Hotshot utilizes a three-phase commit process and incorporates techniques like Practical Byzantine Fault Tolerance (PBFT) and chaining to ensure rapid completeness, safety, and liveness while keeping network load low. Unlike Hotstuff, which has a fixed number of validators, Hotshot is permissionless, allowing anyone to join as a validator.
• Espresso DA: A Data Availability (DA) solution provided by Espresso, in which randomly selected sequencers in the network take turns forming a Data Availability Committee (DAC) to ensure the availability of data. The membership of the DAC members is rotated on an epoch or block basis.
• Rollup REST API: An API utilized by rollups participating in the Espresso Sequencer network.
• Sequencer Contract: A smart contract on the L1 (Layer 1) that validates Hotshot consensus and records checkpoints. This contract is separate from the L1 contract through which Rollups send call data, state transitions, and proofs.

Source: EigenLayer

Although Espresso employs ETH re-stakers as sequencers, it functions similarly to a conventional shared sequencer network. When a user initiates a transaction through the user client, the sequencer nodes exchange messages regarding the transaction and store them in the sequencer mempool. Through the Hotshot Proof-of-Stake (PoS) mechanism, one of the sequencers is elected as the leader node, responsible for selecting transactions from the mempool to form a block. Prior to finalizing the transaction on L1, the leader node shares the block with 1) rollup validators and transaction executors, 2) the Data Availability Committee (DAC) to obtain a DA certificate, and 3) the L1 sequencer contract to secure a commitment and quorum certificate validating the block.

Source: Espressosys

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

Metro is a shared sequencer network currently under development by Astria, a startup that has successfully secured $5.5M in seed funding from nine prominent venture capital firms, including Maven 11, 1kx, Delphi Digital, and Lemniscap. Astria has chosen Celestia as its DA layer and is actively constructing the Astria EVM, drawing inspiration from Cevmos and Rollkit. The operational mechanism of Metro closely resembles the shared sequencer network mentioned earlier, we will omit its detailed description in this section (refer to the figure below). 

Source: Astria, “Introducing Astria, The Shared Sequencer Network”

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

Before delving into the specifics of SUAVE (Single Unifying Auction for Value Expression), it is important to clarify that SUAVE is not a shared sequencer network. However, we have included it in this section because we believe there are structural similarities between SUAVE and a shared sequencer network, allowing for potential synergies between the two.

SUAVE is a shared mempool and block builder solution, as well as a permissionless EVM chain that can be utilized on any blockchain, regardless of whether it is Layer 1 or Layer 2. The SUAVE protocol comprises a messaging layer (SUAVE mempool) that disseminates and aggregates users' transactions, and a configuration layer (SUAVE chain) that organizes these transactions into blocks. When a blockchain adopts SUAVE, it can delegate two roles: 1) mempool (allowing users to utilize the SUAVE mempool instead of the blockchain's native mempool) and 2) block builder (where builders, following the Ethereum PBS design, can adopt blocks from SUAVE builders). SUAVE aims to provide builders/searchers with maximum MEV opportunities, validators with optimized block reward revenue, and users with protection against MEV attacks while minimizing gas costs for transaction execution. In essence, SUAVE serves as a multichain extension of the current MEV-boost service.

Source: Flashbots, “The Future of MEV is SUAVE”

The SUAVE process encompasses three phases: 1) Universal Preference (Transaction) Environment, which aggregates users' transactions from each chain; 2) Optimal Execution Market, which explores the SUAVE mempool to identify the most efficient transaction execution options for users; and 3) Decentralized Block Building, where block builders assemble these transactions to form blocks.

Source: Flashbots, “The Future of MEV is SUAVE”

Let's delve deeper into how SUAVE operates. Suppose SUAVE is utilized on the Ethereum network. Users will submit their Ethereum transactions to the SUAVE mempool. SUAVE builders then combine these transactions within the SUAVE chain to create an Ethereum block that maximizes MEV opportunities. Ethereum validators subsequently evaluate both the Ethereum builders' constructed block and the SUAVE builders' constructed block, selecting the one with a higher MEV to include in the Ethereum block. In essence, SUAVE presents additional choices for Ethereum validators. Similarly, SUAVE does not impose SUAVE blocks on rollups, nor does it require rollups to alter their fork selection rules. SUAVE simply provides sequencers with the block offering the highest MEV. This distinction highlights the difference between SUAVE and a shared sequencer network. From a rollup perspective, it may be feasible to leverage both SUAVE and a shared sequencer network. In such cases, the shared sequencer functions as a block proposer while SUAVE serves as a block builder.

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

Radius is a groundbreaking project that is spearheading the development of Korea's first and only Sequencing as a Service (SaaS) solution. The Radius management team comprises esteemed experts in blockchain and software development and their expertise has been acknowledged through funding from the Ethereum Foundation and a top 10 ranking in HackMoney 2022.

What sets Radius apart is its utilization of advanced technologies in the sequencing layer to ensure the privacy and validity of transactions. Radius guarantees secure and private transactions by implementing time-lock puzzle encryption technology and Practical Verifiable Delay Encryption (PVDE). technology, incorporating ZK proofs. The time-lock puzzle encryption technology ensures encryption and privacy until the moment a block is sent to the rollup, while the use of ZK proof verifies that the same symmetric key was used for the encryption and decryption of sequenced blocks. This prevents malicious users from encrypting transactions with invalid keys.

In addition, Radius has successfully launched its first SaaS solution, 360, an MEV-resistant decentralized exchange (DEX), on the Polygon network. 360° provides users with protection against MEV attacks, including frontrunning and sandwich attacks, and enables the smooth execution of arbitrage transactions. The success of 360° serves as a reference for rollups considering Radius' sequencing layer. Please refer to the roadmap below for future developments.

Source: Radius, “Sequencing Layer for Rollups”

Closing

To conclude, the current limitations of existing rollups in terms of censorship resistance, MEV, and L2 interoperability and composability stem from their reliance on a single sequencer. While these challenges may be less evident in the current nascent market with fewer rollups and less user demand, they could pose significant barriers to widespread blockchain adoption in the future. However, the industry is actively addressing these issues. Industry experts are engaged in discussions and developing decentralized solutions, among which shared sequencer networks hold great promise as a long-term solution. Over the next year, we can anticipate the rise of shared sequencer networks gaining momentum, with notable launches of mainnets such as Espressosys, Metro, SUAVE, and Radius. These advancements signal positive developments and inspire optimism for a more efficient and robust blockchain ecosystem.

References:

• https://hackmd.io/@EspressoSystems/EspressoSequencer
• https://blog.astria.org/introducing-astria/
• https://docsend.com/view/ybwgf63brvja82si
• https://joncharbonneau.substack.com/p/rollups-arent-real
• https://writings.flashbots.net/the-future-of-mev-is-suave/
• https://forum.celestia.org/t/sharing-a-sequencer-set-by-separating-execution-from-aggregation/702
• https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877
• https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788