A world computer that ten thousand people run in lockstep
Picture ten thousand accountants scattered across the planet, each keeping a copy of the same ledger, bound by one rule: no entry counts until every one of them has personally re-checked it. That maddening redundancy is exactly why you can trust the ledger without trusting any single accountant — and exactly why it can never be fast. That is a blockchain. The slowness is not a bug you can patch away; it is the price of decentralization.
Put numbers on it. Ethereum's base layer settles roughly 15–30 transactions per second; Bitcoin manages about 7. Visa, by contrast, routinely processes thousands per second and claims headroom in the tens of thousands. The gap is jarring — but it is not because Visa's engineers are smarter. Visa runs a private cluster a handful of people control; a blockchain runs a public network that anyone can join and everyone must be able to verify.
Why every node redoes everything
A full node does not trust — it verifies. When a new block arrives, the node re-executes every single transaction inside it, re-derives the resulting state, and confirms the result matches what the block claims. If even one transaction is invalid, the node rejects the whole block. This independent re-execution by thousands of machines is the literal mechanism of trustlessness: you don't have to take anyone's word, because you (and everyone) checked.
But verification isn't free. Every node pays three bills at once: CPU to re-execute the code, bandwidth to receive every transaction as it gossips across the peer-to-peer network, and storage to hold the entire world state — every account, balance, and contract. The history alone is enormous: an archive node that keeps all past states runs to many terabytes. The chain doesn't just have to be fast now; every node has to carry the weight of everything that ever happened.
# Ethereum mainnet — a back-of-envelope throughput ceiling BLOCK_GAS_LIMIT = 30_000_000 # gas per block (raised over time as hardware improves) BLOCK_TIME = 12 # seconds per slot/block GAS_PER_TRANSFER = 21_000 # a plain ETH transfer, fixed cost transfers_per_block = BLOCK_GAS_LIMIT / GAS_PER_TRANSFER # ~1,428 ceiling_tps = transfers_per_block / BLOCK_TIME # ~119 tx/s (TRANSFERS ONLY) # But almost nobody just sends ETH. A Uniswap swap costs ~120,000 gas: GAS_PER_SWAP = 120_000 swaps_per_block = BLOCK_GAS_LIMIT / GAS_PER_SWAP # ~250 realistic_tps = swaps_per_block / BLOCK_TIME # ~21 swaps/s # => real mixed load lands around 15-30 tx/s, NOT thousands. # The block gas limit is a hard cap on total work per 12 seconds, # and that cap exists to keep an ordinary node able to keep up.
Here is the deep point hidden in that arithmetic: throughput is capped not by the fastest node, but by the weakest machine we still want in the club. We deliberately set the limit so a person on consumer hardware and a home internet connection can keep up. Raise the limit and you raise the bar to participate. The ceiling on speed is, quite literally, a decision about who gets to verify.
The naive fixes — and why they backfire
If a block holds too little, two fixes leap to mind: make each block bigger, or produce blocks more often. Both genuinely raise throughput. Both also quietly attack decentralization — and the second attacks security too.
- Bigger blocks (raise the gas limit or byte size): 10x the data per block means 10x the CPU, bandwidth, and disk that every node must afford, forever. Hobbyist and small validators silently drop out; only data-center-grade machines survive. You bought throughput by trading away decentralization.
- Faster blocks (shorten the block time): a block takes hundreds of milliseconds to propagate across a global network. Produce blocks faster than they can spread, and nodes routinely disagree on the tip — you get orphaned blocks and reorgs. Well-connected nodes near the producers win the races, centralizing the chain and making cheap chain reorganizations easier, which weakens security.
This isn't theory. The Bitcoin block-size wars (2015–2017) tore the community apart over exactly this question and ended in a hard fork: Bitcoin Cash split off in August 2017 with bigger blocks, and Bitcoin SV later split again chasing gigabyte blocks. Solana took the opposite bet — raw speed, reaching thousands of transactions per second — but its validators need data-center-grade hardware, and the network has suffered multiple full outages where it halted entirely. Every 'just make it bigger' is, underneath, a sale of decentralization.
The scalability trilemma, stated precisely
Ethereum's Vitalik Buterin named this recurring tension the scalability trilemma: a blockchain wants three properties at once, and naive designs can comfortably get only two of them.
- Decentralization — anyone can run a node and independently verify the chain on modest, affordable hardware, with no gatekeeper's permission. This is what makes the system censorship-resistant and credibly neutral.
- Security — the chain resists an attacker who controls a large fraction of resources; a 51% attack or a deep reorg must be ruinously expensive to attempt.
- Scalability — the chain processes a high volume of transactions (high throughput) at low cost per transaction.
Now you can read every design as a corner of the triangle. Bitcoin and Ethereum L1 sit firmly at decentralization + security, paying for it with low scalability. A chain run by a handful of beefy nodes can have scalability + security but weak decentralization. A fast sidechain guarded by a tiny validator set can offer scalability + (some) decentralization but with a far smaller security budget than the chain it sits beside. Pick two; the third suffers.
The breakthrough: make checking cheaper than doing
Look again at the assumption underneath all the pain: *to verify the chain, you must re-execute it.* Verifying costs as much as doing. That symmetry is what forces every node to redo every transaction, and it's what caps throughput at the weakest node's speed. Break the symmetry — make verification much cheaper than execution — and the trilemma loosens dramatically.
There are two known ways to make a claim of 'this batch was executed correctly' cheap to check. A fraud proof (the optimistic approach) assumes the batch is valid and lets anyone who spots a lie post a compact proof of the fraud during a challenge window — honest verification is nearly free, and you only do real work when something looks wrong. A validity proof (the zero-knowledge approach) attaches a succinct cryptographic proof that the batch ran correctly, which anyone verifies in milliseconds without ever redoing the computation.
Either way, the economics flip. A few powerful, specialized actors do the heavy execution, and everyone else — including your laptop — verifies cheaply, without surrendering the right to check. That is the loophole the trilemma left open: you can raise throughput while keeping verification within reach of ordinary people. The next four guides are the engineering of that loophole.
Moving execution off the base layer
That insight points straight at the strategy now dominating Ethereum's roadmap: stop making the base layer do everything. Push execution up into a Layer 2 — a rollup — that batches transactions off-chain, then posts the data plus a proof (fraud or validity) back down to the base layer. The L1 stops being the world's busiest computer and becomes something narrower and stronger.
The base layer's job shrinks to the two things it is uniquely good at: ordering and finalizing transactions as a settlement layer, and guaranteeing that the underlying data was actually published so that anyone can reconstruct the state and check the proofs. That second job — data availability — turns out to be the real bottleneck and the dominant cost of a rollup, which is why upgrades like EIP-4844 blob transactions and the road to danksharding target cheap data, not faster computation.
Step back and you see the whole shape: a modular design that splits the monolithic chain into specialized layers — execution, settlement, consensus, and data — each free to scale on its own. The trilemma isn't repealed; it's reorganized so that each layer only has to win two of the three, and the system as a whole inherits the strongest property from each.
From here the rung builds in order: how a rollup actually borrows the base layer's security by posting data to it; the optimistic path that assumes validity until a fraud proof says otherwise; the zk path that proves correctness up front; and finally why data availability — not computation — is the bottleneck the whole field is now racing to widen.