State growth is the bottleneck. High TPS is meaningless if the node hardware required to store the chain's state becomes prohibitively expensive and centralized.
the-ethereum-roadmap-merge-surge-verge
Blog
The Real Bottleneck Verkle Trees Address
Everyone talks about TPS as Ethereum's scaling limit. They're wrong. The real, existential bottleneck is state growth. Verkle Trees, part of 'The Verge,' directly attack this by enabling stateless clients, which is the prerequisite for true scaling.
introduction
THE STATE BOTTLENECK
The TPS Obsession is a Distraction
The real scaling constraint is not transaction throughput but the exponential growth of the state database, which Verkle Trees directly address.
Verkle Trees compress state. They replace Ethereum's Merkle Patricia Trie with a vector commitment scheme, collapsing proof sizes from kilobytes to ~150 bytes for stateless clients.
This enables statelessness. Light clients and validators no longer need the full state, reducing sync times and hardware costs, a prerequisite for true scaling solutions like danksharding.
Evidence: An Ethereum archive node today requires ~15TB. Without Verkle Trees, this grows linearly with TPS, creating a centralization pressure that high throughput alone cannot solve.
key-trends
THE REAL BOTTLENECK
The State Growth Crisis: Three Unavoidable Truths
The fundamental limit for any L1 is not TPS, but the exponential cost of proving and accessing its own history.
01
The Problem: State Bloat is a Tax on Every User
Every new account or smart contract stored on-chain adds permanent, cumulative cost. This 'state rent' is paid by all future nodes in the form of exponentially growing hardware requirements and slower sync times, centralizing validation.
- Direct Cost: Storing 1GB of state can cost a node operator ~$100/month in SSD costs alone.
- Indirect Cost: Full sync times for Ethereum have stretched from days to weeks, a barrier to new validators.
1TB+
State Size
Weeks
Sync Time
02
The Solution: Statelessness via Verkle Tries
Verkle Trees replace Merkle Patricia Tries with vector commitments, enabling 'stateless' clients. Validators no longer need the full state; they can verify blocks using tiny, constant-sized proofs.
- Proof Size: Witness size drops from ~300 KB to ~150 Bytes per block.
- Validator Access: Nodes can participate with near-zero storage overhead, radically decentralizing consensus.
~150B
Witness Size
>1000x
Efficiency Gain
03
The Consequence: Unlocking the Next Scaling Frontier
Solving state growth isn't about slightly higher throughput; it's the prerequisite for mass adoption of L1s. It enables sustainable rollup scaling, secure light clients for wallets, and paves the way for full danksharding.
- Rollup Scale: Base layer can support thousands of rollups without validator collapse.
- Client Diversity: Mobile phones can become fully verifying light clients, breaking reliance on centralized RPCs.
1000+
Rollup Capacity
Mobile
Client Tier
deep-dive
THE STATE BOTTLENECK
Verkle Trees 101: From Megabytes to Kilobytes
Verkle trees solve the fundamental scaling limit of Ethereum's state growth by enabling stateless clients and drastically reducing proof sizes.
The real bottleneck is state. Ethereum's current Merkle-Patricia Trie forces nodes to store the entire world state, which grows linearly with usage, crippling decentralization.
Verkle trees enable statelessness. They replace Merkle proofs with vector commitments, allowing validators to verify transactions with kilobytes of data instead of megabytes.
This is a cryptographic upgrade. Unlike Merkle trees requiring sibling hashes, Verkle proofs use KZG commitments or IPA, collapsing proof size from ~1MB to ~150KB.
Evidence: A stateless client for the current Ethereum chain needs a 1-2 MB witness; a Verkle tree witness is under 200KB, a 95% reduction enabling mobile nodes.
STATELESS CLIENT BOTTLENECK
Merkle Patricia Trie vs. Verkle Trees: The Hard Numbers
A quantitative comparison of the data structures underpinning Ethereum's state, focusing on the proof sizes that enable stateless clients.
| Core Metric / Feature | Merkle Patricia Trie (Hex) | Merkle Patricia Trie (Binary) | Verkle Tree (IPA Commitment) |
|---|---|---|---|
Witness Size for 1000 Accounts | ~3.5 MB | ~1.7 MB | ~150 KB |
Proof Size per Storage Slot Access | ~1 KB | ~0.5 KB | ~150 bytes |
Tree Depth (Worst-Case) | 9 levels (Hex) | 17 levels (Binary) | 256 levels |
Node Fanout (Branching Factor) | 16 (Hex) or 2 (Binary) | 16 (Hex) or 2 (Binary) | 256 |
Enables Practical Stateless Clients | |||
Requires New Crypto (Polynomial Commitments) | |||
Primary Bottleneck Addressed | Bandwidth & Storage for Witnesses | Bandwidth & Storage for Witnesses | Witness Size |
counter-argument
THE REAL BOTTLENECK
The Steelman: "But We Have L2s and Statelessness Roadmaps"
Verkle trees are not a performance patch; they are the prerequisite for Ethereum's core scalability and decentralization.
The L2 scaling fallacy is the belief that rollups like Arbitrum and Optimism eliminate the need for base-layer state growth solutions. They do not. L2s compress transactions but still post state diffs and proofs to L1, where the full state must be validated.
Statelessness is the true goal, but the current Merkle-Patricia trie makes it impossible. A node verifying a block today needs the entire state, which is why full node hardware requirements are exploding and limiting decentralization.
Verkle trees enable stateless verification by using vector commitments. This allows validators to verify blocks with a tiny witness, not the full multi-terabyte state. This is the prerequisite for EIP-4444 (history expiry) and PBS (proposer-builder separation) to work at scale.
The evidence is in the data: Ethereum's state size grows by ~50 GB/year. Without Verkle trees, stateless clients remain theoretical, and the network's security model relies on an increasingly centralized set of nodes that can afford the hardware.
takeaways
STATE GROWTH CRISIS
TL;DR for Protocol Architects
The fundamental scaling bottleneck isn't TPS, it's the exponential growth of the state trie, which cripples node hardware requirements and network decentralization.
01
The Problem: State Bloat Kills Decentralization
The Ethereum Merkle Patricia Trie forces every new node to store the entire history, leading to terabyte-level storage requirements. This creates prohibitive hardware costs, centralizing validation among a few large operators and threatening the network's security model.
- State size doubles every ~12 months
- Full archive nodes require >10 TB of SSD
- Sync times stretch to weeks, not hours
>10 TB
Archive Node Size
~12 mo.
Doubling Time
02
The Solution: Verkle Trees (Statelessness)
Verkle Trees use Vector Commitments (like KZG) to create tiny, constant-sized proofs. This enables stateless clients, where validators only need a ~1 MB witness instead of the full state, radically lowering the barrier to node operation.
- Witness size: ~1 MB vs. full state
- Enables stateless validation
- Uses KZG polynomial commitments for efficiency
~1 MB
Witness Size
1000x
More Efficient
03
The Architectural Shift: From Storage to Computation
Verkle Trees flip the scaling paradigm. The bottleneck moves from node storage I/O to CPU/bandwidth for proof verification. This aligns with a ZK-centric future, where execution clients (like geth) become stateless and rely on EIP-4444 for historical data expiry.
- Enables EIP-4444 (state expiry)
- Paves way for zk-EVM stateless proving
- Node requirement: Fast CPU > Large SSD
EIP-4444
Enabled
zk-EVM
Aligned
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall