Ethereum Verkle trie migration and the Fusaka upgrade delay

The Merkle Patricia Trie bottleneck

Ethereum nodes currently store 50 GB for the state and over 150 GB including all Merkle proofs. This data requirement increases by roughly half that amount every year. To validate a block, clients execute all transactions and verify the root hash. The current Merkle Patricia Trie requires providing all sibling nodes in a proof, which makes the witness too large for 12-second slots. A Merkle trie witness for 1,000 leaves reaches 3.5 MB. This size creates centralization pressure because only nodes with fast internet connections can process blocks in time. As the network grows, the inefficiencies of Merkle trees hinder scalability. Generating proofs for state and transaction verification in the current system can also be slow and computationally expensive. In a Merkle Patricia trie, a branch node is a 17-item node containing 16 nibble values and a value element. Extension nodes shortcut the descent by using a partial path. A 64-character path requires traversing many nodes, and a systems paper found the average depth at block height 18 million was 8.6 levels. This complexity causes disk I/O to become a bottleneck for full nodes. Because the current Merkle Patricia Trie requires providing all sibling nodes in a proof, the resulting witness size remains too large to broadcast across the network within a 12-second slot. This structure forces clients to store historical blocks, with Geth typically keeping state data for 128 blocks behind the head. A Merkle proof requires providing all sibling nodes along the path from a value to the root.

Verkle trees solve the witness size problem

Verkle trees address the witness size problem by using polynomial commitments instead of standard hashes for node computations. These trees use 32-byte keys composed of a 31-byte stem and a 1-byte suffix. Because Verkle trees use a width of 256, the tree is much flatter than a Merkle trie. This flatness reduces the number of levels between a leaf and the root. In the commitment phase, the prover computes a commitment to a polynomial P(x), which is a "compact representation" of the polynomial. During the evaluation phase, the prover provides proof that the polynomial evaluates to a specific value at a point X0. This allows the verifier to check a claimed value without revealing the full polynomial. A Verkle tree witness for 1,000 leaves requires only 150 kB, which is 23x smaller than the Merkle version. In 2026, researchers pivoted toward a binary tree design under EIP-7864 due to computational costs and quantum risks. This shift, combined with the September EOF delay, pushed the Fusaka upgrade to 2027. While current proposed widths are 256, there is an inclination to amplify this to 1024.

The path to statelessness

Stateless clients rely on a witness that arrives with the block instead of a local copy of the entire state database. This witness contains individual pieces of state data and cryptographic proof that the data belongs to the full set. Verkle trees enable small witnesses that validators can broadcast across the network in time for a 12-second slot. This reduction in data makes participation easier for smaller devices and increases sync speeds. This transition provides reduced data requirements and sustainable storage requirements while removing never-ending synchronizations. Verkle trees allow blocks to be "self-contained execution units" that allow verification without requiring any extra information, particularly the full state of the chain. This improvement ensures that knowing the state of one’s account is faster. Migrating to Verkle trees requires a new data structure, a new gas accounting model, and new cryptography primitives. You should keep in mind that developers must also devise a strategy to migrate existing state from the MPT to the VKT. Can the network manage the complexity of these new cryptographic primitives without compromising security?