Ethereum's Verkle Tree Upgrade: Solving the State Bloat Problem

Every Ethereum transaction touches state: account balances, contract storage slots, code hashes. All of it lives in a data structure called the Merkle Patricia trie, and that trie has been growing since genesis. Running a full node now requires 1.5 to 2 TB of disk space, with the state trie alone exceeding 150 GB of on-disk data. The trajectory is unsustainable: Vitalik Buterin has estimated state growth at roughly 100 GB per year, and recent gas limit increases have pushed weekly new state creation from approximately 105 MiB to over 300 MiB.

Verkle trees were designed to solve this by replacing hash-based proofs with vector commitments, shrinking proof sizes by an order of magnitude and enabling stateless clients that can verify blocks without storing the full state. While Ethereum's roadmap has since evolved toward an alternative approach, the Verkle tree design remains one of the most important contributions to blockchain state management, and understanding it is essential for anyone following Ethereum's scaling trajectory.

Why State Bloat Matters

Ethereum uses an account model where every address has a persistent entry in the global state: a nonce, a balance, a storage root, and a code hash. Smart contracts add storage slots that persist indefinitely. Unlike a UTXO that gets consumed when spent, an Ethereum account entry never disappears. Even an empty account with zero balance still occupies space in the trie until explicitly removed.

This design creates a one-way ratchet. State bloat is the term for the cumulative growth of this dataset. Every new contract deployment, every ERC-20 balance update, every NFT mint adds trie nodes that every full node must store and every new node must download during initial sync.

The hardware spiral: As state grows, the minimum hardware for running a full node rises. Fewer people can afford to run nodes, which concentrates validation among well-resourced operators. This directly undermines decentralization, the property that gives a public blockchain its value.

Current Node Requirements

Running a full Ethereum node in 2026 requires an NVMe SSD of at least 2 TB, 16 to 32 GB of RAM, and a modern multi-core CPU. Archive nodes, which store every historical state, demand 12 to 16 TB on Geth and roughly 2 to 3 TB on Erigon's more compact layout. The gap between a pruned full node and an archive node illustrates how much state Ethereum has accumulated since 2015.

How Merkle Patricia Tries Work

Ethereum's current state structure is a hexary Merkle Patricia trie: each internal node can have up to 16 children (one for each hex digit), plus a value slot. The trie maps 256-bit keys to values, and the root hash commits to the entire dataset. Changing any leaf value cascades through the tree, producing a new root hash that reflects the updated state.

The Proof Size Problem

To prove that a particular value exists in the trie, you must provide the path from the leaf to the root along with every sibling hash at each level. In a hexary trie, each node has 16 children, so each proof level requires 15 sibling hashes. For a trie of any meaningful depth, this adds up fast.

A block witness under the current structure contains the values a block touches (balances, storage slots, contract code) plus the Merkle proofs linking those values to the state root. For a typical Ethereum block touching thousands of state elements, the aggregate witness can reach several megabytes. That is far too large to include in each block, which is why Ethereum currently requires every validator to store the full state locally.

Verkle Trees: Vector Commitments Instead of Hashes

Verkle trees, first described by John Kuszmaul in 2018, replace the hash-based commitments in a Merkle tree with vector commitments. The name combines "vector" and "Merkle." The key insight is that a vector commitment can prove the value at any position without revealing the other values, eliminating the need for sibling hashes entirely.

Pedersen Commitments and IPA

Ethereum's Verkle tree design uses Pedersen commitments over the Bandersnatch elliptic curve, paired with Inner Product Arguments (IPA) as the proof system. This combination was chosen for several reasons:

• No trusted setup is required, unlike KZG commitments, which need a ceremony to generate public parameters
• Security relies on the discrete logarithm assumption, a well-studied cryptographic foundation
• IPA proofs can be batched efficiently, which is critical when a single block touches thousands of state elements
• Each commitment is a single elliptic curve group element (32 bytes), keeping internal nodes compact

The proposed tree width is 256 children per node. In a traditional Merkle tree, increasing the branching factor inflates proof sizes because each level adds more sibling hashes. With vector commitments, proof size is independent of the branching factor. A wider tree means a shallower tree (fewer levels), which further reduces proof sizes.

How Verkle Proofs Work

To prove that a value exists at a particular key, you provide the path from the leaf to the root, plus a compact commitment proof at each level demonstrating that the child commitment is consistent with its parent's vector commitment. No sibling data is needed. The verifier checks each proof against the parent commitment and, if all checks pass, confirms the value belongs to the state committed by the root.

The practical effect is dramatic. Vitalik Buterin's analysis comparing a Verkle tree against a binary Merkle tree over a billion data points found that a binary Merkle proof requires roughly 1 KB, while a Verkle proof comes in under 150 bytes. Against Ethereum's existing hexary structure, the reduction is even larger: 20 to 30 times smaller proofs for the same data.

Merkle Patricia Trie vs Verkle Tree

Why proof size matters: Smaller proofs are the gateway to stateless clients. If a block can carry its own proof of state access at a reasonable size, nodes no longer need to store the full state to validate it. This is the core premise behind Ethereum's "Verge" roadmap phase.

Stateless Clients: The End Goal

The purpose of shrinking proof sizes is to enable stateless validation. A stateless client keeps only the state root and verifies each block using a witness included with it. The witness contains the specific state values that the block's transactions read or modify, plus cryptographic proofs that these values are consistent with the state root.

The client processes the block's transactions against the witness data as a temporary database, computes the resulting state changes, and derives a new state root. If the computed root matches the block's claimed post-state root, the block is valid. No local state storage required.

What Stateless Clients Enable

• Full validation on consumer hardware: a smartphone or Raspberry Pi could verify the Ethereum chain without terabytes of storage
• Faster sync: new nodes only need the latest state root, not the entire state database
• More validators: lower hardware requirements mean more people can run validating nodes, improving decentralization
• Reduced bandwidth for light clients that only need to verify specific state values

The Pivot: From Verkle Trees to Binary Trees with STARKs

Despite years of research and prototype implementations, Ethereum's core developers have shifted direction. In early 2026, Buterin published a proposal favoring a binary tree structure combined with STARK proofs over the original Verkle design. The reasoning centers on a critical limitation: Verkle trees are difficult to prove inside a SNARK or STARK circuit.

Why the Change

Ethereum's long-term roadmap depends on validity proofs for execution. If the chain eventually wants a STARK proof that a block was executed correctly (which would enable instant finality and even more lightweight verification), the underlying data structure needs to be SNARK-friendly. Pedersen commitments over elliptic curves are expensive to prove inside STARK circuits, which use finite-field arithmetic.

A binary Merkle tree using a STARK-friendly hash function like Poseidon2 or BLAKE3 avoids this mismatch. The proof itself consists of only the data being proven plus approximately 100 to 300 KB of fixed STARK overhead. Buterin described the state tree and VM as accounting for over 80% of proving bottlenecks, making this change a prerequisite for verifiable computation on Ethereum.

EIP-7864: The Unified Binary Tree

EIP-7864 formalizes this approach. The proposal merges Ethereum's currently separate account trie and storage tries into a single binary tree with 32-byte keys. Account data is grouped into leaves in sets of 256 for storage locality. The reference implementation uses BLAKE3 as its hash function, with Poseidon2 as a potential future replacement if its security properties hold up under continued analysis.

As of late 2026, EIP-7864 remains a draft. Its activation is tentatively associated with the Hegota upgrade, which is expected in late 2026 or 2027. However, Ethereum hard fork timelines have historically slipped, and this one involves a fundamental restructuring of how the chain stores state.

Migration Challenges

Replacing a live blockchain's state tree is among the hardest upgrades any network can attempt. Ethereum's state trie contains hundreds of millions of entries, and every one must be re-committed under the new structure.

The Conversion Problem

Two main approaches have been discussed. An in-place conversion would halt the chain (or use a transition period) to rebuild the state tree entirely. An overlay approach would maintain both the old and new trees simultaneously during a migration window, gradually moving data from the legacy trie to the new structure as it is accessed. The overlay method avoids downtime but increases complexity and storage requirements during the transition.

Smart Contract Compatibility

Any contract that generates or verifies Merkle state proofs on-chain will break after migration. This includes contracts that use Merkle proofs for cross-chain verification, storage proofs for governance, and any protocol that hardcodes assumptions about the state tree structure. A migration period with backwards-compatible proof verification is likely necessary.

Implications for Layer 2s and Light Clients

The state tree redesign affects more than just L1 validators. Rollups that post state roots to Ethereum and rely on L1 state proofs for their security model will need to update their proof verification contracts. Optimistic rollups using state proofs in their fraud proof mechanisms and ZK rollups referencing L1 state in their validity proofs will both require changes.

For light clients, the upgrade is transformational. Current light clients trust full nodes or use the sync committee's attestations without independently verifying state. Stateless verification would let light clients check individual state values against the state root, achieving trustless verification at a fraction of current resource requirements.

Bitcoin's UTXO Model: A Structural Comparison

Ethereum's state bloat problem is a direct consequence of its account model. Bitcoin takes a fundamentally different approach with the UTXO model, which avoids indefinite state accumulation by design. For a detailed comparison of the two models, see our research on UTXO vs account model tradeoffs.

In Bitcoin, each transaction output is a discrete, self-contained object. When it is spent, it is consumed and removed from the active set. The UTXO set represents only the current spendable outputs, not the entire transaction history. As of 2026, the Bitcoin UTXO set occupies roughly 7 to 12 GB, depending on the serialization format. Compare this to Ethereum's 150+ GB state trie.

Bitcoin's UTXO model does not need a Verkle tree upgrade because it does not have a state bloat problem to solve. The tradeoff is programmability: Ethereum's account model enables complex smart contracts, while Bitcoin's script-based spending conditions are deliberately restrictive. This is a design tradeoff, not a flaw in either system.

Extending Bitcoin Without Inheriting State Bloat

Bitcoin's structural advantage in state management extends to its Layer 2 ecosystem. Spark, for example, builds on the UTXO model via statechains, enabling instant off-chain transfers without creating persistent state entries. When a VTXO is transferred on Spark, the previous owner's key share is deleted and a new one is created for the recipient. There is no accumulating trie, no state rent problem, and no monotonically growing database that every participant must store.

This is not a coincidence. The UTXO model's natural state hygiene means Bitcoin Layer 2 protocols can scale without facing the same structural challenges that forced Ethereum to redesign its core data structure. Developers building on Bitcoin's UTXO foundation through the Spark SDK inherit this property by default.

State Expiry: The Complementary Approach

Verkle trees and binary trees address proof sizes, but they do not directly solve the growth of the state dataset itself. For that, Ethereum researchers have proposed state expiry: a mechanism where state entries that have not been accessed within a defined period are evicted from the active tree and moved to cold storage. Accessing expired state would require providing a proof of its last known value.

An Ethereum Protocol Fellowship prototype found that approximately 58% of trie nodes could be moved to cold storage, reducing active node storage by roughly 22%. State expiry and tree redesign are complementary: smaller proofs make it cheaper to revive expired state, while expiry keeps the active tree from growing without bound.

Looking Ahead

The path from Merkle Patricia tries to whatever replaces them will be one of the most consequential upgrades in Ethereum's history. Whether the final design is a Verkle tree, a binary tree with STARK proofs, or something not yet proposed, the goal remains the same: shrink state proofs enough to enable stateless verification, so that anyone with modest hardware can validate the chain independently.

For a deeper look at the cryptographic foundations, see our research on zero-knowledge proofs and the lessons Bitcoin scaling has drawn from Ethereum's L2 experiments. For developers exploring how different blockchains handle state and scaling, the rollup vs state channel comparison provides additional context on the design space.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.