Preface
Sequencer is one of the core components in the Ethereum scaling solution known as Rollup. It is responsible for ordering transactions and performing tasks such as block creation, transaction acceptance, transaction ordering, transaction execution, and submission of transaction data. With the continuous increase in Layer 2 solutions on the Ethereum network and the flourishing development of its ecosystem, the profitability models and centralization issues of Layer 2 are receiving increasing attention. In particular, within Rollup, how to achieve decentralization of the sequencer and the profit distribution mechanism of the sequencer have become hot topics of interest.
A sequencer, as the name implies, is responsible for ordering transactions. In the Bitcoin network, this task is handled by miners; in the Ethereum network, it is undertaken by a group of nodes. These roles are not fixed but are determined by a consensus mechanism that dictates who has the authority to participate in the sequential execution of transactions.
Currently, most mainstream Rollup solutions operate with a centralized single sequencer. Users' transactions on Layer 2 (L2) first enter the mempool (where transactions are unordered). The sequencer then orders these transactions, compresses them into a batch, and sends the batch to Ethereum's data availability (DA) layer.
Decentralized Sequencer can be implemented in two ways: one is developed by the Rollup project itself, and the other is through third-party services. When leveraging third-party services for decentralized sorting, it is typically referred to as Sequencing-as-a-Service. Currently, several projects focus on decentralized Sequencer solutions, including Espresso, Astria, SUAVE, and Radius. Although their implementation paths vary, the goal for all is to enhance the decentralization and reliability of sorters.
Under the Espresso Sequencer’s Sequence mechanism, L2 transactions generally undergo the following lifecycle:
Transaction Submission: Transactions occurring on the Layer 2 network are sent to the Rollup server via API by users.
Transaction Sequencing: Once transactions enter the mempool, the Sequencer sorts them using the HotShot consensus election and includes them in a block.
Transaction Broadcasting and Confirmation: The Sequencer broadcasts the sorted transactions, and other nodes reach consensus through HotShot before creating the block and executing the transactions. At the same time, a soft confirmation mechanism provides rapid transaction confirmation.
Block Commitment: The Sequencer sends the block containing the transactions and its consensus certificate (QC: Quorum Certificate) to be stored in the Layer 1 sorter contract, proving that the block has achieved soft finality through consensus.
State Update: Rollup nodes that have executed the block send the updated Rollup state to Layer 1. In the case of zkRU (Zero-Knowledge Rollup), a validity proof is required, while in ORU (Optimistic Rollup), the update enters a challenge period.
State Validation: The Layer 1 Rollup contract verifies the QC sent from the sorter contract to check the validity of the state update.
This process can be simplified as:
1.Transaction Sequencer and Block Creation: Among a group of Sequencers, one Sequencer is selected through the HotShot consensus mechanism to Sequencer Rollup transactions and includes them in a block.
2.Consensus and Block Commitment: The block must be signed and agreed upon by other Rollup nodes (at least 2/3 of HotShot nodes) to achieve "finality". Then, the block commitment and new Rollup state root are submitted to the Layer 1 base layer for validation.
3.Quick Confirmation and Finality: The term "finality" in quotes is used to allow Rollup transactions to be confirmed more quickly, reducing latency and enhancing user experience. However, Rollup transactions still need to be validated by the Layer 1 base layer (zkRU requires validity proof verification, ORU requires waiting for the challenge period to end). If Layer 1 validation finds no issues with the transactions, Rollup transactions achieve true finality.
4.Potential Rollback: If Layer 1 validation finds transactions invalid, the related already-minted Layer 2 blocks will face rollback. Thus, the quoted "finality" is for quick transaction confirmation, while true finality ensures the security inherited from Ethereum.
Astria aims to provide a general-purpose, permissionless decentralized Sequencer, offering an out-of-the-box shared Sequencing service for various Rollups.
Operating Mechanism
Astria's decentralized Sequencer operates similarly to the Espresso Sequencer, aiming to reduce the privileges of Sequencers by decentralizing the right to Sequence transactions. Specifically, Astria has proposed two rotation mechanisms for Sequencers:
1.Leader Rotation: This is a simple rotation mechanism where the leader role is rotated among Sequencers based on predetermined rules or time intervals, thus distributing Sequencing power.
2**.Byzantine Fault Tolerance (BFT) Consensus Algorithm**: This is a more complex and secure mechanism that allows consensus to be reached even in the presence of malicious nodes. Through this algorithm, multiple Sequencers participate in decision-making, ensuring the system can continue to operate normally despite a certain number of node failures or attacks.
Leader Rotation
A set of Sequencers is formed through an election process, and the Sequencers in the set take turns Sequencing Rollup transactions. This method prevents a single Sequencer from monopolizing the transaction sorting rights for an extended period and, to some extent, addresses concerns about continuous censorship of users.
SUAVE is a decentralized, plug-and-play shared Sequencer solution developed by Flashbots. As a general-purpose platform, SUAVE provides mempool management and decentralized block construction for various L1/L2 networks. Unlike traditional shared Sequencer designs, SUAVE Chain is an EVM-compatible chain that achieves transaction Sequencing through a block "bidding" mechanism.
SUAVE Architecture
The architecture of SUAVE consists of three core components: the Universal Preference Environment, the Optimal Execution Market, and Decentralized Block Building.
Preference Environment SUAVE's preference environment encompasses a wide range of needs, from simple transactions to complex events. Users' transaction preferences are reflected in the mempool in the form of transactions, and the preference environment acts as a public mempool aggregating these preferences. The universal preference environment provided by SUAVE not only makes the preferences of multi-chain users open and transparent, but also effectively reduces information asymmetry and alleviates cross-chain MEV issues to some extent.
Execution Market The execution market consists of a group of executors who are responsible for monitoring SUAVE's mempool and competing with each other. This competition drives these executors to provide the best execution plans for users' preferences. These executors can be seen as participants who fulfill user needs through a "bidding" process, aiming to return as much MEV as possible to the users.
Decentralized Block Building Finally, based on the collected preference data and the optimal execution paths, the decentralized block building network packages this transaction information into blocks, completing the entire process from transaction discovery and sequencing to block production.
Radius is positioned as a trustless shared sequencing layer. Unlike the implementation mechanisms of the previously mentioned solutions, Radius ensures that the Rollup transaction sorting process is trustless by introducing an encrypted mempool. This approach effectively eliminates MEV and user transaction censorship issues, thereby ensuring the fairness and transparency of transactions.
Although decentralized Sequencers based on consensus mechanisms, such as Espresso and Astria, reduce MEV and censorship risks to some extent, they often do so at the expense of network scalability and time efficiency, leading to transaction confirmation delays (due to the need to reach consensus on transaction sorting). Additionally, even though these Sequencers operate in a decentralized environment, the public and transparent nature of transaction information in the mempool still poses a risk of Sequencers maliciously extracting MEV. Radius addresses this by introducing an encrypted mempool, ensuring that Sequencers cannot see the transaction information, aiming to fundamentally solve the problems of malicious MEV extraction and transaction censorship by Sequencers.
Technical Architecture
Radius's technical architecture is divided into four main functional layers: the Sequencing layer (Radius), the execution layer (Rollup), the settlement layer, and the data availability layer.
1.Sequencing layer
a.Users submit encrypted transactions and their proofs to the Sequencer.
b.The sequencer verifies the validity of these proofs and transactions.
c.The sequencer sorts the transactions before decrypting them.
d.The sequencer constructs a block.
e.The sequencer submits the constructed block to the Rollup execution layer.
2.the execution layer (Rollup)
a.The Rollup receives the block submitted by the sequencer and executes the transactions in the specified order.
b.The Rollup submits the transaction state and state proofs to the settlement layer.
3.the settlement layer
a.The settlement layer is responsible for receiving and verifying the state and state proofs from the Rollup to confirm the finality of transactions.
b.The settlement layer ensures that transaction execution adheres to the order specified by the sequencing layer.
4.the data availability layer
Encrypted Mempool Mechanism - PVDE
Radius uses the zero-knowledge proof-based encryption scheme "Practical Verifiable Delay Encryption" (PVDE) to implement the encrypted mempool. This mechanism ensures that transactions remain encrypted during the sorting process, enhancing the security of transaction processing.
The specific process is as follows:
1.User Submits Transaction
The user generates a time-lock puzzle and a symmetric key.
The user encrypts the transaction using the symmetric key, and the encrypted transaction enters the mempool.
2.Sequencer Processes Transaction
The sequencer sequences the encrypted transactions but cannot obtain the decryption key until the time-lock puzzle is unlocked.
Before unlocking the time-lock puzzle, the sequencer computes an order commitment and submits this commitment to the settlement layer. This commitment is used to verify that the sequencer submitted the transactions to the Rollup execution layer in the correct order.
Metis is one of the first Layer 2 networks to implement decentralized PoS sorters, providing an important model for future development. This model not only achieves decentralization of the sequencer but also offers a decentralized Optimistic Rollup solution based on PoS (Proof of Stake). In this model, Metis’s decentralized PoS sorter includes three main roles: administrators, sequencers, and the PoS consensus layer.
In the traditional Rollup model, a single Sequencer, while effectively handling transactions and data, also centralizes power and may introduce various risks:
Operational Risk: If the Sequencer fails or is attacked, the entire system’s transaction processing can be disrupted.
Censorship Risk: The Sequencer can selectively process or reject transactions, potentially limiting user access to specific decentralized finance (DeFi) protocols or services.
Manipulation Risk: The Sequencer may prioritize its own transactions in Sequencing, gaining unfair advantages through increased transaction fees, i.e., maximum extractable value (MEV).
To address these issues, Metis has designed a decentralized Sequencer pool where multiple Sequencer nodes collaboratively handle transaction aggregation, sorting, and execution. This design ensures the fairness and transparency of the system:
Consensus Mechanism: More than two-thirds of Sequencer nodes must reach consensus on the state of each new block before the transaction batch is submitted to the Ethereum mainnet (L1).
Multi-Party Computation (MPC) Signatures: Before the transaction batch is submitted to L1, MPC signatures are used to verify the authenticity of the batch, ensuring data accuracy.
Advantages of Decentralized Sequencers:
Enhanced Security: By involving multiple nodes in decision-making, the risk of single points of failure is reduced, improving the robustness and security of the network.
Reduced Censorship and Manipulation Potential: The presence of multiple Sequencers makes it difficult for any single node to manipulate or censor transactions, protecting users' transaction freedom.
Stability and Redundancy: The smooth rotation of Sequencers supports network stability and minimizes the impact of failures or interruptions.
In Metis's decentralized Sequencer model, each node consists of several key components:
L2 Geth (including OP-Node): Responsible for transaction sorting and block assembly.
Adapter Module: Acts as an intermediary for interacting with other external modules (primarily PoS nodes).
Batch Proposer: Responsible for constructing transaction batches and submitting them to L1 after obtaining approval from multiple Sequencers.
PoS Nodes: Coordinate between Ethereum, the consensus, and the Metis layer, ensuring the secure locking of assets and rewarding validators.
Consensus Layer: Composed of Tendermint PoS nodes running in parallel with the Ethereum mainnet, ensuring operational efficiency without disrupting the mainnet's processes.
L2 Geth (including OP-Node)
The main code is https://github.com/MetisProtocol/mvm fork of optimism.
The main modifications are as follows:
1.Block Assembly: In mvm\l2geth service code, the applyTransactionToTip processing logic has been added to determine whether the current sequencer should assemble the current block.
2.Transaction sequencing: Modified the original op-node code to use the MPC consensus layer's adapter module to obtain the current sequencer’s position corresponding to the rotation list and block height, in order to check whether it is the current valid sorter.
Sequencer Rotation
1.The rotation information is sequenced in the L2 MetisSequencerSet contract and is controlled by the consensus layer (PoS nodes).
2.Each epoch, the consensus layer updates Sequencer information. After MPC signing, it initiates a transaction to update the Sequencer list in the contract.
3.Each epoch, Sequencers take turns based on the contract's Sequencer list.
4.Violations: If a Sequencer fails to act in time or produces erroneous transactions (e.g., two transactions with the same L2 TxID), the PoS layer will select a new Sequencer. This involves constructing a ReselectSequencer transaction and obtaining an MPC signature. The new Sequencer will initiate a transaction for the current TxID on L2 and also update the MetisSequencerSet contract {no penalty mechanism}.
5.Triggering Updates: When a regular transaction is received and the rotation interval is reached, the current regular transaction will be paused. The MetisSequencerSet.sol contract update transaction will be executed, and then the PoS layer will select a new Sequencer to execute the current regular transactions.
6.Joining: In the PoS contract deployed on L1, anyone can apply to become a Sequencer by staking Metis. When the limit is reached, applicants enter a waiting queue.
a.Receive an NFT: Applicants are given an NFT.
b.Direct transfers are prohibited. Transfers can be made through the LockingPool contract -> updateSigner to change the signer and transfer the NFT.
c.NFT Token ID: The token ID of the NFT corresponds to the sequence ID.
7.Replacement: When a Sequencer remains in an unhealthy state for an extended period, it will be kicked out and replaced by a substitute.
8.Exit:
a.Destroy the NFT
9.Update: Use the LockingPool contract -> updateSigner to change the signer and transfer the NFT.
10.Selection: Weighted random selection algorithm
MPC Module
Responsible for managing the entire lifecycle of multisignature keys:
1.Multisignature generation
2.Key resharing
3.Application signing
4.Deleting signatures
5.Providing support for the asynchronous use of multiple multisignatures
Processing Flow
Phase 1: Notify MPC Nodes to Prepare
Locally generate a random sessionID.
Use the keyGenPrepare command to broadcast the message to all MPC nodes via the P2P network.
Each MPC node, upon receiving the keyGenPrepare message, initiates its respective processing goroutine.
Check local data based on keyId to see if the TSS module has stored the corresponding MPC information for that ID.
If the data is in the READY state, return the data directly from storage without continuing the key generation process.
If data with a PENDING state already exists, return an error to avoid inconsistencies caused by concurrent execution of different key generation calls.
Establish P2P communication channels.
Return the keyGenReady message to the initiating node.
Phase 2: Start the keyGen Process
The initiating node waits to receive keyGenReady messages from all nodes.
Once the initiating node receives keyGenReady messages from all nodes, it broadcasts the keyGenStart message to all MPC nodes using the P2P network.
Upon receiving the keyGenStart message, each MPC node:
Locally constructs a LocalParty instance.
Begins receiving information from other nodes.
The development prospects for blockchain sequencers are full of exciting changes. As the blockchain ecosystem continues to evolve, sequencers will undergo a significant transition from centralized to more decentralized, efficient, and adaptable solutions. This transformation is crucial for improving the transaction efficiency, scalability, and security of the Ethereum ecosystem.
Decentralization is a core philosophy of cryptocurrencies. Through shared sequencing networks, economic mechanisms can effectively address issues of value accumulation and income distribution. As modular construction and development frameworks for sequencers become more mature, these technologies will become powerful catalysts for industry development, driving the blockchain ecosystem towards more innovative and efficient directions.
References