# 09 — Scaling: Rollups and Data Availability Every node executes every transaction. That redundancy *is* the security model — and it's also, obviously, the bottleneck. So here's the design problem that has consumed a decade of research: how do you do less work without trusting more people? Notice the tension before reaching for solutions. Verification here is redundancy; strip the redundancy carelessly and you've stripped the security. Everything in this module is a different way of being lazy *safely* — and once you see that framing, the whole zoo of rollups and DA layers organizes itself. ## Layer 1, Layer 2 A **Layer 1** is a base chain — Bitcoin, Ethereum — with its own consensus, settlement, native asset, and security. A **Layer 2** builds on top, batching execution off L1 but anchoring security there. The goal, in one line: > Execute cheaply elsewhere; settle securely on the base layer. ## Rollups A rollup executes transactions off-chain and posts data plus commitments back to L1. The clever part: the L1 never re-executes the work — it just holds the evidence. Which raises the natural question: what counts as evidence? Two schools answer differently — the same fork as [[Distributed Systems Bridges|detect-and-recover vs prevent-by-construction]]: - A **fraud proof** challenges a posted state with evidence of an invalid transition (optimistic rollups). - A **validity proof** proves upfront that the transition is correct (ZK rollups). **Optimistic rollups** assume transitions are valid unless someone objects: ```text L2 transactions -> sequencer orders them -> state root posted to L1 -> challenge window -> fraud proof if invalid ``` Innocent until proven guilty. The security rests on an assumption you can actually name: at least one honest party is watching, and the **challenge window** — time during which anyone can dispute a posted state root — gives them time to object. Withdrawals usually wait out this window. Someone really does have to be watching. **ZK rollups** prove validity up front: ```text L2 transactions -> prover generates proof -> proof verified on L1 -> state accepted ``` Here invalid states aren't caught — they're impossible to submit, because the [[02 Cryptographic Primitives|validity proof]] wouldn't verify. The costs sit elsewhere: proving is computationally heavy, circuits are complex, and EVM compatibility took years of hard work (it has largely arrived). | | **Optimistic** | **ZK** | |---|---|---| | Trust model | One honest challenger | Soundness of the proof system | | Withdrawal delay | Days (challenge window) | Hours or less | | EVM compatibility | Easy | Was hard, now viable | | Cost profile | Cheap unless disputed | Pay for proving, always | If this fork feels familiar, it should — it's the classic distributed-systems choice between detect-and-recover and prevent-by-construction, wearing new clothes. ## Data availability Now for the failure mode that's subtle enough to deserve its own layer. Imagine a rollup posts: ```text new_state_root = X ``` The **state root** here is the same idea as module 03's `state_root` — a hash committing to all L2 account balances and contract storage after a batch. Now suppose it withholds the transactions behind it. The root sits on L1, looking perfectly official. But nobody can check whether `X` is honest — and worse, nobody can construct the proofs they'd need to exit their own funds. The state is committed; the evidence is missing. Everyone is suddenly trusting the one party holding the data, which was exactly what the design was supposed to prevent. So a distinct question emerges, with its own name: was the data *published*, such that anyone could reconstruct and verify the state? Not stored forever — published, at the moment it mattered. That's [[Data Availability]], and it turns out to be the load-bearing wall of the modular world. Ethereum's answer is **EIP-4844**: **blob**-carrying transactions — cheap, temporary data buckets for rollups. Data is published and committed but not stored forever on every node. The insight worth keeping: > Rollups need cheap data publication more than they need L1 execution. Dedicated DA layers (Celestia and kin) push further with **DA sampling**: light nodes fetch random chunks of a block, and if enough samples succeed, the whole block is almost certainly available — checked without downloading everything. | **Term** | **One-line meaning** | |---|---| | Validium | Validity proof on-chain, data kept off-chain by a committee | | Volition | Hybrid — users choose per-tx whether data goes on-chain or off | | Restaking | Reusing staked assets to secure additional services | ## The modular decomposition Remember the four-layer table from [[01 Replicated State Machines]]? The old world ran all four layers in one chain. The new world splits them across systems: | **Role** | **Meaning** | |---|---| | Execution layer | Runs transactions | | Settlement layer | Resolves disputes/finality | | DA layer | Publishes and verifies data availability | | Consensus layer | Orders blocks | This decomposition is why the vocabulary exploded — rollups, appchains, validiums, volitions, shared sequencers, restaking. Here's the trick for staying oriented: when you meet a new one, skip the branding and ask which of the four jobs went where, and what [[Trust Assumptions|trust]] each assignment costs. The answers usually fit on a napkin. ## Sequencers, and finality across layers One more piece of honesty about the current landscape. Most L2s today have a **sequencer** — the party that orders L2 transactions and produces L2 blocks; often a single machine run by the team — that hands out instant confirmations. The UX is great. The centralization is real: a sequencer can censor, go down, extract [[MEV]], and its cheerful instant "confirmed" is a promise about an L1 settlement that hasn't happened yet. Which brings back the question [[Finality]] trains you to ask, now with more layers. A single rollup transaction passes through five different meanings of "confirmed": | **Stage** | **Meaning** | |---|---| | Seen by sequencer | Fast but weak | | Included in L2 block | Better | | Batch posted to L1 | Stronger | | Challenge window passed / proof verified | Strongest | | L1 finalized | Stronger still | So the reflex, whenever anyone says "confirmed": confirmed where, by whom, under what assumption? Wallets, bridges, exchanges, and payment products live or die on choosing the right stage to believe. ## Learning outcomes Questions worth trying on: - Could you explain how a rollup inherits L1 security — and name precisely what it does *not* inherit? - Fraud proofs versus validity proofs: could you map them onto detect-vs-prevent patterns you already know, and say when each wins? - Could you explain the data-withholding attack to someone new — and why "just store the data" misses what availability actually means? - Given a new scaling project's landing page, could you decompose it into the four modular roles and price its trust assumptions? - And the thread to pull forward: there are many chains now, each with its own state. How does value move between them — and why does that keep going wrong? ## Checkpoint 1. Why does an optimistic rollup need a challenge window while a ZK rollup doesn't? *(Hint: fraud proofs need time for someone to object; validity proofs are checked immediately. If unsure, revisit "Rollups" or [[Distributed Systems Bridges]].)* 2. What can a malicious sequencer do — and what can it *not* do — to a rollup with honest L1 settlement? *(If unsure, revisit "Sequencers".)* 3. Blobs get pruned after weeks. Why doesn't that break the availability guarantee? *(If unsure, revisit [[Data Availability]] — the key is publication versus storage.)* **Exercise.** Build the toy rollup from [[Projects to Build]]: a testnet contract that accepts state roots, an off-chain script that batches toy transactions and posts roots, and a mock challenge flow that disputes one bad root. It's small — and settlement, DA, and challenge windows become moving parts you've touched rather than words you've read. ## Resources - **Ethereum.org docs: Rollups, Data availability** — first stop, canonical taxonomy. - **EIP-4844 / proto-danksharding explainers** — why blobs exist and what's visible where. - **OP Stack docs** — a production optimistic rollup's architecture: sequencer, batcher, fault proofs, L1/L2 messaging. - **Arbitrum docs** — the contrast case: sequencer inbox, batch posting, rollup vs AnyTrust assumptions. - **Celestia docs** — the modular decomposition and the DA-sampling intuition. --- Next: chains multiply. Value and messages must cross between them. Who vouches for what, and why do bridges keep getting robbed? → [[10 Bridges and Interoperability]]