The shift toward binary trees and STARK proofs in Ethereum

Vitalik Buterin’s March 3, 2026, proposal changed the path for Ethereum engineers by suggesting the network skip the Verkle tree endpoint to move directly to binary trees paired with STARK proofs. This proposal changed how engineers view state proofs, stateless clients, and the Verge upgrade. While researchers spent years studying Verkle trees, the binary-STARK design offers smaller witnesses. In 2021, Vitalik Buterin noted that a tree holding a billion pieces of data needs 1 kilobyte for a proof under a traditional binary Merkle tree, but a Verkle tree requires under 150 bytes. A separate 2026 estimate covering 1,000 Ethereum accounts puts Merkle Patricia Trie witnesses closer to 170 KB against roughly 150 KB for Verkle trees, and under 25 KB for the emerging binary-tree-plus-STARK design that Ethereum is now leaning toward. I find the push for binary trees makes the Verkle tree development look like an unnecessary middle step. This 23x reduction in witness size for 1,000 state leaves is why researchers moved toward binary trees. A Merkle tree is a hash-based structure where every parent node hashes the concatenation of its children to create a single root hash. The current Merkle Patricia Trie uses Keccak-256 hashing and 16-way branching.

State minimalism in the Hegota upgrade

The Hegota upgrade in the second half of 2026 targets state minimalism and censorship resistance. It follows the Glamsterdam upgrade in the first half of 2026, which targets parallel transaction execution and a gas limit of 200 million. Hegota includes Verkle trees to reduce node storage requirements by 90%. This reduction helps validators avoid the high hardware costs of maintaining the entire state. Because disk operations take 100 to 1000 times longer than RAM access, reducing the need for massive disk storage helps decentralization. You should understand that Verkle trees replace the 16-way branching of the Merkle Patricia Trie with 256-slot nodes. The 2026 upgrade calendar also includes Fork-Choice Enforced Inclusion Lists to prevent validator censorship. Current state growth is 150 GB per year. Minimizing the state bloat tax, which currently sits at $12 per year for storage at $0.08 per GB, remains a priority. As long-term state size increases, the requirement for large amounts of fast memory creates a centralization risk. Witnesses must arrive within a 12-second slot to allow for timely validation.

Structural details of Verkle trees

Verkle trees use 32-byte keys split into a 31-byte stem and a 1-byte suffix to organize data. Each node contains commitments to its 256 children. A parent node creates a vector of these commitments using KZG polynomial commitments to prove a position holds a specific value. This structure eliminates the requirement to provide all sibling node hashes along the path to the root. In a tree with 1,000 leaves, a Merkle trie witness is 3.5 MB, while a Verkle tree witness is only 150 KB. I see no reason to favor Verkle trees if the 25 KB binary-STARK proofs become the standard for the Hegota upgrade. The MapToScalarField function acts as a translator to squash child commitments into numbers for the parent vector. This 31-bit prime configuration enables single-instruction multiple-data parallelism to assist validators. In a Verkle tree, a path to an account uses 1-byte chunks of the address to select an index. If the first byte is 0x01, the path moves to Index 1 in the Root Node, and this process continues through the levels until the leaf node is reached. Will the transition to a binary-STARK model happen before the Hegota deployment?