Original author source: helloyyy

I. Introduction

Time flies. It has been more than a year since Optimism issued its coin, and nearly half a year since Arbitrum issued its coin. Issuing coins is only the first step in their long journey. During this period, Optimism implemented the Bedrock upgrade and launched a general modular L2 stack OP Stack, based on which star Rollups such as Base were born. Arbitrum is committed to exploring L3 to promote the application of Arbitrum Orbit.

Led by the two giants, the TVL of the entire Rollup track once exceeded 10 billion US dollars, and is currently stable at around 10 billion US dollars. Although Rollup is talked about as Ethereum's "signature" expansion solution, they still have non-censorship-resistant and centralized attributes. Mainstream Rollup chains are generally operated by official centralized sorters. Although Arbitrum, Optimism, StarkNet and other Rollup projects have included the decentralization of sorters in their roadmaps, they are all in a state of not being realized in the short and medium term. As the most important piece of the puzzle for Rollup decentralization, the decentralized sorter has a very important strategic position for Rollup itself and is also what the people want.

2. Rollup transaction fees

Before understanding what a sorter is, let’s talk about the composition of Rollup transaction fees. Rollup transaction fees are the gas fees generated by users in L2 transactions such as Arbitrum.

It mainly consists of 2 parts:

1) L2 execution fees

2) L1 data charges

L2 execution fee: the cost of executing a transaction on L2 (each transaction initiated on the L2 chain is subject to an execution fee)

Transaction gas price = L2 base fee + L2 priority fee

L2 execution fee = transaction gas price * L2 gas usage

L1 data fee: The cost of publishing L2 transactions to L1. Typically, L1 data fees are higher than L2 execution fees.

L2 transaction fee = L2 execution fee + L1 data fee

Sorter’s net income = L2 transaction fee income - Sorter operating costs - L1 data fees

The centralized sorter operated by the project has a certain degree of pricing power (for example, the L2 execution fee is higher and the L1 data fee is higher), which is why several well-known Rollup projects are making a lot of money.

What is a sequencer?

The sorter, as the name implies, is responsible for sorting transactions. In the Bitcoin network, the responsibility for transaction sorting is the responsibility of miners; in Ethereum, it is the responsibility of the node collection. They are not fixed roles, but rather a consensus mechanism to determine who has the right to participate in sequential execution.

Currently, mainstream Rollups all run a centralized single sorter. The user's transactions in L2 enter the mem pool (at this time, the transactions in the mem pool are in an unordered state), and the sorter sorts and compresses the transactions into a set of ordered batches, and then sends them to the DA layer of Ethereum.

Does Rollup require a sorter?

The answer is no. Transactions on Rollup can completely bypass the sorter and be submitted to the L1 base layer, which will be responsible for sorting and settlement, but will also face higher gas consumption and longer transaction confirmation time.

The Rollup sorter is similar to using a "fast lane" to compress and aggregate hundreds of L2 transactions into a single L1 transaction, thereby greatly reducing gas costs. This is also the reason why the current mainstream Rollups all run centralized sorters, providing users with lower gas and faster transaction confirmation, thereby improving the user transaction experience.

3. Centralized Sorter vs. Decentralized Sorter

Centralization!

The advantage of centralization is very obvious. You can sort transactions however you want, without changing people to sort them, and without reaching a consensus on the sorting results. This means that transactions are confirmed very quickly, and the user experience is better; but centralization also gives the sorter great autonomy in transaction sorting. It can sort transactions arbitrarily to maximize its arbitrage opportunities, seize MEV value, delay user transactions, or even completely censor users.

The sorter can grab MEV value by changing the transaction order within a single block; what is more harmful is that because the sorter controls the order of multiple consecutive blocks, it is easy to execute cross-block MEV, resulting in a larger-scale attack.

The above situations are all malicious actions of the sorter. Some errors are not intentional by the sorter, but still damage the user experience and rights. For example, the sorter accidentally includes a spent token transaction in the soft commitment and then sends it to L1 for verification. There may be a situation where the transaction cannot be confirmed for a long time; another example is that a single sorter is offline, resulting in the inability of the second layer to produce blocks normally, and the network is down for a long time.

You can't have your cake and eat it too, but optimizing Rollup performance must not come at the expense of decentralization and censorship resistance.

Decentralization?

If centralization is 1, then decentralization is more. Different decentralized sorter solutions have different implementation paths, but their core concept is the same, which is decentralization.

The sorter no longer has the supreme right to sort transactions in a centralized manner. The role responsible for sorting is selected from a set of sorters based on a specific election mechanism and rotated at fixed intervals.

Decentralization prevents the sorter from continuously grabbing MEV, and also prevents a single sorter from reviewing the user's transactions. In addition, the corresponding penalty mechanism for malicious behavior can also effectively regulate the behavior of the sorter.

4. Overview of the decentralized sorter track

After going around in circles for so long, we finally get to the point. There are two types of decentralized sequencers: one is made by the Rollup project itself, and the other is implemented with the help of a third party. Implementing a decentralized sequencer with the help of a third party can actually be called Sequencing-as-a-Service.

Projects such as Espresso, Astria, SUAVE, Radius, etc. all focus on decentralized sorter solutions, and their implementation paths are different.

1. Espresso

Espresso Systems was originally a service provider focusing on privacy solutions. In March 2022, it announced that it had received nearly $30 million in Series A funding from Electric Capital, Sequoia, and Blockchain Capital. Espresso Systems has basically transformed into an Espresso Sequencer, specializing in providing decentralized sequencer services for Rollup.

Under the sorting mechanism of the Espresso sorter, the L2 transaction generally goes through the following life cycle:

1) The user's transactions on the second layer are sent to the Rollup server (API);

2) The transaction enters the mem pool, and the sorter (through HotShot consensus election) sorts the transaction and includes it in a block;

3) The sorter broadcasts the transaction, and after reaching a HotShot consensus with other nodes, the block is generated and the transaction is executed; soft commitment provides fast transaction confirmation;

4) The sorter sends the block commitment containing the transaction with a consensus certificate (QC: Quorum Certificate) and stores it in the L1 sorter contract (proving that the block has reached soft finality through consensus);

5) The Rollup node that has executed the block sends the new Rollup state to L1 (at this time, zkRU needs to be accompanied by a proof of validity, and ORU opens the challenge period);

6) The L1 Rollup contract checks the validity of the status update by verifying the QC sent by the sorter contract.

This process may seem obscure, but the simple understanding is:

The HotShot consensus selects one of the sorters from a group of sorters to be responsible for sorting Rollup transactions and including them in a block; this block must be signed by other Rollup nodes to reach consensus (more than 2/3 of the HotShot nodes agree) to be "final", and then the relevant block commitment and the new Rollup state root are submitted to the L1 base layer for verification.

The word "finality" above is in quotation marks. This "finality" in quotation marks is not the same as the finality without quotation marks. The "finality" in quotation marks is to make Rollup transactions confirmed faster, with less delay and better user experience; but Rollup transactions will eventually need to be verified by the L1 base layer (zkRU needs to verify the validity proof, and ORU needs to wait for the challenge period to end). When the transaction submitted by Rollup is verified to be OK, the Rollup transaction will have real finality.

This means that if the L1 base layer verifies that the transaction is invalid, the related L2 block that has been produced will face rollback. Therefore, "finality" is to make the transaction confirmed quickly, and finality is to inherit the security of Ethereum.

  • Espresso + EigenLayer

Espresso solves the sorter rotation problem and the problem of determining the "finality" of transactions based on the HotShot consensus, and solves the sorter access problem by introducing EigenLayer.

EigenLayer's re-staking mechanism makes it possible for Ethereum stakers to become Espresso sequencers at the same time, providing security for HotShot consensus. In short, Ethereum node stakers can become Espresso Sequencer (ESQ) through EigenLayer's re-staking mechanism. While Ethereum stakers obtain PoS node benefits, they also capture the value of the second-layer MEV.

The potential benefits for ETH holders = node rewards of the native network + L2 EVM + node rewards of other PoS chains (using the EigenLayer re-staking mechanism). The triple buff greatly empowers ETH.

As a general decentralized sorter solution, Espresso's ecological cooperation projects include not only EigenLayer, but also Arbitrum, OP Stack, Caldera, AltLayer and other star modular projects.

2. Astria

Astria is positioned as a universal, permissionless, decentralized sorter, providing out-of-the-box shared sorter services for different Rollups. In terms of financing, Astria announced in April 2023 that it had completed a $5.5 million seed round led by Maven 11, with follow-up investors including 1 k(x), Delphi Digital, Lemniscap, Robot Ventures, etc. Although the scale of financing is not large, the lineup of institutions is very gorgeous.

  • Operation Mechanism

The operating mechanism of Astria decentralized sequencer is similar to Espresso Sequencer, and the purpose is to weaken the privileges of sequencers by delegating the right to sort transactions. Specifically:

For the rotation of sorters, Astria proposes two rotation mechanisms: simple leader rotation and Byzantine Fault Tolerance (BFT) consensus algorithm.

1) Leader rotation

The elected sorters form a set, and the sorter set takes turns to sort the Rollup transactions. This method prevents a single sorter from monopolizing the ordering rights of transactions for a long time, and to a certain extent solves the problem of continuous censorship of users.

2) BFT consensus algorithm

Similar to the leader rotation mechanism, the sorter whose turn it is has the right to be responsible for transaction sorting, but 2/3 or more members in the sorter set must reach a consensus on this sorting.

Both methods have their own advantages and disadvantages: the former has faster transaction confirmation speed, achieves fast block generation, and is close to the efficiency of centralized sorters. But the trade-off is that it is still difficult to constrain the sorter on its turn not to do evil; the probability of evil is lower when using BFT consensus, and it requires 2/3 of the sorters in the set to vote to reach a consensus before a block is generated. However, it takes a certain amount of time for consensus voting, which causes network delay problems.

3. SUAVE

SUAVE is a decentralized, plug-and-play shared sorter solution built by Flashbots. As a general solution, SUAVE can provide memory pools and decentralized block construction for any L1/L2. The difference between SUAVE and the aforementioned shared sorter design is that SUAVE Chain itself is an EVM-compatible chain that implements transaction sorting through block "bidding".

  • SUAVE Architecture

SUAVE's architecture consists of three core components: a universal preference environment, a best execution market, and decentralized blockchain construction.

1) Preferred environment

Preferences cover a wide range, from simple transactions to complex events. User preferences are reflected in the mempool in the form of transactions, and the preference environment acts as a public mempool to bring preferences together. The universal preference environment provided by SUAVE makes user preferences on multiple chains public and transparent, eliminates information asymmetry, and solves the problem of cross-chain MEV to a certain extent.

2) Execution Market

The execution market is a network of executors who monitor the SUAVE memepool and compete with each other. Competition drives them to provide the best execution for user preferences. It can be understood that all executors implement user preferences through "bidding" and return as much MEV generated by user transactions to users as possible.

3) Decentralized Blockchain Construction

Finally, based on the collected preferences and the best execution path, the decentralized block construction network includes them in the block, thus realizing the whole process of transaction discovery, transaction sorting, and block generation.

4.Radius

Radius is positioned as a trustless shared sorting layer. Different from the implementation mechanisms of the previous solutions, Radius enables an encrypted mempool to ensure that Rollup transactions are sorted trustlessly, thereby eliminating effective MEV and user transaction censorship.

In terms of financing, Radius announced in June 2023 that it had completed a $1.7 million Pre-seed round of financing led by Hashed, with follow-up investors including Superscrypt, LambdaClass and Crypto.com.

Decentralized sequencers based on consensus mechanisms such as Espresso and Astria have reduced the risk of MEV and censorship to a certain extent, but at the expense of network scalability and time efficiency, they have brought about certain transaction confirmation delays (consensus on transaction ordering is required). In addition, although transaction ordering is in a decentralized environment, since the relevant transactions of the mempool are transparent, the sequencer still has room to do evil and grab MEV. Radius encrypts the mempool, and the relevant transaction information is invisible to the sequencer, aiming to eliminate the problem of malicious MEV grabbing and transaction censorship by the sequencer from the source.

  • Technology Architecture

The Radius technical architecture can be divided into the following four functional layers: sorting layer (Radius), execution layer (Rollup), settlement layer and data availability layer.

1) Sorting layer

1. The user submits the encrypted transaction and proof to the sorter;

2. The sequencer verifies the proof and validates the transaction;

3. The sorter sorts the transactions, and the transactions cannot be decrypted before that;

4. The sorter builds a block;

5. The sequencer submits the block to Rollup for execution.

2) Execution layer

1. Rollup receives blocks from the sorter and executes transactions in the order provided;

2. Rollup submits the transaction status and status proof to the settlement layer.

3) Settlement Layer

1. The settlement layer receives the state and state proof from Rollup, and is responsible for verifying the proof and determining the finality of the transaction;

2. The sorting layer verifies that the execution matches the order.

4) Data availability layer

The data availability layer stores data and ensures that it is available.

  • Mempool encryption mechanism - PVDE

Radius uses a zero-knowledge proof-based encryption scheme called "Practical Verifiable Delayed Encryption" (PVDE) to create an encrypted mempool.

The specific process is as follows:

When a user submits a transaction to the sorter:

1. The user generates a time lock puzzle and a symmetric key;

2. The user uses a symmetric key to encrypt the transaction, and the encrypted transaction enters the mempool;

3. The sequencer sorts the encrypted transactions. The sequencer needs to unlock the time lock puzzle to obtain the decryption key;

4. The sorter calculates the order commitment before unlocking the time lock puzzle and submits the commitment to the settlement layer (used to verify that the sorter submitted the transactions to the Rollup in order).

  • Decentralized Sorter Solution

The encrypted mempool ensures that the sorter is trustless, but the risk of single point failure still exists. If a single sorter + encrypted mempool is run, sorter failure will cause network downtime. To solve this problem, Radius has proposed a variety of decentralized sorter implementation solutions, including secret leader election mechanism, sorter group sharding mechanism, etc.

Of course, Radius can also choose to refer to the sorter rotation mechanism of Espresso and Astria, while achieving decentralization and trustlessness of transaction sorting.

  • Block space optimization

Radius aims to achieve the goal of protecting users and maximizing Rollup profits through block space optimization. Rollup uses a first-come, first-served (FCFS) sorting mechanism. The advantage is that it can effectively prevent MEV, but the disadvantage is that the potential profits of block space auctions must be sacrificed.

In order to solve the above transaction ordering dilemma, Radius divides the block space into two parts: the top block space and the bottom block space:

The top block space is dedicated to user transactions, which are encrypted and eliminate transaction ordering manipulation, thereby protecting users from harmful MEV and censorship risks; the bottom block introduces an auction-based trading market where arbitrageurs can submit bundled transactions and their bids to the sorter, which will select the bundled transactions with the highest bid to be included in the block. This method can maximize Rollup profits.

The above are the current mainstream universal decentralized sorter solutions. For Rollup, there are multiple pros and cons to consider, such as whether to run a centralized sorter or a decentralized sorter? Integrate a third-party universal sorter solution or implement decentralization yourself? Which technology implementation solution should be used to achieve decentralized transaction sorting?

5. Game between Rollups

Tradeoff 1: Is it decentralized?

Optimism, Arbitrum, zkSync, Base and other major Rollups have made a lot of money by running centralized sorters. Decentralization will inevitably involve profit sharing when the right to sort transactions is decentralized. Without considering the increasingly fierce competition in the Rollup track, no one is willing to share this sweet cake. But if a Rollup takes the lead in launching a decentralized sorter, this may be a huge traffic entrance, forming a demonstration effect in the Rollup segment, thereby forcing other Rollup projects to decentralize their sorters.

Tradeoff 2: Integrating a generic third party vs. an in-house proprietary solution

Generally speaking, there are two ways to achieve decentralization in a sorter: one is to use what others have done; the other is to do it yourself. If third parties such as Espresso and Astria can provide Rollup with out-of-the-box decentralized sorter services, then Rollup itself can continue to focus on product differentiation and performance optimization to improve its core competitiveness; in addition, integrating general decentralized sorter solutions is also more conducive to interoperability, bringing more possibilities including cross-Rollup arbitrage. The disadvantage of this solution may be that it cannot effectively empower the native token of Rollup itself.

If Rollup uses an internal dedicated solution to implement a decentralized sorter, this is the most time-consuming and expensive solution, but it is indeed the most effective way to enable Rollup native tokens. For example, StarkNet project owners can require users to pledge protocol native tokens to become sorter collections to participate in Rollup transaction sorting, and charge a certain service fee, thereby realizing value accumulation.

Tradeoff 3: Which technical implementation should be used to achieve decentralized sorting?

As mentioned above, there are many technical solutions for implementing decentralized transaction sorting, including but not limited to solutions based on different consensus mechanisms, FCFS, block bidding, encrypted mempool, etc. Each technical implementation has its own advantages and disadvantages: the consensus mechanism will be limited by time efficiency, and the encrypted mempool cannot maximize the profit of Rollup, etc. Of course, you can also refer to Astria's fusion of 2 different technical implementation solutions. The trade-offs between various technical implementation solutions are issues that all Rollup projects need to consider carefully.

Conclusion

Although the current leaders of the Rollup track, Optimism and Arbitrum, have already issued tokens, this may just be a starting point, and the real competition may have just begun. At least from the current trend, decentralized sorters must be a battleground.

Zk-based Rollup projects are also quietly rising. In an increasingly competitive environment, a wrong step may cause irreparable losses. However, in the face of innovations that affect the survival of the project, Rollups have no choice but to follow the trend.

references

[ 1 ] Binance Research: Ethereum’s Rollups are Centralized. A Look Into Decentralized Sequencers

https://www.binance.com/en/research/analysis/ethereums-rollups-are-centralized-a-look-into-decentralized-sequencers

[2] Espresso HotShot: Consensus Designed for Rollups

https://medium.com/@espressosys/espresso-hotshot-consensus-designed-for-rollups-b080ba7362d1

[ 3 ] Based rollups—superpowers from L1 sequencing

https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016 

[ 4 ] Introducing Astria: The Shared Sequencer Network

https://blog.astria.org/introducing-astria/

[5] Introducing the Astria Development Cluster

https://blog.astria.org/introducing-the-astria-development-cluster/

[6] Why Decentralize Sequencers?

https://blog.astria.org/why-decentralize-sequencers/

[7] IOSG explains SUAVE: A new decade of MEV scale-up

https://foresightnews.pro/article/detail/24673

[8] The Future of MEV is SUAVE

https://writings.flashbots.net/the-future-of-mev-is-suave/

[9] Radius Gitbook

https://docs.theradius.xyz/overview/introduction-to-radius