Verkle Trees and Statelessness

The previous page, Account Abstraction, reshaped what an account can be. This page reshapes something deeper: what a node must hold to check a block at all. Today, a full node stores the entire state — every account, balance, nonce, and storage slot — because that is the only way it can recompute the state root and reject a lying block. Verkle trees and statelessness are a plan to break that requirement, so a node can verify a block from a small proof the block carries with it, without holding the state at all.

This matters directly to 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? The “cost to run one” has been quietly rising for years, because the state keeps growing and every full node must store all of it. If the cost of being a verifier climbs high enough, the circle of people who can verify shrinks, and the network drifts toward trusting a handful of large operators. Statelessness is an attempt to keep that circle wide even as the world computer’s memory keeps filling up.

One honest caveat up front, repeated at the end because it governs the whole page: this is roadmap-stage. The mechanisms below are real and well-studied, but the exact shape Ethereum ships — Verkle trees, a competing approach, or something built on newer cryptography — is not settled as of 2024. Learn the problem and the shape of the solutions; hold the specifics loosely.

Recall the problem: state grows, and everyone stores all of it

Back in the state-and-tries part, we built the machine Ethereum actually uses: a Merkle-Patricia trie, keyed by account (and, inside each contract, by storage slot), collapsing the whole world into one 32-byte root that sits in every block header. That root is what lets two distrusting nodes check they reached the identical world by comparing 32 bytes instead of whole databases.

But there is a cost the trie’s elegance hides. To produce the next root — to validate a block — a full node must be able to read and update any account the block touches. In practice that means holding the entire state trie locally. And the state only ever grows: every new account, every new contract, every fresh storage slot adds nodes to the trie and bytes to disk.

   state size over time (schematic — the shape, not exact figures):

     disk
     used   │                                   ╭──────
            │                             ╭──────╯
            │                    ╭────────╯
            │           ╭────────╯
            │  ╭────────╯
            └──┴────────┴────────┴────────┴────────┴──── time
                                             every full node holds ALL of this

Two things climb together. Disk and memory — a node must store tens of gigabytes of state and keep the hot parts fast to access. And the barrier to entry — the more it costs in hardware to run a verifying node, the fewer independent people run one. That second effect is the dangerous one for a credibly-neutral system: verification is only decentralised if verifying stays cheap enough that ordinary people, not just data-centre operators, keep doing it.

By the numbers — why the witness, not the state, is the lever

Ethereum’s state is large and growing — on the order of tens of gigabytes for the account and storage tries as of 2024 (treat the exact figure as volatile; it rises over time). A full node must hold it all. Now imagine we could instead ship, inside each block, a proof of exactly the state that block reads and writes.

   a block touches, say, a few thousand state items.
   the question is how many BYTES it costs to prove them under a trusted root.

   Merkle-Patricia proof:   each item drags ~O(log n) sibling hashes (32 bytes each),
                            and branch nodes are 16-wide, so siblings pile up fast.
                            → a full-block witness is estimated in the MEGABYTES.

   Verkle proof:            one short proof covers ALL the touched items together.
                            → a full-block witness is targeted in the low
                              HUNDREDS of KILOBYTES.

The state stays large; the witness — the proof of just the touched slice — is what a stateless node downloads per block. Shrinking the witness by roughly an order of magnitude is what makes shipping it in every block plausible. (Figures are design targets, not guarantees; see the hedge at the end.)

Merkle proofs vs Verkle proofs: the width problem

We already built Merkle proofs in Merkle Proofs and Light Clients: to prove one key under a trusted root, you hand over every node on the path from that key’s leaf up to the root, so the verifier can re-hash the path and check it lands on the root. The proof’s size is the number of nodes on the path times the size of each node.

Here is the sting. Ethereum’s trie uses branch nodes with 16 children (one per hex nibble). To prove you took one branch, you must reveal the hashes of the other fifteen siblings — otherwise the verifier can’t recompute that node’s hash. Multiply that by the depth of the trie, multiply again by every item a block touches, and the sibling hashes dominate. This is why an honest, full-block Merkle-Patricia witness is estimated in the megabytes: it is mostly siblings you don’t care about but must reveal to hash.

   proving ONE key under a Merkle branch node (16-wide):

        branch node
        ┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐
        │h0│h1│..│  │  │  │  │  │  │  │  │  │  │  │  │h15│
        └──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
               ▲ the child on our path
          all 15 OTHER hashes must be in the proof to recompute this node's hash.

What a vector commitment changes

A Verkle tree (“Vector commitment + merkle tree”) swaps the hash-based branch node for one built on a vector (polynomial) commitment. The precise cryptography is beyond this page, but the property that matters is simple to state:

A vector commitment commits to a whole list of children at once, and can produce a short opening proof that “position i holds value v” — a proof whose size does not grow with how wide the node is, and does not require revealing the other children.

That single change attacks the width problem at its root:

• No siblings to reveal. Proving one child no longer costs fifteen extra hashes. The opening proof stands on its own.
• Wider nodes become cheap. Because width no longer inflates proofs, Verkle designs use very wide nodes (256-way), which makes the tree shallower — fewer levels from leaf to root.
• Proofs aggregate. Openings for many keys across the tree can be combined into one small proof for the whole set, rather than a separate path per key. This is the property that turns “prove every item a block touched” from megabytes into a single compact witness.

   Merkle path (deep + wide siblings)        Verkle path (shallow + no siblings)

        root                                      root
       /  \  \ ... (16-way, reveal siblings)     /|\ ... (256-way, no siblings)
       .   .   depth ~7-8                         .   depth ~3-4
       .                                          .
      leaf  + O(log n) × 15 sibling hashes       leaf  + ONE aggregated opening

The result is a state commitment with the same meaning as before — a single root that changes iff the state changed — but proofs that are small enough to travel inside a block. Same idea we have leaned on all book long (a tiny commitment to a huge world); a different, more proof-friendly machine underneath.

What a stateless client is

Now the payoff. Define it precisely:

A stateless client is a node that validates a block using only the block itself plus a witness — a proof of exactly the state that block reads and writes — without holding the full state locally.

Walk the mechanism. A block proposer (who does hold the state) knows which accounts and storage slots its transactions will touch. Alongside the block, it publishes a witness: the pre-values of those items plus a Verkle proof that each one is correct under the previous block’s state root. A stateless verifier then:

   1. receive block  +  witness
   2. check the witness proves each touched item against the PARENT state root
        (this needs only the parent root — 32 bytes — not the whole state)
   3. re-execute the block's transactions using the witnessed pre-values
   4. compute the NEW state root from the results
   5. accept iff step 4 matches the state root the block claims

At no point does the verifier need a local copy of the state. It trusts the parent root (which it verified the same way for the parent block), the witness proves the inputs, and re-execution proves the output. A megabyte-scale witness would make step 1 too heavy to do every block; a Verkle-sized witness is what makes this loop practical.

This is a genuinely different creature from the light clients we already met. A light client verifies specific facts on demand and trusts the chain’s consensus for the rest. A stateless client does the full job of a validating node — it re-executes the block and checks the state transition — just without the storage. It is a full verifier that happens to keep no state.

Under the hood — who still stores the state?

“Stateless” is a slight misnomer: the state does not vanish. Someone must still hold it to build blocks and to generate witnesses. The vision splits the network by role:

• State providers / block builders keep the full state and produce witnesses. (This dovetails with Proposer–Builder Separation: builders are already the specialised, state-heavy actors.)
• Stateless validators hold no state and just verify witnessed blocks — cheap to run, easy to multiply.

There is a transition cost that is easy to underrate: converting Ethereum’s existing Merkle-Patricia state into a Verkle tree is a massive, one-time migration of the entire state, and clients must handle the changeover without halting the chain. The migration mechanics are one of the hardest, least-settled parts of the plan — another reason to hold the timeline loosely.

Why this keeps the verifier circle wide

Tie it back to the throughline. The health of a credibly-neutral chain rests on how many independent parties can afford to verify it. Every gigabyte of state you must store to validate is a tax on being a verifier, and taxes on verification centralise it.

Statelessness removes the storage tax. If a validator needs only the block, a small witness, and 32 bytes of parent root, then verifying no longer requires a big disk — it can run on modest hardware, even a phone or a browser tab, and the circle of “who can check the world computer for themselves” stays wide even as the state grows without bound.

It is also a precondition for other designs. Cheap, self-contained state proofs make certain rollup and cross-chain constructions simpler: if a block carries a proof of exactly the state it touched, systems that need to verify Ethereum state elsewhere can lean on that proof instead of tracking the whole trie. Smaller witnesses are infrastructure that other parts of the scaling roadmap can build on.

The uncomfortable trade — witness bandwidth for state storage

Statelessness does not delete a cost; it moves one. Every block must now carry its witness, so the network spends bandwidth per block it did not spend before, and builders spend CPU generating proofs. The bet is that bandwidth and proving are cheaper and more decentralising to pay than forcing every verifier to store the whole state forever. That bet is only good if witnesses stay small — which is exactly why the order-of-magnitude shrink from Verkle proofs is load-bearing, not a nice-to-have. Break the small-witness assumption and the whole trade stops paying.

The competing path: state expiry, and why nothing is final

Verkle-plus-statelessness is one answer to “state keeps growing.” It is not the only one, and the roadmap has openly weighed alternatives:

• State expiry / statelessness variants. Instead of (or alongside) shrinking proofs, expire state that hasn’t been touched in a long time — move old, cold state out of what nodes must actively hold, and require a proof to resurrect it when someone finally touches it again. This attacks the growth directly rather than making proofs of the whole thing cheaper.
• Newer proving systems. Advances in general-purpose proofs (the same family powering zk-rollups) raise the possibility of committing to and proving state with different machinery than Verkle’s vector commitments — potentially superseding parts of the Verkle plan before it ships.

The point is not to memorise which one wins. It is that the destination is stable and the vehicle is not: Ethereum wants verification to stay cheap as state grows, and is willing to change the mechanism to get there. Follow the EIP process and roadmap page for how such a change would actually be specified, tested, and shipped — and expect the specifics above to move.

The architect’s lens

• Why does it exist? Because validating a block currently requires holding the entire state, and the state grows forever — steadily raising the hardware cost of being a verifier and, with it, the risk that only large operators bother.
• What problem does it solve? It shrinks the proof of touched state (the witness) enough that a block can carry it, so a node can validate the block from the witness alone — no local state — keeping verification cheap and widely accessible.
• What are the trade-offs? It swaps a storage cost for a bandwidth-and-proving cost: every block now ships a witness and builders must generate it. The whole trade only pays if Verkle-style proofs keep witnesses small, and it demands a large one-time migration of Ethereum’s existing state.
• When should I avoid it? As a builder, don’t design today’s systems assuming statelessness has shipped — it is roadmap-stage and its exact form may change. And a party that must build blocks or serve witnesses still needs the full state; statelessness helps verifiers, not state providers.
• What breaks if I remove it (or it never ships)? State keeps growing under Merkle-Patricia, node hardware requirements keep climbing, and the population of independent verifiers thins over time — weakening the very decentralisation that makes the chain worth trusting.

Check your understanding

1. Why is a growing state a problem for decentralisation specifically, not just for disk vendors? Tie your answer to who ends up able to run a verifying node.
2. Explain the “width problem” with Merkle-Patricia proofs: why does proving one key under a 16-way branch node force you to reveal fifteen other hashes, and why does that make full-block witnesses large?
3. What single property of a vector (polynomial) commitment lets Verkle trees produce dramatically smaller proofs, and how does it also let the tree become shallower?
4. Define a stateless client, and walk the five steps by which one validates a block without holding the state. What is the one 32-byte input it must already trust?
5. The page insists statelessness “moves a cost rather than deleting it.” Which cost moves to where, and what assumption must hold for the trade to pay off?

Show answers

1. Validating a block requires recomputing the state root, which today means holding the whole state locally. As the state grows, the disk, memory, and bandwidth to run a full node climb, so fewer independent people can afford it and verification drifts toward a few large operators. A chain is only credibly neutral if verifying stays cheap enough that ordinary people keep doing it — so state growth is a slow tax on decentralisation itself.
2. To recompute a branch node’s hash, the verifier needs the hashes of all its children; a 16-way branch has fifteen you didn’t take, and all of them must be in the proof so the verifier can hash the node and check it matches its parent. Multiply those sibling hashes by the trie’s depth and again by every item a block touches, and the siblings dominate — pushing a full-block witness into the megabytes.
3. A vector commitment can produce a short opening proof that “position i holds value v” whose size does not grow with the node’s width and does not require revealing the other children. Because width no longer inflates proofs, Verkle designs use very wide (256-way) nodes, which makes the tree shallower (fewer levels), and openings across many keys can be aggregated into one small proof.
4. A stateless client validates a block using only the block plus a witness (a proof of exactly the state it reads/writes), without holding the full state. Steps: (1) receive block + witness; (2) check the witness proves each touched item against the parent state root; (3) re-execute the block’s txs using the witnessed pre-values; (4) compute the new state root; (5) accept iff it matches the block’s claimed root. The one thing it must already trust is the parent block’s 32-byte state root.
5. It moves cost from storage (every verifier holding the whole state) to bandwidth and proving (every block carrying a witness, builders generating it). The trade only pays if witnesses stay small — the roughly order-of-magnitude shrink from Verkle proofs — otherwise per-block bandwidth balloons and the benefit evaporates.