Ethereum News
How Ethereum’s Verkle tree migration changes statelessness roadmaps
The Ethereum roadmap shifted toward unified binary trees under EIP-7864. This change follows the Kaustinen testnet hitting 500 MB proofs this September. Verkle trees rely on cryptography that lacks security against quantum attacks. Binary trees use only hash functions which stay safe in a post-quantum world.
The roadmap changed.
Developers moved toward the binary tree design to avoid future replacements. Verkle trees use vector commitments to shrink proofs. While Verkle trees use polynomial commitments to flatten the tree, the reliance on elliptic curve points requires a trusted setup ceremony to ensure that no participant retains the secret parameters that could allow them to forge proofs. Verkle keys use a 31-byte stem and a 1-byte suffix. These keys organize into extension and inner nodes. The tree width is 256, though some suggest increasing this to 1024. The Verkle tree stores all edits to state and a copy of all accessed state. This structure uses the KZG polynomial commitment scheme to allow the witness to have a fixed size regardless of the number of leaves it proves.
Witness efficiency and scale
The Merkle Patricia Trie creates witnesses that grow as the state expands. A naive approach for a block with a few thousand transactions per block, 256-bit hashes, and hundreds of millions of accounts produces a block witness in the tens of Megabytes. A witness for 6000 account accesses in a block reaches 18 MB. This size is too large to broadcast through a peer-to-peer network within a 12 second slot. State growth is a problem. A non-pruning node sees storage requirements grow by 14 GB every week. The MPT, which is a hexary tree, requires all sibling nodes on the path from the leaf to the root to be provided.
Verkle trees reduce size.
The best solution for shrinking witness size is the Verkle tree. Verkle trees provide a 23x reduction in witness size for 1,000 leaves. The Merkle trie witness for that many leaves is 3.5 MB, while the Verkle tree witness is 150 kB. Verkle trees reduce account witness sizes to about 200 bytes in the average case. A single state lookup in the Merkle Patricia Trie at block height 18 million requires 8.6 database reads. Verkle trees group related account data under the same 31-byte stem. This grouping ensures that changing one field inside an account only requires updating one commitment.
| Structure | Witness Size (1,000 leaves) |
|---|---|
| Merkle Patricia Trie | 3.5 MB |
| Verkle Tree | 150 kB |
| Unified Binary Tree | A few MBs |
The MPT is inefficient.
Decentralization goals
Statelessness aims to lower hardware requirements for validators. This allows nodes to run on mobile phones or home computers. Weak statelessness puts the burden of state storage on block proposers. Other nodes verify blocks using witnesses. This requires proposer-builder separation so builders can use powerful hardware to generate witnesses.
The transition continues.
EIP-4444 allows validators to prune historical data. This offloads data to the Portal network. The Nimbus team developed the Fluffy client to support the Portal network. This helps nodes query data from a distributed storage network. The Verge includes the goal of running a fully verifying node with only a few GB of storage space. This goal is part of a move toward a rollup-centric architecture. The Nimbus team developed the Verified Web3 Proxy to verify responses from RPC endpoints against the blockchain state. This protects against malicious or fraudulent behavior. Nimbus builds lightweight, high-performance execution-layer and consensus-layer clients. You should know that this transition favors long-term quantum resistance. Will the network reach strong statelessness?
