Verkle tree migration and the path to Ethereum statelessness

Ethereum clients currently use a Merkle Patricia Trie to store state data. Information about individual accounts resides as leaves on the trie, and pairs of leaves undergo repeated hashing until only a single hash remains. This final hash defines the root. To verify blocks, clients execute all transactions and update their local state trie. A block remains valid if the root of the local tree matches the one provided by the block proposer. Verifying the blockchain requires each client to store the entire state trie for the head block and several historical blocks. Geth, for instance, keeps state data for 128 blocks behind the head. This requirement demands significant disk space, which creates a barrier for running full nodes on cheap, low-power hardware. The Merkle structure makes witness sizes too large because the witness must include all intermediate hashes and all sibling nodes for every node in the proof. Verkle trees provide a data structure that uses polynomial commitments, specifically vector commitments built on Kate-Zaverucha-Goldberg (KZG) schemes, to solve this. Verkle trees use a higher branching factor of 256 children compared to the 16 children in a Merkle trie. This structure makes the tree flatter, which reduces the data required to generate a proof. Verkle keys consist of 32-byte elements composed of a 31-byte stem and a single byte suffix. These keys organize into extension nodes and inner nodes. Because the polynomial commitment allows the witness to have a fixed size regardless of the number of leaves it proves, the size remains manageable.

Hegota targets the fourth quarter of 2026 for the implementation of Verkle trees and state expiry. Developers moved these features from the H1 2026 Glamsterdam upgrade to Hegota to manage technical scope. The Fusaka upgrade, which launched December 3, 2025, included PeerDAS and EOF but left the harder infrastructure work for later. Hegota bundles Verkle trees, state expiry, and stateless client features. Because the technical implementation of Verkle trees requires heavy infrastructure work, developers moved the Verkle transition from the H1 2026 Glamsterdam upgrade to the Hegota upgrade in the fourth quarter of 2026. Main client teams like Geth, Nethermind, Besu, and Erigon all have active Verkle branches. Consensus on the exact stem and extension node encoding arrived in late 2025. The implementation uses a conversion overlay where new state goes into a Verkle tree while old state stays in the Merkle Patricia Trie. This transition is a prerequisite for history expiry under EIP-4444. Testnets like Kaustinen have tested the conversion overlay logic. As state is touched, it migrates naturally. A forced migration of cold state requires a background process across multiple blocks to prevent gas spikes.

The witness size for a block containing 1,000 leaves drops from 3.5 MB in a Merkle trie to 150 kB in a Verkle tree. Polynomial witnesses reach sizes between 0.128 and 1 kB. However, contract code poses a massive difficulty for witness efficiency. A contract can contain up to 24,000 bytes, which could push a witness size over 100 MB. To solve this, the protocol uses code chunking to break bytecode into 31-byte segments. This method allows the protocol to charge for accessing individual chunks. At each step of EVM execution, the program counter determines which chunk is accessed. A JUMP or JUMPI instruction accesses the destination chunk only if the jump condition is true. A PUSH instruction accesses all chunks between the current program counter and the index of the pushed data. Accessing code chunks incurs a 350 gas cost. This chunk size of 31 bytes allows the protocol to prepend one byte to represent the number of bytes at the start of the chunk for pushdata.

Stateless clients use witnesses to verify blocks without maintaining a local state database. This allows nodes to run on consumer hardware by reducing storage requirements. The reduction in witness size facilitates easier peer-to-peer network propagation. You already know that reducing disk I/O helps prevent denial-of-service attacks. However, stateless clients cannot participate in transaction gossip or serve JSON-RPC endpoints like eth_call without the full state. If the migration fails to address the need for transaction gossip, stateless clients remain limited in utility. Validator operators gain the most benefit through reduced hardware requirements. If running an independent validator becomes cheap, the bundling benefit currently offered by staking pools might compress. Adoption metrics will depend on validator count growth and client diversity. A single client reaching a 33 percent supermajority threshold could affect the network. Banking examiners would ask for the rollback procedure if state migration fails post-fork and the audit trail confirming state-root continuity. Will the conversion overlay handle the cold state effectively?