Revision — Scaling: Rollups & L2s

This part took the book’s throughline — how do untrusting strangers agree on the state of a shared world computer, and what does it cost to run one? — and pushed on the second half until it broke. The overview set the stakes: Ethereum’s trustlessness comes from every full node re-executing every transaction and keeping the state forever, and that same property is a hard ceiling on throughput. You cannot quietly turn verification-by-everyone off to go faster, because verification-by-everyone is the security model.

So the part asked one sharp question and answered it six ways: how do you add throughput without re-introducing the trusted middlemen that decentralization removed? This page walks back through the whole answer as one continuous argument — the constraint, the pattern, the two proof families, the real bottleneck, the fix, and the roadmap — and then restates the single test that ties all of it together.

The constraint: the trilemma rules out “just make L1 bigger”

The scalability trilemma is the wall every design in this part negotiates. Informally: a blockchain wants to be scalable (high throughput), secure (expensive to attack), and decentralized (verifiable by ordinary people on ordinary hardware) — and you cannot maximize all three at once. Push hard on one and you pay in another.

The trilemma is what makes the obvious fix a trap. “Just raise the L1 gas limit” or “demand beefier nodes” does buy throughput — but it buys it by shrinking the set of people who can afford to independently verify the chain. That is not a free upgrade; it is decentralization spent for speed. A full node’s whole job is to re-derive the state from raw transactions so it trusts no one. If a block demands more compute, bandwidth, or disk than a normal person’s machine can handle, then only well-funded operators keep up and everyone else must trust their word for the state. Verification-by-everyone has quietly become verification-by-a-few, and the chain is decentralized in name only.

   the trilemma as a budget you cannot overspend
   ───────────────────────────────────────────────
                 SCALABLE
                   /  \
                  /    \        pick a design ⇒ you sit somewhere
                 /      \       inside this triangle, never at all
                /        \      three corners at once
         SECURE ───────── DECENTRALIZED

   "make L1 bigger"  = slide toward SCALABLE by giving up DECENTRALIZED
   the rollup move   = keep L1 in its corner, add scale in another layer

This is why the part does not try to make L1 faster at all. It relocates the work instead. That relocation is the rollup pattern.

The pattern: execute off-chain, settle on L1

The rollup pattern is the core move of the entire part. Instead of every user transaction executing on L1, a separate system — a rollup, an “L2” — executes thousands of transactions off-chain, then posts back to Ethereum two things: the compressed transaction data, and a commitment to the new state (a state root). L1 stops being the computer everyone runs on. It becomes the court everyone can appeal to.

This is the “rollup-centric roadmap” in one sentence: Ethereum’s base layer deliberately does not try to be a high-throughput execution engine. It specializes into two narrower jobs it is uniquely good at — being a settlement layer (the final, trustless arbiter of who owns what) and a data-availability layer (a public bulletin board guaranteeing rollup data was actually published). Execution moves up onto the rollups.

The economics is just amortization. A rollup takes a fixed cost — posting a batch to L1 — and spreads it across every transaction in that batch:

   naive:  1 user tx  = 1 L1 tx        = pay full L1 cost, every time
   rollup: N user txs = 1 L1 batch     = (data + one state commitment)
           per-user L1 cost  ≈  batch overhead / N   →  shrinks as N grows

The whole bet, stated plainly: you can move execution to a system that is allowed to be less decentralized, as long as its correctness is still enforced by, and appealable to, a chain you don’t have to trust. That last clause is the litmus test the overview handed you, and it is worth pinning to the wall for the rest of this recap:

The L2 litmus test: if the L2 lies — reorders your trade, steals your funds, or invents a balance — can a cheated user still appeal to L1 and recover their funds?

A design where the answer is yes is a real rollup. A design where the answer is “just trust our sequencer” is not scaling Ethereum’s guarantees; it is a faster database with a crypto logo. Everything below is a different mechanism for keeping that answer yes.

The two families: optimistic vs ZK

If a rollup posts a new state root to L1, L1 must have some way to know that root is honest — that the off-chain execution really produced it. There are exactly two strategies, and Optimistic vs ZK Rollups is the page that split them apart.

Optimistic rollups assume the posted state is correct — optimistically — and make lying punishable rather than impossible. After a batch is posted, a challenge window opens (roughly a week on the major optimistic rollups, as of 2024). During that window, any honest watcher who can re-run the batch and finds the state root wrong can submit a fraud proof to L1. L1 checks the disputed step, and if the rollup cheated, the bad state is thrown out and the challenger is rewarded. The security assumption is “at least one honest party is watching and will speak up in time.”

ZK (validity) rollups make lying impossible rather than merely punishable. Alongside the new state root, the rollup posts a validity proof — a succinct cryptographic proof (a SNARK/STARK) that the state transition was computed correctly. L1 verifies the proof before accepting the root. A false root simply cannot produce a passing proof, so there is nothing to dispute after the fact.

   OPTIMISTIC                              ZK / VALIDITY
   ──────────                              ─────────────
   post root, assume honest                post root + a proof it's honest
   ↓                                       ↓
   ~7-day challenge window opens           L1 verifies the proof on the spot
   ↓                                       ↓
   anyone can submit a FRAUD PROOF         a lie can't produce a valid proof
   ↓                                       ↓
   trust: ≥1 honest watcher                trust: the math (no watcher needed)
   withdrawals wait out the window         withdrawals as soon as proof clears

The key consequence is withdrawal speed, and it falls straight out of the two designs. An optimistic rollup cannot let you withdraw to L1 until the challenge window has passed, because until then the state root might still be overturned by a fraud proof — hence the roughly week-long wait for a native withdrawal. A ZK rollup has already proven the state before L1 accepted it, so there is no window to wait out; native withdrawals can finalize as fast as the proof is verified. Optimistic rollups trade withdrawal latency for cheaper, simpler proving; ZK rollups pay a heavier proving cost up front to buy fast, watcher-free finality. Both pass the litmus test — a cheated user’s recourse is either a fraud proof or an unforgeable validity proof — but they pass it by different routes.

The real bottleneck: data availability

Here is the part’s turn, and its most important idea. Neither fraud proofs nor validity proofs work if the data behind the batch is missing. Data Availability is the page that names the real constraint.

Walk it through. To submit a fraud proof, an honest watcher must be able to re-run the batch — which means they must have the transaction data. To reconstruct their own account and exit an optimistic rollup, a user must be able to recompute the state — again, from the data. Even a ZK rollup, whose proof guarantees the state root is correct, has a problem if the raw data is withheld: users cannot see their own balances or build the withdrawal transaction. A correct-but-unpublished state is a state nobody can act on. This is the data-withholding attack, and it defeats both rollup families at once.

So the binding cost of a rollup is not computing the new state — that happens cheaply off-chain. It is publishing enough data on L1 that anyone can independently reconstruct and check the state. That is why “data availability” is the phrase, and why the overview’s dependency order insists you understand this page before the next one: the whole point of blobs is to make publishing that data cheap.

   what actually costs money in a rollup
   ──────────────────────────────────────
   off-chain execution ........ cheap (one operator's server)
   the validity/fraud proof ... a fixed, amortized cost
   publishing the DATA to L1 .. the dominant, per-byte cost  ◄── the bottleneck

The fix: EIP-4844 blobs

Before March 2024, rollups had only one place to put their data on L1: regular transaction calldata, which competes with every other transaction for the same block gas and is priced for permanent storage even though rollups only need the data to be temporarily available. Rollups were paying prime real-estate rent for a bulletin board they only needed for a few weeks.

EIP-4844 — “proto-danksharding,” shipped in the Dencun upgrade on 13 March 2024 — added a purpose-built cheap data lane called a blob. The key design choices all follow from “rollups need cheap, temporary data availability, not permanent storage”:

Blobs are a separate resource with their own fee market. Blob space is priced independently of ordinary gas, so a busy DeFi day no longer directly bids up rollup data costs, and vice versa. Its price adjusts up and down with blob demand, EIP-1559-style.
Blobs are pruned. The EVM never sees blob contents — only a commitment to them — and consensus nodes only keep blobs for a short retention window (about 18 days, as of 2024), long enough for anyone to download and check the data, then discarded. That is the “temporary availability” insight made concrete: don’t charge for forever when you only need weeks.
The result was a sharp, immediate drop in rollup fees. Giving rollups a dedicated, correctly-priced place to post data cut L2 transaction costs substantially right after Dencun. Treat the exact multiple as a moving target — the durable point is the mechanism, a separate cheap lane for temporary data, not a headline number.

Blobs are the first concrete payment on the data-availability bottleneck. But they are a floor, not a ceiling: EIP-4844 shipped with a modest target number of blobs per block on purpose, because the endgame needs a way to add far more blob capacity without asking every node to download all of it.

The roadmap: danksharding and data-availability sampling

The Danksharding Roadmap is where the part looks forward. The goal is many more blobs per block — an order of magnitude or more of data-availability capacity — which runs straight back into the trilemma: if every node must download every blob to be sure the data is available, you have just re-created the “make L1 bigger” problem for data instead of execution.

The escape is data-availability sampling (DAS). The idea is that a node does not need to download an entire blob to be confident it was published. Using erasure coding, the blob data is expanded so that the full data can be reconstructed from any sufficiently large fraction of the pieces. That makes withholding a meaningful chunk of the data statistically hard to hide: a light node can randomly sample a handful of small pieces, and if the data were actually being withheld, those random checks would fail with overwhelming probability. Many independent nodes each sampling a little adds up to the whole network being confident the data is available — without any single node downloading all of it.

   full danksharding, conceptually
   ────────────────────────────────
   many blobs per block, erasure-coded
        │
        ▼
   each node SAMPLES a few random pieces  (not the whole thing)
        │
        ▼
   samples pass ⇒ data is available with high probability
        │
        ▼
   capacity ↑↑  while per-node cost stays flat  (trilemma, sidestepped)

That is the resolution of the whole part in one line: sampling lets availability be checked by everyone without being downloaded by everyone, which is exactly the property the naive “bigger node” approach destroyed. Proto-danksharding (blobs, live since 2024) is the first step; full danksharding with DAS is the destination.

A necessary hedge: this roadmap is genuinely in progress. Proto-danksharding shipping in Dencun on 13 March 2024 is an established fact. Full danksharding, the exact number of blobs per block over time, and the precise sequence of intermediate upgrades that raise blob targets are all moving targets — Ethereum’s roadmap has repeatedly reordered and re-scoped these steps. State the mechanism — erasure coding plus random sampling to scale data availability — with confidence; treat any specific future date or blob count as provisional as of 2024.

The thread, pulled tight

Every page in this part was one attempt to keep a single answer yes: if the L2 lies, can a cheated user still appeal to L1 and recover their funds?

The trilemma (page 2) proved you cannot buy that guarantee by enlarging L1 — you would spend the decentralization that made the appeal trustworthy in the first place.
The rollup pattern (page 3) relocated execution off-chain while keeping L1 as the court of appeal, financed by amortizing one L1 posting cost across a whole batch.
Optimistic vs ZK (page 4) gave two ways to make the appeal enforceable — a fraud proof inside a challenge window, or a validity proof checked up front — and explained why that difference sets withdrawal speed.
Data availability (page 5) revealed the appeal only works if the data is published, making publishing — not computing — the true bottleneck.
EIP-4844 blobs (page 6) built a cheap, temporary, separately-priced lane for that data, live since Dencun on 13 March 2024, cutting rollup fees sharply.
The danksharding roadmap (page 7) points to scaling that data lane with erasure coding and sampling, so availability stays checkable by everyone even as capacity grows.

The throughline holds all the way through. Untrusting strangers still agree on one state of the world computer — but now most of the transactions changing that state happen on rollups, and what keeps them honest is not a new kind of trust. It is the old kind of verifiability, cleverly relocated: L1 guarantees the rules can be enforced (settlement) and the data to enforce them was published (availability), and the reader can always fall back to the same question to sort real scaling from marketing. Hold onto that test, and the whole part reduces to one sentence — make the transactions-per-second number go up while the answer to “can I appeal to a chain I don’t trust?” stays yes.

Check your understanding

Explain, using the trilemma, why “just raise the L1 gas limit until it’s fast enough” is not a real answer to this part’s question. Which corner of the triangle does it quietly spend?
State the L2 litmus test in your own words. How does it distinguish a genuine rollup from a fast server that says “just trust us”?
Optimistic and ZK rollups both pass the litmus test, but native withdrawals from an optimistic rollup take about a week while a ZK rollup’s can finalize much faster. Why does that difference fall directly out of how each one proves honesty?
A ZK rollup’s validity proof guarantees the state root is correct. Why, then, does it still fail if the underlying transaction data is withheld — and what does that tell you about which is the real bottleneck?
EIP-4844 blobs are pruned after a short retention window, and full danksharding relies on data-availability sampling instead of full downloads. Explain how each of those choices reflects the insight that a rollup needs data to be temporarily available and checkable by everyone, not permanently stored by everyone.

Show answers

A full node stays trustless only by independently re-deriving the state from raw transactions. Raising the gas limit makes each block demand more compute, bandwidth, and disk, which prices ordinary machines out of verifying — so verification-by-everyone becomes verification-by-a-few. It buys the scalable corner by spending the decentralized corner, which is exactly the property that made the chain worth trusting. So it doesn’t add throughput without re-introducing trusted middlemen; it is re-introducing them.
The test: if the L2 lies — reorders a trade, steals funds, invents a balance — can a cheated user still appeal to L1 and recover their funds? A genuine rollup publishes its data and abides by rules L1 enforces, so a lie is detectable and reversible without anyone’s permission — the answer is yes. A “just trust us” server offers no such trustless recourse: if it lies, you have no appeal, so it fails the test and is a faster database, not a scaling of Ethereum’s guarantees.
An optimistic rollup only assumes the posted state is honest and relies on a fraud proof submitted during a challenge window (roughly a week) to catch a lie; until that window closes, the state root could still be overturned, so a native withdrawal must wait it out. A ZK rollup posts a validity proof that L1 verifies before accepting the root, so the state is already proven correct — there is no window to wait out, and withdrawals can finalize as soon as the proof clears. The withdrawal delay is a direct consequence of “punish lying later” vs “make lying impossible up front.”
Because a correct-but-unpublished state is a state nobody can act on: without the data, users can’t see their balances, reconstruct their accounts, or build a withdrawal transaction, even though the root is provably right. This is the data-withholding attack, and it shows that the binding constraint is publishing the data so anyone can reconstruct and use the state, not computing the state — data availability is the real bottleneck, which is exactly why blobs exist.
Pruning reflects that rollups need the data only long enough for anyone to download and check it (build a fraud proof, reconstruct state, exit), not forever — so charging permanent-storage prices was overpaying, and blobs are kept only for a short retention window. Data-availability sampling reflects that availability must be checkable by everyone without being downloaded by everyone: erasure coding plus random sampling lets many light nodes each verify a few pieces and collectively be confident the whole blob was published, so capacity can grow without every node downloading all of it. Both choices keep the “checkable by everyone” security property while dropping the “stored forever by everyone” cost.