Abstract
Ethereum’s execution layer has used Merkle Patricia Tries for state storage since the genesis block. MPTs are well understood and battle-tested, but they produce large witnesses: to prove that a single storage slot exists requires transmitting every sibling hash along the path from root to leaf, which scales logarithmically with tree depth. Verkle trees replace hash-based commitments with polynomial commitments, specifically vector commitments built on Kate-Zaverucha-Goldberg (KZG) schemes, reducing witness size dramatically. The migration is now the central enabling piece for stateless client verification on Ethereum mainnet, and it is one of the most complex state-layer changes the protocol has attempted. This post covers how Verkle trees differ structurally, what the migration involves, and where the implementation stands as of early 2026.
Structural Differences from Merkle Patricia Tries
A Merkle Patricia Trie produces a proof by revealing sibling hashes at each branching point. For a trie of depth d, the proof is O(d) hashes. In Ethereum’s 256-bit key space with a branch factor of 16, worst-case path length is 64 nodes, and witnesses for accessing multiple leaves in the same block multiply because shared path segments are not deduplicated efficiently. A Verkle tree uses a higher branching factor (256 in the current Ethereum specification) and KZG polynomial commitments at each internal node. Proofs for multiple leaves under the same subtree can be aggregated into a single proof whose size is sublinear in the number of leaves accessed. For a block that touches thousands of storage slots, the witness size difference is roughly an order of magnitude.
The Conversion Overlay Approach
The Ethereum Ipsilon team and Geth contributors settled on a “conversion overlay” migration design rather than a flag-day switch. Under this approach, the Merkle Patricia Trie continues to exist, but newly written or modified state is written into a Verkle overlay that sits on top. Reads check the overlay first; the MPT is consulted for entries not yet migrated. Over time, as state is touched, it migrates naturally. A forced migration of cold state (accounts and storage slots not accessed in years) requires a background conversion process that runs across multiple blocks to avoid per-block gas spikes. The ethereum/go-ethereum repository has had a verkle experimental branch tracking this design, with periodic merge-backs into a staging branch as components stabilize.
Stateless Clients and the End Goal
The reason Verkle trees matter beyond witness size is stateless client verification. A stateless client can verify a block without holding any local copy of the state, provided the block producer attaches a witness proving all state accessed during execution. With MPT witnesses, this witness is too large for practical gossip: it can exceed 20 MB for a full block. Verkle witnesses shrink that to a range where network propagation before the next slot is feasible. This matters for light client security, for validator decentralization (nodes do not need fast SSDs to hold the full state trie), and as a foundation for future history expiry schemes under EIP-4444. The Verkle migration is therefore a prerequisite for several other roadmap items, which explains the sustained protocol-level investment despite the implementation complexity.
Current Implementation Status
As of February 2026, Ethereum testnets have run Verkle-enabled forks on short-lived devnets, with Kaustinen and subsequent devnet iterations testing the conversion overlay logic and witness generation. The main client teams - Geth, Nethermind, Besu, and Erigon - all have active Verkle branches. Consensus on the exact stem and extension node encoding was reached in late 2025. The EIP formalizing the Verkle transition (EIP-6800 and its successors) is in the final specification stage. A mainnet activation date has not been announced, but the devnet cadence suggests a 2026 testnet deployment on a long-lived public testnet is the next milestone before a mainnet fork proposal.