Ethereum's Hegotá Fork: How Verkle Trees Could Shrink Node Storage by 90% and Unlock Stateless Clients
Running an Ethereum full node in 2026 demands 4-8 TB of NVMe SSD storage, 32-64 GB of RAM, and a modern eight-core CPU. That hardware bill prices out hobbyists, concentrates validation power among well-funded operators, and quietly undermines the decentralization promise that justifies the entire network. The Hegotá hard fork, scheduled for late 2026, aims to change that equation with a single architectural swap: replacing the 15-year-old Merkle Patricia Trie with Verkle Trees, a cryptographic data structure that could cut node storage requirements by up to 90% and make "stateless" Ethereum clients a production reality for the first time.
The State Bloat Problem Ethereum Can No Longer Ignore
Ethereum's state — the complete record of every account balance, contract storage slot, and nonce — has ballooned past 200 GB, and the full chain data (including history) now exceeds 3 TB on Geth. Archive nodes require 18-20 TB. Every transaction adds to this burden, and nothing in the current architecture trims it.
The consequences are measurable. As of early 2026, Etherscan detects roughly 14,339 full nodes globally. The United States hosts 38.96% of them, Germany 14.53%, and China 14.01%. Home-run nodes did grow 18% year-over-year, but the barrier to entry keeps rising. A solo staker who bought a 2 TB SSD in 2022 has already been forced to upgrade — or quit.
This is the problem the Verge phase of Ethereum's roadmap was designed to solve. And Verkle Trees are the technical centerpiece.
What Verkle Trees Actually Change
At its core, a Verkle tree looks similar to Ethereum's current Merkle Patricia Trie. Both are tree-shaped data structures where every node is either empty, a leaf (holding a key-value pair), or an intermediate node with children. The critical difference lies in how they prove that a piece of data exists in the tree.
Merkle Patricia Trees use hash-based proofs. To prove a single value, you need to provide every sibling node along the path from the leaf to the root — the full set of "sister nodes." For Ethereum's hexary (width-16) trie, this means proof sizes of roughly 150 KB per proof. As the state grows, these proofs get heavier.
Verkle Trees use vector commitments based on polynomial cryptography. Instead of hashing each sibling independently, the prover generates a single compact proof that covers all parent-child relationships along the entire path. The proposed Ethereum implementation uses a width of 256 (some researchers advocate 1,024), which makes the tree shallower and the proofs dramatically smaller.
The numbers speak for themselves:
| Metric | Merkle Patricia Trie | Verkle Tree |
|---|---|---|
| Proof size per value | ~150 KB | ~1-2 KB |
| Witness data for a block | Megabytes | Kilobytes |
| Tree width | 16 (hexary) | 256 |
| Proof structure | All sibling hashes | Single polynomial commitment |
A Verkle tree can prove membership in a tree with a billion data points using fewer than 150 bytes. The current system needs roughly 1 KB under ideal conditions — and Ethereum's Patricia Trie is far from ideal.
Stateless Clients: The Endgame
The real prize is not just smaller proofs — it is stateless validation.
Today, every Ethereum full node must download, store, and maintain the complete state trie. When a new block arrives, the node re-executes every transaction against its local copy of the state to verify correctness. No state, no verification.
Verkle Trees change this equation. Because proofs are compact enough to include inside blocks themselves, a "stateless client" can verify a block by checking only the Verkle proof attached to it — without storing any state at all. The validator receives the block, checks the proof against the root commitment, and confirms correctness in milliseconds.
What this means in practice:
- Near-zero storage for validators: A staking node could operate with minimal disk space, potentially under 1 GB.
- Instant sync: New nodes would not need to download 200+ GB of state. They verify blocks as they arrive.
- Broader participation: The hardware barrier drops from "dedicated server" to "Raspberry Pi with good bandwidth."
- Stronger decentralization: More nodes means more geographic distribution, more client diversity, and more resilience against censorship.
Vitalik Buterin has described Verkle Trees as the key to enabling "stateless validator clients" that achieve near-instant synchronization. If the vision holds, running a validating Ethereum node could become as simple as checking a few kilobytes of data per block.
The Quantum Elephant in the Room
Not everyone is convinced Verkle Trees should ship. The most serious objection comes from the quantum computing community.
Verkle Trees rely on elliptic curve-based polynomial commitments — the same class of cryptography that quantum computers, running Shor's algorithm, could theoretically break. If a sufficiently powerful quantum computer arrives within the next decade, every Verkle proof on Ethereum would become untrustworthy, and the network would need yet another migration.
This has sparked an active debate within Ethereum's developer community between two camps:
Ship Verkle Trees now. The benefits are immediate and well-understood. Quantum computers capable of breaking elliptic curve cryptography are likely 10-15 years away. Ethereum can adopt Verkle Trees today and migrate to quantum-resistant structures later.
Skip straight to STARKed binary hash trees. EIP-7864 proposes replacing the current trie with a binary tree using an efficient hash function (Blake3 or Poseidon). Combined with STARK proofs, this approach would be quantum-resistant from day one. Binary trees produce Merkle branches four times shorter than today's structure, and a hash function swap could add another 3-100x proving efficiency improvement.
The pragmatic middle ground — and the current trajectory — appears to be shipping Verkle Trees in Hegotá while monitoring quantum computing progress and STARK proof performance. If STARK-based alternatives mature fast enough, a future fork could swap the commitment scheme without repeating the state migration.
Hegotá in Context: Ethereum's 2026 Upgrade Cadence
Hegotá represents the second major hard fork of 2026, following Glamsterdam in the first half of the year. This two-fork cadence reflects a deliberate shift in Ethereum's development philosophy: smaller, more frequent upgrades instead of the massive, delayed releases that characterized earlier eras.
Glamsterdam (H1 2026) focuses on execution-layer improvements: gas optimizations, Block-level Access Lists, and enshrined Proposer-Builder Separation (ePBS). These are incremental but important changes that improve L1 throughput and MEV handling.
Hegotá (H2 2026) targets the state layer itself. Verkle Trees are the leading candidate for the "headline" feature, though state and history expiry mechanisms are also under discussion.
Both follow the 2025 upgrades — Pectra and Fusaka — which delivered PeerDAS and expanded blob capacity for rollups. Together, these four forks trace a coherent arc: blob space for L2s, gas efficiency for L1, and now state compression for node operators.
The naming convention reflects this continuity. "Hegotá" combines "Bogotá" (the execution layer codename, referencing the 2022 Devcon host city) and "Heze" (the consensus layer codename, referencing a star). Every Ethereum fork since the Merge has followed this city-plus-star pattern.
What Changes for Node Operators, Stakers, and Developers
Solo stakers stand to benefit the most. Current minimum hardware requirements — 32 GB RAM, 2+ TB SSD, dedicated internet — create a financial barrier that pushes many toward liquid staking protocols (Lido, Rocket Pool) or centralized exchanges. If Verkle Trees reduce storage needs to under 100 GB, the economics of solo staking fundamentally shift.
Node infrastructure providers face a different calculation. Companies running hundreds or thousands of nodes will see hardware costs drop, but they must invest in client updates and migration testing. The transition from Patricia Tries to Verkle Trees requires a one-time state conversion that cannot fail — any bug in the migration could corrupt Ethereum's entire state database.
DApp developers should notice no difference in their smart contract code. The state trie is an infrastructure-layer concern, abstracted away by client implementations. However, developers who build tools that directly query Ethereum's state (block explorers, analytics platforms, MEV searchers) will need to update their proof verification logic.
L2 rollups benefit indirectly. Smaller state proofs on L1 mean cheaper state verification for rollups that post proofs to Ethereum. This compounds the cost reductions already achieved through EIP-4844 blobs, potentially pushing per-transaction L2 costs below $0.0001.
The Migration Risk
The hardest part of Verkle Trees is not the cryptography — it is the migration.
Ethereum cannot simply swap data structures in a single block. The entire state trie — every account, every contract, every storage slot — must be converted from Merkle Patricia format to Verkle format. This is a multi-gigabyte transformation that must happen atomically across all clients, all validators, and all nodes simultaneously during the hard fork.
Previous Ethereum upgrades have modified how data is processed, but none have restructured how data is stored at this fundamental level. The closest analogy is the Merge itself, which swapped the consensus mechanism from proof-of-work to proof-of-stake — but the Merge did not touch the state trie.
Client teams (Geth, Nethermind, Besu, Erigon, Reth) are already building migration tools and running testnet conversions. The Hegotá timeline gives them roughly six to nine months of testing from the time features are locked. Given the stakes, this may be the most heavily audited upgrade in Ethereum's history.
Looking Forward: From Verge to Purge
Verkle Trees are not the final destination. They are the enabling technology for the next phase of Ethereum's roadmap: the Purge.
Once stateless clients are live, Ethereum can safely expire old state data without compromising network security. Nodes would no longer need to store years of historical state — they could verify new blocks using only the current state root and Verkle proofs. This "state expiry" mechanism would permanently cap Ethereum's storage requirements, regardless of how many transactions the network processes.
Combined with history expiry (EIP-4444), which allows nodes to drop block bodies and receipts older than a configurable threshold, the full Verge-to-Purge pipeline could reduce Ethereum node requirements to something that fits on a smartphone.
That is still years away. But Hegotá, if it ships as planned, takes the single most important step: proving that Ethereum can fundamentally restructure its state layer without breaking the network.
BlockEden.xyz operates high-performance Ethereum RPC nodes and API infrastructure, providing developers with reliable access to the network as it evolves through upgrades like Hegotá. Explore our Ethereum API services to build on infrastructure designed for what comes next.