Chapter 11 · Why We Need Layer 2
Why not simply make blocks bigger?
- Capabilities practiced
- Protocol LiteracySystem Thinking
- Hands on
- Make a transfer on an L2, find its corresponding L1 submission, and calculate the transaction's true cost components.
- AI Lab
- Have AI explain Optimistic and ZK Rollup withdrawal flows separately, then check the actual withdrawal wait time on a specific L2.
A Real-World Problem
You want to send a friend five dollars. The fee is twelve dollars.
You do not send it.
During congestion, this is ordinary rather than extreme. More than expense, whole categories of use are excluded: small payments, game actions, social interactions, and per-call APIs may be worth only cents. They become impossible, not merely expensive.
Chapter 7 explained nearly fixed supply meeting surging demand.
Everyone's first solution is making blocks bigger.
That natural idea deserves serious treatment. This chapter explains its limits and the alternative people found.
Thought Experiment
Return to the town and its board.
Increase each board tenfold, from 100 to 1,000 lines.
Year one brings immediate success. Prices fall to one coin and the farmer records small debts again. Everyone is pleased.
Year two, board-copying participants leave. Anyone can copy the board to verify independently. Daily copying now takes ten hours instead of one. Two hundred copiers become thirty wealthy households able to hire help.
Year three, storage fills up. A newcomer must copy ten years of boards to verify current state. Nobody wants to spend six months doing so, and newcomers ask those thirty households for balances instead.
Year four, those thirty households determine what counts.
The town returns to chapter 2: a few people control the ledger. Boards and rules remain, but independent verification no longer works in practice.
Pause and change perspective.
Which daily tasks truly require everyone together?
Only three:
- Everyone must access original contents to verify them.
- Disputes need a way to determine correctness.
- Everyone must agree on order to prevent double spending.
But everyone need not independently compute a thousand entries' result. One person computes and others check.
A new approach emerges.
A clerk processes a thousand notices at home, then writes two things on the main board: the result and compressed original notices, taking one and a half lines.
Anyone can obtain those inputs and recompute. If the clerk errs or cheats, evidence submitted in the square makes them pay.
A thousand tasks occupy one and a half lines, without trusting the clerk.
Your Decision
The council chooses among four proposals.
What Happens
One sentence captures the difference:
A chain performs four tasks, and they need not all happen in the same place.
| Task | Question | Must everyone participate together? |
|---|---|---|
| Compute results | What is state after a thousand transactions? | No; one computes and others check |
| Make inputs available | Can I recompute myself? | Yes; otherwise verification fails |
| Resolve disputes | Which result is authoritative? | Yes; disputes need resolution |
| Establish order | Which transaction comes first? | Yes; otherwise double spending is possible |
Computation uses the most resources and is the only task that can move elsewhere.
The answer is moving computation out while retaining the other three on the main board, rather than enlarging it.
Compare locations:
| Proposal | Computation | Inputs | Disputes | Order | Trust required |
|---|---|---|---|---|---|
| Larger board | Main board | Main board | Main board | Main board | Independent verifiers become fewer |
| Results only | Clerk | Clerk | Main board | Main board | Clerk provides data |
| Results and data | Clerk | Main board | Main board | Main board | No trust in clerk |
| Independent board | New board | New board | New board | New board | Its security providers |
The second and third rows differ in one cell, determining whether asset safety depends on code or goodwill.
Remember that cell above all others.
Build a Model
Separate a chain into four layers:
- Execution: compute new state
- Data availability: everyone obtains inputs
- Settlement: resolve disputes
- Consensus: ordering and finality
Trade-offs by layer:
| Layer | Benefit of moving it | Cost |
|---|---|---|
| Execution | Much cheaper and faster | Little, if the other layers remain |
| Data availability | Further cost reduction | Losing recomputation and evidence |
| Settlement | Independence from main-chain congestion | No shared final adjudication; security starts anew |
| Consensus | Freely chosen parameters | It is now a separate chain |
Transaction cost breakdown
The model explains the bill:
| Cost | Determined by | Payer |
|---|---|---|
| Upper-layer execution | Its resource pricing, usually low | User |
| Shared main-chain data | Main-chain price divided by batch size | User, through upper-layer fees |
| Proof or challenge-window cost | How clerk correctness is established | User, usually included in fees |
| Operator profit | Upper-layer pricing | User |
This explains:
- Cheap upper-layer fees: hundreds or thousands share one data bill.
- Fees rising with the main chain: the shared numerator still comes from its market.
Costs never fully detach from the main chain. Reducing main-chain data prices is especially effective, as the cases show.
Why withdrawals wait
The reason is how the system proves the clerk did not cheat.
- Proof afterward: Assume correctness, then allow a sufficiently long challenge window. Withdrawals wait through it.
- Proof beforehand: Each batch includes mathematical proof verified before acceptance. No challenge window is needed, but proof generation has costs and technical requirements.
Both are widely used. Withdrawal waits follow security mechanisms, not operator laziness.
Most users instead obtain immediate liquidity from a third party that waits on their behalf. Its fee buys that waiting time.
What It Is Called
Computing new state from transactions under rules.
It is the most resource-intensive layer and the one that can safely move, because results can be verified from original inputs.
Verifiable work can be outsourced; agreement itself cannot.
The final dispute-resolution layer and record of ultimate asset ownership.
Upper layers borrow security because disputes are adjudicated on the main chain under its rules. This is chapter 1's settlement question between chains.
Agreement on which transactions occur and in what order.
It determines ordering and finality, as chapters 3 and 6 described. Moving it means a separate chain, whatever the system calls itself.
Whether everyone can actually obtain original inputs.
Data existing somewhere is not enough; you must be able to obtain it now.
Without inputs, you cannot recompute, prove wrongdoing, or establish balances after operator failure. Ask where the data is and whether you can retrieve it first.
Moving execution off-chain while submitting both results and original data to the main chain.
Hundreds or thousands of transactions roll into one batch, sharing costs.
Its security logic is trusting main-chain adjudication rather than the operator's honesty.
Check whether original data really reaches the main chain. Otherwise it is another design, perhaps useful but with different assumptions.
Bring it together:
Rollups move execution out while retaining settlement and data on the main chain.
Ask where the original data lives when assessing scaling.
Hands-on
Strongly prefer a testnet first. On mainnet, keep transfers to a few dollars: the deliverable is a trace, not a meaningful payment. Do not bridge large amounts for practice.
Transfer on an L2. Use faucet tokens or an existing small balance. Record hash, time, and fee.
Find its L2 explorer details. Identify its batch, often by batch number or L1 submission link, and submission time.
Measure the delay between L2 confirmation and main-chain publication. This reveals submission frequency.
Open the main-chain submission. Record its fee, number of L2 transactions, and data location.
Divide the first by the second: what is each transaction's shared main-chain cost?
Calculate the cost breakdown.
| Cost | Amount | Share |
|---|---|---|
| Your total L2 fee | 100% | |
| Shared main-chain data cost | ||
| L2 execution and profit |
If the parts do not match, record the difference and investigate where it goes.
Check withdrawal waiting time in official documentation.
Then inspect upgrade authority and timelocks using chapter 9's method.
Finally ask whether you can recover assets if the operator shuts down tomorrow, and how.
The answer depends on step five's findings, not marketing.
AI Lab
Give AI a structured task:
Explain withdrawals for two rollup types: later challenge-based verification
and prior mathematical proof.
For each, describe:
1. Steps after withdrawal initiation
2. Waiting duration and its reason
3. Remedies if the operator refuses transactions
4. Asset recovery if the operator stops entirely
For my specified L2, provide:
- Its type
- Officially documented withdrawal wait
- Original-data publication location
- Sequencing authority
- Upgrade authority and timelock
Attach official links. Write “Not Found” for missing information.
Do not infer from similar projects.Then open documentation and verify each item.
Watch especially for instant third-party liquidity times misrepresented as official withdrawal times.
They differ:
- Official withdrawal follows the security mechanism and its wait without a third party.
- Third-party exchange advances main-chain funds while the provider waits, requiring fees and provider trust.
The second is usable, but know which route you use, especially when everyone wants to exit simultaneously and liquidity may run short.
Also inspect who controls the L2 contracts now. Retained upgrade authority is common during development, but belongs in the risk checklist rather than being hidden by inherited-security claims.
Verify these points yourself after using AI
- Find the same withdrawal duration in official documentation
- Check that official-bridge withdrawals and third-party instant liquidity remain distinct
- Check original-data publication on the main chain for both designs
- Check user recovery after operator outage and whether the path actually works
- Check who holds upgrade authority
- Check whether decentralized sequencing is implemented or merely planned
- Check sources and dates on every number
Real-World Case
Chapter 8's debate becomes clearer here: one side prioritized fees, the other participation thresholds.
They chose different priorities within the four-layer model.
The industry found a third route rather than one side persuading the other: moving execution without enlarging blocks. Most scaling work follows this direction.
A protocol upgrade introduced space specifically for upper-layer data, priced separately from ordinary blockspace.
Dependent networks' fees promptly fell by more than an order of magnitude.
This validates shared main-chain data cost as a major upper-layer expense. Lowering it lowers upper-layer fees, showing their continuing connection.
Single sequencing-service failures have stopped upper-layer transactions for tens of minutes or hours.
Assets were not lost, because records and adjudication remained on the main chain, but users could not act, including positions nearing liquidation.
Sequencing authority is therefore essential to inspect. Until decentralization is implemented, it remains a single point of failure.
Some low-cost designs entrust original data to a committee rather than publishing it to the main chain.
They work cheaply until committee failure, withholding, or forced shutdown. A state root remains on-chain, but nobody can supply the underlying data proving user entitlements.
Such designs may be usable. Know the design and size exposure according to its risk.
Change One Variable
Upper-layer fees fall substantially, as already happened once.
Also, withholding data from the main chain loses its economic rationale if savings no longer justify the risk.
Some apparent technology disagreements are price disagreements. Changing prices can make approaches converge.
Single-point outage risk falls and censorship resistance improves.
Coordination among sequencers raises costs and latency, conflicting with upper layers' speed advantage.
Also, sequencing is a major revenue source. Who receives that income after decentralization remains open, revisited in chapter 26.
Challenge windows and daily use remain unaffected within that period.
But complete historical reconstruction later requires finding someone who retained the data.
The trade is permanent availability for window-limited availability, easing long-term main-chain burdens. Most users notice only when they need old data.
An immutable network continues under existing rules, including bugs.
A retained but lost key prevents repairs; a stolen key lets someone replace the logic and move assets.
Chapter 9's questions take priority: who can change, how many, what delay, and what detection? For a network holding large assets, these matter more than TPS.
Takeaway Questions
Ask which layer must be on-chain.
Shared ordering, final adjudication, and accessible data need the chain. Computation does not necessarily.
Layered questions avoid a simplistic on-chain-or-off-chain binary.
Each upper-layer fee partly pays main-chain data prices determined by main-chain congestion.
Thus unrelated upper-layer actions still experience main-chain price changes. Understanding the transmission explains fee increases.
Revenue comes from user fees minus main-chain submission costs, plus ordering income.
Inspect what remains after paying the main chain. Rising main-chain costs can shrink or reverse that margin. Chapter 26 uses the same approach.
Off-main-chain data adds custodian risk; a single sequencer adds availability risk; upgradeable contracts add key-custody risk.
These are independent. Test inherited-security claims against each separately.
Chapter Check
It is possible, but the costs appear years later.
More processing, transmission, and storage excludes weaker verifiers. Eventually only resource-rich institutions can verify, undermining the chain's central value.
Larger blocks exchange participation for capacity rather than removing the trade-off.
Execution, data availability, settlement, and consensus.
Execution can safely move because others verify results from original inputs.
The remaining three need shared agreement. Moving them changes the chain.
It determines whether operator trust is necessary.
Main-chain data lets anyone recompute and prove cheating independently.
Without it, withholding or disappearance prevents recomputation, evidence, and even balance proofs.
The question is whether I can obtain it now, rather than whether it exists somewhere.
Security mechanisms determine the wait.
Challenge-based designs allow time to detect and prove errors. Prior-proof designs accept after verification without that window.
Many users actually take third-party instant liquidity rather than official withdrawals. It is fast but adds fees and provider risk, especially during simultaneous exits.
Check at least:
- Does original data really reach the main chain? Inspect submissions.
- Who sequences? A single party can halt or censor the network.
- Who can upgrade, and is there a timelock? Marketing often hides this.
Only then do you know its scope. The claim may be true while covering less than users assume.
Key idea
A rollup moves execution elsewhere while keeping settlement and data on the main chain.