Ethereum News
Verkle tree migration and the move to statelessness

Ethereum uses Merkle Patricia Tries to organize account balances, contract code, and storage. These structures require nodes to store the entire state to validate blocks. A Merkle trie witness for 1,000 leaves reaches approximately 3.5 MB, while Verkle trees reduce this to 150 KB. In a 15 million gas block with 6,000 accesses, the Merkle witness size reaches 18 MB. You already know how much the growing state size stresses current node operators who must maintain large local copies of the network state. Verkle trees replace repeated hashing with polynomial commitments to shrink these proofs. These trees produce witness sizes of 1 to 2 KB per proof or 200 bytes per account. This change creates a 23x reduction in data requirements for 1,000 leaves. By replacing standard hashing with polynomial commitments, Verkle trees allow a single commitment to represent up to 256 children, which drastically reduces the number of proof elements required at each layer. The transition to Verkle trees defines the move to statelessness.
Developers implement this change using an Overlay tree to migrate state. This process moves 1 billion key-values from the Merkle Patricia Tree to the new Verkle Tree. The migration of 1 billion key-values from the Merkle Patricia Tree to the Verkle Tree creates significant technical risk. To convert addresses, the protocol prepends 12 zero bytes to create an Address32. Verkle trees group account data under a 31-byte stem. This grouping means a single vector commitment covers a balance, nonce, and code hash simultaneously. Node operators must manage higher CPU and RAM requirements because polynomial commitment operations exceed the intensity of standard hashing.
| Component | Specification |
|---|---|
| Verkle Node Width | 256 |
| Code Chunk Size | 31 bytes |
| Recommended Storage | 4TB NVMe |
| Recommended RAM | 64GB |
The protocol uses 31-byte chunks for code. Accessing a code chunk costs 200 gas per 31 bytes. For developers, the cost for accessing storage slots 0 through 63 decreases from 2100 to 200. Hardware requirements for validators include at least 8 cores and 16 threads. A single thread rating of 3500 or more satisfies the target for commodity hardware. A setup costing $1000 using a NUC or Minisforum meets these needs.
The 2026 roadmap follows a sequence of major upgrades. Glamsterdam arrived in the first half of the year. Hegota follows in the second half of the year. As of March 2026, over 1.1 million active validators secure Ethereum, and the entry queue has surged to approximately 60 days. Hegota includes FOCIL, or EIP-7805, to prevent censorship at the block production level. Hegota also introduces smart accounts through EIP-8141, which gives native multi-signature control and gas sponsorship to users. PeerDAS, or EIP-7594, allows for scaling data availability through sampling, which reduces the need for nodes to download all blobs. Most nodes with stake sizes above 4096 ETH require more data processing after PeerDAS. FOCIL selects 17 participants per slot to enforce transaction inclusion. The 2026 roadmap focuses on throughput and user experience. Users must manage the transition as the network moves toward a modular, rollup-centric architecture. Will the reliance on KZG polynomial commitments introduce new security vulnerabilities?