Verkle trees are a band-aid for Ethereum's state bloat, not a cure. They compress witness sizes to enable stateless clients, but they do not address the fundamental economic flaw: the state grows indefinitely.
zk-rollups-the-endgame-for-scaling
Blog
Why Verkle Trees Are a Stopgap, Not a Solution
Verkle trees are a clever cryptographic upgrade for Ethereum, designed to enable stateless clients. However, they are a tactical fix that ignores the strategic problem: the economic impossibility of unbounded on-chain state. This analysis argues that ZK-rollups, which externalize state, represent the only viable long-term scaling architecture.
introduction
THE STOPGAP
Introduction
Verkle trees are a necessary but insufficient upgrade for Ethereum's state growth problem.
The real bottleneck is state management, not just proof size. Solutions like EIP-4444 (history expiry) and statelessness require Verkle trees, but the endgame is a state expiry model, as proposed by Vitalik Buterin.
Ethereum's roadmap treats Verkle trees as a prerequisite for The Verge. This is a tactical engineering win that enables the next phase, but the strategic victory requires a complete re-architecture of state economics.
thesis-statement
THE SCALING BOTTLENECK
Thesis Statement: The State is the Problem
Verkle trees optimize a flawed paradigm, failing to address the core scalability constraint of global state.
Verkle trees optimize storage, not scalability. They compress Ethereum's witness size by ~80% using polynomial commitments, enabling stateless clients. This is a local optimization for a global problem.
The state size still grows linearly with usage. Every new Uniswap pool or ENS name adds permanent data. Verkle trees make this growth cheaper to prove, but they do not stop the exponential state bloat.
Proof systems like zkSync and Starknet sidestep this by moving execution off-chain. Their validity proofs verify state transitions without re-execution, a fundamentally different scaling vector than state compression.
Evidence: Ethereum's state is ~150GB and grows ~50GB/year. Even with Verkle trees, full nodes require immense resources, centralizing infrastructure to providers like Infura and Alchemy.
key-trends
WHY VERKLE TREES ARE A STOPGAP
Executive Summary: Three Hard Truths
Verkle trees solve Ethereum's state growth problem for the next upgrade, but they fail to address the fundamental architectural constraints of monolithic blockchains.
01
The Problem: State Growth is Exponential, Bandwidth is Linear
Ethereum's state grows with every new contract and NFT. Verkle trees compress proofs, but the underlying data still needs to be stored and propagated by every node. This is a bandwidth and storage arms race that centralizes node operation.
- State size: ~1TB+ and growing exponentially
- Proof size reduction: ~20-30x smaller than Merkle-Patricia
- Unsolved issue: Full nodes still must sync and store the entire compressed state
1TB+
State Size
~30x
Smaller Proofs
02
The Solution: Statelessness is a Local Maximum
Verkle trees enable stateless clients, where validators don't store state. This is a clever optimization, not a paradigm shift. It shifts the burden to specialized proving networks and creates new trust assumptions, mirroring the issues of light clients and oracles.
- Enables stateless validation
- Creates dependency on proof providers
- Does not enable horizontal scaling of execution
0
State Stored
New Deps
Trust Assumptions
03
The Future: Monolithic vs. Modular Architectures
The real scaling endgame is separating execution, settlement, and data availability. Projects like Celestia, EigenDA, and zk-rollups treat data availability as a scalable resource. Verkle trees keep Ethereum monolithic, optimizing a single chain rather than embracing a multi-chain future.
- Modular DA: Scales independently (e.g., Celestia)
- Monolithic Limit: ~100 TPS practical cap for full L1
- Architectural Debt: Verkle trees add complexity to the core protocol
100 TPS
Monolithic Limit
Modular
Scaling Path
deep-dive
THE STOPGAP
Deep Dive: The Verkle Illusion and ZK Reality
Verkle trees are a temporary optimization for state growth, not a fundamental solution for blockchain scaling.
Verkle trees are a band-aid. They compress Ethereum's state witness size by ~80% using polynomial commitments, enabling stateless clients. This solves a specific data availability bottleneck for validators but does not address transaction throughput or execution speed.
The real scaling is ZK. Zero-knowledge proofs, like those used by Starknet and zkSync, move computation off-chain and verify it on-chain. This decouples execution from consensus, enabling exponential scaling without bloating the base layer's state.
Verkle enables statelessness, ZK enables stateless scaling. Verkle's stateless clients reduce node hardware requirements. ZK-rollups like Polygon zkEVM use this to batch thousands of transactions into a single, tiny proof, achieving the final scaling vector.
Evidence: A Starknet validity proof verifies ~1M Cairo steps in ~0.2ms on L1. Verkle trees only make the data for that verification slightly cheaper to store, not the computation faster.
WHY VERKLE TREES ARE A STOPGAP
Architectural Showdown: Verkle-Enabled L1 vs. ZK-Rollup Stack
Comparing the scalability and decentralization trade-offs of upgrading a monolithic L1 with Verkle trees versus adopting a modular ZK-rollup architecture.
| Core Architectural Metric | Verkle-Enabled Monolithic L1 (e.g., post-Dencun Ethereum) | ZK-Rollup Stack (e.g., zkSync Era, Starknet) | Stateless Client Paradigm |
|---|---|---|---|
State Growth Perpetuity | Deferred, not solved | Solved via periodic state diffs | Solved via stateless verification |
Witness Size for Full Node Sync | ~1-10 MB (from ~100s of GB) | < 1 MB (ZK validity proof) | ~1-10 KB (Verkle proof per block) |
Time to Finality (L1 Settlement) | 12 seconds (Ethereum slot time) | < 10 minutes (proof generation + L1 inclusion) | 12 seconds (inherited from L1) |
Developer Friction | Low (single, coherent state) | High (cross-domain tooling, data availability) | Very High (cryptographic proof integration) |
Maximum Theoretical TPS (Layer) | ~100-1,000 (bottlenecked by consensus) | ~10,000+ (limited by prover capacity & DA) | Inherits throughput of underlying L1 |
Trust Assumptions | 1/N honest validators (consensus) | 1/N honest provers + Data Availability security | 1/N honest validators + Verkle proof soundness |
Capital Efficiency for Validators/Provers | Low (32 ETH stake, full state) | High (no stake, hardware-bound proving) | Very High (no state, minimal hardware) |
Upgrade Path to Full Decentralization | Complex (requires all nodes to upgrade) | Modular (Sequencer -> Prover -> DA decentralization) | Theoretical (depends on widespread client adoption) |
counter-argument
THE SCALING IMPERATIVE
Counter-Argument: But We Need Stateless L1s Too
Verkle trees are a necessary but insufficient upgrade for achieving true statelessness at the base layer.
Verkle trees are a stopgap. They shrink witness sizes for stateless clients but do not eliminate the state growth problem. The historical state still accumulates on full nodes, creating a centralizing force over time.
Statelessness requires state expiry. Protocols like Ethereum's EIP-4444 and Celestia's data availability sampling are the true long-term solutions. These systems prune old state, making the chain's history a verifiable data stream, not a permanent storage burden.
The endgame is modularity. A stateless execution layer (like a future Ethereum L1) verifies proofs against a minimal state root, while a separate data availability layer (Celestia, EigenDA) stores the history. Verkle trees are a stepping stone in this architecture.
protocol-spotlight
BEYOND VERKLE TREES
Protocol Spotlight: Who's Building the Post-State Future?
Verkle trees reduce witness sizes for stateless clients but fail to address the core scaling bottleneck: state growth itself. These projects are building the real solutions.
01
The Problem: State is a Public Good, Not a Private Burden
Every full node must store the entire state, creating a ~1 TB+ burden that centralizes infrastructure. Verkle trees only compress proofs, not the state.\n- State Bloat grows ~2 GB/month on Ethereum\n- Hardware Requirements price out home validators\n- Sync Times can take days, harming liveness
1 TB+
State Size
~2 GB/mo
Growth Rate
02
Celestia: Decouple Execution from Consensus & Data
Modular blockchains separate the roles. Celestia provides consensus and data availability (DA), forcing execution layers like Ethereum L2s and Cosmos zones to manage their own state.\n- Sovereign Rollups define their own state rules\n- Data Availability Sampling (DAS) enables light nodes to verify TBs of data\n- Ethereum's Danksharding is a direct response to this architecture
~100x
Cheaper DA
~10 KB
Light Node Data
03
Fuel & Monad: Parallel Execution Engines
Verkle trees don't improve execution speed. These VMs use parallel processing to utilize hardware fully, making state access a throughput problem, not just a storage one.\n- Fuel's UTXO Model enables parallel transaction validation\n- Monad's Superscalar Pipelines and async execution decouple steps\n- Solana's Sealevel pioneered this approach, achieving ~50k TPS
10-100x
Throughput Gain
~50k TPS
Theoretical Max
04
Avail & EigenDA: Data Availability as a Scaling Primitive
If state is the problem, don't store it on-chain. These specialized DA layers ensure data is published, letting rollups handle state locally and settle periodically.\n- KZG Commitments provide cryptographic data guarantees\n- Enables Validiums & Optimiums with ~90% lower fees than rollups\n- Critical for high-throughput chains like Polygon CDK and Arbitrum Orbit
~90%
Fee Reduction
16 MB/s
Data Throughput
05
The Solution: Statelessness via State Expiry & Weak Subjectivity
The endgame: clients don't store historical state. Ethereum's State Expiry and EIP-4444 auto-prune old state, while Weak Subjectivity checkpoints let nodes sync from recent snapshots.\n- Portal Network provides on-demand historical state via a P2P network\n- Verkle Trees are a prerequisite for feasible witness sizes\n- Ultra-light clients become the norm, not the exception
~10 GB
Client Target
EIP-4444
Key Proposal
06
Mina & Celestia: The Light Client Future
Mina proves the model: a constant-sized blockchain (~22 KB) using recursive zk-SNARKs. Celestia's light clients use Data Availability Sampling for similar trust-minimization. This is the post-state paradigm.\n- Mina's zkApps execute client-side with zero knowledge proofs\n- No full nodes required for security\n- The antithesis of the 'state-as-burden' model
22 KB
Chain Size
100%
Light Clients
future-outlook
THE STOPGAP
Future Outlook: The Inevitable Shift
Verkle trees are a necessary but temporary upgrade, not the final solution for Ethereum's state growth problem.
Verkle trees are a complexity trade-off. They reduce witness sizes for stateless clients by moving from Merkle Patricia Tries to vector commitments. This introduces new cryptographic assumptions and a more complex proof system, trading one form of overhead for another.
The endgame is stateless verification. The ultimate goal is for validators to execute blocks without storing the full state, relying solely on witnesses. Verkle trees are a stepping stone to this architecture, not its final form.
State expiry is the inevitable companion. Even with Verkle trees, the historical state grows infinitely. Solutions like EIP-4444 (execution layer history expiry) or a full state rent model are required to make the system sustainable long-term.
Evidence: The modular roadmap. Ethereum's post-merge focus on rollups (Arbitrum, Optimism) and data availability (Celestia, EigenDA) shows scaling happens off-chain. Verkle trees optimize the base layer for this new reality, but they do not solve state bloat at the L2 level.
takeaways
THE STATE CAPTURE
Key Takeaways
Verkle trees solve Ethereum's immediate state growth crisis but fail to address the fundamental architectural flaw.
01
The Problem: Exponential State Bloat
Ethereum's Merkle Patricia Trie requires nodes to store the entire state history, leading to terabytes of data and centralization pressure. This is the root cause of the state expiry debate.
~1.5 TB
Full Node Size
>99%
Pruned Data
02
The Solution: Statelessness via Verkle Trees
Verkle trees use vector commitments to shrink witness sizes from ~300 KB to ~150 bytes. This enables stateless clients and paves the way for Verkle-based state expiry as a near-term fix.
- Enables light clients with full security
- Reduces sync time from days to hours
- Mandatory for post-Danksharding scaling
2000x
Smaller Proofs
-90%
Sync Time
03
The Reality: A Stopgap for Weak L1 Scaling
Verkle trees optimize data storage, not data availability. They don't increase Ethereum's core transaction throughput. The real scaling bottleneck is blob bandwidth, addressed by rollups like Arbitrum, Optimism, and data availability layers like Celestia and EigenDA.
- L1 TPS remains ~15-45
- Scaling is outsourced to L2s
- DA is the new competitive frontier
~30 TPS
L1 Cap
$30B+
L2 TVL
04
The Future: State Expiry & Historical Pruning
Verkle trees enable the EIP-4444 (execution layer history expiry) roadmap. This forcibly prunes old state, trading decentralization for sustainability. It's a contentious, politically difficult upgrade that highlights the limits of monolithic chain design.
- Forces clients to discard old data
- Relies on Portal Network for history
- Creates new trust assumptions
1 Year
Proposed Cutoff
High
Governance Risk
05
The Alternative: Modular & Stateless Rollups
Next-gen rollup stacks like Fuel and RISC Zero are building native statelessness from day one. They treat state as a cache, not a database, achieving parallel execution and instant syncing. This makes Verkle trees look like a legacy patch.
- Native parallel VM design
- Sub-second state sync
- True horizontal scaling
10k+ TPS
Theoretical Cap
<1s
State Sync
06
The Bottom Line: Technical Debt Realized
Verkle trees are a $100M+ engineering effort to retrofit statelessness onto a stateful monolith. They are necessary for Ethereum's survival but represent the cost of not designing for scale in 2015. The real innovation is happening in modular, stateless architectures.
- Admits initial design flaw
- Buys time for L2 ecosystem
- Contrasts with clean-slate L1s
$100M+
Dev Cost
Stopgap
Architecture
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