Verkle Tree

What Is a Verkle Tree?

A Verkle tree is a data structure that combines the branching layout of a Merkle tree with vector commitments instead of cryptographic hashes. The name is a portmanteau of "Vector commitment" and "Merkle tree." It was proposed by John Kuszmaul in 2018 while he was a student in MIT's PRIMES research program. The original paper described it as "a bandwidth-efficient version of Merkle Hash Trees built using Vector Commitments."

In a traditional Merkle tree, each parent node is the hash of its children. To prove that a leaf belongs to the tree, a verifier needs all sibling hashes along the path from leaf to root. This is a Merkle proof. In a Verkle tree, the parent node is a vector commitment to its children. The commitment scheme itself can prove that a child value exists at a given position, eliminating the need for sibling data entirely.

This seemingly small change has a large practical consequence: proof sizes shrink from kilobytes to hundreds of bytes, even for trees storing billions of values. For blockchains like Ethereum, where every validator must verify state transitions, smaller proofs translate directly into lower bandwidth requirements and the possibility of running verification on resource-constrained devices.

How It Works

Understanding Verkle trees requires grasping how they differ from Merkle trees at the commitment level, and why that difference matters for proof generation.

From Hashes to Vector Commitments

In a binary Merkle tree, each internal node stores hash(left_child || right_child). To prove a leaf value, you provide every sibling hash along the path to the root. With a tree of depth d, a proof contains d sibling hashes.

A Verkle tree replaces this hash with a vector commitment: a single cryptographic object that "commits" to an ordered list of values. The commitment scheme provides an "opening proof" that demonstrates a particular value exists at a specific index in the committed vector, without revealing any other values. Crucially, this proof is small and does not grow with the number of values in the vector.

Two polynomial commitment schemes are commonly discussed for Verkle trees:

• KZG (Kate-Zaverucha-Goldberg): produces very small proofs (around 48 bytes per opening) but requires a trusted setup ceremony
• IPA (Inner Product Argument): slightly larger proofs but no trusted setup required, relying on standard discrete logarithm assumptions

Ethereum's implementation uses Pedersen commitments with IPA proofs on the Bandersnatch elliptic curve. This avoids the need for a trusted setup while still achieving compact proofs.

Tree Structure

Verkle trees use a much wider branching factor than binary Merkle trees. Ethereum's Verkle tree design uses a width of 256 children per node, compared to 2 in a binary Merkle tree or 16 in Ethereum's current hexary Patricia trie. The wider branching reduces tree depth: for the same number of leaves, a 256-ary tree is much shallower than a binary one.

The tree contains two types of nodes:

• Internal nodes: each holds a vector commitment to 256 child subtree roots
• Extension nodes: store up to 256 values that share the same "stem" (the first 31 bytes of the key), using two commitments (C1 for suffixes 0 to 127, C2 for suffixes 128 to 255)

Keys in Ethereum's Verkle tree are 32 bytes: a 31-byte stem plus a 1-byte suffix. This structure groups related data (an account's balance, nonce, code hash) under the same stem, allowing a single proof to cover multiple fields.

Proof Generation

Here is a simplified comparison of how proofs work in each structure:

# Merkle proof (binary tree, depth 30)
# Must include 30 sibling hashes (each 32 bytes)
proof = [sibling_hash_0, sibling_hash_1, ..., sibling_hash_29]
size  = 30 * 32 bytes = 960 bytes

# Verkle proof (256-ary tree, depth 4)
# Path of 4 commitments + one IPA multi-proof
proof = [commitment_0, commitment_1, commitment_2, commitment_3, ipa_proof]
size  ≈ 150–200 bytes (for a single value)

The critical insight: in a Merkle proof, you need sibling data at every level because the hash function requires all inputs to recompute the parent. In a Verkle proof, the vector commitment scheme directly proves the parent-child relationship without exposing siblings. As Vitalik Buterin explains: "You do not need to provide sister nodes; instead, you just provide the path, with a little bit extra as a proof."

Furthermore, Verkle proofs can be aggregated. Multiple opening proofs across different branches can be combined into a single compact multi-proof, further reducing the total witness size for a block.

Proof Size Comparison

The proof size reduction is the primary motivation for adopting Verkle trees. The exact numbers depend on the comparison context:

For Ethereum, the practical impact is on block witnesses: the set of state data and proofs a validator needs to verify a block. With the current Merkle Patricia Trie, worst-case witnesses can reach 18 MB, far too large to transmit within Ethereum's 12-second slot time. Verkle witnesses for the same blocks shrink to a size that fits comfortably within network constraints.

Use Cases

Stateless Clients

The primary use case for Verkle trees is enabling stateless verification. Today, an Ethereum validator must store the entire state database (over 200 GB and growing at roughly 30 GB per year). This creates a significant hardware barrier. With Verkle trees, block proposers can attach a compact witness containing all the state data and proofs needed to verify that block's transactions. Verifiers check the witness against the state root commitment without storing any state locally.

Stateless clients would dramatically lower the barrier to running a validator, improving Ethereum's decentralization. Vitalik Buterin has described a vision where "every mobile wallet, browser wallet, and even smart watch" could verify blocks directly.

Reduced Gas Costs for Storage Access

Ethereum's Verkle tree design reorganizes how account data is stored. Under EIP-6800, related storage slots (an account's balance, nonce, and code) share the same key stem. Accessing adjacent storage slots within the same stem costs significantly less gas: as low as 200 gas versus the current 2,100 gas for cold storage reads. This benefits smart contracts that read multiple storage variables in a single transaction.

Light Client Verification

Compact proofs allow light clients to verify specific state claims (account balances, contract storage values) with minimal bandwidth. This is especially valuable for mobile applications and embedded systems that cannot maintain a full copy of the blockchain state. Light clients powered by Verkle proofs would be far more trustworthy than those relying on centralized RPC providers.

Improved Data Availability

Smaller proofs improve data availability verification in modular blockchain architectures. When state proofs are compact enough to include in block headers or distribute alongside block data, validators and light clients can confirm that state transitions are correct without downloading the full state.

Ethereum's Verkle Transition

Verkle trees are a centerpiece of Ethereum's "Verge" roadmap phase, one of five post-Merge development tracks. The transition from the existing Merkle Patricia Trie is defined primarily in EIP-6800, authored by Vitalik Buterin, Dankrad Feist, Guillaume Ballet, and others.

Migration Strategy

The migration introduces a new Verkle state tree alongside the existing Patricia trie:

1. After activation, all new state writes and copies of accessed state go into the Verkle tree
2. The existing Patricia trie becomes immutable (frozen)
3. Over time, state gradually migrates from the old tree to the new tree as it is accessed
4. Eventually, the old tree can be pruned entirely

This overlay approach avoids a disruptive "big bang" migration that would require touching every account and contract simultaneously.

Current Status

Verkle trees were originally targeted for inclusion in Ethereum's Hegota network upgrade. Trail of Bits and Consensys Diligence completed security audits in late 2025, and devnet testing progressed through multiple iterations. However, as of mid-2026, the Ethereum community has been debating whether to proceed with Verkle trees or pivot to an alternative approach using STARKed binary hash trees (proposed in EIP-7864). The binary tree approach would be resistant to quantum computing attacks, while Verkle trees' reliance on elliptic curve cryptography makes them theoretically vulnerable to future quantum computers. The final direction has not been officially confirmed.

Risks and Considerations

Quantum Vulnerability

Verkle trees built on elliptic curve commitments (Pedersen/IPA on Bandersnatch) are vulnerable to quantum computing attacks. A sufficiently powerful quantum computer could break the discrete logarithm assumption that underpins the commitment scheme. Binary hash trees using hash-based commitments are quantum-resistant by contrast. This concern has driven the debate within the Ethereum community about whether to pursue Verkle trees at all, or skip directly to a zero-knowledge proof based approach with binary trees.

Migration Complexity

Transitioning Ethereum's entire state tree is one of the most complex upgrades the network has attempted. Keys expand from 20 bytes to 32 bytes, account data is reorganized, and gas costs for storage operations change significantly. Smart contracts and tooling that depend on specific state layouts may require updates. The overlay migration strategy reduces risk but introduces a period where two tree structures coexist, adding implementation complexity.

Proof Generation Cost

While Verkle proofs are small to verify, generating them is computationally more expensive than generating Merkle proofs. Block proposers must compute polynomial commitments and opening proofs for every piece of state accessed in a block. This shifts computational burden from verifiers (who benefit from smaller proofs) to proposers, potentially reinforcing the trend toward specialized block builders in Ethereum's execution layer.

Cryptographic Assumptions

Merkle trees rely on collision-resistant hash functions, which are well-studied and widely trusted. Verkle trees introduce additional cryptographic assumptions (the security of the Bandersnatch curve, the soundness of IPA proofs). Any vulnerability in these primitives could compromise the integrity of the entire state tree. The newer cryptographic foundations have undergone less real-world stress testing than established hash functions like SHA-256.

Verkle Trees Beyond Ethereum

While Ethereum has driven most of the practical development around Verkle trees, the concept applies to any system that benefits from compact state proofs. Certificate transparency logs, distributed databases, and other blockchain networks could adopt Verkle trees to reduce proof overhead. The general principle of replacing hash-based commitments with algebraic commitments to shrink proofs is a pattern that extends beyond any single blockchain. For further reading on related proof systems, see the research on zero-knowledge proofs in blockchain applications and how post-quantum cryptography may reshape these designs.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.