State is the bottleneck. Execution speed is a solved problem; rollups like Arbitrum and Optimism already process thousands of transactions per second. The real cost is storing the resulting state changes, which grows linearly with usage and must be accessible for all future execution.
the-ethereum-roadmap-merge-surge-verge
Blog
Why Stateful Execution Is Hard to Optimize
Ethereum's performance ceiling isn't about consensus or data availability—it's the stateful execution model. This deep dive explains the fundamental constraints of the EVM, why parallelization is a band-aid, and how the Verge's stateless future is the only real fix.
introduction
THE STATE
The Bottleneck Isn't Where You Think
The primary constraint for scaling blockchains is not transaction throughput, but the exponential growth of state data that nodes must store and process.
Statelessness is the goal. Protocols like Ethereum's Verkle Trees and Solana's State Compression aim to separate execution from storage. A validator only needs a cryptographic proof of state, not the entire database, radically reducing hardware requirements.
The evidence is in the data. A full Ethereum archive node requires over 12TB. Without state expiry or stateless clients, this growth creates centralization pressure, as only well-funded entities can afford to run infrastructure.
key-trends
THE THREE-WAY TRADEOFF
The Stateful Execution Trilemma
Optimizing stateful execution for blockchains forces a brutal compromise between three core properties: performance, decentralization, and security.
01
The Problem: The Monolithic Bottleneck
Traditional blockchains like Ethereum execute, settle, and store data on a single layer. This creates a fundamental scaling wall.\n- Sequential Processing: Transactions are processed one block at a time, capping throughput at ~15-30 TPS.\n- Global State Bloat: Every node must store the entire history, requiring >1TB of SSD and limiting decentralization.\n- Congestion Pricing: Network demand directly translates to volatile, unpredictable gas fees.
~15 TPS
Base Throughput
>1TB
Node Storage
02
The Solution: Modular Execution Layers
Separate execution from consensus and data availability. This is the core thesis behind rollups (Optimism, Arbitrum, zkSync) and parallel execution engines (Sui, Aptos, Monad).\n- Specialization: Dedicated layers optimize for fast computation using techniques like optimistic rollups or ZK-proofs.\n- Horizontal Scaling: Throughput scales with the number of parallel execution shards or rollup instances.\n- Inherited Security: They rely on a base layer (e.g., Ethereum) for ultimate settlement and data, avoiding new trust assumptions.
4,000+ TPS
Rollup Capacity
$30B+
Combined TVL
03
The Trade-Off: Security vs. Sovereignty
Modularity introduces a new axis of compromise. Ethereum-aligned rollups (OP Stack, Arbitrum Orbit) maximize security by posting data to Ethereum, but inherit its costs and latency. Sovereign rollups (Celestia, EigenLayer) and app-chains (dYdX, Cosmos) opt for their own data/consensus layers for performance, but must bootstrap their own validator security, often leading to <100 validators and higher trust assumptions.
<100
Typical Validators
-90%
Cost vs. L1
04
The Frontier: Parallel EVMs & Async Execution
The next evolution tackles state contention within the execution layer itself. Monad and Sei v2 implement parallel execution of independent transactions, while Solana and Sui use optimistic concurrency control.\n- DAG-based Ordering: Transactions are processed as a directed acyclic graph, not a single chain.\n- State Access Lists: Identifying non-conflicting transactions to run simultaneously, boosting theoretical TPS into the tens of thousands.\n- The Catch: Complex state dependencies (e.g., high-frequency DEX arbitrage) can serialize execution, capping real-world gains.
10,000+
Theoretical TPS
~200ms
Finality Target
05
The Hidden Cost: State Growth & Pruning
Faster execution accelerates state bloat. Without active management, node requirements explode, recentralizing the network. Ethereum's Verkle Trees and stateless clients aim to solve this by separating proof of execution from state holding.\n- Witness Size: Nodes only need a cryptographic proof (~1-2 KB) of relevant state, not the entire database.\n- Archive Node Reliance: The system depends on a sufficient number of full nodes to serve these proofs, creating a new liveness assumption.\n- Long-Term Threat: Unchecked, state growth is a silent killer of decentralization.
~1 KB
Witness Size
+50 GB/yr
State Growth
06
The Endgame: Intent-Centric Architectures
The ultimate optimization may bypass transaction-based execution entirely. Protocols like UniswapX, CowSwap, and Across use solvers to fulfill user intents off-chain, settling only net results on-chain.\n- Declarative Model: Users specify a desired outcome (e.g., "best price for 100 ETH"), not a step-by-step transaction.\n- MEV Capture & Redistribution: Solvers compete to find optimal execution paths, capturing and potentially returning MEV to users.\n- The Risk: Centralizes complexity into solver networks, requiring robust economic security and censorship resistance mechanisms.
$10B+
Processed Volume
-20%
Avg. Price Impact
deep-dive
THE BOTTLENECK
Deconstructing the State Monster
Stateful execution, the core of smart contract platforms, inherently creates performance and decentralization trade-offs that limit scalability.
State is the bottleneck. Every transaction modifies a global database, requiring consensus and storage. This creates a fundamental throughput ceiling, as seen in Ethereum's 15-30 TPS limit.
Parallelization hits a wall. Optimistic (Solana) or deterministic (Sui, Aptos) parallel execution requires knowing which state a transaction will touch. Complex, composable interactions make this prediction impossible, forcing sequential fallback.
Storage costs compound. The state bloat problem forces nodes to prune history or increase hardware requirements, centralizing infrastructure. Solutions like EIP-4444 and stateless clients are multi-year endeavors.
Evidence: Arbitrum Nitro's 2M TPS benchmark is for compute, not state updates. Real-world throughput collapses under heavy state contention, proving the monster remains.
WHY STATEFUL EXECUTION IS HARD
Optimization Attempts vs. Fundamental Limits
A comparison of architectural approaches to scaling stateful execution, highlighting the trade-offs between performance, decentralization, and developer experience.
| Core Constraint / Metric | Monolithic L1 (e.g., Ethereum Mainnet) | Modular Execution Layer (e.g., Arbitrum, Optimism) | Parallel Execution Engine (e.g., Sui, Aptos) | Stateless / ZK-Coprocessor (e.g., RISC Zero, Axiom) |
|---|---|---|---|---|
Execution Throughput (TPS) | ~15-30 | ~4,000-40,000 | ~100,000+ (theoretical) | Off-chain compute, ~1,000+ proofs/sec |
State Growth per Block | ~1 MB | ~10-100 MB (compressed) | ~50-500 MB | 0 MB (state is an input, not stored) |
Worst-Case Block Time | 12 seconds | ~1-2 seconds (to L1) | < 1 second | Proof generation time (~2-10 sec) |
Developer Complexity (State Mgmt) | Manual optimization required | Similar to L1, but cheaper | Requires explicit ownership declarations | Pure functions; no persistent state |
Cross-Shard/Chain Messaging Latency | N/A (single chain) | ~1-20 minutes (L1 finality delay) | Instant (within shard), minutes (cross-shard) | Synchronous via proof verification |
Hardware Requirements (Node) | ~2 TB SSD, 16 GB RAM | ~1-3 TB SSD, 32+ GB RAM | ~500 GB-1 TB SSD, 64+ GB RAM | Verifier: minimal; Prover: 128+ GB RAM, high-end CPU |
Inherent Centralization Pressure | Low (global consensus) | Medium (sequencer optionality) | High (validator performance critical) | Very High (proving is computationally intensive) |
future-outlook
THE STATE CRISIS
The Path Through the Verge: Statelessness is the Only Exit
The exponential growth of execution state is the fundamental bottleneck that makes scaling blockchains via execution sharding or parallelization economically unsustainable.
Stateful execution creates unbounded costs. Every transaction modifies the global state, forcing every node to store and process the entire history. This makes scaling via parallel execution shards like Near or Zilliqa a temporary fix, as each new shard multiplies the total state burden.
Statelessness inverts the scaling paradigm. Instead of nodes carrying the full state, users provide cryptographic proofs of their state. This enables verification scaling, where nodes only verify proofs, not manage data. The Verge in Ethereum's roadmap is the canonical implementation of this principle.
Witness size is the new bottleneck. Stateless clients require witnesses—Merkle proofs of relevant state. Current binary Merkle trees produce proofs too large for mainnet. The shift to Verkle trees reduces witness size from ~1KB to ~150 bytes, making statelessness practical.
Ethereum's roadmap validates the thesis. The merge, surge, and scourge address throughput and cost. The verge (statelessness) is the final piece that makes scaling sustainable by eliminating the node's state management overhead, enabling true horizontal scaling.
takeaways
THE STATE COMPLEXITY TRAP
TL;DR for Protocol Architects
Stateful execution is the core bottleneck for scaling L1s and L2s. Here's why optimizing it is fundamentally hard.
01
The Problem: State Bloat is Exponential
Every transaction modifies the global state, which must be stored, proven, and made available forever. This creates a quadratic scaling problem for validators and nodes.\n- Storage Cost: A full Ethereum archive node requires ~15TB and grows by ~100GB/month.\n- Sync Time: Bootstrapping a new node can take weeks, centralizing network participation.
15TB+
Archive Size
Weeks
Sync Time
02
The Solution: Statelessness & State Expiry
Decouple execution from full state storage. Clients only hold state they need, verified via cryptographic proofs. Verkle trees (Ethereum) and stateless clients are the endgame.\n- Witness Size: Reduces proof size from MBs to KBs, enabling light clients.\n- Node Requirements: Lowers hardware needs from TB to GB, enabling broader decentralization.
GBs
Node Storage
KBs
Witness Size
03
The Problem: Parallelization is State-Contention Hell
Optimistic parallel execution (Solana, Aptos, Sui) hits diminishing returns due to access conflicts. Transactions touching the same state must be serialized, creating bottlenecks.\n- Contention Rate: Real-world workloads see >30% conflict rates, capping throughput.\n- Scheduler Overhead: Dynamic scheduling adds ~10-100ms latency per block, eating gains.
>30%
Conflict Rate
~100ms
Scheduler Tax
04
The Solution: Intent-Based & Specialized VMs
Move complexity off-chain. Let users express what they want, not how to do it. UniswapX, CowSwap, and Across use solvers. Specialized VMs like FuelVM and SVM optimize for specific state models.\n- Throughput: Solvers batch and optimize off-chain, enabling 10,000+ TPS equivalents.\n- Efficiency: Dedicated VMs reduce opcode overhead by ~40% vs. general-purpose EVM.
10k+
Effective TPS
-40%
Overhead
05
The Problem: Cross-Shard/Chain State Sync
Fragmented state across rollups or shards breaks composability and creates latency. Atomic cross-domain transactions require complex, slow bridging protocols.\n- Finality Delay: Moving assets via canonical bridges can take 10 mins to 7 days.\n- Security Risk: LayerZero, Wormhole-style bridges add new trust assumptions and attack surfaces.
10min-7d
Sync Latency
New Attack Surface
Security
06
The Solution: Shared Sequencing & Isolated State
Coordinate execution across domains via a shared sequencer (e.g., Espresso, Astria) or treat each app/chain as an isolated state machine with asynchronous messaging.\n- Atomicity: Enables sub-second cross-rollup composability.\n- Simplification: Isolated state (like Celestia rollups) reduces global sync requirements by >90%.
<1s
Cross-Domain Tx
-90%
Sync Burden
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