The Complete Guide to Rollups

Introduction

Vitalik gave us the amazing Incomplete Guide to Rollups. I present to you The Complete Guide to Rollups. 

Ok it’s not actually complete, but it’s a great meme so I’m stealing it. This report only analyzes the design space of rollups on Ethereum and Celestia. I strongly recommend my recent Ethereum report for background. 

I cover the two I’m most familiar with, but there are actually many other teams building here. Polygon (Avail), Tezos, and Milkomeda among others are also in the rollup stack game. Tezos in fact will likely be the first to ship “enshrined” rollups, and Polygon Avail is incredibly similar to Celestia architecturally. 

First, what are “modular” blockchains? It’s mostly a meme at this point with plenty of disagreement, but I’ll define how I use the term for simplicity. Then you can fight over why I’m wrong in my Twitter comments. 

Modular stacks strip apart the following tasks into separate technical components:

• Data Availability (DA) – Ensuring the transaction data behind rollup block headers has been published and made available so that anyone can recreate the state.
• Consensus – At minimum agreement over the transactions and their ordering.
• Settlement – This varies based on the implementation, but tasks can include verifying/arbitrating proofs and coordinating cross-chain asset transfers/arbitrary messaging.
• Execution – Computation taking the pre-state → run transactions → transition to the post-state.

Ethereum can handle each of these. It offers a unified DA, consensus, and settlement layer with general execution. When you transact on L1, Ethereum acts as any monolithic chain does. Alternatively, rollups can handle execution with Ethereum providing DA, consensus, and settlement. 

Celestia only provides DA and consensus. No Uniswap living on L1 Celestia, and no verification/arbitration of proofs by the L1. Celestia has no enshrined settlement layer or smart contract execution. The L1’s functionality is limited to Celestia token transfers and validator set management.

Note possibilities such as Validiums and Celestiums using separate layers for DA and settlement also exist. Any settlement layer could be used so long as it accepts an attestation from Celestia that the data has been made available. 

However, these are not rollups, and they bring meaningful additional security assumptions. This report will focus on actual “rollup” stacks. I’ll break down the economics first, then dive into each stack in depth.

I use a few abbreviations throughout to save your eyes:

• SCR – Smart contract rollup
• ER – Enshrined rollup
• SR – Sovereign rollup

 

Part I – Modular Economics

I’ve written previously about the importance of L1 value capture (fees and other forms of MEV). Assets which are relied upon for economic security need a high value staked. Revenue provides the fuel to craft attractive monetary policy (real yield, low and predictable inflation, etc.). Value capture → good monetary policy → monetary premium → high economic security. Fees and other MEV kickstart step 1.

 

Rollup Fees

Let’s analyze a rollup transaction from first principles. This simplified graphic depicts the parts which apply to both Ethereum optimistic rollups (ORUs) and zk-rollups (ZKRs):

1. Sequencer receives and orders transactions. Users quickly get a soft confirmation of their transaction eventually being recorded on L1 (if they trust the sequencer feed). Sequencer is only relied upon for ordering and transaction completion. They’re unable to submit invalid transactions. 
2. Deterministic state transition function takes each transaction and updates the L2 state, creating an L2 block. These blocks can be produced more quickly than L1 blocks. 
3. Every so often a batch of transactions is compressed and sent to the L1. Currently stored as calldata, but eventually rollups will use data blobs. 

Users are charged L2 gas when the state transition is applied, executing their transactions. L1 gas is paid later when the batch is posted. L1 and L2 gas prices vary based on their respective congestion. So the user is incurring costs in two types of gas, and there’s a timing mismatch. Sequencers commit to a transaction and collect L2 fees before they know the full contents of the batch, how well it’ll compress, or what the L1 base fee will be when posted. 

L2s do their best to guess what their L1 cost will be and charge users accordingly. When things are quiet, only a small margin is charged over the L1 cost on average. When rollups become constrained by their own execution environment (and not L1 costs), that margin goes up. Fee market surge pricing kicks in to meter demand. Higher margins correspond to bursts of high local demand.

We clearly see this in Arbitrum’s latest spike, though their margin has been quite stable otherwise. The recent bottleneck was L2 execution (not L1 costs), and so their native fee market kicked in:

We see similar trends with Optimism, though with higher variability:

Rollups’ L1 costs today are primarily calldata. Even for ZKRs, Polygon estimates that posting transaction data to Ethereum will represent ~90% of total costs (which is largely calldata) with ~10% for proofs. With EIP-4844 potentially coming as soon as the Shanghai hard fork next year, those costs plummet. It increases DA throughput and implements isolated EIP-1559 fee markets for Ethereum’s DA layer and settlement layer. An oversupply of DA means fees hit the floor. Later on, danksharding would make DA even more abundant. Rollups with any reasonable activity will significantly increase those profit margins.

Lastly – the figures above do not include any MEV (outside of regular transaction fees). In reality, rollup tokens are able to accrue significant value from MEV (more on this shortly).

 

Fixed vs. Variable Costs

ORUs post compressed full L2 transaction data (with signatures), L2 state roots, and fraud proofs (only in the event of dispute) back to L1. While the full transaction data is stored in Ethereum’s history, the hash of the transaction data is added to its state. If a fraud proof is delivered, then it can check the inclusion proof against the previously stored hash as part of the fraud proof. 

ZKRs don’t need to post the full transaction data to L1. It suffices to post the state differences (they choose this because it’s cheaper). Imagine Alice and Bob trade 1 ETH back and forth within the batch – ZKRs only need to post the state change at the end (who has that 1 ETH, and who doesn’t) whereas ORUs would need to post each trade. State diffs are enough to reconstruct the state. ORUs must include all transactions in the event they’re needed for fraud proofs. ZKR provers must also include a validity proof with every batching proving that the associated state root is valid. (For more on ZKRs, you can read our previous Pro report on it here.)

SCRs have fixed costs regardless of transaction activity they must pay to Ethereum: 

• State commitments
• Validity proofs (only for ZKRs)

And they also have variable costs which scale with the transaction activity:

• Transaction data (plus signatures for ORUs)

On top of these fees paid to L1, rollups charge surge pricing for L2 gas fees as needed and costs to cover rollup operator expenses. A more detailed analysis can be found here. 

Note the timing/cost tradeoff here. Settling frequently means the L1 gives true finality sooner. However, waiting longer to settle amortizes those fixed costs over more transactions = cheaper transactions for rollup users. Rollups balance settling often enough for safety vs. giving rollup users cheaper fees with lower assurances (pre-confirmations). 

Let’s look at Optimism as an example. For background, Optimism has two smart contracts that sequencers and proposers post to:

• Canonical Transaction Chain (CTC) contract – an append-only log of transaction batches submitted by the sequencer
• State Commitment Chain (SCC) contract – log of proposed state roots which proposers assert to be the result of each transaction in the CTC

Optimism’s cost breakdown looks like this:

Posting transaction batches to the Canonical Transaction Chain (CTC) incurs two costs:

• Variable cost – Calldata gas used by the L1 CTC (transaction batch) submitter which scales roughly linearly with the size of the transaction batch
• Overhead cost – Posting to the CTC also incurs small non-calldata costs

The gas used by posting state roots to the State Commitment Chain (SCC) is pure overhead cost (though note part of this cost uses L1 calldata as well). Splitting them up by variable/overhead you get this:

These overhead costs may be higher than you expected – there are still many inefficiencies to be ironed out in coming months. Optimizations such as Bedrock will significantly improve data compression, and it will drop fixed costs to near negligible. Gas costs per batch could drop from ~280k per batch excluding calldata to ~21k gas per batch. The SCC will be replaced by the L2OutputOracle, and the CTC will be removed. L2 blocks will instead be saved to Ethereum using a non-contract address, greatly reducing the on-chain footprint and minimizing gas costs. (For more on Optimism, you can read our previous Pro report on it here.)

Similarly, Arbitrum incurs gas costs of ~375k per batch which will be significantly reduced by Nitro. (For more on Arbitrum, you can read our Pro report on it here.)

Tying everything together, the below illustration from a great article by Barnabé Monnot depicts rollup value flows:

He also recently spoke on the topic here. 

 

Base Layer Fees – Ethereum

Ethereum fees are derived from: 

1. L1 Execution & Settlement – Go to L1 Uniswap, and swap some USDC for ETH. 
2. Settlement from Rollups – Rollups post proofs to the L1. Ethereum also handles trust-minimized bridging between rollups and the L1. 
3. DA from Rollups – Rollups post data to the L1 using calldata. 

Fees for isolated monolithic chains are capped at: 

Fees = Throughput x $ users will pay for individual transactions

Modular DA and settlement layers (such as Ethereum) have a higher ceiling as they’re capped at:

Fees = Throughput x $ users will pay for aggregated transactions

A rollup can pay Ethereum a larger single fee to settle many transactions (e.g., a proof securing many blocks, settling many aggregated DeFi pooling transactions, etc.) compared to what a single user can pay for an L1 transaction taking up the same block space. Introducing new fee payers to Ethereum (rollups) with a higher marginal utility per transaction adds value in the long-run assuming sufficient demand. 

However, note that Ethereum’s revenue kinda looks like this today:

Ethereum is a long way from being primarily a settlement or DA layer for rollups. The vast majority of fees paid to the L1 come from native L1 execution:

So while modular base layers are capable of extracting meaningful revenue should the demand arise from rollups, we need vastly more demand before they do so. It’s critical that Ethereum’s rollup fee capture is in addition to its native L1 execution, not reliant solely on it. 

Where that value capture goes from here is a point of debate. Many in the Ethereum and Celestia communities believe DA will eventually be incredibly valuable. Dankrad recently gave his views in a podcast I hosted between him and John Adler:

“Asset… needs to derive its security from some… means of generating yield. And so I see for now only two of these, which are the settlement layer and the data availability layer. I think short-term, we will probably see that the settlement layer still generates much more value.

We’ve seen it already that we have had significant fees on Ethereum in the past, and also some on other settlement layers. But long-term, I believe that the most valuable asset will just be in the data availability, that the block space will become the most valuable asset in the decentralized economy.”

What rollups should be willing to pay for premium DA is an interesting argument. However, the reality is that DA will soon be massively oversupplied between Ethereum scaling and alternative DA solutions. For some context on scale:

Ethereum blocks currently average ~90 KB with calldata ~10 KB of this. The DA supply shock is looming, and rollups will continue to significantly improve data compression. When data blobs get their own fee market and supply < demand, DA fees hit the floor. 

Rollup users will pay higher fees, but the primary bottleneck will likely be the rollups’ own native execution environments (based on current order of magnitude activity and DA bandwidth in EIP-4844). DA will no longer be your primary cost when you go to swap on your favorite rollup. Super cheap fees will drive incremental activity, more rollups pop up, etc. Only when DA is saturated up to the target will the EIP-1559 mechanism kick in, pulling fees off the lower bound. However, rollups have many upcoming optimizations which will increase their currently constrained native execution. If this is used up, that could eventually shift the goalposts closer toward DA becoming a larger cost again.  

For Ethereum to start charging anything meaningful for DA, you need more than 1.3 MB/s (assuming the current danksharding spec) of actual valuable data that demands the highest security. Even if you hit 1.3 MB/s, the overflow can just go elsewhere. Alternatives such as Celestia, DataLayr, DACs, Adamantiums, Polygon Avail and others will offer massive amounts of cheap DA. Only the most secure transactions require full Ethereum security. Also, DA throughput can be safely increased (with more validators), so 1.3 MB/s is not a fundamental limit. 

I’m confident that for at least several years, DA fee revenue will be negligible compared to robust settlement layers such as Ethereum’s. 

Lastly, native smart contract execution can also provide ETH stakers with more value than Celestia – ETH can be used to earn additional yield as a productive asset. In particular, EigenLayer is an innovative solution which will allow for “re-staking” of ETH. ETH stakers will be able to subject their stake to additional slashing conditions. They would secure new applications looking to leverage ETH’s economic security, and their fee revenue would accrue to ETH (very similar to Cosmos’ concept of interchain security accruing value to ATOM).

 

Base Layer Fees – Celestia

This is where Celestia comes in – the only cost is DA. Rollups handle settlement. In that same podcast, John made an interesting point regarding dYdX’s decision to move from StarkEx to Cosmos. Base layers should accrue as much value as possible for economic security, but economically rational apps want to accrue as much value as possible for themselves. All else equal, they prefer not to pay rent to a settlement layer. DA is the minimum cost of shared security. This accrues less value to Celestia, but it could incentivize more rollups to stay because it’s cheaper. 

I tend to disagree with this argument for the reasons I highlighted earlier. The costs paid to the settlement layer are actually relatively low. For ZKRs, costs approach 0 as the fixed cost is amortized over many transactions except for transactions that are settled, which users can pay for (so the rollup isn’t paying this). For ORUs, there are no real settlement costs. I therefore view this cost portion of this equation as negligible – teams will choose between SRs or using a settlement layer based on their particular needs. Both have interesting technical and social arguments which I’ll dig into later.

If Celestia’s business model of taking a smaller cut on a bigger pie is successful, note the percentage value capture can also matter. If the base layer only captures a miniscule amount of value relative to the value it secures, security leverage could get uncomfortable. Maybe you’re comfortable with $1 billion staked securing $20 billion of value (Ethereum’s security ratio is currently ~20x), but are you comfortable with $100 billion? $200 billion? There’s no correct answer. A base layer which is economically self-sufficient even without rollup revenue does not have this concern. 

It remains to be seen if relying on DA alone provides sufficient value capture to build economic security. DA is valuable, but it’s a resource we know how to scale incredibly well. A paradigm shift would be required for this to change. Looking at something like 5+ years out though, I don’t think anyone can reasonably predict. 

So that’s exactly what I’ll do now anyway. Back of the envelope DA giga-bull case math could look like this years down the line: 

Not bad, $30 bn! 

13 bytes per transaction would be a meaningful optimization from where we sit today, but it’s possible. For example, Polygon Hermez expects that they’ll eventually need only 14 bytes per transaction. At the current danksharding spec of 1.3 MB/s, you get the nice round 100k TPS. Note most rollups are currently nowhere near 13 bytes per transaction, and you can only get this low by posting state diffs as ZKRs are able to. If you post full transaction data as ORUs do it’s much higher, and even some ZKRs will choose to post full transaction data. It’s quite optimistic that every rollup will run near the lower bound of DA efficiency.

Note the $0.01/tx I assume here is only for DA. This does not include other L2 transaction fee considerations. Valuable real estate (e.g., a DeFi hub rollup) could certainly charge a premium, but cheaper state charges lower execution fees. This could even be enough buffer to clear Vitalik’s $0.05 test. 

It’ll be important to consider how those margins stack up for L2 fees in the long run (i.e., what % is paying for DA). If it becomes easy to spin up many chains, and bridging gets so good that app-specific rollups finally make sense, execution could become relatively inexpensive. This leaves some room for DA to get its penny. Significant bridging development will also matter a lot for whether SRs ever make sense over sharing a settlement layer, and the general stickiness of DA.

For reference, Ethereum captured ~$10bn fees in 2021, and its peak months had an annualized run rate >$20bn (note this does not include other forms of MEV). Something like $30bn/year could imply a market cap of a few hundred billion maybe? Is that enough? I don’t know. Personally, I’d want far higher security for nation-state level security, so this gets into a bit of a philosophical debate. At this scale, you’d be securing many trillions of dollars of economic activity, so I’d want more. 

Note the difference between Ethereum and Celestia here as well. Being “meaningful” for each one means different things. Maybe 10% of total Ethereum revenue is meaningful, maybe it’s 20%, pick a number. It’s got a cash cow settlement layer paying the bills anyway. For Celestia it’s simple – it has to be enough to fund its entire security budget to protect everything built on top of it.

The reality is those numbers shouldn’t be taken with a grain of salt, they should be taken with the whole shaker. They’re completely made up in a hyper-optimized rollup world to give you a sense of orders of magnitude over a very long time horizon.

Celestia faces a hurdle in bootstrapping economic security with little value capture. We’re used to startup valuations being a bet on future growth, but it’s an admittedly risky proposition when the entire business model (DA) hinges on a paradigm shift to accrue enough value for economic security.

 

MEV in the Modular Stack

MEV is a deeeeep rabbit hole, so I’ll keep it short here. 

Let’s start with the basics. MEV still isn’t quite formally defined, but I’ll oversimplify it here to all potential value that block producers can extract (including regular transaction fees, arbitrage, liquidations etc.). 

Simplified L1 Ethereum MEV will look like this with in-protocol PBS (or MEV-Boost in the interim):

Searchers bundle transactions and bid for their inclusion to builders. Builders aggregate searcher bids and bid for the full block to be included by validators. In an efficient market, searchers bid most of their revenue to builders who then bid most of their revenue to validators. As a result, ETH captures the majority of MEV. 

Rollups look a bit different, but similar concepts apply. This simplified example shows Optimism running an MEV auction (MEVA) for sequencing rights: 

Again, searchers bundle transactions and bid for their inclusion to sequencers. Sequencers aggregate searcher bids and bid for the full block to be included in the MEVA. In an efficient market, searchers bid most of their revenue to sequencers who then bid most of their revenue to the MEVA. You could also insert validators in place of the MEVA if the rollup uses staking for leader-selection. In either case, the rollup captures the majority of MEV. This can accrue to the token, or it can fund something like public goods (as Optimism does). 

All else equal, shifting a transaction from L1 to a rollup doesn’t change the amount of MEV. It just shifts how it’s captured and who gets it. In this simplified model, the MEV capture has now been pushed from the L1 asset to the L2 asset. 

But is it that simple? Honestly…

And neither does anyone else yet. So if you’re a curious fellow this is a great area of research. How much MEV will leak down to shared DA and/or settlement layers? Will rollup operators start paying the L1 for their MEV executed on L2? If something like a cross-domain Flashbots arises we could gather more concrete data. Let’s look at some hypotheticals for now.

The simplest idea is that it will always accrue to the bottom of the stack. For example, look at a stack with Celestia DA + settlement rollup + recursive rollups. Recursive rollups may be dependent on the settlement rollup for cross-chain MEV, but the DA layer may be able to censor and delay the settlement rollup’s blocks, demanding a piece of that MEV being captured. This kind of negotiation is contingent on social norms and could be a tricky line to cross (similar to time bandit attacks in PoW). The power is there, but will that negotiation happen? Maybe the L1 wants to eat the rollup’s lunch, maybe not. 

Then there’s the fancier cross-chain MEV. In the following example:

• R = Rollup 
• B = Block 
• S = Swap 

R₁ and R₂ have coordinated sequencers and they share the same DA layer. This allows for atomic cross-chain MEV. Each rollup could submit blocks whose acceptance is contingent upon the other. For example, only accept R₁ B₁ (which includes S₁) if R₂ B₂ (which includes S₂) is completed, and vice versa for R₂’s conditions. Similarly, a rollup could submit two blocks to its DA layer, one which is the base case, and another which is only to be included if some condition on another rollup is met. The atomicity introduced here could be quite powerful, and it will be interesting to see how it impacts the dynamics of MEV value accrual. 

Importantly, this is a wild card for value accrual. If more MEV leaks down than we’re currently aware of, this could accrue significant value to Celestia. This would help subsidize the security budget. 

 

DA Layer Economic Security

Let’s take a look now at why we even care about DA layer economic security.

 

33% Attack

This one is pretty simple – halt the chain. Tendermint cannot progress (liveness failure) if it does not have the requisite votes to finalize (⅔). Rollups dependent on Celestia wouldn’t love this. 

Ethereum runs Gasper for consensus. So even if >⅓ of stake is faulty, Ethereum keeps chugging along retaining liveness. However, this ledger cannot finalize without the requisite votes. If the faulty >⅓ simply fails to vote, they will be inactivity leaked out until the protocol is eventually able to finalize again.

 

67% Attack

First off – validity conditions are a part of consensus. So even if you control 100% stake you can’t start printing a bunch of Celestia tokens/Ether out of thin air, steal funds, etc. Honest nodes will reject this as invalid. You could try these though:

• Double signing – Re-orgs are possible in Gasper, but they’re not in Tendermint. You could still double sign though, causing confusion. The chain would halt and revert to social consensus. It’s provable that at least ⅓ of stake double signed at the same block height, and will be slashed in-protocol. So you can do this, but it will be expensive (if staked value is high). 
• Data withholding attack – Finalize a block and never make the data behind it available. Data withholding is a non-attributable fault, and as such cannot be slashed in-protocol. Social coordination is needed to slash the attacker out-of-protocol via hard fork. This is likely the worst attack for rollups. You wouldn’t be able to submit a fraud proof for an invalid ORU, and you wouldn’t be able to recreate state for a ZKR. Thankfully, we have data availability sampling (DAS) nodes. They simply check if the data was made available, so even if consensus signs off on the block they know to reject it. 
• Fraud proof censorship – A censoring DA layer can maliciously bridge funds across rollups (even for rollups within the same DA zone of security). This is not protected by running a DAS node. This one’s a bit nuanced so I’ll give an example.
  • SR₁ (sovereign rollup) is an ORU on Celestia that wants to bridge funds to SR₂. One option is to directly embed light clients of each other into each rollup, and distribute proofs P2P. No censorship attack vector here via a malicious consensus (other attack vectors exist, such as an eclipse attack). Alternatively, SR₁ could post fraud proofs directly to SR₂’s Namespace Merkle Tree when it wants to bridge. This effectively swaps out the synchrony assumption (in the case of P2P bridging) for an honest majority assumption of Celestia (in the case of posting it to Celestia). SR₂ just looks out for a proof on its own NMT that it’s already tracking, and executes when it sees it. However, this now allows SR₁ to maliciously bridge funds to SR₂, and Celestia could censor your proofs at the DA layer. Ethereum can also censor fraud proofs sent to smart contracts, which is why their ORUs require such a long timeout period. 

The data withholding and censorship attacks do not directly affect the DA layer itself, but they are attack vectors for the rollups reliant on the DA layer.

TLDR here – DA layers need economic security. With varying levels of stake taken over, you can do bad stuff. A key point here that I have seen many confuse – just because something is relied upon for security, does not make it valuable. You must first build a valuable asset, and only then it can be relied upon for meaningful economic security. The asset securing the system needs some way to accrue value and/or monetary premium. 

If you want to witness the Great Modular War of our times, please read this thread. Pop it open on Treeverse, and spend a whole day sifting through it. The vast majority of this report (and honestly most of my crypto knowledge) is sourced from me taking notes watching Twitter mayhem. 

Summary

Revenue generation is a key component of building economic security, so understanding value flows in the modular stack is critical to design. Base layer native assets need to be designed for value capture (fees and other MEV) and/or being good money. 

As it stands today, DA captures negligible value. This will remain the case for the foreseeable future. Rollup execution layers capture a relatively small amount of value currently. As certain ones become incredibly popular and potentially contain high value financial transactions, they could see meaningful revenue. Premium general-purpose settlement layers with high value transactions dominate (potentially even L2 settlement layers as StarkNet plans to be with many L3s on top), and likely will for the foreseeable future. 

This is Russ. Russ put radio on the internet. Don’t be like Russ. 

Part II – Ethereum Rollup Stacks

Mustafa recently offered the most concise definition of rollups which I’ll use for this report. Rollups are blockchains that post their blocks to another blockchain, and inherit the consensus and DA of that blockchain. 

Rollups have various actors such as sequencers, proposers, provers, and challengers depending on the implementation. I collectively refer to them as “operators.” Operators combine user transactions and periodically post data to the base layer. They also submit commitments to the updated rollup state (e.g., Merkle roots). 

Anyone can use the compressed transaction data (as long as it was made available) to recreate the state and check if a state transition is valid. Rollup light clients do not download and execute the full transaction data though, so they rely on fraud/validity proofs for assurances that the state transition is valid. 

 

Ethereum – Smart Contract Rollups

We see these on Ethereum today (e.g, Arbitrum, Optimism, StarkNet, zkSync, etc.). They look like this:

Smart contract rollups (SCRs) effectively live in a series of L1 smart contracts. Rollup execution is handled off-chain, and operators periodically post back to the L1. The smart contracts verify proofs/arbitrate disputes as needed. They also track all rollup state roots and transaction data so they can recompute the state:

Fraud (ORUs) or validity (ZKRs) proofs then confirm the validity of the state transitions. Operators post a bond in the L1 smart contract to publish blocks. If the block or proof was invalid, their bond can be slashed and the transactions will not be finalized. This can take over a week for ORUs, but validity proofs finalize instantly.

Submitting and arbitrating a fraud proof is actually quite fast. ORUs need such a long timeout period primarily because the L1 smart contract needs to receive the proof, and this can be censored. In the event that the L1 censors the proof, we need time to coordinate via social consensus. 

These smart contracts also serve as trust-minimized two-way bridges between the rollups and L1. This is one of their key advantages. It’s trust-minimized because rollups implicitly fully validate Ethereum, and the smart contract on the L1 acts as a light client (receiving block headers protected by fraud/validity proofs) of the rollup. 

Now for the FUD. 

These are still smart contracts. You don’t have to look far to see scary bridge hacks (which have largely been bugs, not compromised keys or economic attacks). Rollups aren’t immune. The contract is a very special trust-minimized two-way bridge, but it’s still a bridge. You slip a typo in your code and ya boy here rugs your bridge, oops.

That’s why many rollup teams are holding tight to their upgrade keys for now. There’s often a multisig committee with an upgrade notice period, and in others the code can even be changed arbitrarily by the team without notice. 

There’s a balancing act on upgrade timing between safety and trustlessness. If you discover a bug, you probably don’t want to blast it out on your governance forum and wait a month. You want to fix it. 

One idea is to have delayed upgradeability, but add a halt button which could stop the rollup immediately. It’s not pretty if you need to halt, but it reduces the trust placed in whoever holds the upgrade keys.

Bartek recently gave an awesome rollup FUD speech on this topic and L2Beat’s risk framework linked here. 

Here’s a related fun take to get everyone mad at me:

I understand it takes time for the training wheels to come off here. My point is just to be realistic about what stage much of this is still at. As with the centralized sequencers and fraud proofs (if any), the teams here intend to progressively decentralize.

There are two options for handing over upgrade keys:

1. Immutable rollup – Nobody can upgrade the smart contract (unless the L1 will fork to do so). This is a massive tradeoff. You basically accept that this rollup will be deprecated eventually, and you’ll just deploy another instance from scratch. Rollups that aim to be EVM-equivalent definitely can’t do this. When the L1 changes, they must upgrade their own VM in line. Fuel v1 is currently the only immutable rollup live on Ethereum today.
2. Decentralized governance – This is what I actually expect. It adds trust assumptions beyond transacting on L1 though – rollup governance now controls the upgrade keys. SCRs can build in delays (set longer than the rollup’s withdrawal period) before upgrades can take effect. Don’t like the upgrade? Then you can safely exit. This is trust-minimized as you’re now just acting on a synchrony assumption for rollup governance (not an honest majority assumption). You just assume that you see the planned upgrade and exit before then.

Great conversation here from the major rollup teams on their thoughts around decentralizing. 

Back to that last point – rollup exits. An L1 execution layer to safely exit to is a nice fallback. Ethereum has this option, but Celestia will not. They’re practical in isolated cases, but quickly forcing thousands of users back onto L1 with small amounts of money in a future where L1 gas fees are $1000/tx doesn’t seem great. One area that should be explored more is designing the ability to exit to another rollup.    

 

Key Takeaways I

Trust-minimized two-way bridging is incredibly valuable – you have a giant ecosystem of rollups all tapping into shared liquidity and interoperability. Mostly condensing security assumptions into one ultra-secure base layer is great.

But smart contract bugs and upgradeability are kinda scary for now. Immutable rollups alleviate many concerns, but for an unworthy tradeoff. 

Eventually, battle hardened contracts with well crafted governance (with upgrade delays) will be a great solution approaching the security of the L1 itself. 

 

Ethereum – Smart Contract Settlement Rollup & Smart Contract Recursive Rollups

StarkNet has some pretty cool fractal scaling plans as a tangible example here:

1. Today – StarkEx. dYdX, Sorare, and Immutable X are already running at massive scale. But they aren’t general-purpose or composable. They’re islands built via contractual agreements with StarkWare. 
2. Soon – StarkNet. A general-purpose permissionless rollup like the SCRs we’re used to. 
3. Later – Fractal scaling. StarkEx instances (and other L3s) can deploy on top of StarkNet:

Today you have the following relationship between L2 and L1:

And it would look like this with an L3 on top:

Recursive proofs are a pretty mind blowing path to scaling. A verifier contract on L2 can accept many L3 validity proofs, create one validity proof that it verified those proofs, and post that one proof to Ethereum. This efficiency matters in a gas-constrained environment like Ethereum. L3s will likely also experiment with off-chain DA solutions for even further cost reduction (though with stronger security assumptions).

 

App-specific Rollups

These L3s are a natural fit for app-specific ZKRs. Much of the L3 appeal is controlling your own environment away from “noisy neighbors” while retaining network effects via the L2 settlement layer. As bridging and interoperability continue to improve, I expect to see more app-specific ZKRs deploy. They’ll retain most of the advantages of shared execution environments but shed the downsides.

Additionally – show me the incentives, and I’ll show you the outcome. App-specific rollups capture more value than being deployed as a smart contract, as your token now captures execution fees and other MEV. This isn’t worth the tradeoff though if leaving a shared execution environment isolates you. Which is why as I mentioned, better bridging, liquidity sharing, etc. will be critical for this trend to unfold. 

 

Key Takeaways II

Recursive rollups present an attractive value proposition, particularly for app-specific use cases. You get increased scale in a flexible environment while retaining network effects. The L2 can act as a more scalable settlement layer than Ethereum is currently capable of. As long as their data gets pushed back to L1, they’ll have similar security assurances as L2s – they’ll be able to recreate state and exit. 

 

Ethereum – Enshrined Rollups?

This is the crazy stuff – enshrined rollups (ERs) are a bit futuristic. Some of it’s also controversial, which makes them even more fun. 

You’ve probably heard ERs tossed around on Twitter, but don’t actually know what they are because nobody’s ever written about them extensively (except for Justin Drake here, who helped me a ton for this section). I got you.   

ERs are built directly into the L1 spec rather than deployed as a smart contract. This removes the risks of malicious governance/multisig upgrades or bug risk (external to Ethereum itself). They’re aligned with the social consensus of the base layer within the scope of hard forks. 

At the merge, the execution layer (f.k.a. Eth1) will be merged with the consensus layer (f.k.a. Eth2). The execution layer (which settles to the consensus layer) is what could upgrade to an enshrined rollup.

 

Enshrined Rollups – Optimistic vs. zkEVM

Transitioning to an ER is likely quickest as an ORU. With weak statelessness already in Ethereum’s roadmap, you can easily add fraud proofs. The simplest fraud proof is distributing the block itself in isolation to re-execute (which will now include witnesses along with the pre/post-state roots, transactions, etc.). However, fraud proofs and finality aren’t exactly friends, so this isn’t ideal.

The ambitious “plan” is instead to shoot directly for enshrined ZKRs. There’s already a team at the Ethereum Foundation led by Barry Whitehat building a zkEVM. Note this is a massive undertaking that will take several years. 

Whether ORU or ZKR, the point is that full nodes no longer need to execute transactions (unless there’s a fraud proof). This applies to consensus nodes as well – neither the proposer nor anyone in the committee executes. 

 

Step 1 – Upgrade the Settlement Layer to an Enshrined zkEVM Rollup

“The settlement layer is upgraded to an enshrined zkEVM rollup. The entire Ethereum ecosystem – potentially thousands of rollups/volitions and millions TPS – will be verified by a single succinct ZKP. Hallelujah.”

This is the pretty non-controversial step (once the tech is safe, well understood, etc.). The single instance EVM we know today gets upgraded to a state root equivalent zkEVM. This means each L1 block comes with a SNARK proving the state root is valid. 

There are some open implementation details, as this is still years away. Regarding proof distribution, you now have two options:

• Sidecar – The SNARK (or SNARKs, implementation detail) is just sent around as a sidecar, and people can verify it implicitly.
• On-chain – The SNARK does actually go on-chain, and smart contracts can readily have access to the proof itself to verify it.

Ultimately, there are two layers to consensus – social and code. The sidecar approach would lean toward social reliance, and the on-chain approach would lean toward code.  

 

Performance Bottlenecks

As mentioned, ERs remove the need for full nodes to re-execute transactions. This makes syncing to the chain easier, and it also removes compute as a bottleneck for validators. Several consensus bottlenecks exist for validators today:

Weak statelessness already knocks off storage and disk I/O – clearing the primary bottleneck we have today. But full nodes would still need to execute every transaction at this stage. Getting a SNARK for every block’s validity would knock compute off as well. Statelessness and zkEVM each represent opportunities to raise gas limits as you remove more bottlenecks. Bandwidth is then the only major resource requirement left (which also scales with Nielsen’s law). 

 

zkEVM Enshrined Rollup Benefits

• Simpler consensus – Statelessness (without fraud proofs) still requires full node execution, but zkEVM removes this bottleneck. Execution clients can swap out thousands of lines of consensus-critical EVM execution code for much simpler SNARK verification code.
• No state witnesses – Statelessness allows consensus nodes to stop keeping state on hand. They now receive witnesses (Verkle proofs) proving correct state access in every block along with the transactions. zkEVM removes this need as well – state diffs suffice. This increases validators’ consensus bandwidth efficiency allowing for higher gas limits.
• Safer light clients –  Light clients filter invalid state roots with SNARKs much more quickly than with fraud proofs. This allows for safer and/or faster Ethereum to alt-L1 bridges.

 

Step 2 – Deploy Many Parallel zkEVM Enshrined Rollups

Oh, you thought execution shards were gone, did you? Well get ready for the sequel – ERs. (Despite the meme, these are gonna be like Part II not Part III, so even better than the first one). 

Once the single-instance EVM has been upgraded, it’s not too hard to deploy many (e.g., 64) parallel zkEVM ERs. This is a form of homogenous L1 execution sharding. It’s also a question whether this sharding will even be needed any time soon. As a zkEVM ER, the single instance throughput could be increased by orders of magnitude over current capacity. 

The distinction can seem blurry for typical execution shards vs. ERs, and there’s been plenty of messy Twitter debates over it. The key point again is that full nodes do not need to execute ER blocks. So execution shards with zk-proven state roots can be ERs. You get the same scalability and functionality as a regular SCR (proposers just need to accept a proof and check DA), but you get the advantages of the rollup being enshrined in consensus (will elaborate on these shortly).

The old execution sharding assigned subsets of the Ethereum validator set to each shard. Each monolithic shard would handle its own execution, consensus, and DA then checkpoint back to the Beacon Chain. 

zkEVM ERs only handle execution (making them far more efficient), similar to the rollups we see today. They rely on the Beacon Chain for consensus, settlement (posting proofs), and DA (they would consume data blobs). 

Another implementation detail regards committees. It’s possible to have a committee of proposers at each rollup verifying a SNARK and then sending it along to the main settlement rollup. Alternatively, you could just skip the committees and have rollup block producers send the SNARKs directly to the main chain where all proposers operate. 

Either way, proposers are just accepting the highest bid, checking DA, and verifying a SNARK which comes with each rollup block as an extra field. You can think of it all as one big block. It looks something like this:

Advantages of zkEVM Enshrined Rollups

Upgrading the current settlement layer seemed obvious, but what’s so great about enshrining all these other zkEVMs vs. just being zkEVM SCRs?

• Social alignment – ERs inherit L1 social consensus. SCRs currently have centralized operators holding the upgrade keys, and eventually this risk will lie with rollup governance. 
• Economic alignment – All ER fees and MEV accrue to ETH. Nuclear zombie apocalypse World War III economic security. 
• Subsidized proof verification – ERs can subsidize the cost of proof verification vs. SCRs which have to pay EVM gas for settlement. Verifying SNARKs will be very cheap at this time anyway. This mitigates issues that rollups work around today. For example, rollups like Arbitrum will delay settlement to avoid L1 gas spikes at times. 
• Optimal settlement latency – Consensus can enforce SNARK proofs for every ER block giving per-block settlement latency.
• Optimal liveness – Centralized rollup sequencers can go down (we’ve seen this happen). SCRs can also elect to have their own consensus for sequencers to give pre-confirmations (StarkNet will do this). This suffers from suboptimal liveness because the external consensus may fail and L1 escape hatches only activate after a timeout.
• State root EVM equivalence – Current tooling and light clients will work out of the box. SCRs today are mostly targeting a Solidity-compatible VM (e.g., zkSync) or a bytecode equivalent EVM (e.g., Scroll), not full EVM state root equivalence.
• Network effects – Grows the EVM’s network effects even further from its already leading position. Allowing developers to coalesce around a standard is valuable. (Though conversely, experimenting with new VMs could also yield exciting possibilities).
• Maximum gas efficiency – ERs use native opcodes because they’re built into the protocol. SCRs instead may have to work around VM inefficiencies.

 

Disadvantages of zkEVM Enshrined Rollups

They’re not perfect though:

• No public goods funding – Private rollups like Optimism have discretion to redirect their revenue to fund public goods. ERs would be limited to funding L1 security and burning ETH.
• Suboptimal compression – SCRs currently settle on-chain far less frequently than every block, allowing for better data compression. They may also have custom or frequently-updated dictionaries for improved data compression.
• VM inflexibility – An Ethereum ER would likely be an EVM. SCRs are able to adopt other popular VMs (e.g., WASM, RISC-V, MIPS) or create a new one (e.g., Cairo, FuelVM). A custom zkVM may be able to achieve better data compression than a zkEVM.
• Harder pre-confirmations – SCRs may choose to have a centralized sequencer that provides instant (~100ms) pre-confirmations for better UX. This is harder to achieve with decentralized sequencing for ERs.
• Last mover – ERs will be very slow to make any changes due to the conservatism of the L1. Upgrades would go through the governance process (EIP and forks). To hedge against circuit bugs, a redundant multi-circuit setup (e.g., 2-of-3) or heavy formal verification may be required.
• Potentially increased builder cost – The builder now must create a proof, unless the sequencer and prover are split into separate roles (which is possible, implementation detail). Ethereum could also decide to issue ETH to offset ER proving costs. This gets to the question of “exactly how specialized will block building end up?” I currently expect meaningful centralization regardless (due to the economic incentives, as I’ve written about previously), but we don’t know for sure. Proving will also be significantly cheaper and faster when this is implemented. 
• Justin will have to redo his projections because so much ETH is gonna get burned.

 

Speculative Advantages of zkEVM Enshrined Rollups

Builders operating across multiple ERs (or potentially building all rollup blocks, settlement, and data) could offer synchronous interoperability between ZKRs. 

For example, builders could put down collateral and promise to include your synchronous transactions. If they accept your bid but fail to execute the transactions, they would stand to lose their bond. crLists could also assist in providing pre-confirmations, as proposers (who can also optionally be bonded with collateral) would be able to force inclusion of transactions.

The economic incentives lead to builders operating across rollups – we already see this centralizing force with cross-chain MEV today. These soft confirmations for synchronous interoperability are something that users will want, and they’ll pay for it. If you’re able to offer this service, you can make more money. If you can make more money than everyone else, you become the best builder. 

Note that similar dynamics are at play with ZKRs making synchronous calls to the L1 even prior to any of this. This possibility is retained by the new danksharding design as everything is confirmed in one block. For example, you could bridge down funds to L1 and then execute a swap with those funds all in the same block. To offer this service though, you would need to control L1 and L2 block production to ensure both legs will execute (i.e., only bridge these funds if this swap gets executed right behind it). This is a centralizing force for block builders across rollups and the L1. 

 

Arguments Against Enshrined Rollups – Credible Neutrality

Upgrading the single instance EVM to a zkEVM seems like a no-brainer (if and when we get comfortable with the technology). That next step of 64 enshrined rollups is the more controversial part. 

“Most of the stuff in the blockchain is opinion things as it turns out and less about technical stuff.” No exception here for the case against ERs. Here’s a fun thread of Ethereum devs, Celestia devs, and Ethereum shitposters making good cases on both sides. There’s plenty of disagreement here. Some worry that ERs do this to SCRs:

The argument posits that ERs would inherently compete with the SCRs that Ethereum is trying to foster, hurting its credible neutrality. SCRs would feel like “second-class citizens.” It could “limit the credible neutrality of the Ethereum settlement layer, weakening its socio-economic guarantees to non-ERs.” This is a similar line of thinking as the debate over Cosmos Hub minimalism. This interesting balance of base layer functionality/minimalism is something that Vitalik has discussed before as well. 

 

Arguments for Enshrined Rollups – Credible Neutrality

Conversely, some argue that ERs could protect Ethereum’s credible neutrality by preventing any commercial rollup team from becoming too dominant. Say “Rollup Labs A” becomes too successful, and their rollups crowd out everyone else. Having such a reliance on one private team could be a serious concern to Ethereum’s credible neutrality and network effects. A neutral balance from ERs could alleviate this. 

Going a step further, a successful rollup ecosystem could even break away from their Ethereum alliance. 

This is the argument Ali Atiia has made in the past:

The current Ethereum scaling plan is primarily to be a DA layer for SCRs with a constrained settlement layer. Ethereum relies on rollups for scalable computation. However, SCRs could cut off the “aging middleman” and bring in their own rollup-native assets. 

The hypothetical example cited was that Optimism, Circle (USDC), MakerDAO (DAI) all share the same investors. Investors promote cross-pollination of portcos, and natively deployed assets are cheaper with better UX. It thus makes economic sense for Circle and MakerDAO to deploy USDC and DAI respectively on Optimism natively. Once a rollup has built up sufficient native assets, DeFi, and security they may decide Ethereum is no longer providing them sufficient value.

To build stickiness, Ethereum needs a better settlement layer. DA alone may not be sticky enough. To build the best settlement layer, you need scalability and shared liquidity. ERs make communication between SCRs vastly more efficient. The “hyper-scale” L3s we hear about today could become more feasible just one layer above Ethereum’s ERs. ERs become the go-to place for sovereign and institutional settlement using the highest value dApps = massive liquidity.

 

Personal Views on Enshrined Rollups

ERs do not threaten Ethereum’s credible neutrality. Yes, activity will occur on ERs that may have in theory gone to SCRs. But this is exactly the same argument that was made against Ethereum SCRs, and continues to be spread by many monolithic alt-L1 proponents. SCRs are not parasitic to Ethereum – they are synergistic. ERs are not parasitic to SCRs – they are synergistic. Ethereum is better off with SCRs, and SCRs are better off with ERs.

ERs grow the pie by far more than they capture for themselves. 50% of a watermelon is better than 100% of a grape.

SCRs will always be the home of innovation and higher scale, and they’ll continue to host the vast majority of rollup activity as a result. ERs are about making sure that Ethereum lives up to its end of the bargain of remaining the best settlement layer around:

• Trust-minimized bridging and access to the largest pool of shared liquidity
• Higher scale makes bridging massively cheaper for SCRs living on top, opening up incredibly exciting new possibilities

I don’t go quite so far as Ali’s concern that Ethereum rollups will break away, though others share a similar sentiment:

If rollups are economically rational actors, they have a simple equation to weigh:

ERs tip this scale even more favorably in both directions – they make Ethereum a better settlement layer and they provide lower cost to SCRs on top.

Spinning off a rollup to become an isolated L1 (with an insecure pairwise bridge) shrinks your pie massively, and all you get in return are ever so slightly improved profit margins (saving on cheap settlement fees). Additionally, you’d need to subsidize your own security now, likely by issuing inflationary block rewards. This makes no economic sense.

The one potentially economically rational argument for why a rollup would leave Ethereum is if they can make a better settlement layer. Then maybe you could capture a bigger pie in theory. The only way I think anyone has any shot is with the following:

However, you sacrifice massively on that latter half of network effects, decentralization, and credible neutrality. It makes far more sense to build a settlement layer *on top of* Ethereum, exactly as StarkNet is doing with their L2. You get the best of both worlds – a high value financial settlement layer that retains the massive upsides of Ethereum, all for a very small price.   

 

Protocol Complexity

Vitalik hit on a very important topic in his recent EthCC speech. Ethereum is entering its most rapid period of innovation. Lots of goodies planned in the next few years. However, layering on complexity means more risk, and it’s getting tougher even for Ethereum devs to keep up with the rate of innovation (tryna do my part here!). While Ethereum doesn’t need to ossify completely, it will eventually pump the brakes a bit:

It’s fair to note that adding zkEVM ERs isn’t exactly a walk in the park. However, they appear to me as the final major step in Ethereum’s ambitious roadmap, somewhere around the top of that graph as the curve is plateauing. We’ll slow down one day, but not quite yet.

 

Key Takeaways III

My favorite analogy here is that ERs are the public sector and SCRs are the private sector. SCRs remain the home of innovation and most rollup activity. ERs are the slow and steady predictable base layer for them to operate on top of, providing the utmost security. Both coexist harmoniously. ERs add far more value to SCRs than any marginal activity they cannibalize. 

Ethereum already has a convincing plan for scaling DA. But that doesn’t mean it should be content with its settlement layer. Ethereum can and should compete here as well. zkEVM ERs offer the best route to scaling L1 Ethereum, positioning it as the dominant settlement layer. 

ERs’ economic and social alignment with Ethereum retains their credible neutrality, creating an incredibly cohesive system. Ultrasound money² yields next level economic security, subsidizing security for the entire ecosystem. 

The only argument against ERs is a “social” one around neutrality and competition. While I understand these concerns, I believe they are generally overstated and are vastly outweighed by the upside. Ethereum should certainly pursue one zkEVM ER when the tech is ready, then evaluate parallel instances later on. 

You didn’t think that Ethereum’s base layer would be weak and low throughput forever did you, anon?

Ethereum – Settlement & DA Layers

Now that we have a better understanding of how these rollups work, let’s turn back to what they actually need out of their base layer. 

DA is obvious – make it super cheap, offer a lot of it, make it easily verifiable with DAS. Ethereum and Celestia both aim to do this in one way or another.

My general thesis regarding settlement – I do not believe the best settlement layers will be restricted to the core functions of just verifying/arbitrating proofs and bridging tokens. Ethereum should retain a rich general-purpose native execution environment. This will be home to the likes of large scale DeFi which is not price-sensitive on a per-transaction basis. This provides massive network effects, liquidity, and built up security for SCRs to tap into. 

Ethereum should have a long-term focus on scaling the settlement layer (statelessness, zkEVM).

 

DeFi Pooling

Maybe some of you have a private jet, but most of us fly commercial. I need to split the bill with everyone else on board. That’s kinda what DeFi pooling is. 

• Fragmented liquidity is bad – so it’s good to pool liquidity in one place (like Ethereum). 
• But high fees are also bad – so do we need to break up the liquidity to avoid congestion? 
• No – we just fly commercial on L2. 

If I want to deposit $100,000 USDC into Yearn, paying $10 is fine. But paying 10% on a $100 deposit makes no sense. Instead, an L2 can take 1000 people who want to deposit $100 into Yearn, bundle them all together, and just make one L1 deposit! All without the user ever paying an L1 gas fee – you just pay your $0.01 share of the fee. In fact, this is exactly what Argent is already offering from zkSync. 

Aave is also exploring this as part of its deployment on StarkNet. They would develop a smart contract to aggregate L2 user deposits, then deposit them on L1. The contract would distribute aTokens from Aave L1 to StarkNet users according to their proportion in the pool. The contract would aggregate users’ aTokens and deposit them to L1 Aave when redeeming their collateral. (Our recent report on Aave can be found here Aave: A Review Of The Fundamentals).

Here’s an oversimplified version of what it looks like:

 

Decentralized AMM (dAMM)

dAMMs were first proposed by StarkWare last year in collaboration with Loopring. I’ll summarize their design here. However, note this is an area of active research with open design questions. There are no live implementations, and future designs could look quite different from this one. 

dAMM is an L2 AMM that aggregates liquidity in a single L1 pool enforced by an L1 contract. Execution happens across multiple ZKRs asynchronously sharing liquidity. LPs serve the L1 AMM while partaking in L2 trading, exposing them to more trades. (Higher trading volume) / (same liquidity) = higher fee % → better capital efficiency. 

Asynchronicity = L2s can process transactions without mandatory communication with other L2s using the same dAMM L1 liquidity pool. This is key to making shared AMMs possible.

This is achieved by separating the liquidity pool from the pricing state. Because the funds and state are decoupled, you can have multiple states (for multiple ZKRs) utilizing the same liquidity pool. Each ZKR gets its own dAMM state. 

The contract agrees to provide whatever price is offered by the L2 state as long as the L1 contract has enough liquidity to fulfill the quote. All states should return to an equilibrium ratio due to arbitrage. 

This solves the main hurdle in sharing an AMM between L2s – concurrency risk if users can trade at the same time. This could otherwise make it impossible for each L2 to know if it can settle safely. 

 

Impermanent Loss (IL)

LPs are at a greater risk of IL in dAMMs – the risk grows linearly with the number of markets the LPs are exposed to. So the worst case subjects LPs to n times the IL they would have suffered under a regular UniswapV2 AMM. This isn’t concerning for stable pairs (e.g., in Curve), but it could be high for other pools. This can be mitigated using a parameter in the smart contract known as the dAMM “Health Factor” which limits the max IL LPs can suffer. This Health Factor can guarantee that the dAMM liquidity ratio does not fall too low.

 

L1 <> L2 Simultaneous Trading

This design can support multiple independent markets on L1 and L2 all sharing the same liquidity. L1 liquidity (e.g., trading on Uniswap) can be used as dAMM liquidity by allowing L1 LP tokens (e.g., from UniSwap ETH/DAI) to be deposited directly to the corresponding pool on the dAMM (e.g., ETH/DAI).

dAMM can support L1 trading, but the Health Factor can no longer be easily mitigated. LPs can choose to take on this additional risk and expose themselves to L1 trading though. 

 

Stickiness  

Vitalik has made his thoughts clear on the other side of Ali that sharing a DA layer along with settlement is indeed quite sticky:

Much of this comes back to Vitalik’s famous post about why the future is multi-chain but not cross-chain. TLDR here, trusted pairwise bridges mean a 51% attack on the connected chain = your bridge gets rugged (and many bridges are actually far worse). Similar principles apply if you settle to Ethereum but post data elsewhere (e.g., in a Celestium). If Celestia gets majority attacked here, you’re out of luck again. 

Rollups sharing a DA and settlement layer avoid these issues because they get trust-minimized bridges with each other (it’s also possible to get trust-minimized bridging with only DA and no shared settlement layer, will touch on this later). If Ethereum doesn’t get 51% attacked, you can’t 51% attack the rollups separately. Even if Ethereum were to get 51% attacked and reverted, then its rollups would revert as well, remaining consistent. As a result, you can safely hold assets that were issued on one rollup and wrapped on another.

So sharing a DA and settlement layer gives the best security. But what’s the benefit/tradeoff if you decide to use Ethereum as a settlement layer, but then offer another DA source (e.g., volition like zkPorter, validium, celestium, etc.)? You still can use the same bridge and connection to the L1 as any rollup – you share liquidity, DeFi pooling, etc. For volitions, both off-chain (e.g., zkPorter) and on-chain (e.g., zkSync) DA modes share the same state and are fully composable. You just choose at a user level when you want your data stored on or off-chain. 

Settlement alone then largely provides network effects, while DA adds on full security. These network effects are safely optimized by sharing DA. For example, you can more comfortably implement a burn and mint mechanism across rollups, allowing you to natively deploy a token across chains. However, you wouldn’t be quite as comfortable doing this with very different trust zones. 

Ultimately, we can see there’s a security spectrum here. Many Ethereum rollups, validiums, etc. will use Ethereum for settlement – but not all of them will use its DA. DA is at least somewhat more commoditizable, and it will be an abundant resource. 

 

Bridging

This is the biggest wild card here in how strong network effects will be for different layers. The reality is we’re incredibly early days in understanding how rollups will communicate with each other in the future, and this can have a meaningful difference in how these stacks play out. There’s a lot that’s theoretically possible, a lot of unanswered questions, and a lot of tough engineering problems. For example, Slush is working on some of the most exciting bridging possibilities for ZKRs. We may see atomic composability between ZKRs in the future.

 

Part III – Celestia Rollup Stacks

Celestia – Sovereign Rollups

If ERs are one end of the rollup spectrum, sovereign rollups (SRs) are all the way on the other end. Some people think they’re both just made up words, but I think they’re cool.  

SRs still post transaction data to a base layer for DA and consensus (just agreement over transaction ordering, not validity), but they handle settlement client side within the rollup. Full and light nodes download the blocks from their P2P network, and they also check for DA on Celestia. Fraud proofs are sent around the SR’s P2P layer for light nodes to see. Validity proofs can also be sent around the P2P layer.

Alternatively, ZKRs can post their validity proofs along with the rollup blocks directly to Celestia. Celestia will not be able to verify the proof, but rollup light clients tracking Celestia will be able to do so easily.  (For more on Celestia, you can read our previous Pro report on it here.)

Celestia refers to Ethereum SCRs as “baby chains” because the correct rollup chain is decided by an L1 smart contract. SR nodes instead decide the correct chain for themselves. They check for DA on Celestia, then they locally verify the fork-choice rule.  

Note that this is only a trust-minimized one-way bridge now. That smart contract verifying the rollup’s validity is what gives you a trust-minimized bridge back. You could in theory send the Celestia token up to a rollup, but it could never go back (not a great idea). Celestia’s token will be confined. More on this later. 

 

Sovereignty

“Sovereignty” refers to the right to fork permissionlessly, whenever you want, without losing security. Your DEX got hacked? Some whale gamed your airdrop? 

“To not enshrine a settlement layer is primarily a social distinction rather than a technical one, which means that there is a social contract between the rollup’s community that the rollup’s transaction validity rules are defined by the community rather than an immutable L1 contract. In practice, this means that bridges to the rollup, which are not enshrined, must be mutable so that there is an upgrade path which acknowledges hard forks on the sovereign rollup.”

SCRs are still able to fork, but the decision over what is the canonical chain is delegated to an L1 smart contract. This relies on multisigs/centralized teams (today), majority governance of the rollup (as they decentralize), or they become immutable and forfeit this right (or the L1 could fork, unlikely). Note this upgrade process is subject to majority rule via on-chain governance. Off-chain coordination could deploy a new instance of a SCR, but then you’re starting from scratch drawing users with no history to the chain. SRs are able to fork permissionlessly, even as a minority, via off-chain governance. However, this fork may not be very useful depending on your bridging situation (more on this shortly). 

 

Considerations Around Sovereignty & Forking

You can always fork a SR in theory, but in practice there are plenty of scenarios where this wouldn’t work so well. So let’s understand where this sovereignty is particularly useful, and where it isn’t. 

One mitigant to sovereignty would be a SR’s (or any chain’s) reliance on meaningful centralized assets. A perps exchange heavily reliant on USDC would have a useless fork if USDC doesn’t support it. 

Smart contracts deployed on general-purpose SRs have a similar situation. Large communities have murkier socioeconomic alignment. Let’s say your DEX on Ethereum gets hacked. You’re free to fork the chain and revert it, but if every other user and dApp stays on the original chain it’s quite pointless. The SR as a whole certainly has the sovereignty to fork and make changes, but you won’t have much power as an individual contract on a shared chain. App-specific SRs thus most likely derive the greatest benefits of sovereignty. 

Sovereignty could be valuable to a project with a strong community, but I argue that most projects lack this today. It’s hard to predict what the future of crypto looks like, but most of it is currently DeFi. Applications driven by purely financial and transactional relationships are likely to value other technical benefits of a given rollup stack over sovereignty, so SRs will need to compete on features vs. SCRs. This is highly dependent on how SR bridging plays out, which is still unclear at this stage (more on this shortly).

Forking rollups with trust-minimized bridges would get very tricky if they were enshrined (e.g., if the bridge logic of SR_A is part of SR_B’s consensus rules). This would mean that all linked rollups need to hard fork in lockstep. This would make rollup uses such as DeFi (which would connect to many other chains) very difficult.   

But if the bridges are not enshrined, SR_B does not have to fork when SR_A forks, even if they have a trust-minimized bridge. The rollups can instead simply run a smart contract which interprets the state of each bridged rollup and verifies a validity proof for them. You bake everything (including the fork choice rule) into the proof, so that there can only be one canonical version of the chain. This is analogous to SCRs on Ethereum today. If they upgrade via governance, smart contracts interacting with them may need to upgrade as well. 

 

Flexibility

Another benefit of SRs – they grant developers more flexibility over their execution environments. Ethereum SCRs are bound by the settlement layer’s ability to process their fraud or validity proofs, which can present challenges in some instances. 

SRs aren’t bound by having fraud or validity proofs interpretable by any particular VM (such as the EVM, as Ethereum SCRs are). This execution agnosticism could foster higher innovation in designing VMs, as we see with new L1s.

This isn’t without some difficulties though. Trust-minimized bridging to other SRs requires them to interpret your execution environment and verify proofs. So you may create interoperability challenges for getting too creative. Uniform standards avoid this. 

 

Fraud Proofs in Sovereign Rollups

First, fraud proofs come in two flavors:

• Non-interactive (a.k.a. single-round) – Challenger submits a fraud claim which is checked by fully executing all state transitions between the two asserted states. This constrains rollup execution to what can be re-executed by light clients (such as a smart contract). In SRs, a light client receives the proof via the P2P layer to execute it.
• Interactive – Challenger submits a fraud claim, and the responder defends themself. They play an interactive verification game (IVG) – the challenger requests the responder to split their claim into smaller claims. They iteratively narrow down to a disagreement over a single instruction. Someone “referees” this dispute – an Ethereum smart contract (for SCRs) or a P2P light client (for SRs). Finally, light clients run that single instruction to check fraud. If either party stops responding, the other side wins. This is more complex than a single-round fraud proof, but checking fraud is more efficient. 

For reference, Arbitrum uses an IVG. Optimism’s initial plan was to run single-round fraud proofs, but they’ve since decided to pursue an IVG as well. You can see a recent overview of their new design here.

Now we’ll focus on how these relate to SRs. One benefit of distributing fraud proofs via P2P is faster light client finality. The synchrony delay here in normal cases would likely be lower than getting it included on-chain, and you no longer have to worry about L1 miners/validators censoring your fraud proof. You avoid SCR ORUs’ long timeout period. 

The Stanford research team recently proposed a method for playing IVGs over a “dirty ledger” like Celestia. You can watch an overview here. Remember Celestia accepts any raw information, it doesn’t check for “invalid” transactions. It’s a “dirty” ledger. Rollups themselves determine the validity of their chain. But there are some issues here which have since been discovered.

Let’s say a challenger wants to prove that transaction T₃  is a double spend. They submit as evidence that the money was already spent in T₂. That seems reasonable to prove fraud, but what if there exists some T₁ that proves T₂ was actually invalid? If T₂ was invalid, then maybe T₃ is perfectly valid. With a dirty ledger you’ll never know the true state unless you go back to the chain’s genesis and replay every transaction. This means challengers and responders would both have to be archival nodes – this is incredibly burdensome.

This differs from a “clean” ledger like Ethereum, where the smart contract will reject any invalid transactions. You know the latest confirmed tip of the chain was valid before the new proposed state. 

To reduce archival nodes’ requirements, you could introduce a new weak subjectivity assumption. Say you only require challengers and responders to hold onto 3 weeks of data. But even this would drastically increase node requirements compared to challengers and responders for SCR ORUs:

• SCR challengers/responders are required to store the state for the actual dispute period
• SR challengers/responders are required to store all of the different historical states over the entire weak subjectivity period

This increases their requirements significantly which makes the SR less scalable. Block space would need to be limited in order to bound challenger/responder requirements. 

There’s also a stronger synchrony assumption in SRs for the IVG game:

• SCRs assume that one honest challenger exists who will submit a fraud proof to the smart contract, which will then be arbitrated for everyone to see. You assume there is no eclipse attack that completely cuts off the network from submitting a fraud proof, and you see that fraud proof.
• SRs assume that each light node is connected to honest challengers and responders who can prove fraud. These challengers and responders are constrained in how many light clients they can connect to, so you’re now assuming many more synchronous connections. IP is also trivially Sybil attackable. 

SRs are likely to use single round fraud proofs (this is what Cevmos plans to use). These operate on a much weaker assumption because light clients can receive the fraud proof from an honest challenger and keep passing it along. Light clients no longer sit between the challenger and responder while maintaining a connection. You just need to receive the fraud proof from anyone, then you can check it yourself. Note that single round fraud proofs can introduce higher latency though, as they’re slower to execute. They can also have a larger attack surface than IVGs.

 

Committee-based Bridges vs. Proof-based Bridges

SRs add additional bridge design considerations, but trust-minimized or trusted bridges are still possible with other Celestia rollups. You can read more details about some of the specific design possibilities in Mustafa’s recent blog post, much of which I will summarize here. 

• Committee-based bridges – A committee attests to the validity of blocks. Not trust-minimized – the committee can steal funds. IBC is an example of a committee-based bridge (committee is the validator set of the source chain). You could also have a committee operated by bridge providers attesting to multiple chains.
• Proof-based bridges – For the bridge to be trust-minimized, SR_A and SR_B must be able to verify fraud/validity proofs for each other. Therefore, they must be able to interpret each other’s state machine. This has higher complexity than a committee-based bridge. 

 

Peer-to-peer Settlement vs. On-chain Settlement

There are two options here for proof-based bridges:

• P2P settlement – SR_A and SR_B both run light clients of each other which are embedded in their chains. These receive block headers and associated fraud/validity proofs via the P2P network. Both SRs have a bridging contract allowing for asset transfers via a lock-and-mint mechanism. The bridging contract is monitored (either directly or indirectly via a relayer) by each chain’s sequencers or validators to execute the transfers.
• On-chain settlement – SR_A and SR_B both run light clients of each other which are implemented as on-chain smart contracts. These smart contracts receive the block headers and fraud/validity proofs. This is how Ethereum SCRs work. 

 

Static Bridging vs. Dynamic Bridging

Static bridging – Bridges must be explicitly added by chain upgrades or hard forks. SR_A and SR_B must support each others’ execution environments to interpret their fraud/validity proofs. 

Example – SR_A is an ORU that wants to bridge to SR_B. SR_A’s state machine is written directly in Golang (e.g., using the Cosmos SDK). SR_B is an EVM chain that doesn’t understand this. SR_B must upgrade their node software to include SR_A’s state machine as a library in order to validate SR_A’s fraud proofs. SR_B can’t just automatically add SR_A’s state machine code because it could pose a security risk. This similarly applies to validity proofs which otherwise would not be understood by the connected chain. In either case, social consensus or governance is needed to add this bridge by a chain upgrade. 

Dynamic bridging – If the ORU SR_A was instead written in a sandboxed smart contract environment (e.g., EVM or CosmWasm), then SR_B could allow SR_A’s state machine code to be added directly into its own. This could be done without any social consensus or governance, for example using a smart contract. This similarly applies to ZKRs who are able to understand each others’ validity proofs. 

 

Upgradeable Bridges vs. Non-upgradeable Bridges

SCRs enshrine Ethereum as a settlement layer which determines its validity. SR bridges are not enshrined, and as such they must be mutable with an upgrade path. SR_B must acknowledge that the validity of SR_A is determined by its community. SR_A could fork via social consensus at any time without requiring on-chain governance or hard fork a settlement layer. 

Let’s play this example out where SR_A is hard forking, and SR_B needs to upgrade its light client for SR_A. There are several approaches, and they impact whether or not the bridge is trust-minimized:

 

Pairwise Bridging vs. Hub-and-spoke Bridging 

Rollups on a shared settlement layer only require N bridges to the settlement layer. However, pairwise SR bridging would result in N² bridges for N rollups to connect to each other. They also lack the shared liquidity and DeFi of a settlement layer. 

There’s another issue with the path dependency of assets. If I transfer an asset from chain A → B → C, that asset is not fungible with one transferred from chain A → D → C (unless it’s natively deployed on all chains, and you’re using a burn-and-mint mechanism). This again fragments liquidity, in a manner that is solved by bridging through a shared settlement layer. 

A hub-and-spoke model mitigates many of these complexities – many SRs connect to a central hub SR. This reduces bridging overhead back to N. The central hub can be the focal point of shared liquidity and cross-chain communication. It serves a very similar functional role as a shared settlement layer would in this regard. 

This is similar to the debate over how the Cosmos ecosystem should unfold. The initial “plan” was for the Cosmos Hub to serve as the focal point with all zones communicating through it via IBC. In reality though, entirely pairwise bridging has come about. Every zone just creates an IBC connection with whatever chains they want to interact with. 

A hub would serve many of the valuable roles that Ethereum’s settlement layer does today. It would host valuable DeFi and liquidity while coordinating cross-chain messaging. This likely captures very significant value. However, unlike Ethereum’s settlement layer, it provides no economic security to the Celestia ecosystem. It is not enshrined in the Celestia protocol.  

 

Aggregated ZK Bridging 

I saved the best for last. All-to-all bridging with linear complexity using validity proof aggregation. If this works out, the following idea may be a game-changer for rollup topologies which completely flips the appeal of SRs. Credit to Preston Evans and Cem Özer from Sovereign Labs who only very recently pulled this idea together. 

Let’s run through an example – SR₁ wants to bridge with SR₂ through SR_N. 

Naive solution – As described earlier, the obvious option is for SR₁ to run N-1 light clients, 1 for each chain, and verify a proof for each. N² bridging complexity – very tricky, hence the hub-and-spoke model described above. Can we do better? Yes (I think).

Better solution:

1. The aggregator for SR₁ receives the proofs for SR₂ – SR_N. The aggregator runs a light client of each chain, but this is now done off-chain making it far cheaper. 
2. The (untrusted) prover verifies and then aggregates the proofs of all N chains into a single proof. This aggregation is basically free as verifying proofs off-chain is incredibly cheap. 
3. The aggregator pushes only that single proof to a smart contract on-chain.
4. SR₁ verifies this single proof in the same amount of time it would take to verify any individual SR’s proof. 

The on-chain verifier contract would contain a mapping from chainId to state root for SR₂ – SR_N. Whenever it verifies a new aggregated proof, it would update the state roots for SR₂ – SR_N. The only remaining N² complexity is now in the state roots – each chain is tracking every other chain’s state roots (but the constant here is tiny). SR₁ has removed the N² complexity of running N-1 light clients and verifying N-1 proofs. Each rollup would likely run its own prover, though in theory you could also have one prover aggregate and send the proof to all N SRs. 

There are some assumptions about the interpretability of the other SR’s state machines, but those problems are solvable. Each type of alternative VM that you’re bridged to would require its own interpreter smart contract. Say that SR₁ is an EVM chain connected to 3 EVM, 3 Move, and 3 Sealevel SRs. It would need to run two interpreter contracts – one for Move and one for Sealevel. 

It’s likely still beneficial to have a DeFi “hub” (e.g., as in the hub-and-spoke model or a shared settlement layer). There’s value in concentrated liquidity. But this hub is no longer relied upon for settlement and two-hop bridging. This eliminates the latency of L3s using something like StarkNet as a scalable settlement layer with high liquidity. You’ve flattened the stack and created shorter paths between all rollups. 

Additionally, there’s no longer a locked-in settlement layer. This hub which is a DeFi focal point can evolve over time and progressively shift to be other chains as tech improves. You’re no longer locked into legacy tech of your settlement layer.

Final note – this is still an extremely new idea, and will need continued vetting. This will likely take years to build. 

 

Ethereum Sovereign Rollups

SRs are certainly the brainchild of Celestia, but note you could just as easily use Ethereum’s DA layer and simply ignore the settlement layer. It’ll be efficient once data blobs get their own cheap fee market post EIP-4844. You get the same benefits and tradeoffs, with a few exceptions:

• Higher economic security – ETH has far higher economic security than Celestia due to its settlement layer. The settlement layer subsidizes the security cost for DA which is provided altruistically. 
• Trust-minimized bridging to Ethereum rollups – Recall that SRs can construct pairwise trust-minimized bridges with rollups sharing the same DA layer (it’s just harder). You now get this option with Ethereum rollups rather than Celestia rollups. 
• Better liveness – Ethereum’s consensus mechanism Gasper can retain liveness even in the event of a 33% attack, though it will not finalize (as discussed earlier). This is valuable for a base layer which rollups are dependent upon.  
• Slower finality – While Gasper gives you better liveness, it trades off on finality. Ethereum is much slower than Tendermint to finalize (which does so instantly). Ethereum is actively researching single-slot finality, but it’ll be quite some time if and when it’s implemented.   
• Not overhead minimized – Celestia SRs only need to run a Celestia light client, but Ethereum SRs must run Ethereum full nodes for comparable assurances. They must check the validity of all L1 execution to know the canonical chain because validity rules are part of the consensus rules. However, this will no longer be the case once Ethereum implements light client DAS (could be several years away though). Then a light client would be sufficient – even in the event of an Ethereum honest majority failure, it wouldn’t cause a safety failure for the SRs as DA would still be guaranteed in a fork.

 

Key Takeaways IV

Sovereignty can be quite useful for communities with clear social alignment that don’t want to bootstrap their own L1 validator set. However, complexities may arise during forks if these SRs are bridging to many other chains in a trust-minimized way. Relatively isolated non-financial applications may be a more niche market – they at least don’t exist broadly at the moment.

Purely financial applications are likely to value other technical benefits of a rollup stack over sovereignty, so SRs need to compete on features vs. SCRs here. The hub-and-spoke model mitigates many of the downsides of not sharing a settlement layer, but introduces a number of complexities. By far the most compelling bridging vision is the aggregated ZK-bridging I described above. If it works out, this presents a very interesting route.

 

Celestia – Sovereign Settlement Rollup & Smart Contract Recursive Rollups

Many Celestia rollups won’t be willing to forfeit a shared settlement layer. You see just how powerful it is in the Ethereum rollup ecosystem, and you want that too.

Enter settlement rollups. These are specialized SRs designed for non-sovereign recursive rollups to live on top of. Recursive rollups place smart contracts on the settlement rollup, providing them with a trust-minimized two-way bridge. These recursive rollups post proofs, state updates, and transaction data to the settlement rollup. The settlement rollup batches the recursive rollups’ data and posts it to Celestia. 

Now you avoid all those bridging tradeoffs we just discussed for SRs, and you avoid the complexities surrounding P2P proof settlement. N trust-minimized bridges to a shared settlement layer allowing for easy bridging of tokens. 

Verifying the validity of the settlement rollup is overhead-minimized for the recursive rollups on top if the settlement rollup is fraud/validity provable. For example, Cevmos intends to be a settlement rollup which is a simplified single-round fraud-provable EVM.

 

Restricted vs. General-purpose Settlement Layers

Now, should your settlement rollup be a restricted environment optimized solely for posting proofs and token transfers? Recursive rollups would then get cheaper fees – they no longer compete in an expensive general execution environment against DeFi, NFTs, etc. 

There’s a couple of ways to do this potentially:

1. Permissioned settlement rollups with contracts being whitelisted
2. Change gas costs of certain instructions to heavily discourage any activity other than proofs and transfers

If you go this route, you lose out on all the rich DeFi use cases (e.g., DeFi pooling, dAMMs, etc.) and make it more difficult to build up liquidity. StarkNet is of course going the opposite route of Cevmos here. StarkNet will be a general-purpose settlement rollup for recursive StarkEx rollups. The other difference is that StarkNet is a SCR, so it ultimately settles back to Ethereum and retains a trust-minimized two-way bridge (vs. Cevmos is a SR without a trust-minimized two-way bridge to the base layer).

The other argument is that the routine operating costs of a rollup at scale paid to a settlement layer are low anyway. Even SCRs today pay very little to Ethereum’s settlement layer, and this will reduce further with upcoming optimizations. Any other settlement layer would be far cheaper and less constrained (particularly a settlement rollup). These costs will drop further with more efficient proofs and amortization of them over more transactions. Ethereum will also scale its settlement layer (though years down the road) potentially with statelessness, state expiry, and zkEVM.

Still, nothing is stopping you from deploying a general-purpose settlement rollup (L3) on top of Cevmos (L2), with recursive rollups (L4) sitting atop that yet another layer up. It’s possible, but now you’re stretching all the way to L3 to get any kind of rich trust-minimized shared liquidity and DeFi (which you would normally just get at L1 Ethereum). You’re potentially relying on additional layers for censorship resistance.

Positive of a four layered approach:

• More efficient resource pricing – Price certain resources more optimally for some use cases. For example, if a Celestia version of ENS just wants a place to settle proofs and transfer tokens, it doesn’t need to overpay to post proofs to a general-purpose execution environment where it competes with DeFi and receives no value. 

Negatives of a four layered approach:

• Socioeconomic fragmentation – For example, the base layer and both settlement rollups now build their own individual economic security without pooling it together in one place. This makes it far more difficult to build up security in any part of the stack, creating weak links. Additionally, restricted settlement rollups are likely to accrue little value (they’re more like a bridge than a typical general-purpose rollup).
• Degradation in liveness and censorship resistance – If any part of this stack fails, your rollup on top could be out of luck. Unfortunately, this is exacerbated by the above point. More on this below as it’s nuanced.

SCR forced transaction inclusion is pretty well-understood. Generally you can allow any L2 user to submit a transaction directly to the L1 contract. If it’s not submitted by the sequencer after some predetermined window (say one day), then the sequencer will no longer be able to submit blocks without it. Submitting blocks will become permissionless, and you’ll be able to force withdrawal to the L1 individually. This is more expensive to the user than getting batched with other L2 withdrawals, but it works. 

Now for recursive rollups on top of sovereign settlement rollups. If the settlement rollup is censoring you, there needs to be a way to force inclusion within your own rollup. You can still inherit censorship guarantees from the L1 DA layer though. You can enforce a rule within your recursive rollup such that transactions posted to your namespace on Celestia must be processed for the rollup block to be valid. Users can force transactions into the DA layer individually which would be ordered by execution layer fees. This places no reliance on the settlement rollup, but would need to be built into the rollup’s state transition rule. This becomes 1 of N honesty – if the sequencer doesn’t include your transaction, a fraud proof can be submitted showing they must submit this transaction.

Regarding liveness – if the sequencers for the recursive rollup itself fail, then you could still exit to the settlement rollup (as you can on Ethereum today). In the event of a settlement rollup liveness failure though, your recursive rollup is out of luck. You won’t be able to progress. 

 

Key Takeaways V

You tradeoff the benefits of sovereignty to regain those practical benefits of a shared settlement layer. Adding more and more layers to the stack can start to feel uncomfortable though.

 

Celestia – Enshrined Rollups???

If the Ethereum ERs were speculative, this is a mile further. There are no current plans for this. This is just one left side of the bell curver offering an opinion. I think enshrining a general-purpose rollup into Celestia is a potentially attractive option. Let me explain. 

We’ve discussed how valuable settlement layers are for shared liquidity, trust-minimized two-way bridging etc. But enshrining it in the base layer itself is also particularly important for two reasons in my view:

1. Value Capture – A well-designed general-purpose rollup is likely to capture more value than a DA layer. Because the base layer asset is relied upon for economic security by the entire stack above it, this is crucial.
2. Native Asset Utility – It makes the base asset useful. ETH can be used in DeFi etc. on L1, or it can be bridged to any enshrined or SCR via a trust-minimized two-way bridge, allowing it to flow through the entire ecosystem as money. Celestia lacks this trust-minimized two-way bridge to be sent elsewhere, and you won’t be able to do anything other than stake or transfer it on Celestia itself. This effectively gives up on Celestia ever being “money,” which arguably remains the largest TAM in all of crypto.  

You have a few remaining options here to represent Celestia’s token elsewhere. 

1. Multisig Bridge – A small third party external committee must approve all transactions. Not very exciting. 
2. Custodial (e.g., WBTC) – Hopefully I don’t have to explain why this isn’t great. This is also basically just a bad 1/1 multisig with no crypto-economic penalties.
3. Light Client Bridge (e.g., IBC) – It’s not trust-minimized, as you rely on the honest majority of any chain you connect to. The number of IBC connections, if any, to Celestia must also be kept very minimal to minimize complexity and prevent a large burden on Celestia’s state machine. 
4. Enshrined Settlement Rollup – This gives Celestia trust-minimized two-way bridging, enhanced asset utility, and higher economic security. 

Getting a trust-minimized bridge requires verification of DA and fraud/validity proofs for the state transition of the connected chain. Ethereum SCRs get this because their smart contracts verify the rollup’s state transitions. Celestia is not capable of supporting smart contracts for this bridge, so it would have to enshrine the rollup into the core protocol to make this work. 

Celestia rollups could then all have a trust-minimized two-way bridge with this settlement rollup. This provides easier communication between all of them and allows the Celestia token to flow throughout the ecosystem.

The downside is that this increases the complexity of Celestia. Validators must now ensure its validity, and non-consensus nodes would verify its state transitions. It would somewhat increase their bandwidth requirements to download the ER’s data. However, because it’s an enshrined rollup with fraud/validity proofs, this verification is overhead-minimized – no execution is required by any validators or non-consensus nodes. 

Ultimately, I view this as a bit of a free option. I think the downside is incredibly limited with potentially very high upside: 

• Worst case – Settlement layers aren’t needed at all (so it won’t serve that role) because SRs win out, and this ER gets outcompeted by every other SR. Then this ER won’t be super active, and it won’t pay for your security budget. At minimum, you get a trust-minimized two-way bridge for your token which can now be used broadly throughout the ecosystem. Still a win.
• Medium case – SRs win out, and a settlement layer is not needed. Well this can just be yet another rollup in that ecosystem, except it’s likely to have a strong Schelling point and garner meaningful activity. This helps fund the security budget, and gives Celestia a trust-minimized two-way bridge.
• Bull case – SCRs win out, and they really want a settlement layer. One that is enshrined in consensus not pulling apart socioeconomic concerns is very appealing. This would likely be a very active focal point of the ecosystem with high liquidity and activity. This helps ensure a sustainable value capture mechanism subsidizing security for the broader Celestia rollup ecosystem. And of course, trust-minimized two-way bridge. 

Maybe SRs eat the world, and DA accrues a ton of value securing everything. The DA value accrual bull case would be that even with massive amounts of DA supply, the network effects on one ecosystem are massive. As a result, SRs pay up for prime real estate to get trust-minimized bridging in that ecosystem. 

Even still, we know how to scale DA to pretty extreme lengths, and artificial pricing may need to be imposed to generate revenue. Or maybe it happens naturally because there’s an obscene amount of demand. In either case, there will be many other DA layers offering far higher throughput at far lower cost, and things are likely to load balance. For example, Ethereum’s security budget is subsidized by its settlement layer (at least currently) – it wouldn’t need to artificially raise DA prices. Other, far cheaper alternatives will also exist. 

The other argument against enshrining a rollup is for “credible neutrality.” I.e., other rollups will be scared to deploy on Celestia because the base layer is competing with them, so it can’t be neutral. I generally disagree with this argument. If we think the future of France is a 5x on what we see around us today, we seriously need to think bigger. There’s room for a heck of a lot more than for one rollup out there. Rollups would continue to happily deploy on Celestia. 

Alternatively, this enshrined rollup could become the settlement layer that every Celestia rollup decides to use. This becomes quite sticky, and makes it difficult to replace. Even if a better settlement layer becomes available technologically, it may be too late to make the move. 

In the event that DA does accrue a ton of value and SRs eat the world, great. But there is a very significant risk that this does not happen in my view. It’s incredibly hard to predict what most future applications will need exactly, and how technology such as ZK-aggregated bridging unfolds from here. ERs seem to present upside in any of these uncertain scenarios. 

 

Key Takeaways VI

A lot of the decision-making here is understandably socially driven. In my opinion though, the practical benefits tip the scale towards enshrining a rollup in Celestia. And of course, SRs can still deploy on Celestia as they wish! In the same way SRs could use Ethereum and ignore the settlement layer, they could ignore Celstia’s enshrined rollup. To not enshrine a rollup appears to be a very expensive form of virtue signaling. 

TLDR – I believe enshrining a general-purpose ER is far better from a tech PoV, and arguably unfavorable from a social PoV. I favor the tech in this scenario, but remember “most of the stuff in blockchain is opinion things as it turns out and less about technical stuff.”

Concluding Thoughts

Sorry just one more podcast quote I liked, back to John on the different rollup stacks:

“Whether or not I expect one to be more prevalent than the other, I wouldn’t say I expect anything, except expect the unexpected. The world is full of surprises and I can’t really predict which one will be used more.”

There’s truth here. I have opinions, and other people have other opinions. But that’s the point – they’re opinions. No stack I described here is strictly better than the others. There are tradeoffs. I expect really smart people to build on everything I described here, and only time will tell what they value most or what accrues value. 

And if you still don’t think rollups are cool yet, well honestly it’s not my problem anymore. 

Thanks to Justin Drake, Dankrad Feist, Preston Evans, Cem Özer, Nick White, Mustafa Al-Bassam, Ismail Khoffi, and Josh Bowen for their review and insights.