Originally posted to Substack.
Thank you to Ben Fisch, Josh Bowen, Cem Özer, Kelvin Fichter, Zaki Manian, Hasu, Robert Miller, Tarun Chitra, Sreeram Kannan, and many others for their input and great discussions around the topic.
Kelvin thinks that ZK rollups aren't real, but I don't think that any "rollups" are real, at least not yet. So, how do we make them real rollups?
Today's rollups are mostly trusted and permissioned:
I'll provide an overview of the landscape for:
Many other requirements to improve rollup security will fall outside the context of this post (reducing upgrade keys' power, implementing robust and permissionless proofs, etc.).
First, a brief refresher on how SCRs work. These are the rollups we're used to on Ethereum today. At a super high level, a SCR is basically just:
More specifically, traditional sequencers commit to rollup blocks by posting their state root and calldata (eventually data blobs) to their associated L1 smart contracts. New blocks extend the tip of the rollup. The on-chain contract runs a light client of the rollup, keeping its block header hashes in storage. The contract is convinced of settlement upon receipt of a validity proof, or after the fraud proof window has passed. If an un-finalized ORU block is invalid, it (and all subsequent blocks) can be orphaned by submitting a fraud proof which rolls back the tip of the chain. Proofs help to protect the bridge:
Batch submission should require some type of bond/deposit to disincentivize malicious behavior. If a fraudulent batch is submitted (e.g. invalid state root), the deposit would be burned and given to the fraud challenger in some split.
SCRs have "merged consensus" - a consensus protocol that's verifiable on-chain. Rollup consensus can run entirely in an L1 smart contract. It doesn't affect or require any support from the main chain's consensus rules.
Decentralized consensus protocols generally consist of four primary features (note this is an oversimplification which doesn't cleanly account for many families of consensus protocols, e.g., leaderless ones):
With 1 and 2 arguably provided, the bare minimum requirements to decentralize a sequencer are then some form of Sybil resistance + leader election. Fuel Labs has been in this camp, arguing that PoS:
There are also good arguments for why you should have an L2 local consensus. More on this later.
SRs still post transaction data to the L1 for DA and consensus, but they handle "settlement" (I already sound dumb, so it's fine) client-side within the rollup. DA layers tell you the data exists, but they do not define what the canonical chain is for the rollup:
Related note: There's an interesting argument that there is no such thing as a globally canonical chain (only bridges deciding which chain to consider canonical), good counter arguments, and other great related Twitter threads on the tradeoffs all rollups make between sovereignty and (automatic) composability. I encourage you to sift through them as well as this recent thread on Bitcoin sovereign rollups.
In any case, the "canonical" framework above is easy to understand, and it's not a central point for this piece here, so I'm going with it. For more background on general rollup architecture, you can refer here.
Smart Contract Rollups
As mentioned above, sequencers are generally responsible for batching transactions and posting them to the L1 smart contract. However, users can also directly insert some transactions to the contract themselves:
Of course this is inefficient and expensive, so sequencers will batch transactions and submit them together in the normal course. This amortizes the fixed costs over many transactions and allows for better compression:
The sequencer promises to eventually publish these transactions on the L1, and we can compute the outputs in the meantime to get softer pre-confirmations:
When the sequencer posts these transactions to the L1, that solidifies the outputs:
Normally, users would just include transactions themselves when coming from the L1 to bridge funds up to the L2. This is added as an input to the L1 contract which tells the L2 that it can mint funds on the L2 backed by this locked asset on the L1.
If I want to get my money back to L1, I can burn it on the L2 and tell the L1 to give me my money back down there. The L1 doesn't know what's going on with the L2 (it's not executing its transactions), so a proof needs to be submitted along with the request to unlock my funds on L1.
Because I'm coming from the L2, the sequencer can initiate this withdrawal request and submit it to the L1. However, now you're trusting the L2 sequencer for censorship resistance (CR). You're no longer operating under the same guarantees you get on L1. Maybe they don't like you, or the sequencer just shuts down, so you're stuck on L2 forever now.
Rollups can increase their own CR locally with a variety of measures. This may include having an L2 consensus set with high value staked, some variation of inclusion lists, adding threshold encryption, etc. to minimize the chances of L2 user censorship. These are great, but ideally we also want L2 users to have the same CR assurances as the L1.
If users are being censored, they need some way to either force withdrawal from the rollup or force inclusion of their transactions into the L2. That's why L2 users should retain the ability to do things like force inclusion of their L2 transactions directly into the L1 contract themselves. For example, censored users may be able to submit a single-operation batch themselves directly to the L1.
It's not ideal though if the only option for L2 users is to force transactions into the L1 directly. This is likely to be infeasible for many low-value users, particularly as the L1 gets more expensive to interact with. More advanced designs may be able to work around this limitation, forcing atomic transactions between rollups. Kalman Lajkó is working on a fascinating design here which I highly recommend reading. It looks to enable cross-rollup forced transactions in systems with shared provers and DA layers.
Sovereign Rollups
Forced inclusion works differently for SRs because, as mentioned earlier, they enforce their fork-choice rule differently than SCRs (great post by Sovereign Labs on this here).
In a SCR, the L1 smart contract enforces the rollup's fork-choice rule. In addition to verifying the ZK proof, it also checks that the proof builds on the previous proof (and not some other fork), and that it's processed all of the relevant forced transactions which were sent on L1.
A SR can post its ZK proofs to the L1 DA layer for all to see as calldata/blobs (even though the L1 isn't verifying them). Then, you simply add a rule that a new proof is only valid if it builds on the previous valid proof. This rule could be enforced client-side, but it would then require users to scan the chain's history back to genesis or some checkpoint.
Instead, the calldata can be tied back to the L1 block headers, and a statement can be added saying "I have scanned the DA layer for proofs (starting at block X and ending at block Y), and this proof builds on the most recent valid proof". This proves the fork-choice rule directly in the proof rather than enforcing it client side.
Since you're already scanning for proofs, you can also prove that you've scanned for any forced transactions. Anyone can post a forced transaction directly to the L1 DA layer when they wish.
On-chain proof verification on Ethereum is generally very expensive, so current ZKRs such as StarkEx tend to only post STARKs to Ethereum on the order of every few hours. Proofs tend to grow very slowly relative to the number of transactions, so this batching meaningfully saves on costs. However, this long finality time isn't ideal.
If a rollup only posts state diffs on-chain (and not full transaction data), then even full nodes can't be assured of this eventual finality without a proof. If the rollup's full transaction data is posted on-chain, then at least any full nodes can finalize along with the L1.
Normally light nodes would just rely on centralized sequencer soft confirmations. However, a ZKR could instead quickly generate and distribute ZK proofs in the p2p layer for all light clients to see in real-time, providing them finality at the L1 speed as well. Later on, these proofs can be recursively batched and posted to the L1.
This is what Sovereign Labs is planning to do, and similarly Scroll is planning to post intermediate ZK proofs on-chain (but not verify them), so light clients can sync fairly quickly. With both of these constructs, rollups can start to finalize at the speed of the L1 rather than waiting to save on gas costs. Note that in both cases, you're simply bringing hard finality time back down to the absolute minimum (L1 speed).
Different sequencer designs will never give you that strongest level of finality faster than L1 block times. The best that different sequencer designs can do is give you pre-confirmations faster than L1 block times with varying levels of certitude (e.g., you probably can trust the pre-confirmation of an L2 with a decentralized consensus set with high value staked more than you can trust the pre-confirmation of a single trusted sequencer).
Patrick McCorry also recently put out a great overview on the Tiers of Transaction Finality for Rollups. You probably get the basic idea now:
Today, most rollups have one sequencer permissioned to submit batches. This is highly efficient, but provides weaker real-time liveness and CR. With proper safeguards in place, this may be acceptable for many use cases:
Reserve sequencers could be elected by the rollup's governance for example. With this setup, users get safety, CR, and liveness. Single active sequencers may be a viable option even in the longer run then.
Base is likely the start of a trend. Companies can now manage and optimize their product like they got all excited about with that enterprise blockchain hype nonsense, but it can actually be a permissionless, safe, and interoperable chain now.
Base intends to decentralize their sequencer set eventually, but the point is they don't strictly need to, and others may not (or they could to a very limited extent such as a small sequencer set). To be clear, this requires rollups to implement the necessary steps so that it's actually safe and maintains CR (remove arbitrary instant upgrades, implement robust proofs, forced transaction inclusion, MEV auctions, etc). It's not safe today.
This will be a massive improvement over centralized/custodial products, not a replacement for maximally decentralized ones. Rollups simply expand the design space. This is also largely why sequencer decentralization hasn't been a top priority for most rollup teams - those other items are simply far more important for ensuring user safety, CR, and reducing trust in the rollup operators.
However, it's still not ideal if users/other parties need to step in to maintain liveness and "real-time CR" (as opposed to "eventual CR" such as forcing transactions through the L1). Depending on the forced transaction inclusion mechanism, it may be costly or impractical for low-value users to step in. Rollups with a high preference for maximum guarantees around real-time CR and liveness will look to decentralize. There may also exist regulatory considerations in operating a single permissioned sequencer.
One straightforward improvement over a single sequencer would be permissioning a handful of geo-distributed sequencers (perhaps other reputable companies). Sequencers could simply rotate equally in a round robin style. Having them put up a bond would help incentivize honest behavior.
This general concept shouldn't be too unfamiliar - multisig bridges often have a handful of trusted corporates, or similarly the committee for something like Arbitrum's AnyTrust DA. Importantly though, they have far less power here (you don't rely on rollup sequencers for safety, unlike how multisig bridge operators could withdraw locked funds). Overall, this is better for CR and liveness vs. a single sequencer, but still imperfect.
Instead of allocating sequencer rights based on stake, a rollup could also directly run a MEV auction (MEVA) via a smart contract. Anyone can bid for the right to order transactions, and the auction contract awards sequencing rights to the highest bidder. This could be done per block, or for an extended period of time (e.g., bidding for the right to be the sequencer for the next day). Winning sequencers should still post some bond so that penalties can be imposed if they are then faulty/malicious.
In practice, an out-of-protocol MEVA will naturally result if the auction isn't directly baked into the protocol. If sequencing rights are determined based on stake weight, some form of MEV-Boost/PBS-style auction system will arise, similar to what we see on L1 Ethereum today. In this case, fees/MEV would likely go to stakers. If the auction is baked into the protocol, then fees/MEV would likely go to some form of rollup DAO treasury (though it could also be distributed, burned, etc. in either case).
Permissionless to join as a sequencer, but you must stake (likely the L2's native token). The staking mechanism can be established on the base layer through a smart contract or directly within the rollup. You can use this PoS + some form of randomness on-chain to do leader selection in much the same way as any L1. Your probability of getting to sequence a block = your proportion of total stake. Penalties can be imposed on faulty/malicious sequencers via missed rewards, inactivity leaks, and slashing.
Note that this does not require the sequencers to reach consensus for the reasons described above. Rollups use the L1 for consensus, so local consensus is not required. Stake determines the rotation of what sequencers can propose blocks, but they don't need to vote on the blocks proposed by other sequencers.
This could grant sequencing rights for an arbitrary length epoch. You may be entitled to sequence for 100 consecutive rollup blocks, or 1000, etc. Longer periods may be more efficient, and only a single sequencer is needed at a given time. However, granting extended monopolies can have other externalities. Alternatively, the leader could alternate every block as with normal L1s.
Dymension
Dymension is one project working along these lines. The Dymension Hub will be a typical honest majority PoS L1 in Cosmos. Its L2s ("RollApps") will use it for settlement and consensus while relying on Celestia for DA (so these L2s are actually "optimistic chains" not "rollups").
Per their Litepaper, decentralized RollApp sequencing will require staking DYM (Dymension's native asset) on the Dymension Hub. Leader selection is then determined by the relative amount of DYM staked. These sequencers will receive the revenue (fees and other MEV) from their respective rollups then pay the associated underlying costs to the Dymension Hub and Celestia.
As a result of this mechanism, nearly all value capture in this stack accrues directly to the DYM token. Rollups that use their own native token for sequencing (as StarkNet intends to do with STRK, described below) accrue value to their own token. This setup here is analogous to if Ethereum rollups could only ever use ETH for their sequencer election.
In my opinion, this massively reduces the incentive to deploy an L2 on such a settlement layer. Most L2 teams will naturally want their own token to accrue meaningful value (not just be used for a fee token, as would be possible here). They're running a business after all.
It's also possible to use L2 staking for sequencer election and local consensus prior to L1 confirmation if desired. This is exactly how StarkNet plans to use their STRK token:
Additionally, STRK may be used in some form for:
The transaction flow looks like this:
For more detail on StarkNet's plans, you can refer to the series of forum posts starting with this one.
As we saw, an L2 may or may not implement its own local consensus (i.e., L2 validators signing off on its blocks before sending them to the L1 for final consensus). For example, the L1 smart contract can be aware based on its rules that:
To have a rollup without local consensus, all you need to do is:
Note that in either case, the value from the L2 can accrue to the rollup token. Even if the L2 token is just used for some form of leader selection (not consensus voting), the value from sequencing rights still accrues to the L2 token.
Disadvantages of L2 Consensus (Only Leader Selection)
Now let's discuss the tradeoffs of having/not having local consensus prior to the L1.
One argument as made by the Fuel Labs team is that it can decrease CR. "This allows a majority of validators to censor new blocks, meaning user funds can be frozen. There is no need for PoS to secure a rollup, because a rollup is secured by Ethereum." This is a bit of a gray area here. As described previously, you can still provide CR even with censoring sequencers (e.g., forcing transactions into the L1 directly, or more intricate designs such as the one Kalman Lajkó is working on).
Another argument is that full consensus is simply "inefficient." For example, it seems easier to just have:
This of course varies widely depending on the exact sequencer design and consensus mechanism chosen.
Additionally, note that some have raised concerns about using PoS in sequencer decentralization as noted here and here. The intricacies of L1 vs. L2 may make it more challenging to deal with certain types of attacks.
Advantages of Adding L2 Consensus (In Addition to Leader Selection)
Probably the largest goal for sequencers is to give users faster soft confirmations prior to the full safety and security of L1. Looking at StarkNet's mechanism requirements:
"Strong and Fast L2 Finality - StarkNet state becomes final only after a batch is proven to L1 (which might take as long as several hours today). Therefore, the L2 decentralization protocol should make meaningful commitments regarding the planned execution order well before the next batch is proved."
Adding some form of consensus backed by the economic security of many sequencers helps to provide stronger guarantees in the interim that your pre-confirmations are good to go:
"Starknet consensus must be strongly accountable in the sense that safety and liveness violations are punishable by slashing for any fraction of the participants (including malicious majority of stake)."
Rollups also have flexibility to experiment with different tradeoff points on the spectrum of consensus mechanism options, as they can always fall back to the safety and dynamic availability of Ethereum L1 eventually.
All of the above constructs privilege sequencers to create rollup blocks in one form or another. For example, PoS is permissionless to join, but the elected L2 sequencer for a given slot is the only party capable of submitting a block at that time. Alternatively, there are a few related proposals which do not privilege any L2 sequencers. These designs place reliance on the L1 itself for their transaction sequencing.
Total Anarchy
Vitalik proposed this "total anarchy" idea back in 2021. Allow anyone to submit a batch at any time. The first transaction that extends the rollup is accepted. It fulfills the two minimum requirements discussed above to decentralize sequencers:
This is sufficient because the L1 already provides security. If L2 blocks have been posted to the L1, they can only be orphaned if they're invalid or building upon invalid blocks (will be rolled back). If they're valid and posted to the L1, they have the same security guarantees as the L1 itself.
The big problem Vitalik noted - it would be incredibly inefficient. Multiple participants are likely to submit batches in parallel, and only one can be successfully included. This wastes a large amount of effort in generating proofs and/or wasted gas in publishing batches to chain. It's very messy knowing if your transactions will get in quickly, and it's not cost-effective.
Based Rollups
However, PBS could make this anarchy design workable now. It allows for more regimented sequencing with at most one rollup block per L1 block and no wasted gas. (Though you may have wasted computation). L1 builders can just include the highest value rollup block, and build this block based on searchers' input bids similarly to any L1 block. It may also be reasonable to make ZK-proving permissioned by default (with a permissionless fallback), to avoid wasted computation.
This is the core idea behind Justin Drake's recent proposal for "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 for forced transaction inclusion in the event that L2 sequencers are censoring. Additionally, they remove some gas overhead as no sequencer signature verification is required.
One interesting question raised was in regards to where these L2 transactions go to get processed. L2 clients will need to send these transactions somewhere for L1 searchers/builders to pick them up and create their blocks and data blobs. They could possibly be sent to:
One clear downside here is that based rollups limit sequencer flexibility. For example:
Interestingly, this is exactly what early rollup teams were building:
Fun fact: the initial Arbitrum implementation & first public testnet (Ropsten L2) worked like this.
Sequencer was introduced later b/c there was demand / froth for fast transactions. https://t.co/lPTrzo0lHA
— Daniel "sorry if this is a bit niche" Goldman (@DZack23) March 14, 2023
Justin noted that restaking may be able to help here.
Wow pic.twitter.com/zs786upj91
— Jon Charbonneau (@jon_charb) March 15, 2023
These are both areas of research around EigenLayer at least as mentioned in their whitepaper here. It's unclear though that this is a viable solution to solve the problem practically here. For restaking to meaningfully improve these shortcomings, you'd likely want all stakers to opt into running it. It seems more logical to simulate this idea by just having the subset of stakers that want to do this opt into a separate shared sequencing layer (more on this shortly).
Proof of Efficiency (PoE)
Last year, Polygon Hermez made a proposal called PoE. It's another variation of L1-sequencing specifically intended for ZKRs. The sequencer here is a completely open role where anyone can submit a batch (i.e., total anarchy/based, and so it carries the same limitations). PoE consists of a two-step process with two parties:
Sequencer
Sequencers collect L2 user txs and create a batch by sending a L1 tx (which includes the data of all selected L2 txs). Sequencers will submit blocks based on economic value received, or to fulfill a service level for users (e.g., post a batch in every L1 block, even if it makes L2 txs more expensive because users want faster txs).
Sequencers will pay L1 gas fees to post a batch, and the protocol defines an additional fee in MATIC that must be deposited. Once posted, the winning batch immediately defines the new tip of the chain, allowing any node to deterministically compute the current state. A validity proof will then be needed to finalize light clients' view of this (including the L1 smart contract).
Aggregator
Aggregators here are the ZK-provers. Again, it's a permissionless role which anyone can compete at. Very simply:
Aggregators are free to run their own cost-benefit analysis to find what the right frequency of posting a proof is. They get a portion of the fees if they win the race, but waiting longer to post a new proof amortizes their fixed verification costs over more transactions. If aggregators post a proof late (it doesn't prove a new state), then the contract will just execute a revert. The prover wasted computation, but they'll save most of their gas.
Fees can be distributed as follows:
Pure Fork-Choice Rule
Rollkit SRs have a very similar "pure fork-choice rule" concept as noted here to refer to any rollup without privileged sequencers. Nodes defer to the DA layer for ordering and apply a "first-come-first-serve" fork-choice rule.
Economics of L1 Sequencing
These L1 sequencing designs have important economic consequences in that MEV for L2 transactions would now be captured at the level of the L1 block producer. In the "traditional" L2 sequencing models, MEV for L2 transactions is captured by the L2 sequencer/consensus participants/auction mechanism. It's unclear that much MEV would ever leak down to the base layer in this case.
There are mixed feelings over whether this is a good thing or a bad thing:
This could make sense particularly as an easier bootstrapping method for a rollup, but it's hard to see most rollups giving up so much MEV to the L1 that they could capture themselves. One of the great benefits of rollups is indeed economic - they'll need to pay very little back to the L1 once DA starts to scale and those costs drop. The downsides of slower block times and naive approach to MEV also seem suboptimal for users.
As a brief aside, note that the competitive racing market described above in PoE may tend towards centralization around the fastest aggregator. ZK-prover markets very broadly have two economic problems to solve for:
Let's consider two simple models for a ZK-prover market:
At one extreme, you could have an open competitive model. A permissionless market of provers all race to create a proof first for the blocks that the rollup sequencers/consensus have produced. The first to create the proof could get whatever reward is designated for provers. This model is highly efficient in finding the best prover for the job.
This looks pretty similar to proof of work mining. However, there's a unique difference here - proofs are deterministic computations. As a result, a prover with a small but consistent edge over other provers can almost always win. This market is then very prone to centralization.
In PoW mining, the randomness aspect has much nicer properties - if I have 1% of the mining hashpower, I should get 1% of the rewards.
This competitive proving model is also suboptimal in terms of computation redundancy - many provers will compete and spend resources to create the proof, but only one will win (similar to PoW mining).
Alternatively, you could rotate among provers giving them each a turn (e.g., based on some stake deposited, or reputation). This may be more decentralized, but it may be less efficient on proof latency ("slow" provers will get a chance to create proofs when another prover may have been capable of creating the proof faster and more efficiently). However, it can prevent the wasted computation of many provers racing to create a proof when only one will land.
Additionally, you have an issue if the person whose turn it is fails to produce a proof (either maliciously or accidentally). If these turns are long (e.g., a given prover gets a monopoly for several hours) and the prover goes down, it would be difficult for the protocol to recover. If turns are short, other provers could step in and catch up where the primary prover failed to do so.
You could also allow anyone to post a proof, but only the designated prover can capture the reward for a given time. So if they go down, another prover could post the proof, but they wouldn't be able to capture the reward. This would be altruistic then to expend resources doing the computation for no reward.
Scroll is exploring more along the lines of a turn-based approach, dispatching execution traces to randomly selected "rollers" (provers):
There are also many interesting questions on how fees should be charged for proving at the user level at time of sequencing. Further discussion on these topics and more can be found here:
Most of the earlier solutions presume that each rollup needs to figure out how to decentralize their sequencer all on their own. As we saw with the L1-sequenced options, that's simply not the case. Many rollups could instead opt into one shared sequencer (SS). This has some great benefits:
Simply using the native L1 as the sequencer for many L2s fundamentally has several downsides as mentioned previously:
The best that L1-sequencing can do is remove the L1's computational bottlenecks (i.e., if transaction execution is the bottleneck for throughput) and achieve small factor improvements on communication complexity.
So, can we design specialized and more efficient SSs as opposed to just letting the L1 do it...
Metro is one proposal for a SS layer. You can refer to Evan Forbes' research post, Modular Insights talk, and Shared Security Summit talk for more details. Astria, led by Josh Bowen, is the team that is working on actually implementing this design of Metro.
Separation of Execution & Ordering
Rollup nodes today really handle three things:
The key property here would be separation of execution and ordering. This SS:
Ordering is stateless - SS nodes then no longer need to store the full state for all of the different rollups. They remove execution computation. The gigantic bottlenecks which traditional sequencers currently handle are gone.
When you strip out execution from consensus it goes super fast. You're now just limited in the gossiping layer (fast). Nodes can be incredibly efficient if all they have to do is produce ordered blocks of transactions and agree on the block without executing everything. Execution and proving can be done by separate parties after the fact.
Pooling Sequencer Security & Decentralization
SS nodes can then be kept relatively lightweight or even horizontally scalable (by choosing a random subset of consensus nodes to order different subsets of transactions). The result - you can likely make this sequencing layer far more decentralized vs. a traditional sequencer that needs to hold the chain's heavy state on hand and do full execution.
Additionally, we're pooling the resources across many chains - no need to fragment the PoS consensus across many rollups. Aggregate it all in one place. This effect likely yields a more decentralized sequencer set (CR) with more slashable value staked (reorg resistance) as compared to many rollups implementing their own sets. This is important because:
Once transaction ordering has been agreed to, execution (and proving) can be deferred to an entirely different chain after the fact:
This later execution layer doesn't need to be as decentralized because this isn't where CR comes from. Single sequencers aren't ideal for CR, but that doesn't come from their role as an executor. It comes from the fact that they order and include transactions. Here, the SS is already providing the ordered input of transactions, and thus CR. That later calculation and comparison of the state commitment then doesn't need to be as decentralized.
Soft Execution
That step 1 of fast soft execution is what users love:
This requires some form of consensus (or a centralized sequencer) to provide that great UX here:
If you were just to rely on the consensus of the base layer such as Celestia, you can't provide these kinds of soft promises around ordering and inclusion with good assurance. The SS can provide pretty strong commitments on fast blocks (sub-L1 block times) if it has a decentralized committee with high value staked.
So users can get soft confirmations as soon as the SS creates a block. Anyone can just download the agreed upon transactions and apply them to the state prematurely. The strength of this confirmation is dependent upon the construction of the SS (decentralization, economic security, fork-choice rule, etc.). Once the data actually gets posted to the base layer, you can treat these transactions as truly final. Then final computation of the state root and associated proofs can be generated and committed to.
Lazy Rollups
"Lazy rollups" are very simple. They wait until their transactions have all been ordered and posted on the DA layer, then they download those transactions, optionally apply a fork choice rule to select a subset of transactions, perform transaction processing, and apply those transactions to the state. Headers can then be generated and gossiped.
Note that because the SS can't produce blocks in a way that requires access to full state, they're not checking for invalid state transitions. As a result, the state machine of "lazy rollups" using a SS must be able to deal with invalid transactions. Nodes can simply drop invalid/reverting transactions when they execute the ordered transactions to compute the resulting state. Traditional rollups that do immediate execution don't have this limitation.
Rollups that require state access to malleate transactions before including them on-chain wouldn't work here. For example, if a rollup has a block validity rule where all transactions included in the block are valid transactions that don't fail. If the rollup requires transaction malleation but not state access, then a special SS could be created exclusively for rollups of this type (e.g., something like Fuel v2 or a rollup with a private mempool).
Paying For Gas
For this SS to operate, there must be some mechanism for users to pay for their transaction inclusion into the L1. You could simply use the existing signature and address already included in most rollup transaction types to also pay for gas on the SS layer. This would then be the one thing that would require the SS to have awareness of some minimal state depending on implementation (e.g., to parse the signature, nonce, subtract gas from the account). Alternatively, payment could involve some wrapper transaction on the SS where anyone could pay for arbitrary data to be included. It's an open design space here.
Fork-Choice Rule
Rollups are able to inherit the fork-choice rule of the SS they are using. The rollup's full nodes are then effectively light clients of the SS, checking that some commitment to indicate which rollup block is the correct one for a given block height.
However, inheriting the SS's fork-choice rule is optional - you can simply require the rollup to process (not necessarily execute) all of its transaction data posted to the base layer. It would effectively inherit the CR and liveness of the base layer, but you'd sacrifice a lot of the nice SS features that users love.
MEV
Assuming a rollup wants to inherit the fork-choice rule of its SS and get fast soft execution, the SS will naturally be in a very central position in regards to MEV. It decides the inclusion and ordering of transactions that the rollup will abide by.
However, it's not inherently the case that a rollup must execute the transactions provided by the SS, or in the order provided. You could technically allow for your own rollup operators to do a second round of processing to reorder the transactions published by the SS after the fact upon execution. However, as noted above, you'd then lose most of the nice properties of using a SS in the first place, so this appears less likely.
Even in this case though, there's likely to still be MEV at the SS layer since it has power over the inclusion of transactions. If you really wanted, you could even allow your rollup to exclude certain transactions on the second round of processing (e.g., having some validity conditions to exclude certain transaction types), but this of course can get messy, reduce CR, and again mostly lose the benefits of a SS.
Swapping Out a Shared Sequencer
The thing in blockchains that's hard to fork is any form of valuable shared state. Looking at something like ETH vs. ETC or similarly ETH vs. ETH POW, social consensus decides what the "real Ethereum" is. What's the "real" state that we all agree is valuable.
However, SSs are really just a service provider - they don't have a valuable state associated with them. Rollups using a given SS then preserve the ability to fork it out in favor of some other sequencing mechanism with only a minor hardfork (e.g., if the SS is extracting too much value). This should hopefully keep SSs competitive.
The thing that could make this more challenging would be network effects. If many rollups all start using a SS and they get great network effects (e.g., if they derive meaningful value from the potential cross-chain atomicity with many chains), it may be painful to detach unless other rollups are willing to move over as well.
You might've seen that the EigenLayer whitepaper mentioned decentralized SSs as one of the potential consumers of restaking. This SS could be secured by ETH restakers, and it would handle the transaction ordering for many different L2s.
Well Espresso just publicly announced exactly that in their plans for a shared sequencer. It can leverage EigenLayer restakers to secure its consensus. To give a nice visualization, this is what rollups look like today:
And this is what they'd look like with a SS such as Espresso:
The Espresso Sequencer (ESQ) is very similar overall to the general ideas of Metro. It would work by the same core principle - it strips out transaction execution from ordering. In addition to this, ESQ will provide data availability for transactions as well.
HotShot Consensus & Espresso DA (Data Availability)
For background, Ethereum currently uses Gasper for consensus (Casper FFG as the finality tool + LMD GHOST for its fork-choice rule). The TLDR relevant here is that Gasper maintains liveness even under pessimistic conditions where most nodes could drop off the network (dynamic availability). It effectively runs two protocols (Casper FFG and LMD Ghost) which together maintain a dynamically available chain with a finalized prefix. Gasper trades off on fast finality (the ability to confirm transactions as fast as the network will allow).
Overall, ESQ consists of:
Let's take a closer look at the DA. In the optimistic case, high bandwidth nodes will make data available to all other nodes, and the availability of each individual block is also backed up by small randomly elected committees. Given the risk of DDoS and bribery attacks on small committees, verifiable information dispersal (VID) will be used to provide a reliable (but slower) backup path to guarantee DA so long as a sufficiently high fraction of all nodes (by stake) isn't compromised.
This system is built for scale, so ESQ is looking to provide cheaper DA to the L2s opting into it as a SS. They'll still settle their proofs and state updates to L1 Ethereum, but note that this would make chains using ESQ by default "validiums" or "optimistic chains" not full "rollups" (i.e., their DA isn't guaranteed by Ethereum L1). It's stronger than simple implementations of data availability committees (DACs), but it's a weaker guarantee than true rollups.
Transaction Flow
Transactions forwarded to the SS will be sequenced then sent back to the rollups' executors and provers before it is finalized on L1. The SS also sends a commitment to the block to its L1 sequencer contract along with a quorum certificate used to authenticate the block. This allows the L1 rollup contracts to compare the rollup state update proof against a block commitment which is certified as being the output of consensus.
A full view of the transaction flow:
As noted in the Espresso post, a SS can provide some exciting use cases in regards to cross-chain atomicity:
"A sequencing layer shared across multiple rollups promises to make cross-chain messaging and bridging cheaper, faster, and safer. Elimination of the need to build a light client for another chain's sequencer is a free benefit with no cost, creating potential upfront savings. Ongoing savings are also made possible for cross-rollup bridging by removing the need for a given rollup to stay independently up-to-date with other rollups' consensus. Shared sequencers also offer security benefits for bridging: the shared sequencer can guarantee that a transaction is finalized in one rollup if and only if (or even at the same time) it is finalized in the other.
Additionally, shared sequencers enhance users' abilities to express atomic dependencies between transactions across different rollups. Conventionally, Alice would sign and publish her rollup-A transaction t independently of Bob's rollup-B transaction t'. In this case, Alice's transaction might get sequenced long before Bob's, leaving Bob with a long-duration option to abort (e.g., a trade). This optionality imbalance is mitigated with a shared sequencer, where Alice and Bob can instead submit the two transactions together as a signed bundle (i.e., the sequencer must treat these two transactions as one)."
This has implications for cross-domain MEV as on-chain activity eventually starts to grow (I hope). The classic example is "atomic arbitrage." The same asset is trading on two different chains at two different prices. Searchers want to close that gap by executing two trades simultaneously without execution risk. For example:
For the arbitrage to be atomic = either both trades get filled, or neither gets filled. If both rollups are opted into the same SS, then it could fulfill this atomic arbitrage for a searcher. The SS here can guarantee that:
Assuming the rollup VMs execute all transactions in their respective streams sequentially (i.e., there's no such thing as an invalid instruction, just some instructions can throw errors with no impact on the state), then we can also guarantee that:
However, this still is not the same guarantee you'd have if you're transacting on a shared state machine (e.g., entirely on Ethereum L1). As noted previously, the SS does not hold the state for these rollups, and they are not executing the transactions. You cannot offer complete assurance that one of the transactions (on R1 or R2) doesn't revert upon execution.
Building more advanced primitives directly on top of this would be questionable. For example, if you tried to build an instant burn-and-mint cross-chain bridging function on top of this SS that does the following in the exact same block height simultaneously:
You could have a situation where:
You can see how that would be a big problem.
There may be some cases where you can be certain of the intended result of these two transactions as long as both are included in the input streams and thus executed, but that's often not the case. It's an open question how powerful it is to:
These "guarantees" may be sufficient for something like atomic arbitrages where the searcher already has their assets needed to execute these trades on each chain, but it clearly isn't the synchronous composability of a shared state machine. It's not a sufficient guarantee on its own for something like cross-chain flash loans.
This may still be useful in other settings though when combined with other cross-chain messaging protocols. Let's look at how a cross-chain atomic NFT swap could be facilitated when used along with a cross-rollup messaging protocol:
The SS here enables both users to commit atomically in step 1. Then, you use some form of cross-chain messaging for the rollups to verify each others' resulting state and unlock the assets to execute the swap.
Without a SS to conduct it atomically, the two parties could agree on a price. But then U1 could submit their transaction, then U2 could wait around and decide if they want to abort the transaction. With a SS, they would be locked into the trade.
This is pretty much the edge of the map for cross-chain atomicity with SSs. Summarizing:
For other interesting topics on cross-chain atomicity, I recommend checking out:
Summarizing, the basic idea of a SS is that it would try to do this:
Obviously this picture isn't a science, everything is highly subjective, and it's very dependent on the exact construct. But the TLDR comparisons would be something like this:
Eventually, all rollups find their way back to 100% L1 security once the L1 finalizes. Most sequencer designs are just trying to give you really nice features with somewhat weaker assurances in the interim prior to getting the full safety and security of L1 settlement. They all make different tradeoffs.
The differences here can get pretty confusing when we're talking about these shared layers trying to handle transactions for many other chains. Especially when SUAVE is often called a "sequencing layer" among other terms such as a "decentralized block builder for rollups." To be clear - SUAVE is very different from the SS designs described above.
Let's consider how SUAVE could interface with Ethereum. SUAVE would not be enshrined into the Ethereum protocol in any way. Users would simply send their transactions into its encrypted mempool. The network of SUAVE executors can then spit out a block (or partial block) for Ethereum (or similarly any other chain). These blocks would compete against the blocks of traditional centralized Ethereum builders. Ethereum proposers can listen for both, and choose which they would like to propose.
Similarly, SUAVE would not replace the mechanism by which a rollup selects its blocks. Rollups could for example implement a PoS consensus set that may operate in much the same way that Ethereum L1 does. These sequencer/validators could then select a block produced for them by SUAVE.
This is very different from the SSs described above, where a rollup could completely remove the need for decentralizing their sequencer. They simply outsource this function by opting into something like Metro or ESQ, and they can choose to inherit its fork-choice rule. Ethereum, Arbitrum, Optimism, etc. wouldn't be changing its fork-choice rule to opt into SUAVE for all transaction sequencing.
SUAVE doesn't care what your chain's fork-choice rule is or how your blocks are chosen. It looks to provide the most profitable ordering possible for any domain. Note that unlike SS nodes described earlier, SUAVE executors are typically fully stateful (though they may also fulfill certain preferences which don't require state). They need to simulate the results of different transactions to create the optimal ordering.
To see the difference, let's consider an example where a user wants to run an atomic cross-chain arbitrage. These are the guarantees they could receive if they submit this preference to SUAVE vs. submitting it to a SS:
Now, how might SUAVE interact with rollup sequencers as they decentralize, and possibly even SSs? Espresso certainly seems to believe that SUAVE is compatible with ESQ, as described in their post. ESQ is intended to be compatible with private mempool services such as SUAVE that can act as builders. It would look similar to the PBS we're used to on Ethereum, except now:
As in PBS, the builder can obtain a blind commitment from the proposer (the sequencer here) to propose a given block. The proposer only knows the total utility (builder's bid) it will get from proposing the block without knowing the contents.
Putting things together now, let's look back at a searcher who wants to do a cross-chain arbitrage again. SUAVE on its own could build and send to two different rollups:
But it's perfectly likely that B1 wins its respective auction and B2 loses (or vice versa). However, let's consider what happens if those two rollups are opted into the same SS.
SS nodes are really stupid basically.
They have no comprehension of what transactions are actually doing, so they need someone (like SUAVE, or other MEV-aware builders) to build a full block for them if they're going to be efficient. Well, SUAVE executors could then submit both B1 and B2 to the SS, conditional that both blocks are fill-or-kill (execute atomically or drop both).
Now you can get really good economic guarantees throughout that whole process:
I recently made a post on the Flashbots forum about SUAVE's potential economics security models. TLDR I argued why rollups are probably a better option for SUAVE in the long-term than restaking.
Hasu also had some very thoughtful responses on the tradeoffs between restaking and rollups I encourage you to read. Here's the TLDR response:
But here's a new idea - what about doing both! A restaked rollup.
This doesn't address all of the concerns mentioned by Hasu, but it's a very interesting new option nonetheless, especially in the longer term.
Instead of being secured only by EigenLayer restakers (more like its own L1 borrowing security), a rollup could use those EigenLayer restakers for its local consensus, but the chain then rolls up to Ethereum (i.e., it posts its data and proofs to it).
As discussed earlier, rollups can decide to implement their own local consensus for stronger assurances around short-term pre-confirmations and reorg resistance prior to true L1 finality. Well, why don't we just make that rollup consensus set a set of Ethereum restakers? Now you've got both:
This is the same security as any rollup once the L1 has finalized it. This is simply a variation of a rollup implementing its own consensus. Just instead of having its own validator set on its rollup secured by its own native token as described earlier, it opts to have Ethereum restakers running the consensus.
Similarly, it would be interesting if Celestia were to enshrine some form of restaking (currently, the plan is for Celestia's L1 to be incredibly minimal with no smart contract capability). I've written previously that enshrined rollups would be an interesting direction for Celestia, and native restaking would be another fascinating tool allowing the free market to decide what features they want to bolt on. Restaking could also help Celestia's security budget, as the value accrual model of alt-DA layers is still unproven.
The simplest idea here (what rollups generally do today) is to run a single sequencer with naive FCFS. The sequencer just commits to transactions in the order they receive them. You can reasonably trust a single sequencer to abide by FCFS ordering, but it still incentivizes latency races and related negative externalities among other issues (TLDR: don't implement PoW to try to fix it). So even centralized sequencers will need to contend with MEV more effectively.
Some of the solutions above implicitly deal with it (e.g., hosting a total free-for-all public auction), but obviously no rollups want to say their users are getting sandwiched. So, we probably need to get creative. Combining the benefits of an auction + leveraging programmable privacy is where it gets interesting.
That's why centralized sequencers also like having private mempools today - trying to make sure that users aren't getting frontrun etc. But that's not easy to decentralize. If you open up to many sequencers, do you just trust them to run their own private mempools? Even if you do, that could be problematic if each has their own private mempool and you need to start rotating the active leader around.
Encrypted mempools are one fascinating area of research in addressing many of these problems. I'll simply refer you to this post I just made for the relevant information:
Encrypted mempools as a tool for MEV & censorship
This post is largely built around @drakefjustin's great presentations on the topic (links in post)
They're pretty complicated (at least for me), so I tried to break them down simply then expand a bit https://t.co/AYpIjnkods
— Jon Charbonneau (@jon_charb) March 15, 2023
In this post, I'll just give a brief overview of some variations of FCFS proposals.
Realizing the limitations and negative externalities of simple FCFS, Arbitrum has started to explore new variations of it. Most recently, they proposed their Time Boost mechanism. The basics:
The boost is computed by the following formula:
Where:
Today, searchers can only express their preference for fast inclusion to the Arbitrum sequencer by trying to minimize latency to it (opening up many connections, getting physically close to it, infrastructure investment, etc.). Time Boost would instead reduce the incentive to invest in the above latency advantages, as searchers can now express their preference for fast inclusion via their priority fee bid.
It's a clear improvement over naive FCFS, but still has some shortcomings in my opinion:
An alternative proposal (FBA-FCFS) for Arbitrum was made last year by Xin from Flashbots. This implements a frequent-batch auction style variation of Themis. In this proposal:
Similarly to the Time Boost proposal, there's some attempt to guarantee relatively fast inclusion (<500 ms proposed, but could be changed) and prevent front-running via trusted nodes. Again, it reduces the incentive to latency race (though doesn't completely remove all advantage) by allowing for searchers to express their preferences via fees.
There exists a remaining latency advantage for "fast searchers" at the end of a given batch where other "slow searchers" can't compete:
Source: Latency Arms Race Concerns in Blockspace Markets
This is a well understood aspect of these types of auctions. Longer batch times could further make that latency edge relevant a decreasing percentage of the time, though on potentially higher batch values. Longer block times can have other effects on MEV (e.g., staler prices).
Summarizing this latency edge:
Regarding the time delay:
FBA-FCFS results in more variability (e.g., transactions may slip to the next batch depending on receipt time), but inclusion time for regular user transactions not paying priority fees should on average be lower. Time is treated continuously in the Time Boost model (there is no notion of a block), vs. time is discretized in the FBA-FCFS model. Overall:
This post is already long as hell, and I'm tired, so please just read this post by Phil. Thanks.
Hopefully you have a decent overview now of the paths toward sequencer decentralization and the associated hurdles. This is one of the many challenges that rollups will need to contend with as they mature in the coming years.
Some other interesting areas of exploration include:
Disclaimer: The views expressed in this post are solely those of the author in their individual capacity and are not the views of DBA Crypto, LLC or its affiliates (together with its affiliates, "DBA"). The author of this report has material personal positions in ETH; Layr Labs, Inc.; Celestia; and Sovereign Labs Inc.
This content is provided for informational purposes only, and should not be relied upon as the basis for an investment decision, and is not, and should not be assumed to be, complete. The contents herein are not to be construed as legal, business, or tax advice. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. This post does not constitute investment advice or an offer to sell or a solicitation of an offer to purchase any limited partner interests in any investment vehicle managed by DBA.
Certain information contained within has been obtained from third-party sources. While taken from sources believed to be reliable, DBA makes no representations about the accuracy of the information.
