[Infrastructure] Shared Sequencer Networks: Toward a New Value Distribution

Disclaimer: This post is for informational purposes only, and the author is not liable for the consequences arising from any investment or legal decision based on the information contained in this post. Nothing contained in this post suggests or recommends investing in any particular asset. Making any decisions based only on the information or content of this post is NOT advised.

TL;DR

1. The shared sequencing layer was proposed to address the challenge of a single sequencer, including limited L2 rollup revenue structures, transaction finality issues, and censorship concerns.
2. Projects implementing a shared sequencing layer include Espresso, Astria, and SUAVE, each with their own differences in how they distribute MEV value.
3. A vibrant rollup ecosystem is essential to ensure key use cases for the shared sequencing layer.

Sequencers play an important role in the L2 by bundling transactions submitted by users and ordering them for placement in blocks. However, there is still no common understanding of how sequencers work and their role, and there is an ongoing debate about how and to what extent sequencers should be decentralized. We need a deeper understanding of how sequencers work to find answers to these questions. In this article, I’ll share my thoughts on where the sequencer market is headed based on the discussions of how sequencers work.

1. Problems with a Single Sequencer

1.1 Limited revenue structure

Sequencers are responsible for bundling transactions submitted to the L2 and deciding which order to place them in blocks. Most rollup networks currently operate sequencers in a centralized fashion, as do other rollup networks such as Optimism and Arbitrum. To understand the power of sequencers, consider how MEVs are extracted. MEV is the revenue generated by including, excluding, and ordering transactions in a block, which can come in various flavors, including front-running and arbitrage. Sequencers responsible for ordering transactions in the L2 and submitting them in blocks are, therefore, fully authorized to extract MEVs. However, L2 networks use first-come, first-served (FCFS) transaction processing to prevent this kind of MEV revenue monopolization, so it’s not currently possible for L2s to extract MEVs. While FCFS transaction processing can be beneficial in terms of keeping transactions in order and preventing a single entity from monopolizing MEV extraction, it also makes it difficult for L2s to capture additional revenue. To understand this, let’s take a look at the L2 revenue model.

There are three main components to the cost of a rollup: First, the operational cost of processing the transaction. Second, the calldata cost of submitting the user’s transaction information (state root) to the settlement layer. Third, the additional cost of network congestion. And there are two ways that rollups monetize: First, the fees that users pay to have their transactions included in the block. Second, the additional revenue generated by MEVs. Currently, rollup networks limit MEV extraction, so in order to generate additional revenue, they need to either collect more fees from users or find ways to reduce operating costs.

Optimism currently submits over 90% of its transactions to the L1 network, demonstrating the difficulty of achieving profitability without MEV generation. Of course, the upcoming Cancun-Deneb upgrade later this year is expected to dramatically reduce the cost of writing L2 rollup data to Ethereum by introducing blobs. This new transaction type frees up to 0.5MB of additional block space per block. However, a single monetization model based solely on transaction fees is inflexible to market conditions, as fees are determined by demand. In addition, excessive network fees can make it difficult to attract more users. Therefore, it is important to explore different revenue models to ensure meaningful utility for L2 rollups is important.

1.2 Transaction finality issues

Using a single sequencer can also make it difficult to ensure transaction integrity. To understand this, let’s take a quick look at how a user creates a transaction on the Arbitrum network.

Users create transactions and submit them to the Arbitrum chain. The transactions are ordered by a sequencer in an FCFS manner and then submitted to a “state transition function” that audits for invalid transactions. Once the sequencer is satisfied that the transactions are in order, it writes the ordered transactions into a block on the L1 network. But here’s where things go wrong. When the transaction is sent from L2 to the L1 network, it is not immediately included in the block on the L1 network. So the sequencer provides a “pre-confirmation” (or soft confirmation) to let the user know that the transaction has been finalized on L2 before it is finalized on L1. However, if the sequencer crashes before this process is complete, the user’s transaction will remain in L2 without being finalized in L1. This makes it difficult to guarantee that the transaction is 100% complete. It is considered a major limitation of using a single sequencer.

1.3 Censorship concerns

Since many users rely heavily on the sequencer for transaction processing, it can be problematic if a single sequencer censors transactions. Of course, users can queue transactions manually, but this is expensive and adds about 12 to 14 hours of processing time to the sequencer. This is because the queues are intentionally staggered so that the reorg phenomenon — invalidating the transaction history of a connected block in the L1 network and rebuilding the block — does not adversely affect the L2. For example, on the Arbitrum chain, if a user does not submit a transaction through a sequencer but instead queues it directly using a method called forceInclusion, the processing time can be up to 24 hours. In such a rollup, it is difficult for users to submit transactions without using a sequencer, and censorship by a single sequencer is inevitable.

These problems have led some to argue for the need to diversify and decentralize sequencers. However, the reality is that decentralizing a rollup’s sequencer set is not easy since decentralizing transaction ordering, data availability (DA) layer commitments, and L1 transaction execution adds complexity. This defeats the purpose of L2, which is to maximize scalability. So how can we avoid the above problems without relying on a single set of sequencers? The concept of shared sequencers has been proposed as an answer.

2. Decentralized Sequencing Layer vs. Shared Sequencing Layer

Decentralized sequencers are run by several sequencers in a rollup network taking into account various factors such as clients, geography, and so on. On the other hand, a shared sequencer refers to one or more sequencers shared by all rollups. A shared sequencing layer is when a rollup network creates a sequencer that multiple rollup networks can share rather than decentralizing their own sequencers. When a decentralized shared sequencer is implemented, multiple rollups can use a decentralized set of sequencers, creating opportunities for cross-domain MEV creation. If a single sequencer goes down, other sequencers can continue to operate to provide completeness to users. A decentralized set of sequencers is also expected to have less censorship risk than relying on a single sequencer. Recently, we’ve seen a number of proposals for implementing a shared sequencing layer.

2.1 Espresso Sequencer

Espresso Sequencer is a project that aims to implement the aforementioned decentralized shared sequencer layer. Espresso’s Hotshot Sequencer Layer will be implemented in a way that applies the security of Ethereum by utilizing the ETH restaking feature of EigenLayer, which allows ETH tokens already staked on the network to be restaked into other protocols. It has three key components: enhanced security through EigenLayer, fast finality through the Hotstuff consensus algorithm, and rollup transaction execution through a proprietary L2 contract and Espresso DA layer. This configuration allows users to submit transactions to a rollup and have them processed by Espresso’s sequencer, which in turn improves the efficiency and reliability of the rollup.

Next, let’s look at how Espresso’s sequencers execute transactions. The Hotshot network, which is the sequencing layer being developed by Espresso, operates in a way that when a user submits a transaction to an L2 rollup, it is passed to Espresso’s set of sequencers instead of the rollup’s own sequencer. The HotShot sequencer sorts the transactions into blocks. The resulting block is returned to the L2 rollup, which uses it to update its state. The HotShot sequencer then sends a concise commit to L1 for this generated block. At this point, L1’s contract validates and stores the proof of the block commit it received. This process ensures the transaction order and maintains system stability. Espresso’s system plays an important role in increasing throughput and reducing latency by providing an external sequencing layer that can be used by rollups.

3. MEV Distribution: The Key Differentiator for Shared Sequencing Layers

Currently, many different projects are working on their own solutions for implementing a sequencing layer. While there is no consensus on a common sequencing layer yet, let’s take a look at what drives the implementation of a common sequencer set. Just as there are differentiators for sequencing layers, such as consensus algorithms and specific transaction flows, in this article, I’ll talk about MEVs that can be a differentiator for a shared sequencing layer.

As mentioned earlier, L2 solutions do not have a separate mempool because they follow FCFS transaction processing. However, introducing a shared sequencing layer enables interactions between multiple rollups, which can create new types of MEV. This creates new opportunities for MEV extraction, such as cross-domain MEVs and arbitrage opportunities. However, these opportunities are not necessarily a win-win situation. This is because, during the MEV extraction process, the sequencer may execute front-running, sandwich attacks, etc., to cause losses in user transactions. Therefore, even if the extracted MEV revenue is used to expand the ecosystem, many people believe it is wrong to profit from harming users. (Readers interested in learning more about the negative attacks that can occur during the MEV extraction process can refer to this article series.) For this reason, MEV extraction is viewed negatively in the Ethereum community. Offchain Labs, the core developer team behind Arbitrum, has even argued that MEV auctions themselves could pose a risk to the protocol.

Therefore, what can differentiate a shared sequencing network is how the MEV value is distributed. For example, SUAVE chooses to share MEV profit with the user who initiated the transaction. Conversely, Radius uses ZK encryption to protect users by preventing MEV extraction from the mempool. These different approaches illustrate the stance that individual projects take on MEV. It’s up to the sequencer networks to decide whether to block MEV extraction altogether, create a fair auction market to distribute MEV or distribute it fairly to all participants. However, this technical solution is only a partial solution to MEV. We need a social consensus on the use of MEV. The social consensus on MEV will likely depend on what values are emphasized rather than on technical solutions. This consensus will need to be organized in a way that generates meaningful revenue to be generated without harming users.

4. Looking Ahead: PBS at the Sequencer Level

Given the role of sequencers in the shared sequencing layer, it is likely that future discussions will evolve toward a structure similar to Ethereum’s proposer-builder separation (PBS) proposal. The PBS proposal seeks to provide uniform MEV profits among block validators by separating builders, the entities that arrange transactions, from proposers, the entities that execute them. With the exception of Astria, most current shared sequencing layer projects have a structure where the sequencer acts as both a builder and a proposer. However, this approach may limit the scalability of L2s.

By implementing a shared sequencing layer that separates the roles of builder and proposer, such as PBS proposals, sequencers can focus on transaction ordering and block building, while the actual execution of transactions can occur at each rollup network level. This simplification of the sequencer role can contribute to efficient operation and improved scalability. Therefore, we expect to see a shift toward separating the roles of transaction ordering and execution, even in shared sequencing layers, as with the PBS proposal.

5. Closing

In this article, I’ve discussed current trends in the sequencer market and what to expect in the future. However, the key factors I want to focus on are not how sequencers work or the importance of decentralization but rather 1) how L2 rollups will evolve and 2) the growing competition for MEV extraction. From this perspective, having a diverse rollup network for a shared sequencer layer will be essential for meaningful use cases. In the current situation where few L2 rollups exist, the opportunities for cross-domain MEV extraction are limited, making it difficult for the models proposed by Espresso, SUAVE, Astria, and others to have any practical meaning. Different application-specific rollup networks can only connect to the sequencing layer with their individual use cases when this premise is met. The discussion of how to redistribute benefits across protocols should take precedence over the discussion of the morality of MEV extraction, and a vibrant rollup network ecosystem is a prerequisite for this. I would like to conclude this article with the hope of a more vibrant rollup ecosystem.

All for Shared Sequencer Network

‍