Sequencer Research

Why Decentralized Sequencers?

• Single point of failure: if the centralized operator goes down the whole network is affected; liveness concern
• Censorship prone
• Centralization of MEV extraction

Why Shared Sequencer?

• Interoperability between apps across rollups is limited
• Can't have single tx that updates multiple rollup states at once (atomic execution)
• atomic inclusion?

Reason to seperate Ordering layer

• protocol modularity
• opportunity to make design tradeoffs from L1
• faster pre-confirmations

	Non-shared	Shared
Centralized	Current Rollups
Decentralized		What we desire

Ideal Properties of a Decentralized Sequencer

• No centralization - Does not rely on a single centralized operator
• Permissionless - Anyone can join, no permission needed
• Sybil resistance - Prevents creation of deceptive identities
• Geospatial Distribution - widely distributed across diverse geographical locations

Essential Requirements from a Shared Sequencer

• Credible Neutrality: guarantees universal trust and acceptance. It is important to ensure that all rollups, irrespective of their origin, feel comfortable and incentivized to opt into this shared sequencer. Contemplating scenarios where one rollup proposes its sequencer, the critical question arises: Will competing rollups readily adopt it? The ideal shared sequencer must ensure maximal neutrality across diverse spectrum, fostering a cooperative environment within the ecosystem.
• Security Imperative: the shared sequencer's robustness must be of the highest order, capable of taking the collective economic load of all rollups simultaneously. The absolute rejection of 51%-attack vulnerabilities is very important and hence an exceptionally high level of economic security is required. A sequencer takeover, even if short-lived, could prompt mass exits through rollup escape mechanisms. Furthermore, the potential for temporary takeovers raises concerns about catastrophic toxic MEV extraction through market manipulation.
• Low-Latency Preconfirmations: user experience is crucial. To emulate the responsiveness associated with centralized sequencing and platforms like Solana, the shared sequencer must offer low-latency preconfirmations—ideally within a timeframe of 100 milliseconds or less. Preconfirmations, constituting cryptoeconomic commitments from the sequencer to users, play a pivotal role. Any failure to honor these preconfirmation promises should result in the slashing of the sequencer.

L1 Sequenced Rollups aka Based Rollups

Delegating the sequencing job to L1 brings the best decentralization, liveness and ethereum aligned way of running a rollup.

Lets look at some advantages and disadvantages compared to a decentralized L2 sequenced rollup -

Advantages

	L1-sequenced	L2-sequenced
Simplicity	Code-free	External consensus and escape hatch mechanism is needed
Liveness	Ethereum longevity	Network effect reset incase of mass user exit (using escape hatch etc), toxic MEV
Security	ethereum economic security (~$55 B)	New security model assumption and smaller economic security
Neutrality	neutral shared sequencer, fight fragmentation of liquidity	new brand, new token

Disadvantages

• Permissionless Exploiting - centralized sequencers are more secure, they act like an extra layer of security. In case of a vulnerable VM a black hat can exploit a decentralized sequencer as it is permissionless but that is not possible in the case of a centralized sequencer. Possible solutions are - delayed settlement, multi-proving, lindy effect, formal verification.
• No MEV Income - in case of L2 sequenced the income = congestion fee + contention fee (MEV) but in the case of L1 sequenced the income = congestion fee only. Fee data suggest that the contention fee amounts to ~20% of the total income and in future this percentage will keep on decreasing because of advances like encrypted mempools and MEV-smart DEXes
• No Preconfirmations (Major UX downside) - utilizing L1 for consensus comes at the cost of 12 sec block time resulting in slower transactions, possibly eliminating the core benefit of rollups. A possible solution is using based-preconfirmations (also referred as proposer-promised preconfirmation). The preferred way to get the based-preconfirmation is with execution-tickets. Unfortunately, to implement execution-tickets a hard-fork is required.

MEV

Wait it’s all PBS Always have been - Hasu

On a closer look, sequencer has atleast 2 main components -

• Leader election mechanism (Proposing)
• Ordering mechanism (Building)

L2 Sequencer = L1 proposer + L1 builder

Blind Order-Fairness

Interoperability

Initiatives like Optimism superchain and zksync era hyperchain are enabling developers to deploy customizable rollups on top of their stack.

Open Questions

Sequencing transaction fees

Sequencing layer must charge base fee on txs to control for congestion. But since the sequencing layer is not executing the rollup txs, this "statelessness" leads to challenges:

• Sequencing layer can easily charge based on size of tx data, but not gas consumed
• How does sequencing layer verify the correctness of these fees? Requires keeping minimal state (e.g., separate fee token).
• UX challenges: users don't want to make fee payments in two different tokens.

MEV-mechanism Agnostic Sequencing Layer

• Many approaches to addressing MEV, from optimizing to preventing
entirely
• Examples: auctions, FCFS-ordering, threshold encryption, time-delayed permutations,..
• Some involve various assumptions, honest majority etc.
• Can a sequencing layer shared by multiple rollups be agnostic to the MEV-mechanism favored by each rollup?

How is revenue shared among rollups/apps sharing the same sequencing layer?

This problem can also be framed as a real world example, for eg: how would ticket revenue be allocated between different bands playing at a festival?

The process is straightforward for basic fees (directly paid in each rollup/app) but it is more complicated for MEV (sequencing revenue) as the marginal contribution of each rollup to MEV is not transparent.
TODO: write about the auction mechanism

An easier way of solving this is by not sharing the MEV revenue at all; instead, giving all the revenue to the sequencer for the privilege of enjoying synchronous composability with other rollups sharing the sequencer. Rollups gain so much more than they lose (MEV gambit). Another favourable reason is that many application-level MEV solutions in development ensure that the MEV revenue will tend to zero in the long term.

Pre-Confirmation

Is like a "soft commitment" which allows the rollups to give users faster block confirmation

Escape Hatch Mechanism

allowing users to force exit the rollup via an L1 smart contract [52,95]. However,
current escape hatch implementations have limitations. For example, zkSync
Era requires sequencer approval to include escape hatch transactions [95]. Withdrawing funds from dYdX assumes the presence of a counterparty to trade,
posing challenges during mass exits [95]. Moreover, while most escape mechanisms address withdrawals, they do not cater to funds locked in a rollup’s smart
contract [52]. This underscores the pressing need for better sequencer designs

Protocol Analysis

Astria

This “soft commitment” allows rollups to provide their end users with fast block confirmations. Alternatively, rollups can wait for blocks to be included by the base layer, giving them the strongest finality. All transactions still get this “firm commitment” at the speed of the base layer, fast pre-confirmations are just an additional feature that Astria provides to rollups if they choose to use it.

Astria is a lazy sequencer

The Conductor filters these blocks, or batches of blocks, to contain only the data for its particular rollup’s namespace.

Astria handles the transaction ordering for multiple rollups, it’s able to provide guarantees that transactions are only included as part of an atomic bundle. This allows users to specify that a transaction on Rollup A can be included in a block if and only if a different transaction on Rollup B is also included in the same block. By enabling such conditional transaction inclusion, Astria unlocks exciting possibilities such as atomic cross-rollup arbitrage.

Astria's Dusknet-2 testnet runs as a network with 3 block producing sequencer nodes and uses Celestia's public Mocha testnet. The upcoming testnet, Dawnnet (Q1 2024), will be a decentralized network. Astria RaaS allows anyone to deploy rollups on their shared sequencer network.

Dymension Hub

RollApps communicate and transact with one another via dedicated modules which exist both on the RollApp and the Dymension Hub. Inter-Blockchain Communication (IBC) leverages the common ground of all RollApps - the Dymension Hub. The Dymension Hub facilitates bridging for RollApp users within the entire IBC ecosystem.

Espresso

Chimera Chains

NodeKit SEQ

When you are using the same sequencer across many different rollups it is easy for the user/rollups to make a transaction dependent on the inclusion of a transaction from a different rollup. You can even do this across different execution layers which could lead to some very interesting uses of bridges.

Shared Validity Sequencing

• unlocks a unified layer of native assets that can serve an entire rollup ecosystem.
• enables atomic cross-rollup interoperability.
• burn and mint of a shared token between both rollups. A user bridging the shared token from rollup A to rollup B requires that the burn transaction on rollup A succeeds if and only if the mint transaction on rollup B succeeds. Otherwise, funds might get lost
• On rollup A, burnTree contains all included burn actions. On rollup B, mintTree contains all included mint actions. The desired invariant is that burnTree on A is identical to mintTree on B, or equivalently that their Merkle roots are equal.
• It only requires that the shared sequencer builds blocks for both rollups, and that the sequencer executes transactions and inserts conditionally triggered transactions from one rollup to another.
• it is easily generalized to arbitrary message passing and conditional transaction execution between multiple rollups.

Radius

• decentralization should not lead to a decrease in TPS — the fundamental scalability purpose of rollups
• The monolithic approach, while much simpler, faces scalability and optimization challenges due to reliance on a single sequencer. The modular approach, while potentially more efficient and flexible, requires sophisticated coordination and might introduce system complexity.
• This separation of roles between the Builder (who selects transactions) and the Proposer (who finalizes these selections) introduces some latency or uncertainty. This is not ideal from a scalability and user experience perspective, whereas, with a centralized sequencer, a single entity could pre-confirm transaction inclusions that lead to finalization.

Encrypted Mempool
This enables users to submit transactions in an encrypted form. The sequencers commit to these transactions without knowing the contents of the transaction, providing users with protection against censorship and MEV attacks. The commitment, also a form of pre-confirmation, informs users of the execution order of transactions in the upcoming block.
threshold encryption

Radius adopts a time-lock puzzle (delay) encryption instead of the threshold method. In time-lock encryption, the solution to the time-lock puzzle serves as the symmetric key for encryption.