What Are Verkle Trees? Ethereum's Next State Storage Upgrade

Verkle trees are a proposed replacement for the data structure Ethereum currently uses to store its state (account balances, contract code, and storage), designed to produce dramatically smaller cryptographic proofs so that nodes can verify the chain's state without needing to store all of it themselves. The name combines "vector commitment" and "Merkle tree," the two concepts it blends together.

The Problem: Ethereum's State Is Growing

Every account balance, every smart contract's storage, every token balance recorded on Ethereum is part of its "state." Currently, this state is organized in a data structure called a Merkle Patricia trie, which lets nodes cryptographically prove that a specific piece of data belongs to a specific state root (a compact fingerprint of the entire state at a given block).

The problem is that Ethereum's state has grown continuously since launch, and current full nodes need to store the entire state to fully validate the chain and generate these proofs efficiently. This growing storage requirement raises the hardware bar for running a node, working against the goal of keeping node operation accessible to as many participants as possible.

What Verkle Trees Change

Verkle trees use vector commitments (a form of cryptography that lets you commit to a large list of values and later prove specific values within it, with proof sizes that don't scale linearly with the amount of underlying data) instead of the hash-based structure of Merkle Patricia tries.

The practical result: proofs of specific pieces of state can be far smaller and faster to verify than equivalent Merkle proofs, even as the total state being proven grows. This is the property that makes "stateless clients" — clients that don't need to store the full state at all, and instead just verify proofs supplied along with transactions — actually feasible at scale.

Why Stateless Clients Matter

A stateless client could verify that a transaction is valid and correctly executed using only a proof accompanying that transaction, without needing gigabytes of locally stored state data. This has several benefits:

• Lower hardware requirements to run a validating node, supporting broader participation and better client diversity.
• Faster node startup, since new nodes wouldn't need to download and reconstruct the entire historical state before being useful.
• Reduced ongoing storage growth pressure on the nodes that do choose to remain full state holders.

Verkle Trees vs. Merkle Patricia Tries

Aspect	Merkle Patricia Trie (current)	Verkle Trees (proposed)
Underlying cryptography	Hash functions	Vector commitments
Proof size for large state	Grows relatively large	Stays comparatively small
Enables stateless clients	Not practically	Yes, this is the main motivation
Migration complexity	N/A (current default)	Requires a full state transition

Where This Fits in Ethereum's Roadmap

Verkle trees are one of the key pieces under what Ethereum's roadmap calls "the Verge" — the phase focused on simplifying and shrinking state verification. Our overview of Ethereum's roadmap situates this alongside "the Surge" (rollup scaling via things like danksharding), "the Purge" (reducing historical data burden), and "the Splurge" (miscellaneous refinements).

Challenges and Open Questions

Migrating Ethereum's entire state from one data structure to another is a significant, one-time engineering undertaking that must be executed carefully to avoid disrupting existing contracts or breaking assumptions applications rely on. There have also been ongoing research discussions about whether newer cryptographic techniques beyond verkle trees (some based on different proof systems) might ultimately be a better long-term fit, meaning the specific technical path is still subject to refinement even as the underlying goal — smaller proofs, statelessness — remains stable.

Bottom Line

Verkle trees aim to replace Ethereum's current state storage structure with one that produces much smaller cryptographic proofs, making it realistic for nodes to verify the chain without storing its entire state — a change aimed squarely at keeping node operation accessible as Ethereum's state continues to grow. It's a deep infrastructure change rather than a user-facing feature, but it directly supports the network's long-term decentralization goals. For the bigger picture of how this fits with other scaling work, see our guide to Ethereum's roadmap.