A Verkle tree is a cryptographic data structure that organizes key-value pairs in a hierarchical tree format. Each parent node commits to its children using vector commitments instead of conventional hash functions. The name "Verkle" combines Vector commitment and Merkle, reflecting a design that grafts vector commitment mathematics onto the familiar Merkle tree architecture. First introduced by computer scientist John Kuszmaul in 2018, Verkle trees have since drawn significant attention from the Ethereum development community as a proposed replacement for the Merkle Patricia Trie used to store the blockchain's global state.
John Kuszmaul presented Verkle trees in 2018 through the MIT PRIMES research program, mentored by cryptographer Alin Tomescu. His paper's central thesis was that replacing cryptographic hash functions in a Merkle tree with vector commitment schemes produces a structure whose proof sizes grow only with the branching factor, not tree depth. At publication, the concept attracted limited notice outside academic cryptography circles. Broader interest came in 2021 when Vitalik Buterin published a detailed technical explainer applying Verkle trees to Ethereum's state management. Ethereum Foundation researcher Dankrad Feist further elaborated on the tree's structural properties. From then, the concept moved into active protocol development.
Structurally, a Verkle tree closely resembles the Merkle Patricia Trie used in Ethereum today. Every node is one of three types: an empty node, a leaf node holding a key-value pair, or an inner node holding a fixed number of children determined by the tree's width. In Ethereum's proposed implementation, each inner node holds 256 children. Some researchers have discussed raising this to 1024.
Keys in the Ethereum Verkle tree are 32-byte elements composed of a 31-byte stem and a single-byte suffix. Extension nodes represent a single stem shared across up to 256 children differentiated by their suffixes. Inner nodes, which can contain other extension nodes, hold vector commitments that capture all their children's values in a single compact cryptographic element.
The most consequential structural property of Verkle trees is their relative flatness. Each node fans out to 256 children rather than the 16 used in Ethereum's hexary Patricia trie, dramatically reducing the number of levels from any leaf to the root. Fewer levels mean fewer nodes must be traversed when constructing a proof, directly resulting in smaller proof sizes.
The defining technical departure of a Verkle tree from a Merkle tree lies in how parent nodes commit to their children. In a Merkle tree, a parent node is simply the hash of its concatenated children. Verifying a leaf therefore, requires supplying every sibling node at every level of the path up to the root, because without those siblings, the hash at each level cannot be recomputed.
Verkle trees replace that hash with a vector commitment, a cryptographic primitive that commits to an entire ordered list of values and can later produce a short proof that any single element of the list holds a specific value, without revealing the others. This property makes sibling nodes unnecessary: a compact proof attached to the path itself is sufficient to convince a verifier that each child really belongs to its parent.
In practice, Ethereum's Verkle tree implementation uses an even more powerful primitive called a polynomial commitment. The values committed to at each inner node are treated as evaluations of a polynomial, and the commitment binds that polynomial rather than a hash of raw data. Using KZG commitments and Inner Product Arguments over Pedersen commitments, multiple opening proofs from different paths in the tree can be aggregated into a single constant-sized multiproof. That multiproof can verify all parent-child relationships across an unlimited number of keys with a size that does not grow as more keys are added.
The practical impact of this design is clear in proof size comparisons. For a tree with one billion data points, a binary Merkle tree proof requires about 1 kilobyte. A Verkle tree proof for the same data requires fewer than 150 bytes. Compared to the hexary Patricia trie Ethereum currently uses, the advantage is even larger: Verkle proofs are roughly 6 to 8 times smaller than optimized binary Merkle proofs and more than 20 to 30 times smaller than proofs from the existing hexary structure.
This gap matters because Ethereum block validators must receive and verify state proofs within each 12-second slot. If a proof is too large to broadcast across the network in that time, nodes with slower connections fall behind, and only well-resourced nodes can reliably participate. Smaller proofs broaden who can validate the network without specialized hardware.
Ethereum currently requires every validating node to maintain a local copy of the entire state database, roughly 50 GB for state data alone and over 150 GB when Merkle proofs are included, growing by tens of gigabytes each year. This storage requirement raises the hardware bar for participation and concentrates validation among well-resourced operators.
Stateless clients address this by removing the local state requirement entirely. Instead of querying a local database to execute a block, a stateless client receives an execution witness alongside the block. The witness packages the specific state fragments needed to execute the transactions, along with a cryptographic proof that those fragments are genuine parts of the current state tree. The client can then verify the block without having stored anything beforehand.
Achieving stateless clients with the existing Merkle Patricia Trie is technically possible but impractical because witnesses are too large to transmit within a 12-second slot. Verkle trees reduce witness sizes enough to make real-time broadcast feasible. Vitalik Buterin described the intended outcome as enabling staking nodes to operate with near-zero hard disk space and sync nearly instantly. This would improve solo staking and expand access to light clients running on consumer hardware like a Raspberry Pi or mobile phone.
Verkle trees occupy a defined position in Ethereum's published development roadmap, under the phase Buterin labeled "The Verge," the third major stage after the Merge and the Surge. Implementation requires coordinated changes across multiple protocol layers: a new state data structure, revised gas accounting rules reflecting the real cost of generating witnesses, new cryptographic primitives, new block-level fields, and a migration strategy to convert existing state from the Merkle Patricia Trie to the Verkle tree format.
The migration approach most widely discussed is the overlay tree method, where new state writes go directly into the Verkle tree while old state in the Patricia trie is migrated incrementally block by block. Testing has progressed through a series of dedicated testnets. The Beverly Hills testnet served as an early proof of concept, followed by the more feature-complete Kaustinen testnet, which tested multi-client support across several independent implementations. Active Verkle tree work is underway in multiple Ethereum clients, including Geth, Nethermind, Besu, Erigon, Nimbus, and others. The relevant Ethereum Improvement Proposals governing this transition include EIP-6800 (unified Verkle tree state), EIP-4762 (statelessness gas cost changes), EIP-7545 (Verkle proof verification precompile), and EIP-2935 (historical block hash storage in state).
Both Verkle trees and the SNARK-based approaches under consideration as alternatives rely on elliptic curve cryptography, which is known to be vulnerable to quantum computing attacks. As quantum hardware capabilities advance, the long-term viability of elliptic curve constructions will require reassessment. Researchers have pointed to STARKed Merkle proofs and other hash-based proof systems as potential quantum-resistant alternatives, though they carry their own trade-offs in proof size and generation time.
In the near term, further efficiency gains are possible by wrapping the Verkle proof verifier itself in a SNARK, which would compress witness sizes further still. This path also preserves the option of switching to a fully SNARK-based Merkle structure in the future, should SNARK technology mature sufficiently through improvements from GKR protocols, SNARK-friendly hash functions, or dedicated hardware acceleration.
.webp)