Overview — Scaling: Rollups & L2s

You have, by now, built the whole world computer in your head. Accounts and a world state with a single root; a gas-metered EVM that halts any program within a budget; a fee market that prices scarce block space; and proof of stake, which decides whose ordering of transactions is canonical. Every one of those pieces exists to answer this book’s one question: how do untrusting strangers agree on the state of a shared world computer — and what does it cost to run one?

This part is about the second half of that sentence — the cost — pushed to its breaking point. Ethereum’s design forces every full node to re-execute every transaction and to keep the state forever. That is exactly what makes it trustless: you don’t believe a block, you check it. But it is also a hard ceiling on throughput. A chain that everyone can verify on a laptop is a chain that cannot process the transactions of the whole planet — not because the software is slow, but because verification-by-everyone is the security model, and you can’t quietly turn it off to go faster.

So the question for this part is sharp: how do you add throughput without re-introducing the trusted middlemen that decentralization removed? If the answer is “trust this one fast server,” you have rebuilt PayPal with extra steps. The interesting answer — the one Ethereum bet its roadmap on — is rollups.

The strategic choice: don’t scale L1, scale on rollups

There are two directions you could push to get more throughput.

1. Scale execution on L1. Raise the gas limit, demand bigger machines, ask each node to do more work per block. This buys throughput by shrinking the set of people who can afford to run a node — which is decentralization spent for speed. It attacks the very property that made the chain worth using.
2. Scale execution off L1, and use L1 only to settle. Let a separate system (a rollup, an “L2”) execute thousands of transactions, then post a compressed summary plus enough evidence back to Ethereum. L1 stops being the computer everyone runs on and becomes the court everyone appeals to.

Ethereum chose option 2 explicitly. The official framing is the rollup-centric roadmap: Ethereum’s base layer deliberately does not try to be a high-throughput execution engine. Instead it specializes into two jobs it is uniquely good at — being a settlement layer (the final, trusted arbiter of who owns what) and a data-availability layer (a public bulletin board where rollup data is guaranteed to be published so anyone can check it). Execution — the actual running of transactions — happens up on the rollups.

   BEFORE (naive scaling)                AFTER (rollup-centric)
   ─────────────────────                 ──────────────────────
   every user tx executes on L1          users transact on many L2s (rollups)
   throughput = L1's capacity            L1 executes almost none of it
   go faster ⇒ bigger nodes ⇒            each L2 posts a summary + data to L1
     fewer verifiers ⇒ less trustless    L1 = SETTLEMENT + DATA AVAILABILITY
                                         throughput = sum of all L2s
                                         trust ⇒ still anchored to L1

The bet is subtle and worth stating plainly: you can move execution somewhere 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 whole game.

The recurring test for this part

Everything in this part is measured against one question. Whenever a design claims to make Ethereum faster, ask:

If the L2 lies — reorders your trade, steals your funds, or invents a balance — can you still appeal to a chain you don’t have to trust, and win?

A design that passes this test is a rollup: L1 holds the data and the rules, so a lie is detectable and reversible without asking anyone’s permission. A design that fails it — “just trust our sequencer” — is not scaling Ethereum’s guarantees, it is offering a faster database with a crypto logo. The pages below are, in effect, six different angles on making the answer to that question yes.

Roadmap for this part

Read these in order. Each builds on the one before: we first prove the ceiling is real, then introduce the pattern that works around it, split it into its two families, find the actual bottleneck, and follow Ethereum’s roadmap for demolishing that bottleneck.

#	Page	What it establishes	Builds on
2	The Scalability Trilemma	Why “scalable, secure, decentralized — pick any two” is the constraint every design negotiates	Consensus, Gas & Fees
3	The Rollup Pattern — Execute Off-Chain, Settle On L1	The core move: run transactions off-chain, post data + a state commitment to L1	The EVM, State & Tries
4	Optimistic vs ZK Rollups	The two ways to prove the off-chain execution was honest: fraud proofs vs validity proofs	The Rollup Pattern, Cryptography
5	Data Availability — The Real Bottleneck	Why the true limit isn’t computing the state, it’s publishing the data so anyone can check it	The Rollup Pattern
6	EIP-4844 — Proto-Danksharding and Blobs	Ethereum’s first purpose-built cheap data lane for rollups: blobs, a separate fee market	Data Availability, Gas & Fees
7	The Danksharding Roadmap	The endgame: many blobs per block, made verifiable by sampling instead of full download	EIP-4844, Data Availability

The dependency order is deliberate. You cannot appreciate why blobs (page 6) exist until you accept that data availability (page 5) — not computation — is the binding constraint. And you cannot see that until you understand the rollup pattern well enough to notice that a rollup’s cost is dominated by what it must publish to L1, not by what it computes off-chain. So: prove the ceiling, then the pattern, then the real bottleneck, then the fix.

Why “just make L1 bigger” fails — the ceiling in one paragraph

It is tempting to think the ceiling is a mere engineering limit that a faster database or more cores would lift. It is not. A full node’s job is to independently re-derive the state from the raw transactions, so that it trusts no one. If a block demands more work than a normal person’s machine can do — more computation to re-execute, more bandwidth to download, more disk to store forever — then only well-funded operators can keep up, and everyone else must trust those operators’ word for the state. At that point verification-by-everyone has quietly become verification-by-a-few, and the chain is decentralized in name only. This is the trilemma made concrete, and it is why the next page starts there. Rollups don’t repeal this law; they relocate the heavy execution to systems that are allowed to be less decentralized, precisely because L1 can still catch them lying.

By the numbers — the order of magnitude a rollup buys

The exact figures move with every upgrade, so treat these as shape, not gospel (all approximate, as of 2024–2025). Ethereum L1 settles on the order of a dozen-plus transactions per second when full. A rollup executes its transactions off-chain and posts them to L1 in compressed, batched form, so the L1 cost is amortized across an entire batch:

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

The result is throughput one to two orders of magnitude higher and per-transaction costs a fraction of L1’s — and it improved sharply again once blobs (page 6) gave rollups a dedicated, cheaper place to put that data. The durable point is the mechanism: amortizing a fixed L1 posting cost across many L2 transactions. The exact multiple is a moving target; do not memorize a TPS record.

The thread

This part is the same throughline you have followed since Part 0, now asked about cost at scale. Untrusting strangers still have to agree on one state of the world computer — but now most of the transactions that change that state happen on rollups, not on L1 itself. What keeps them honest is not a new kind of trust; it is the old kind of verifiability, cleverly relocated. L1 stops running everyone’s code and instead guarantees two narrower things: that the rules can be enforced (settlement), and that the data needed to enforce them was actually published (data availability). Hold onto the recurring test — if the L2 lies, can I still appeal to a chain I don’t have to trust? — and every page in this part will read as a different, honest attempt to keep the answer yes while the transactions-per-second number goes up.

Check your understanding

1. State this part’s central question in your own words. Why is “just raise the L1 gas limit” not an acceptable answer to it?
2. Ethereum’s roadmap deliberately narrows what the base layer does. What two jobs does L1 specialize into under the rollup-centric roadmap, and what job does it hand off to rollups?
3. What is the recurring test used throughout this part, and how does it distinguish a genuine rollup from “just trust our fast server”?
4. The roadmap table is in dependency order. Explain why Data Availability must come before EIP-4844 — Blobs, not after.
5. A rollup executes transactions on a system that is less decentralized than L1. Why doesn’t that re-introduce the trusted middleman that decentralization was supposed to remove?

Show answers

1. The question is: how do you add throughput without re-introducing the trusted middlemen that decentralization removed? Raising the L1 gas limit buys throughput by demanding bigger, more expensive nodes, which shrinks the set of people who can independently verify the chain — spending decentralization for speed. It attacks the exact property (verification-by-everyone) that made the chain trustless, so it isn’t a real answer to the question.
2. L1 specializes into being a settlement layer (the final, trustless arbiter of who owns what) and a data-availability layer (guaranteeing the data behind rollups is published so anyone can check it). It hands off execution — the actual running of transactions — to the rollups (L2s).
3. The test is: if the L2 lies, can I still appeal to a chain I don’t have to trust, and win? A genuine rollup posts its data and abides by rules enforced on L1, so a lie is detectable and reversible without anyone’s permission — the answer is yes. “Just trust our fast server” gives you no such appeal: if it lies, you have no trustless recourse, so it fails the test and is a faster database, not a scaling of Ethereum’s guarantees.
4. Because blobs (EIP-4844) are a fix for a problem you can only see once you accept that publishing the data, not computing the state, is a rollup’s binding cost. Data Availability establishes why that is the real bottleneck; EIP-4844 is Ethereum’s purpose-built cheap data lane to relieve it. Introducing the fix before the reader believes in the problem would leave blobs looking arbitrary.
5. Because the rollup’s correctness is still enforced by, and appealable to, L1. The rollup can be run by few operators, even a single sequencer, but it must post its transaction data and a state commitment to Ethereum. If it computes the wrong state or tries to steal funds, L1 either rejects an invalid proof (ZK) or lets anyone submit a fraud proof (optimistic), and the lie is caught and reversed. You trust the math and the L1, not the operator — so no trusted middleman is re-introduced.