A Primer on Shared Sequencers
An overview of shared sequencers and current market players.
While rollup solutions offer an incredible amount of scalability benefits, one issue that is being discussed more recently is that their sequencer generally operates on a single node. This essentially means that rollup transaction ordering is reliant on a centralized architecture and does not align with the ethos of the industry, which is building permissionless and trustless systems. Centralized sequencers can theoretically censor transactions, display partiality, or even outright fail because of the nature of operating on a single node. To address these issues, shared sequencers are being introduced and iterated on.
Shared sequencers allow multiple rollups to share the same sequencer (tx orderer), eliminating the hassle of rollups figuring out how to decentralize their sequencer and allowing for atomic composability between rollups. Their primary function is continually taking users’ transactions from the mempool and ordering them for all of the rollups that opt into its services. Importantly, the shared sequencer doesn’t execute transactions; execution is done by a separate layer, unlike the design centralized sequencers use. Separating out ordering / consensus and execution makes the entire transacting process much faster since execution computation is completely removed from the nodes’ responsibility. Shared sequencers also operate on a network of nodes (versus just one) and therefore provide much better liveness than a centralized sequencer.
First: why not to use it
There are many reasons why rollups wouldn’t opt in to using a shared sequencer, one of which is that they’re giving up the MEV / fees to the shared sequencer versus capturing it themselves. For existing, prominent rollups (like Arbitrum and Optimism) with large engineering teams, they’re unlikely to opt in to a shared sequencer, and may explore other ways to decentralize on their own in order to preserve the maximum amount of fees. Nearly every rollup has a “decentralization roadmap” and included in this is a plan to decentralize their sequencer. As more and more liquidity shifts to rollups, it’s becoming increasingly important to make sure sequencers are moving towards decentralization.
Arbitrum and Optimism continue to gain market share. Source: Messari
Why to use it
For newer appchains that aren’t as established, automatically having a decentralized solution available is a huge value add. Building a sequencer from scratch, at least right now, is a massive engineering lift and many projects will lack the resources to build one out themselves. It’s also likely that many appchains will emerge that don’t really care about tx ordering, in which case they can just employ a shared sequencer. For existing smaller rollups, a shared sequencer can save the hassle of decentralizing their own sequencer.
Among the chains that use it, having a shared sequencer would also improve cross-chain bridging and messaging since the chains are connected by the sequencer, making communication much easier and more efficient. For bridging, rollups don’t need to each implement separate sequencing light clients for other rollups – they can just read directly from the shared sequencer. In other words, with shared sequencers, rollups no longer need to constantly keep track of the consensus of the other rollup.
Enhanced interoperability, combined with this plug-and-play model where appchains can just opt in to the sequencer, will likely push forward innovation in the space as appchains no longer need to bootstrap / recruit their own validator set. This type of design has some parallels to EigenLayer’s solution, which allows projects outside of the EVM to leverage Ethereum’s existing validator set to secure their projects. EigenLayer’s whitepaper even notes that shared sequencers could potentially leverage EigenLayer’s solution to secure their networks.
When it comes to users paying to transact on rollups that use a shared sequencer, it could work in the way that the signature and address already included in the rollup tx is used to pay for gas on the shared sequencing layer.
Source: Evan Forbes of Celestia
Regulatory issues may emerge around centralized sequencers if they continue to be used in practice. It’s not a long-term sustainable model because it’s not sufficiently decentralized; therefore in theory certain organizations (including the government) could still intervene to censor certain transactions. Having a centralized sequencer is also problematic from a security standpoint: if a hack occurs, all transactions processed by the sequencer could be compromised – a single point of failure. With a shared sequencer, the decentralized nature of the sequencer makes it much more difficult for the network to be compromised.
Current landscape
Astria
Astria is currently working on implementing a shared sequencer based on Evan Forbes’ proposal, offering “decentralization as a service” to an arbitrary number of rollups that opt in to their sequencer. Astria also allows for cross-rollup composability in that it’s capable of providing guarantees that transactions are only included as part of an atomic bundle. Users can therefore specify requirements for transaction execution, e.g. a tx on one rollup can only be executed if another tx on another rollup is also included in that block. For data availability, Astria is using Celestia.
Source: Astria
For the appchain thesis to play out, it must be easy and inexpensive for teams to opt into a robust decentralized sequencer instead of resorting to building out their own centralized sequencer. Astria will push forward this vision by aiming to power this emerging appchain ecosystem as it grows by enabling developers to easily launch a sovereign, customizable rollup.
Espresso Systems
Espresso Systems is launching a shared sequencer compatible with both zk and optimistic rollups. The Espresso sequencer consists of the following components:
HotShot: an implementation for consensus similar to HotStuff but more optimized for scalability
Espresso DA: a data availability solution that produces certified-available blocks
Rollup Rest API: the API that rollups use to opt in to Espresso’s sequencer
Sequencer contract: a smart contract to verify HotShot consensus
A communication layer for nodes to relay tx and consensus messages
Like Astria, the Espresso Sequencer Network removes the need for each rollup to create and maintain their own sequencer. Espresso engages the entire Ethereum validator set in running its sequencer, allowing their design to leverage robust existing security and enabling better liveness. The sequencer component continually fetches transactions submitted by users to the rollup and queued in the mempool, and then finalizes the execution order.
Source: Espresso Systems
Radius
Radius is building a shared sequencer with an emphasis on shielding users from harmful MEV through encryption features and zero-knowledge cryptography. Radius has a network of sequencers but elects a single sequencer every epoch, eliminating the need for consensus. Specifically, they use PVDE, designed to protect users from reordering power by a centralized sequencer. When users submit transactions, they’re encrypted using zk technology and then ordered by the sequencer, meaning that the sequencer can’t manipulate the transaction order to extract MEV (because it can’t see the contents of the txs). Rollups that opt into the Radius sequencer earn profits through atomic cross rollup txs like arbitrage and liquidation.
Madara
Madara is building out a shared sequencer for the Starknet appchain ecosystem. For consensus Madara uses GRANDPA & BABE, which is what most Polkadot parachains use as well, and for DA Madara offers EigenDA, Celestia, and more to developers. Madara is being built using Polkadot’s Substrate and the Cairo VM so appchain developers can easily customize the chain to their needs.
Source: Madara
Fairblock
Fairblock uses threshold encryption to allow users to submit encrypted transactions for multiple rollups, allowing for pre-execution privacy and protecting users from harmful MEV. The transactions are decrypted only once the set of validators has committed to a finalized ordering. Fairblock is focusing on the Cosmos ecosystem to start and is using Celestia for data availability. Their solution has applications for shared sequencers, specifically to protect the contents of the user’s tx before it’s executed. This infrastructure can also be used for private voting / governance and private limit orders / intents.
Source: Celestia/Fairblock
Looking forward
What’s likely to happen is that rollups as a service (RaaS) companies will start offering shared sequencers. From a market perspective, network effects and usability from a developer experience perspective will probably determine the winner(s) in this space. Ultimately, users just want to be able to transact on a fast and inexpensive chain, but decentralization needs to remain a priority from an infrastructure standpoint. Shared sequencers can help enable that by driving appchain growth / interoperability while allowing for customizable use cases that will provide users with more robust crypto experiences.
Final notes:
Decentralizing sequencers is an open research area and many interesting architectures have been introduced, including Shared Validity Sequencing, which couples shared sequencing with shared fraudproofs:
https://twitter.com/pumatheuma/status/1671940202858958848?s=20
Many posit that decentralizing sequencing isn’t enough and that we need to decentralize block building as well. Flashbots is building out exactly this with SUAVE, a decentralized block builder:
https://twitter.com/bertcmiller/status/1597223619058229248?s=20
An open conversation / debate exists on what shared sequencers are actually capable of. For example:
https://twitter.com/0xkydo/status/1652117581988528128?s=20
There’s also more to read about this from Evan Forbes of Celestia and research by Maven11 that gets a lot more into the technical aspects of a decentralized sequencer.
Thank you to George Lambeth and Kydo for discussions that informed my thinking on this piece.