State access is the bottleneck. Every transaction must read and write to the global state, forcing nodes to store terabytes of data and creating the primary constraint on throughput and decentralization.
developer-ecosystem-tools-languages-and-grants
Blog
Why Statelessness Is the Ultimate Gas Optimization Endgame
We've optimized opcodes and calldata. The final, hardest bottleneck is state access. This is how Verkle trees and stateless clients solve it, enabling the next leap in scalability and developer experience.
introduction
THE BOTTLENECK
Introduction: The State Access Tax
Blockchain scaling is fundamentally limited by the cost of accessing and verifying global state, a hidden tax that statelessness eliminates.
Statelessness eliminates this tax. Clients submit proofs of state changes instead of requiring nodes to hold full state, collapsing the data burden and enabling exponential scaling for protocols like Ethereum and Solana.
The endgame is verification, not storage. This shifts the paradigm from every node storing everything to a network where light clients verify zk-SNARKs or Verkle proofs, a model pioneered by Starknet and Polygon zkEVM.
Evidence: Ethereum's stateless roadmap targets a 90% reduction in node storage requirements, a prerequisite for sustainable rollup scaling beyond the current 100-200 TPS aggregate limit.
key-trends
BEYOND COMPRESSION
The Gas Optimization Stack: What's Left to Fix?
Merkle proofs and calldata compression are incremental; statelessness re-architects the state model to eliminate the root cause of gas cost.
01
The Problem: State Bloat is a Tax on Every Transaction
Every Ethereum transaction must read/write to a global state that's now >1 TB. This forces nodes to store everything, making sync times long and gas costs high for simple operations. The overhead isn't just storage; it's the computational cost of proving state access.
- Gas cost for SLOAD/SSTORE is dominated by Merkle proof verification.
- Node requirements exclude >99% of potential validators.
- The network's security and scalability are fundamentally capped by this model.
>1 TB
State Size
>99%
Validators Excluded
02
The Solution: Stateless Clients with Verkle Trees
Replace Merkle Patricia Tries with Verkle Trees (Vector Commitment Trees). This allows validators to verify state transitions using small, constant-sized proofs (~150 bytes) instead of massive Merkle branches. Clients no longer need to store the full state; they just need the block header and a witness.
- Witness size shrinks from ~1 MB to ~150 KB per block.
- Enables stateless validation, where nodes only hold state they care about.
- Paves the way for single-slot finality by making block processing parallelizable.
~150 KB
Witness Size
>1000x
Proof Efficiency
03
The Endgame: Full Statelessness & State Expiry
Verkle trees enable the final phase: a network where no participant is required to hold historical state. State expiry automatically archives inactive state, requiring users to provide proofs to reactivate it. This creates a sustainable fee market for state rent and permanently solves the state growth problem.
- Eliminates the perpetual state growth tax.
- Reduces hardware requirements for validators to consumer-grade.
- Unlocks the final scalability ceiling for Ethereum L1 execution.
~0 GB
Required Storage
Endgame
Scalability
04
The Hurdle: Witness Propagation & Bandwidth
The critical path is no longer computation but bandwidth. Statelessness shifts the bottleneck to propagating the witness data (the proofs of relevant state) with each block. If witnesses are too large, they become the new scaling limit, similar to today's block gas limit.
- Requires EIP-4844 proto-danksharding to provide cheap blob space for witnesses.
- Demands optimized peer-to-peer networks for witness distribution.
- Creates a new design space for witness compression and aggregation.
P2P Network
New Bottleneck
EIP-4844
Prerequisite
05
The Ripple Effect: L2s, Bridges, and Wallets
Statelessness forces a redesign of the entire stack. Optimistic Rollups must adapt fraud proofs; ZK-Rollups become more efficient. Bridges like LayerZero and Across must handle state proofs. Wallets must manage witness generation for user interactions.
- L2s can inherit the gas efficiency of stateless verification.
- Smart contract wallets (ERC-4337) must bundle validity proofs.
- Interoperability protocols become simpler and more secure with compact proofs.
Full Stack
Redesign Required
ERC-4337
Impacted
06
The Timeline: A Decade-Long Migration
This isn't a hard fork; it's a multi-year protocol migration. The Verkle transition alone is a breaking change requiring client and tooling overhauls. Full statelessness with state expiry is a post-merge, post-danksharding milestone.
- ~2025: Verkle Tree testnets and client implementation.
- ~2026-2027: Stateless client rollout and early state expiry proposals.
- ~2030+: Mature stateless ecosystem with new application paradigms.
5+ Years
Migration Path
Post-Danksharding
Critical Path
deep-dive
THE STATELESSNESS ENGINE
Verkle Trees: The Data Structure That Enables Forgetting
Verkle trees replace Merkle Patricia Tries to enable stateless clients, which is the final step in scaling Ethereum's execution layer by eliminating state bloat.
Statelessness is the endgame for Ethereum's gas optimization. It removes the requirement for nodes to store the entire state, shifting the proof-of-state burden to the transaction sender. This collapses the hardware requirements for validators, enabling true decentralization at scale.
Verkle trees enable vector commitments that compress proofs. Unlike Merkle Patricia Tries requiring hundreds of kilobytes, Verkle proofs are under 150 bytes. This makes witness data small enough to fit in a single Ethereum block, making stateless verification practical.
The key innovation is polynomial commitments. Verkle trees use KZG or IPA commitments to allow a single proof to attest to multiple sibling nodes. This is the cryptographic breakthrough that reduces proof size by orders of magnitude compared to Merkle structures.
Ethereum's EIP-6800 formalizes the transition. The upgrade replaces the hexary Merkle Patricia Trie with a binary Verkle tree. This is a foundational change for the Verkle Tree Testnet and the final piece of The Purge roadmap, enabling stateless clients and peer-to-peer networking.
THE STATELESSNESS ENDGAME
State Access Cost: Merkle Trie vs. Verkle Tree Regime
A first-principles comparison of state access costs, showing why stateless clients are the ultimate gas optimization for scaling.
| State Access Metric | Merkle Trie (Ethereum Mainnet) | Verkle Tree (Ethereum Pectra) | Stateless Client (Endgame) |
|---|---|---|---|
Witness Size per Tx (Avg) | ~3-15 KB | ~150-500 Bytes | ~150-500 Bytes |
Proof Size per Account Access | ~1.5 KB (17-node Merkle path) | ~100 Bytes (single multi-proof) | ~100 Bytes (single multi-proof) |
State Growth Cost (per GB) | Linear O(n) for full nodes | Constant O(1) for clients | Constant O(1) for all nodes |
Sync Time for New Node | Days to weeks (sync & store state) | Minutes (verify proofs) | Minutes (verify proofs) |
Gas Cost per SLOAD Opcode | ~2100 gas (cold), ~100 gas (warm) | Target: ~200 gas (flat) | Target: ~200 gas (flat) |
Requires Full State for Validation | |||
Enables Ultra-Light Clients | |||
Primary Bottleneck | Disk I/O & State Bloat | Proof Generation (Prover Load) | Bandwidth (Witness Propagation) |
counter-argument
THE STATE CRISIS
The Hard Part: Witness Propagation and Client Economics
Statelessness solves Ethereum's state bloat by separating execution from data, but its viability hinges on a new, decentralized network for witness distribution.
Statelessness is the endgame because it eliminates the primary constraint on node count: storage. Full nodes no longer need to store the entire state, only the small witness (Merkle proof) for the transactions they verify. This reduces the hardware requirement from terabytes to megabytes.
Witness propagation is the new bottleneck. The network must reliably deliver the correct witness data to validators before block execution. This creates a new oracle problem for state data, requiring a robust P2P gossip layer that rivals the existing transaction pool.
Client economics must realign. Today, clients like Geth and Erigon compete on execution speed. In a stateless world, the client's role shifts to witness management. Profit will derive from efficient witness fetching, caching, and serving, not just fast EVM interpretation.
The solution is a dedicated witness network. This is a decentralized CDN for state proofs, similar to how The Graph indexes historical data or how IPFS serves content. Validators subscribe to streams of witnesses for the accounts they monitor, paid via micro-transactions.
Evidence: Ethereum's state size grows by ~50 GB/year. A stateless client, using a Verkle tree witness, needs only ~1.5 KB of data to validate a complex Uniswap swap. The network must propagate millions of these proofs per second at sub-block-time latency.
protocol-spotlight
THE GAS OPTIMIZATION ENDGAME
Who's Building the Stateless Future?
Statelessness eliminates the need for nodes to store the entire state, shifting the burden of proof to users and enabling radical scalability.
01
Mina Protocol: The Lightweight Pioneer
Uses zk-SNARKs to compress the entire blockchain state into a constant-sized proof (~22KB).
- State is a proof, not data: Nodes verify the SNARK, not the full history.
- Enables true light clients: Users interact directly with the chain from a phone.
- Trade-off: High prover costs are offloaded to specialized nodes.
~22KB
Chain Size
0-Trust
Sync Assumption
02
The Problem: State Growth Chokes L1s
Ethereum's state is >1TB and growing, forcing nodes into centralization.
- High hardware costs create fewer, more powerful validators.
- Gas costs inflate as state access becomes a bottleneck.
- Verkle Trees & EIP-4444 are stopgaps; statelessness is the purge.
>1TB
Eth State
$1k+
Node Cost
03
Celestia & EigenDA: Data Availability as Prerequisite
Stateless execution requires guaranteed access to historical data. These layers provide cheap, scalable data availability (DA).
- Rollups become stateless: They post data to Celestia/EigenDA and only need the latest state root.
- Enables parallel execution: With proven data, execution layers can process independently.
- Reduces L1 load by >100x compared to full execution.
$0.01/MB
DA Cost
>100x
Throughput Gain
04
The Solution: Witnesses & Proofs, Not Storage
Shift the burden from nodes to users. Clients submit state witnesses (Merkle proofs) with their transactions.
- Nodes verify, don't store: Validity is checked against a canonical state root.
- Parallelizes state access: No global state lock.
- Paves way for SNARKed L2s: The final step is replacing witnesses with a validity proof.
-99%
Node Storage
Async
State Access
05
zkSync & Starknet: The Prover-Centric Path
These L2s are architecturally stateless. Validity proofs verify state transitions, not state storage.
- State diffs are posted on-chain, not full state.
- Provers are the bottleneck, not node storage.
- Endgame: A single SNARK proves the entire chain's history, enabling instant sync.
~10KB
Proof Size
Minutes
Sync Time
06
The Trade-Off: Prover Centralization
Statelessness exchanges storage decentralization for prover centralization.
- zk-SNARK/STARK generation is computationally intensive and costly.
- Specialized proving markets (e.g., RiscZero, Succinct) will emerge as critical infrastructure.
- The new trust assumption: The proving network's liveness and cost.
$0.10+
Proof Cost
New Layer
Trust Assumption
future-outlook
THE ULTIMATE OPTIMIZATION
The Endgame: Gas as Pure Computation
Statelessness eliminates the final bottleneck by decoupling execution from state access, making gas a pure measure of CPU cycles.
Statelessness eliminates state I/O costs. Current gas fees pay for reading and writing to the global state, a massive bottleneck. Stateless clients verify execution with cryptographic proofs, paying only for the computation itself.
The paradigm shifts from storage to CPU. This mirrors the evolution from hard drives to RAM in traditional computing. Protocols like zkSync's Boojum and StarkWare's Stwo are building the proving systems for this future.
Gas becomes predictable and composable. Without unpredictable state-access overhead, transaction costs correlate directly with logic complexity. This enables massively parallel execution and true micro-transactions.
Evidence: A stateless Ethereum client, like Portal Network's 'Trin', aims to reduce node resource requirements by over 99%, making the cost of verifying a block negligible compared to executing it.
takeaways
THE STATE PROBLEM
TL;DR for Builders and Architects
Statelessness eliminates the core bottleneck of global state verification, enabling a new paradigm for scalability and decentralization.
01
The Problem: State Bloat is a Tax on Every Node
Full nodes must store and process the entire chain state (~1TB+ for Ethereum), creating massive hardware requirements and centralization pressure. This cost is passed to users as gas fees and limits throughput.
- Cost: Running a full node requires ~2TB+ SSD and high-end CPU.
- Impact: Less than 0.1% of users run a node, creating trust assumptions.
~1TB+
State Size
<0.1%
Node Ratio
02
The Solution: Verkle Trees & Stateless Clients
Replace Merkle Patricia Tries with Verkle Trees (using vector commitments). This allows validators to verify transactions with tiny proofs (~150 bytes) without storing state. Clients become 'stateless'.
- Benefit: Node requirements drop to ~GBs of data, enabling consumer hardware.
- Benefit: Block gas limits can increase 10-100x without burdening nodes.
~150B
Proof Size
10-100x
Gas Limit Boost
03
The Endgame: Separating Execution from Verification
Statelessness enables a clean separation where block producers execute and validators only verify. This mirrors architectures like zkRollups (e.g., zkSync, Starknet) and Polynya's 'Based' sequencing.
- Result: Enables ultra-fast execution layers with ~500ms block times.
- Result: Unlocks single-slot finality by making verification trivial.
~500ms
Block Target
1 Slot
Finality
04
The Trade-off: Witness Propagation Bandwidth
Statelessness shifts the burden from storage to bandwidth. Block producers must broadcast state witnesses (proofs) with each block. This is the new bottleneck.
- Challenge: Witness size scales with block complexity (~1-10MB per block).
- Mitigation: Techniques like EIP-4444 (history expiry) and peer-to-peer witness networks are critical.
~1-10MB
Witness Size
P2P
Network Need
05
The Architect's Playbook: Design for Stateless Verification
Build protocols where core logic is verified, not re-executed. This is the intent-based and ZK-native design pattern.
- Example: UniswapX uses off-chain solvers with on-chain settlement.
- Example: zkRollup circuits verify batched state transitions.
- Action: Minimize on-chain state mutations; use ephemeral storage.
Intent
Design Pattern
ZK-Native
Stack
06
The Ultimate Win: Trivial Sync & Global Node Distribution
A stateless client can sync near-instantly by verifying the latest block header and its witness. This enables global, permissionless node distribution at scale.
- Outcome: Eliminates the 'sync time' barrier (currently days for full sync).
- Outcome: Realizes the original Ethereum vision of a globally accessible world computer.
~Seconds
Sync Time
Global
Node Distribution
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