The Scalability Trilemma

The overview opened with a number that should bother you: Ethereum settles only a handful of transactions per second, while a single centralized payment processor clears tens of thousands. The obvious fix — “make the blocks bigger, make them faster” — is the first idea everyone has, and it is also the idea this page is going to take apart. Not because bigger blocks don’t raise throughput; they do. Because of what they quietly spend to buy it.

This page is about a single constraint. Once you see it, every later page in this part — the rollup pattern, data availability, blobs — reads as one long answer to it. The constraint is usually called the scalability trilemma, and it is the reason Ethereum did not just turn the block-size dial and call it a day.

The three corners

A blockchain is trying to hold three properties at once. Name them precisely, because the whole argument turns on the definitions:

Decentralization — how cheap it is to run a full node that independently verifies every block. The lower the hardware, bandwidth, and storage bill, the more ordinary people can afford to verify, and the more places power is spread across. Decentralization is not “many validators”; it is “many verifiers” — people who don’t have to trust anyone about the state of the chain because they checked it themselves.
Security — how expensive it is to attack the chain: to rewrite history, censor transactions, or push through an invalid state. In Ethereum’s proof-of-stake, this is the capital an attacker must acquire and put at risk of being slashed.
Scalability — how much useful work per second the chain does: transactions, computation, state changes. Throughput.

                 Decentralization
                 (cheap to verify)
                        /\
                       /  \
                      /    \
                     /      \
                    /        \
                   /          \
        Security  /____________\  Scalability
     (costly to attack)        (high throughput)

The trilemma claims: on a single layer, you can comfortably have two of these, but pushing hard on all three at once fights itself. It is not a theorem with a proof — it’s an engineering observation about where the costs land. And the sharpest version of it is the one hiding inside “just make blocks bigger.”

Why “bigger blocks” is not free

Recall the shared scarce resource this whole book keeps returning to: space in the next block, and the duty to store it forever. Every full node must download, execute, and retain every transaction to know the current state. That is what makes it a verifier instead of a truster. Throughput is just “how much we stuff into each block per unit time.” So raising throughput means every node must do proportionally more work:

   raise throughput on L1  ─►  more tx per block  ─►  each full node must:
                                                       · download more bytes   (bandwidth ↑)
                                                       · execute more opcodes   (CPU ↑)
                                                       · store more state       (disk ↑, forever)
                                                          │
                                                          ▼
                                    the machine you need to run a node gets more expensive
                                                          │
                                                          ▼
                                    fewer people can afford to verify  ─►  decentralization ↓

There is the trade laid bare. You did not get scalability for free — you paid for it in decentralization, by pricing ordinary participants out of running a node. The dial marked “throughput” is mechanically wired to the dial marked “cost to verify,” and turning one turns the other.

Two levers people reach for, and what each spends:

Bigger blocks (more gas per block) raise the bandwidth and storage every node must sustain. Push far enough and only data-center machines can keep up. The set of independent verifiers shrinks toward a handful of professional operators — which is exactly the centralized topology the chain existed to avoid.
Faster blocks (shorter block time) raise the propagation pressure: a block must reach the whole globe before the next one is due. Nodes on ordinary home connections, or far from the network’s center, start missing the deadline and fall out of consensus. Again: fewer verifiers, more centralization.

Neither lever touched security or math. Both spent decentralization. That is the trilemma doing its work.

The point of a low node cost is that a motivated individual can verify the chain on consumer hardware. As of 2024, an Ethereum full node is comfortably runnable on a machine with a consumer NVMe SSD (order of a couple of terabytes) and a normal home internet connection — deliberately kept within reach.

   Say the chain does  X  transactions/sec, each ~100 bytes of calldata on average.
   Bandwidth a node must sustain just to receive them:

      X = 15  tx/s   →  ~1.5 KB/s          ← a phone could keep up
      X = 1,000      →  ~100 KB/s          ← still fine on home broadband
      X = 100,000    →  ~10 MB/s sustained ← now you need a datacenter link,
                                             and ~300+ TB of new state per year to store

   The transactions didn't get "heavier." There were just more of them — and every
   verifier on Earth pays the full bill, forever. That last row is where the ordinary
   participant drops out, and decentralization silently leaves the room.

Treat the figures as round and time-sensitive; the shape — cost scales with throughput, and the poorest verifier sets the ceiling — is the durable point.

Under the hood — why the weakest node sets the limit

A subtle thing makes the trilemma bite harder than a simple average would suggest. Decentralization is set not by the strongest node but by the weakest one you still want to include. If you want a student on a laptop in a country with slow internet to be able to verify the chain, then the block size and block time must fit their budget — not the budget of a well-funded staking company with a fiber uplink.

So every megabyte you add to a block doesn’t just cost the big operators a little; it evicts the marginal participant entirely. Decentralization degrades at the edge first. That is why “the big validators can handle it” is never a good answer: the big validators handling it is precisely the centralized outcome you were trying to prevent. The chain is only as decentralized as its cheapest honest verifier can afford to be.

It’s a constraint to work around, not a law to violate

Here is the move that reframes everything. The trilemma is not a wall that says “you may never scale.” It is a statement about one layer doing all three jobs — execute, secure, and make-data-available — for every transaction. The escape is not to break the trilemma. It is to stop asking one layer to do all three jobs for every transaction.

That single sentence is the seed of the entire modern Ethereum roadmap. Concretely:

Move execution off the base layer. Let a separate system run the transactions and compute the results. The base layer never re-executes them — it only checks a proof or holds a challenge window that guarantees the result was correct. Verifying a proof is far cheaper than redoing the work. This is the rollup pattern, and it is the core of the next page.
Make the base layer verify availability without storing everything forever. Instead of every node downloading all the data, each node randomly samples small pieces and, with high probability, confirms the whole dataset is available — without any one node holding all of it. This is data availability sampling, which we build toward in Data Availability and The Danksharding Roadmap.

Notice what these have in common: both break the coupling between “throughput” and “cost to verify” that made bigger blocks a trap. A rollup can process thousands of transactions while the L1 node only checks a succinct proof. Sampling lets a node be convinced data exists without downloading all of it. The dials get un-wired. That is not cheating the trilemma — it is refusing the premise (one layer, all jobs, full re-execution by everyone) that made it a hard three-way tie.

   MONOLITHIC (one layer does everything, everyone re-does everything)
   ┌─────────────────────────────────────────────┐
   │  execute  +  settle  +  store all data        │  ← scaling this = bigger/faster
   │  every node redoes every transaction          │     blocks = decentralization ↓
   └─────────────────────────────────────────────┘

   MODULAR (split the jobs; L1 verifies instead of re-executes)
   ┌───────────────┐   proof / data
   │  Rollup L2s   │ ───────────────►┌──────────────────────────────┐
   │  EXECUTE many │                 │  L1: SETTLE (verify proofs)   │
   │  tx off-chain │                 │      + guarantee DATA is      │
   └───────────────┘                 │        AVAILABLE (sampled)    │
                                     └──────────────────────────────┘
                                        cheap to verify → stays decentralized

The two bets: monolithic vs modular

The trilemma forces a strategic choice, and the ecosystem split into two honest bets about how to answer it.

The monolithic bet: scale the L1 itself. Keep one layer that executes, settles, and stores everything — and just make it as fast as hardware allows, accepting a higher node cost as the price. Chains taking this route often do achieve high raw throughput. The trilemma’s warning is that they pay for it in decentralization: their full nodes demand serious hardware, so far fewer people verify independently, and the set of real verifiers narrows toward professional operators. That may be an acceptable trade for some use cases — it is a choice, not a free lunch, and the literacy is in naming what was traded.
The modular / rollup bet: split the jobs. Keep the base layer small, cheap-to-verify, and maximally decentralized — its job is to settle (verify correctness) and guarantee data availability, not to execute everything. Push execution out to many rollups that each scale independently. Ethereum chose this bet: a deliberately conservative L1 that stays verifiable on modest hardware, with scale delivered one layer up.

Both are coherent engineering positions. What the trilemma denies is a third bet that quietly assumes you can have monolithic simplicity, datacenter-free node costs, and 100,000 TPS all at once on one layer. That combination is the one the constraint rules out. Ethereum’s answer — “keep the base layer verifiable, scale above it” — is not a claim to have beaten the trilemma; it is a claim about which two corners it refuses to compromise (decentralization and security) and where it goes to buy the third (scalability from rollups plus sampled data).

This isn’t abstract. Bitcoin lived the trilemma out loud. From roughly 2015 to 2017, the community fought bitterly over whether to raise the 1 MB block-size limit to push more transactions through the base layer. One side argued bigger blocks meant cheaper fees and more throughput; the other argued that larger blocks would raise the cost of running a full node and, over time, concentrate verification in fewer hands — trading away exactly the decentralization the system existed for. The dispute was severe enough that in August 2017 it split the chain: Bitcoin Cash forked off with larger blocks (8 MB, later far more), while Bitcoin kept small blocks and moved scaling off the base layer (via SegWit and, later, the Lightning Network — its own “do it on layer 2” answer). Whatever your view of the outcome, the episode is the trilemma made concrete: the “just make blocks bigger” lever was pulled for real, and the argument against it was precisely who can still afford to verify. Ethereum absorbed that lesson and reached for rollups instead of a bigger base block.

Tying it back to the scarce resource

Every page in this book comes back to one thing: block space is a finite, shared, permanent resource, and someone must store it forever. The trilemma is what that scarcity looks like when you try to make the block bigger. You cannot conjure throughput from nothing; you can only decide who pays for it — and if the answer is “every full node, in bandwidth and storage, forever,” then the bill lands on decentralization.

Rollups change who pays and for what: the base layer pays only to verify (a cheap proof) and to guarantee data is available (via sampling), not to re-execute and permanently store every transaction. That is why the rest of this part is not a grab-bag of tricks. It is a single, disciplined campaign to move the expensive jobs off the layer that must stay cheap to verify — so that the block space Ethereum does keep scarce is spent on the one thing only a decentralized base layer can provide: credible, independently-checkable settlement.

The architect’s lens

Why does it exist? The trilemma exists because on one monolithic layer, throughput, cost-to-verify, and cost-to-attack are physically coupled: every full node must download, execute, and store everything, so more throughput is more cost per verifier. It’s the shape of the constraint, not a bug to be patched.
What problem does it solve? It’s a diagnostic, not a feature — it tells you which corner a scaling proposal is secretly spending. Hold it up to “just make blocks bigger” and it immediately shows you the hidden cost (decentralization), which is what stops teams from shipping a fast-but-centralized chain by accident.
What are the trade-offs? Any point you pick sacrifices something: max out throughput on L1 and you concentrate verification; max out decentralization and you cap raw base-layer throughput. Ethereum’s choice is to fix decentralization and security and buy scalability elsewhere (rollups + data sampling), accepting the added complexity of a multi-layer system.
When should I avoid it (as a rule)? Don’t wield the trilemma as a law that “proves” scaling is impossible — it’s an observation about one layer doing all jobs, and it dissolves the moment you split execution from settlement and data. Treating it as an unbreakable wall leads you to the wrong conclusion.
What breaks if I remove it (ignore it)? You ship bigger/faster blocks, feel great about the TPS number, and wake up with a chain only datacenters can verify — you’ve quietly rebuilt the trusted, centralized system the blockchain was supposed to replace. The trilemma is the alarm that goes off before that happens.

Check your understanding

Define the three corners of the trilemma precisely. Why is “decentralization” better stated as “cheap to verify” than as “many validators”?
Walk the causal chain from “raise throughput on L1 with bigger blocks” to “decentralization falls.” Which specific node costs go up, and who gets priced out first?
The page insists the trilemma is “a constraint to work around, not a law to violate.” What premise does the modular/rollup approach reject in order to escape the three-way tie — and name the two mechanisms that let it un-couple throughput from cost-to-verify.
Contrast the monolithic bet with the modular/rollup bet. For each, state which corner is being spent to buy the others, and which two corners Ethereum refuses to compromise.
Tie the trilemma back to the book’s scarce resource. When you “make blocks bigger,” what exactly are you spending, and how do rollups change who pays and for what?

Show answers

Decentralization = how cheap it is to run a full node that independently verifies every block (low hardware/bandwidth/storage cost). Security = how expensive it is to attack the chain (rewrite history, censor, force invalid state) — the capital an attacker must acquire and risk. Scalability = useful work per second (throughput). “Cheap to verify” is the sharper framing because the property that matters is how many people can independently check the chain without trusting anyone — a chain with many validators but where nobody can afford to verify is not decentralized in the sense that counts.
Bigger blocks → more transactions per block → every full node must download more bytes (bandwidth ↑), execute more opcodes (CPU ↑), and store more state forever (disk ↑). That raises the cost of the machine needed to run a node, so fewer people can afford to verify. The marginal participant — the person on modest hardware or a slow connection — is priced out first, so decentralization degrades at the edge.
It rejects the premise that one layer must execute, settle, and store all data for every transaction, with every node re-executing everything. Once you drop that, throughput and cost-to-verify un-couple. The two mechanisms: (a) rollups move execution off-chain and have the L1 verify a proof or hold a challenge window instead of re-executing; (b) data availability sampling lets each node randomly sample small pieces to be convinced the full data is available without downloading all of it.
Monolithic bet: scale the L1 itself (execute + settle + store on one fast layer); it spends decentralization — node costs rise, so far fewer independent verifiers — to buy throughput. Modular/rollup bet: keep a small, cheap-to-verify base layer that only settles and guarantees data availability, and push execution to rollups; it spends complexity (a multi-layer system) rather than decentralization. Ethereum refuses to compromise decentralization and security, and buys scalability from rollups plus sampled data.
You’re spending block space and the duty to store it forever — a finite, shared, permanent resource. Making blocks bigger forces every full node to pay in bandwidth and storage, so the bill lands on decentralization. Rollups change who pays and for what: the base layer pays only to verify (a cheap proof) and to guarantee data is available (via sampling), not to re-execute and permanently store every transaction — so the scarce base-layer space is spent on credible settlement, not raw execution.