Intro to Shared Sequencing
Pooling resources to ensure better network decentralization and security
Similar to shared security, and layer-1 validator networks, there is a rising interest in shared sequencers spearheaded by projects such as Espresso, Radius, and Astria.
The goal of shared sequencing is to bring stronger network security and better network decentralization through shared usage of sequencers as roll-ups currently maintain their own sets of the sequencer (usually only one sequencer) and aren’t censorship-resistant and interoperable with other rollups. (Similar to problems plaguing layer-1 networks)
Background
Due to the scalability issues that plague the Ethereum network causing heightened gas fees, roll-up solutions such as optimistic and zero-knowledge roll-ups emerged as solutions to alleviate scalability issues.
The general idea is to move most of the transaction computation and storage off the main chain (Layer 1) while ensuring that the main chain can still verify the correctness of these transactions such as storing the Merkle root in the case of zero-knowledge roll-ups.
Sequencer and Proposer
Optimistic roll-up transactions generally involve sequencers and proposers before a batch of transactions is “rolled up” to layer-1.
Sequencer
A sequencer receives transactions from users, processes them in the order received, and generates a batch of transactions along with a proof or snapshot of the new state after these transactions have been executed.
Sequencer is the only party who is privy to the off-chain database’s pending state as they have the authority to decide/propose the ordering of pending transactions.
Proposer
Once a batch of transactions is sequenced, the proposer generates a state root representing the new state of the system after these transactions have been executed. This state root, along with the batch of transactions, is then proposed to the Ethereum main chain as a single transaction. The Ethereum network assumes that this transaction is valid unless a fraud-proof is submitted during a challenging period.
A proposer’s task is merely functionary to handle the state change once a batch of transactions is sequenced.
Pros and Cons of Rollups
Due to the rising popularity of modular blockchains, it is now an order of magnitude easier and cheaper to launch a sovereign and secure blockchain.
The reason why deploying your own chain (thus the appchain thesis) as opposed to simply deploying a smart contract is that developers can have full control over their execution environment allowing them to design novel techniques for scalability, trustlessness, and sovereignty.
The downside of such a setup, however, is that rollups do not as easily inherit the censorship resistance and liveness properties that can come from a decentralized network.
Currently, almost all modern rollups use a single sequencer (centralization risk) thus the risk is the single point of failure (and thus violating the principle that blockchains were built in the first place).
Additionally, rollups are not interoperable with one another as they each maintain their own sequencer.
On the other hand, there’s also the “based rollup” solution that utilizes the Ethereum L1 for sequencing in order to reclaim the reliability and security guarantees offered by the Ethereum validator set. This approach, however, limits throughput as it would be limited by the transaction ordering and data availability throughput of the L1.
The shared sequencer concept emerged as the middle ground between these two extremes.
Shared Sequencer
A shared sequencer network is roll-up agnostic and can serve different rollups. In short, shared sequencer architecture is essentially abstracting/modularizing the sequencer setup aforementioned in “monolithic” rollups.
A shared sequencer network, much like the validator network in layer 1, can support a higher level of censorship resistance and liveness.
At the same time, it can support interoperability between rollups (as transactions are now pooled across rollups) and MEV resistance (where a consensus leader can reorder transactions or inject transactions to maximize its own profit).
Much like a validator network, a sequencer network also has the following components:
- ROLL API / JSON-RPCs (Between rollups and the sequencer network)
- This is to support sending transactions (ie. write operation) over the network. (See Ethereum JSON-RPC here)
2. Peer-to-peer layer (between sequencers)
- This is to communication between sequencers and broadcast block across the network. During this process and much like the Byzantine Fault Tolerance consideration in consensus protocols, there is a leader selection and consensus algorithm (Espresso uses HotShot. Others include Tendermint).
After the sequencer sequences the batch of transactions, the block is then added to the data availability layer.
Additionally, following a similar setup to the layer-1 validator network, the sequencer network will also leverage the proof-of-stake mechanism to incentivize sequencer network participation.
Final Thoughts
While this article sought to lay out the frame of mind to understand shared sequencer network and how it works, more research should be conducted to understand the trade-offs between the designs in each of the networks to understand differentiations as well as what each network may be good for.
