Why Faster EVMs Are Hard to Ship

The EVM's single-threaded design is a fundamental bottleneck. It forces all transactions into a global queue, capping throughput at the speed of a single CPU core.

• Hard Cap: Even with perfect hardware, a single EVM chain cannot exceed ~100-200 TPS.
• Congestion Tax: Network demand creates volatile gas fees, making costs unpredictable for users and protocols like Uniswap and Aave.
• No Parallelism: Simple, unrelated transactions (e.g., two separate NFT mints) cannot be processed simultaneously, wasting compute.

Projects like Monad, Sei, and Fantom Sonic are redesigning execution engines to process independent transactions concurrently.

• State Access Lists: Pre-declaring which data a transaction touches allows the scheduler to run non-conflicting ops in parallel.
• Massive Throughput: Targets 10,000+ TPS by utilizing multiple CPU cores, moving beyond the single-threaded ceiling.
• The Trade-off: Requires deep protocol changes and new virtual machines, creating fragmentation and breaking full bytecode compatibility with existing EVM tooling.

Every full node must store and compute over the entire world state, creating massive hardware requirements that centralize node operation.

• Storage Bloat: The Ethereum state grows by ~50 GB/year, pushing solo stakers out.
• Sync Times: A new node can take days to sync, harming network resilience and decentralization.
• I/O Bottleneck: Disk reads/writes become the primary limiter, not CPU power.

Ethereum's roadmap, via EIP-6800, aims to make nodes stateless. Clients would verify blocks using cryptographic proofs instead of storing full state.

• Verkle Trees: Provide extremely efficient proofs (~150 bytes vs. Merkle's ~1KB) that a piece of state is valid.
• Light Node Proliferation: Enables ultra-light clients, potentially on mobile devices, improving decentralization.
• The Trade-off: Imposes higher witness data overhead on block builders and requires a multi-year, hard-fork-dependent upgrade path.

Traditional EVM clients are not optimized for modern multi-core servers and advanced hardware, leaving 90%+ of server capacity idle.

• Single-Thread Bound: Execution, state access, and networking are tangled in a single process.
• Inefficient Storage: Traditional databases like LevelDB are not built for high-frequency blockchain read/write patterns.

Next-generation execution clients like Reth and Erigon apply systems engineering principles to maximize hardware efficiency.

• Modular Architecture: Separates download, execution, and consensus into parallel pipelines.
• Advanced Storage: Uses custom DBs (e.g., MDBX) and flat storage models to minimize I/O latency.
• The Trade-off: Delivers 2-5x sync speed and performance gains without breaking consensus, but is ultimately bounded by the underlying EVM's sequential design.

You can only pick two. Achieving sub-second finality requires sacrificing either decentralization (via a small validator set) or state consistency (via optimistic execution). Full nodes cannot sync a ~1TB+ chain state in real-time.

• Decentralization Cost: A ~500ms slot time necessitates high hardware specs, centralizing validators.
• Consistency Risk: Fast chains often fork, requiring complex reorg handling and MEV protection.

After execution, proving the new state to the network creates a bandwidth wall. Monolithic EVMs force full state witnesses on every node, unlike modular designs like Celestia or EigenDA.

• Bandwidth Wall: A single block can require 10s of MBs of witness data, crippling p2p networks.
• Solution Path: Requires stateless clients, Verkle trees, or offloading data availability (DA).

Optimistic & ZK Rollups (Arbitrum, zkSync) appear fast because they use a centralized sequencer. Decentralizing the sequencer reintroduces the state sync problem, as seen in the long road to Arbitrum BOLD or zkSync's ZK Porter.

• User Experience vs. Security: Users get ~100ms latency by trusting a single operator.
• Real Decentralization: Adds ~2-10s to finality for consensus, mirroring L1 challenges.

While Solana and Aptos champion parallel execution (Sealevel, Block-STM), the EVM's inherent sequential design makes this a hard fork-level change. Monad and Sei are attempting this, but it requires breaking compatibility.

• Throughput vs. Latency: Parallelism improves TPS, not necessarily single-transaction finality time.
• Compatibility Tax: Full EVM equivalence (Ethereum tooling, wallets) locks you into a sequential model.

The Ethereum Merkle-Patricia Trie (MPT) is a performance disaster for fast chains. Random I/O accesses for state reads/writes dominate block processing time. Alternatives like Flat Storage (Near) or Verkle Trees are multi-year migrations.

• Database Bottleneck: >80% of block time can be spent on LevelDB/RocksDB lookups.
• Migration Hell: Changing the state model invalidates all existing tooling and infrastructure.

Achieving speed often means forgoing synchronous composability with Ethereum. Fast-finality chains cannot be natively settled on Ethereum's ~12-minute finality, forcing bridges like LayerZero or Axelar which introduce their own latency and trust assumptions.

• Composability Loss: Dapps cannot atomically interact with Ethereum mainnet.
• Bridge Risk: Users trade speed for additional trust in external validator sets.