Intro to Sequencer Decentralization
The following post serves as an introduction to sequencer decentralization as I see it, and a few different projects and ideas for sequencer decentralization. Think of this post as some sort of beginner introduction to the various rollup ideas for sequencer decentralization.
What are Sequencers?
Sequencer decentralization is a major problem for rollup design. In a rollup system, the sequencer is responsible for executing transactions and rolling up multiple transactions into batches. Currently, almost all rollups have some centralized component, commonly the sequencer, which poses a risk for a fully independent and efficient blockchain because it acts as a single point of failure for the network. Decentralizing the sequencer is one step in a longer process towards achieving a fully decentralized rollup system, but it poses its own challenges and tradeoffs, such as potential loss of efficiency and the need to ensure proper liveness and security. Furthermore, not all rollups are the same, for some the sequencer shares the prover role as well, meaning that it is also tasked with proof generation. This is usually the case on zk-rollups.
There are a laundry list of problems and tradeoffs for sequencer decentralization. Most obviously, decentralizing an integral component of a rollup could lead to worse efficiency. Safety is a result of proper liveness and security. Proper liveness means that user transactions cannot be censored, and a centralized sequencer puts that liveness guarantee at risk. Now, censorship resistance can be achieved without decentralization, through a mempool where txs are invisible until a committed ordering; however, this leaves the problem of a sequencer shutdown. A sequencer shutdown can halt a blockchain and is therefore a poor situation.
Why decentralize the sequencer?
Centralized sequencers pose a risk for a fully independent and efficient blockchain because they act as single points of failure for a network. For example, back in January 2022, Arbitrum’s sequencer went down due to hardware problems, and thus the sequencer stopped processing new txs. Thankfully, this did not cause any lasting harm, as Arbitrum falls back onto using Ethereum’s sequencing upon sequencer failure. Nonetheless, a downed sequencer can mean disordered transactions and ruin the financial flow of the network. Sequencers can also submit full transaction data on-chain to Ethereum for storage. This allows for an alternative sequencer to retrieve the data and rebuild the L2 state (Paradigm).
As rollup technology progresses, decentralization remains an unanswered question. Decentralizing rollups still poses some risks as the underlying technology is still experimental. At Rollup Day, Vitalik gave a talk on this very subject and showed that a ZK-Rollup can have at least 34,000 lines of code. As this number broadens, the likelihood of an error occurring also grows. Hence the current justification for centralization in sequencers, if there’s no centralized backdoor there runs the risk of a million or billion-dollar loss happening, so naturally, there must be a way to reverse or intercept. It should not be understated that decentralizing sequencers is just one step in a lengthy process, as other components of a rollup like full nodes must also reach decentralization.
How can we decentralize the sequencer?
While there is no obvious solution present, and I doubt that there will be for quite some time, we can narrow down the desirable characteristics for decentralizing sequencers.
Hardware minimalistic (low barrier to entry)
Incentives balanced (deter bad actions through a reputation/slashing system)
Efficiency (maintain efficiency of the chain, specifically liveness and finality)
Answer MEV (where does MEV play a role?)
Answer sequencer coordination (if we have multiple sequencers, how will they coordinate with each other?)
Obstacles and Risks
Optimistic risks
Optimistic rollups, such as Arbitrum and Optimism, face a unique challenge in regards to sequencer decentralization. Unlike other rollup systems, optimistic rollups rely on fault proofs to challenge malicious or erroneous transactions in the transition state of the chain. Rollup nodes are incentivized to avoid false transactions with heavy fines, but, if one occurs the merkle root for the state of the L2 committed on the L1 changes.
This results in a backward model for the rollup. Here lies the possibility of a long finality time, where the transaction is not final until the challenge period is complete and the transaction is either included or challenged. This could be disastrous, as it would result in decreased throughput and would cause significant disruption to the network. Thus there are higher stakes for sequencer decentralization in the optimistic case because sequencers simply cannot afford to make a mistake.
ZK computation raises barriers
If you are unfamiliar, a zero-knowledge proof is a type of cryptographic protocol that allows one party (the prover) to prove to another party (the verifier) that they possess certain information, without revealing the actual information. This is accomplished by allowing the prover to interact with the verifier in a series of rounds, where the prover provides responses to the verifier's queries in a way that demonstrates their knowledge of the secret information, without revealing it directly. These are an integral part of zk-rollups (i.e. Scroll, zkSync, Starknet, etc).
For many zk-rollups, transactions must be batched and ordered by the sequencer and then validated by proof. Thus there’s an extra level to the job of the sequencer. Because proof generation is computationally expensive, there are specific hardware requirements in order to compute ZKPs. In some zk-rollups, i.e. Aztec or Polygon Hermez, this job is separated into two components, the sequencer and the prover. In this framework, the entry barrier is lowered for the sequencer; however, there still runs the problem of proof generation.
One of the main challenges in implementing zero-knowledge proofs is that they can be computationally expensive, especially for complex or large sets of information. This is because the prover must generate and provide responses to the verifier's queries in a way that is both convincing and computationally efficient. This requires a significant amount of computational resources, such as CPU and memory, in order to generate the necessary responses in a timely manner.
Proof generation causes a high entry barrier and real world infrastructural requirement for zk-rollups. This leads us into ZK-mining, an idea popularized by Paradigm, which is that because ZKP are costly to produce and have hardware requirements, decentralizing some ZK-rollups may look similar to some Proof of Work schemes from the past. While there are no L2s with the ZK-mining scheme implemented, there is an L1, Aleo, that encourages participants to mine ZKPs for its blockchain.
Ultimately though, I doubt that this will be employed in the short to medium term future simply due to how much this space changes, this model could meet obsolescence in an unknowingly short amount of time.
MEV Auctions, MEVA
In an MEV auction, the right to sequence transactions on a blockchain is allocated through a smart contract, where bidders compete to become the sequencer and extract the maximum value from the transaction. In other words, a single party can win this auction and gain all block rewards until their role is rotated out and the auction restarts. This deserves its own post in the future, same for the rest of these topics.
Experimental Consensus Mechanisms
Since there is no obvious solution to the problem of sequencer decentralization, various rollup projects are experimenting with different methods. These methods often involve a mechanism for choosing sequencer actors, either based on performance and efficiency or through a rotating staking mechanism. Below is a brief overview of some of the methods currently being pursued for sequencer decentralization.
Proof of Efficiency (MATIC)
The Polygon Hermez network uses two main actors, Sequencers and Aggregators, to batch and validate transactions. Anyone can become a Sequencer, as it is a permissionless role, but Aggregators must meet certain hardware requirements. Sequencers gather and batch valid transactions and pay a fee in $MATIC to the network. In return, they receive a portion of the fees paid by network users. Aggregators then produce validity proofs for the batched transactions and are rewarded with a share of the fees. The first Aggregator to produce a proof receives the largest portion, while the rest is distributed to the Sequencer. Late Aggregators are refunded their gas costs.
To incentivize honest behavior, Sequencers also have to pay both gas fees and an additional fee in $MATIC to propose valid batches and transactions. Aggregators compete to produce validity proofs, while Sequencers search for transactions to batch. Although Sequencers can coordinate in this model, this has not yet been accounted for. The model is designed for exchanges, wallets, and other applications that process many transactions. However, without coordination among Sequencers, some may waste gas by double-spending transactions, which can lead to potential problems for the network
In conclusion, the sequencer and aggregator roles for Polygon Hermez provide a mechanism for ensuring the correctness and availability of transactions on the L2 network. However, these roles may also create potential vulnerabilities and inefficiencies in the system if not implemented correctly.
Proof of Block Inclusion (OBX)
For those unfamiliar with Obscuro, it is a L2 rollup for Ethereum with a focus on privacy. It’s signature feature is its Trusted Execution Environment (TEE) that uses a hardware bunker within a computer to shield transactions. These transactions have their contents revealed at a later date. This allows for all sorts of tooling like GameFi lootboxes, better OTC trading, etc. However, for our purposes it uses the POBI method for sequencer decentralization.
Obscuro uses a decentralized consensus mechanism called Proof of Block Inclusion (POBI) specifically designed for L2 rollups. This protocol solves the problem of fair leader election, which is a fundamental issue that all decentralized rollup solutions must address. In a decentralized system, it is important to ensure that the process of selecting the leader or "sequencer" for each round is fair and does not give any one party an unfair advantage. POBI addresses this issue by using a lottery system to distribute the sequencer function among all active registered Aggregators. The protocol also synchronizes L2 round duration with L1 rounds to ensure that L2 finality depends on L1 finality. The Aggregator whose TEE generates the lowest random number from the group wins each round and is responsible for publishing the next rollup on the L1 blockchain. This process is repeated for each new round.
Sequencer Pool (METIS)
Community members can run peer-to-peer nodes that function as sequencers in rotation. These sequencers are typically by on-chain entities or Decentralized Autonomous Companies (DACs). The sequencer in rotation produces a block and then gossips to other peer nodes for auditing to prevent a single point of failure. One current challenge for Metis is that the sequencer peer node pool is small and the rotation period is currently long. Peer-to-peer nodes must fit the minimal hardware requirements as well and stake Metis tokens for incentivization.
Conclusion
In conclusion, sequencer decentralization is a major problem for rollup design and poses a variety of challenges and tradeoffs. Decentralizing the sequencer is important to ensure the safety and efficiency of a rollup network, but it is also a difficult problem to solve. While there is no obvious solution, different rollup projects are experimenting with various methods for sequencer decentralization. These methods aim to balance incentives, maintain efficiency, and address the issue of MEV. However, there are also obstacles and risks to consider, particularly for optimistic rollups. Overall, the search for a solution to sequencer decentralization is ongoing and will likely require continued experimentation and innovation.
Credits:
Credit to @kzdagoof from Curio for talking to me about sequencer decentralization in relation to optimistic rollups, there’s a lot more out of my scope than I think!
If you enjoyed reading this and it helped you understand the rollup world just slightly better, please consider sending a tip to Apollo’s study abroad fund (you don’t have to of course, no pressure!): 0x06a3190586aB2a9fCA1318f09EEf65A82eEC7a68