Sequencers, Rollup's Achilles Heel?
The execution layers are as decentralized as its most centralized component - the Sequencer which is usually the centralized entity.
Index
Modular Blockchains
Role of the Sequencer
Typical User Flow for a Rollup Transaction
Risks Associated with a Single Centralized Sequencer
Shared Sequencers
Shared Sequencer Market landscape
Other interesting directions for sequencing
Conclusion and thoughts
Modular Blockchains
A modular blockchain architecture separates the different functions of block production, such as execution, data availability, consensus, and settlement. This allows different teams to focus on optimizing each function, leading to superior performance and experimentation at different layers of the stack.
Rollups are the scaling solutions from the execution point of view. The users submit their transactions and they get executed and batched together for scalability in speed and costs.
But modular blockchains don’t necessarily inherit the censorship resistance or liveliness of the L1 due to the presence of a centralized component that orders and builds blocks for the transaction - the sequencer. Rollups consist of several distinct system components:
A virtual machine (VM)
A sequencer
A proving system (for zk-VMs)
A rollup contract on the L1 blockchain
Let us talk a little bit about the role of a sequencer in the rollup.
Role of the Sequencer
In a rollup, the sequencer orders or sequences the transactions and has the power to censor, include, and change the order of the transactions.
The sequencer introduces the idea of separation of execution and ordering. The sequencer only does ordering, while the execution is left to the rollup nodes. This allows the sequencer to focus on less operationally intensive tasks and scale to multiple rollups.
But from a point of view of the roles on the L1, the sequencer also acts like the proposer and builder - since it orders the transactions and then sends them to the DA layer where they are considered final for the rollup. PBS was a way to address these concerns on the L1s, by introducing the relays and ensuring that the block building and proposing were separated for reducing the power over the block building. Similarly, there are efforts to separate the roles of ordering and proposing rollup blocks.
Typical User Flow for a Rollup Transaction
Here is a typical user flow for a rollup transaction:
The user submits the transaction to their wallet.
The wallet interacts with an RPC node and submits the transaction to the rollup's mempool.
The sequencer orders the transactions, locally executes them using the VM, creates a block, and provides soft finality to the user. The sequencer also posts the batch on the data availability (DA) layer.
The rollup nodes pick up the data from the DA layer, execute it, and use a proof system to generate a proof along with the state roots.
The transaction is posted on the L1 smart contract and gets finalized.
The user receives hard finality.
Risks Associated with a Single Centralized Sequencer
A centralized sequencer is a single entity that is responsible for sequencing transactions and producing blocks. This presents several risks, including:
Single point of failure: If the sequencer goes down, the entire network is halted.
Centralized control: The sequencer has a great deal of control over the network, which could be used to censor transactions, block users, or take over the network.
Lack of transparency: The sequencer is not transparent, making it difficult to trust or identify and fix bugs.
Communication between the rollups without Shared Sequencer
Currently, each rollup has all its components including its sequencer. In the absence of shared sequencing, applications on the rollups are not their best versions. There are increased costs, low latency, increased complexity, and fragmented liquidity for Defi applications. A shared sequencer eliminates these performance limits so applications can truly scale.
Shared Sequencers
A shared sequencer can be run like a middleware blockchain with a decentralized sequencer set. The transaction originates from a wallet, communicated to a rollup node, post which it waits in a shared mempool. The searchers build bundles that are batched together in a block by builders and passed on to the Shared sequencer for proposing. The sequencer gives soft finality to the user via the rollup RPC node and waits for a hard finality by posting the data on the DA layer. This is similar to a PBS mechanism in ETH.
Every rollup has decentralization of the sequencer on its roadmap. But it is difficult to get there on their own. A shared sequencer is a solution that could outsource the decentralization of sequencers and block building away from the rollups, allowing them to focus on execution. Along with the risks of centralized censorship, with an increase in the number of rollups and rollup SDKs, composability and atomic transactions become a problem to be tackled. Only a decentralized solution helps with the censorship problem, but not for the interoperability between the rollups.
Reduced time and cost for bootstrapping validator set: Bootstrapping a validator set can be costly and time-consuming effort for the rollups, shared sequencer provides this specialized service.
Reduced rollup complexity: Shared sequencing reduces the overall complexity of the rollup, making it easier to maintain and upgrade the rollup over time. Implementing the sequencing layer is a simple process of plugging in and swapping out necessary components.
Enhanced cross-rollup interoperability: Cross-rollup bridging and transaction verifications can be complex when rollups use different sequencers. Right now the rollups have to run light clients on both chains for verifying the sequencing and execution of the transactions. The rollups can instead refer to the shared sequencer for the global ordering of the txns.
The costs for verifying the txns ordering and finality for the other rollup in case of a cross-rollup transfer could also be saved.
In the case of cross-rollup transactions, the finality depends on both the consensus protocols for each rollup. If instead we use a shared sequencer, the time for finality would be shared as well.
Shared Sequencer Market landscape
Astria - Astria replaces centralized sequencers, allowing many rollups to share a single decentralized network of sequencers that’s simple and permissionless to join. This shared sequencer network provides out-of-the-box censorship resistance, fast block confirmations, and atomic cross-rollup composability – all while retaining each rollup’s sovereignty. Astria is also building AstriaEVM that would be the first rollup to use Astria’s Shared Sequencer.
Radius - Radius employs a unique zero-knowledge cryptographic solution called PVDE (Practical Verifiable Delay Encryption) to prevent the centralized sequencer from exploiting its reordering power and building a profitable block. First, when users submit transactions, their transactions are automatically encrypted while the sequencer sequences them. The zk-proven encryption ensures that the sequencer cannot view the contents of the transactions before sequencing them, preventing them from manipulating the transaction order for their benefit.
Espresso system - Espresso Sequencer supports the decentralization of L2s. It handles the decentralized sequencing and data availability of rollup transactions, functioning as middleware between rollups and their underlying layer-1 (L1) platforms. Espresso system has some unique components like Hotshot consensus for fast finality, Espresso DA that has DAG-based mempools. Espresso systems also use ETH restaking for their middleware for enhanced validator guarantees.
Madara - Starknet is also jumping on the app chain-rollups-stack race with their L3s that use Starkware for their settlement. Madara is a sequencer from the Starknet and LambdaClasss team. It is built with a substrate framework with a CairoVM for the creation of provable programs. Madara offers the flexibility to switch between two execution crates, blockifier by StarkWare and starknet_in_rust by LambdaClass. Since the settlement layer for Madara would be the Starkware L2, it would lead to faster soft and hard finality. Madara also provides customization in FCFS, PGA, or more complex schemes like Narwhall & Bullshark for its
SUAVE - SUAVE is a permissionless EVM chain that acts as a universal sequencing layer for all blockchains. Suave is creating a marketplace for the expression of intents/ preferences which are taken up by sophisticated solvers that try to find the best way to translate that into a transaction. Post that there is a shared sequencer for different blockchains and rollups to submit their transactions and get atomic cross-rollup transactions.
Other intersting directions for sequencing
L1 sequencing for L2 transactions! Does it make sense?
That’s right! This is was proposed by Justin Drake’s and called “based rollups.” He uses the term to refer to rollups whose sequencing is driven by the L1 (the “base” layer). L1 proposers would simply make sure to include rollup blocks within their own L1 blocks (presumably via builders). It’s a simple setup that offers L1 liveness and decentralization off the bat. They get to sidestep tricky problems like solving forced transaction inclusion in the event that L2 sequencers are censoring. Additionally, they remove some gas overhead as no sequencer signature verification is required.
These blocks could be sent to the L1 mempool where users would lose on the soft confirmations or there could be a new P2P mempool.
Out of the box - The Distributed Sequencer
Inspired by the DVT architecture, Figment Capital proposed a new middleware sequencer design. For a brief background, DVT creates validator clusters that are run by single or multiple operators. The validator key is split using a cryptographic technique and clients are connected via a consensus mechanism to ensure that the validator cluster functions despite malicious behavior or offline nodes. This design of the sequencer also makes it fault-tolerant, robust, and even geographically diverse. This is a very cool idea and an example of how some designs could be extended to different parts of the infrastructure.
Shared validity Sequencer for Optimistic Rollups
Optimistic rollups have one important component, fraud proofs which typically has a window of a week for finality of transactions. Though there are distributed validator designs that solve for the centralization issue of the sequencer, cross rollup atomic transactions for Optimistic rollups still need a different solution.
Proposed solution contains a mechanism that first solves the mint, burn problem and tries to extend it further. The shared validity sequencer not only orders the transactions but also executes to ensure that the dependencies are executed. For example, the mint function on other rollup must succesfully execute for the burn function, otherwise the tokens on rollups might get lost. It also includes shared blockbuilding and fraud proofs.
Conclusion
Modularism is spreading to layers and functions beyond execution, consensus, DA, and settlement. Teams are finding ways to decentralize and modularize different functions and create new markets.
It is becoming possible for applications to choose from different infrastructure configurations and tune the architecture according to their needs.
There would be a need for aggregators that would optimize different settings for different use cases and provide that as an end service like an SDK so that the product builders don’t have to keep comparing and switching to different configurations.
MEV and censorship resistance is an important topic and is still nascent. There is ample opportunity for providing fair value at different layers.
Cross-rollup communication is a problem looking for a solution, maybe shared sequencers can help.
DST is an interesting design that introduces fault-tolerant, decentralized, and resilient sequencers. This design is inspired by DVT and it remains to be seen if other areas could use it too.