EVM gas is a simulation tax. Every opcode's cost is a heuristic for real-world compute, not a precise measure. This forces ZK provers like Risc Zero or SP1 to waste cycles proving the gas simulation itself, not just the underlying computation.
zk-rollups-the-endgame-for-scaling
Blog
Why the EVM Gas Model Must Die for ZK Scaling
The EVM's stateful, opcode-based gas accounting is a fundamental bottleneck for ZK-rollups. We analyze why a new fee market, priced in proof cycles, is the only path to sustainable hyper-scalability.
introduction
THE BOTTLENECK
Introduction
The EVM's gas model is a legacy abstraction that actively prevents ZK rollups from achieving their theoretical scaling potential.
ZK-native VMs are the counter-intuitive solution. Architectures like zkSync's zkEVM, Starknet's Cairo, and Polygon zkEVM prove execution traces directly. They eliminate the gas metering overhead by designing for provability first, making the EVM's gas oracle a redundant and expensive middleman.
Evidence: A zkEVM proving a simple transfer spends ~20% of its cycles on gas accounting. For complex DeFi transactions, this overhead balloons, capping throughput far below the 100k+ TPS promised by ZK theory.
thesis-statement
THE ARCHITECTURAL MISMATCH
The Core Conflict: Stateful Execution vs. Stateless Proofs
The EVM's gas model is fundamentally incompatible with ZK scaling, creating a performance ceiling that only a new execution paradigm can break.
EVM gas is stateful. It charges for every storage slot read and written, forcing ZK provers to cryptographically verify each state access. This creates a prover bottleneck that limits scalability, as seen in the high proving costs for zkEVMs like Polygon zkEVM and Scroll.
ZK proofs are stateless. A validity proof only verifies a computation's correctness, not its execution path. The current gas model forces ZK systems to emulate a stateful machine, adding massive overhead that nullifies the efficiency gains of zero-knowledge cryptography.
The conflict defines the ceiling. This is why zkRollups today optimize for specific applications (e.g., dYdX, ImmutableX) rather than general computation. A universal ZK scaling layer requires a new execution environment built for stateless verification from the start, not an emulation of the EVM.
Evidence: StarkWare's Cairo VM demonstrates the performance gap. It achieves orders of magnitude higher throughput for its native apps by designing a prover-friendly ISA, bypassing the EVM's state-access accounting entirely.
key-trends
WHY THE EVM GAS MODEL MUST DIE FOR ZK SCALING
The Symptoms of a Broken Model
The EVM's gas model is a deterministic accounting system for a non-deterministic world, creating fundamental friction for ZK-based scaling.
01
The Opcode Tax: Paying for Abstraction You Don't Use
EVM gas costs are a one-size-fits-all tax on computational possibility, not actual cost. ZK circuits prove specific execution traces, making pre-paid gas estimation a wasteful relic.
- Inefficiency: Paying for worst-case
SSTOREorCALLoverhead even when a ZK proof shows minimal state changes. - Mismatch: Gas model designed for live execution validation, not cryptographic verification of a completed result.
~30-70%
Wasted Overhead
Fixed
vs. Variable Cost
02
Frontrunning & MEV as a Systemic Feature
The mempool-and-gas-auction model is a bug elevated to a feature. It's a direct consequence of public, ordered execution. ZK proofs enable private intents and batch settlement, rendering the toxic game theory obsolete.
- Architectural Flaw: Transparent pending transactions are an invitation for extractive value.
- ZK Advantage: Proofs can settle bundles of intents (see UniswapX, CowSwap) without exposing vector.
$1B+
Annual MEV
0 Gas Auction
With Private Intents
03
The Parallelization Ceiling
EVM's sequential transaction ordering is a hard bottleneck. Gas limits per block artificially constrain throughput, forcing L2s to play inefficient bundling games. ZK validity proofs decouple execution from verification, enabling true parallel execution layers.
- Bottleneck: Single-threaded EVM limits even ZK-rollup TPS.
- Future: Projects like EigenLayer and Fuel are building parallelized VMs that the gas model cannot natively price.
<100
EVM TPS Core
10,000+
ZK-Native Potential
04
Cross-Chain Friction & The Settlement Tax
Bridging assets via canonical bridges or LayerZero/Axelar incurs a double gas tax: one for the source chain action, one for the destination validation. A ZK-native model with shared state proofs (e.g., Polygon AggLayer, zkBridge) treats cross-chain as a state transition, not two separate gas events.
- Cost Duplication: Users pay for L1 gas and L2 gas for a single logical action.
- ZK Unification: A single proof can attest to state changes across multiple environments.
2x
Gas Events
-90%
Bridge Cost Potential
GAS ECONOMICS
Cost Mismatch: EVM Opcode vs. ZK Prover
Quantifying the fundamental misalignment between EVM's gas model and ZK proof generation costs. The EVM charges per opcode; ZK provers pay per constraint. This table shows why a new fee market is non-negotiable for ZK scaling.
| Cost Driver | EVM Gas Model (Status Quo) | ZK Prover Reality | Implication for Scaling |
|---|---|---|---|
Primary Billing Unit | Per EVM Opcode Execution | Per R1CS / AIR Constraint | Gas costs are a poor proxy for prover work. |
Cost of Keccak256 Hash | 30-70 gas (sub-cent cost) | ~20,000 constraints (>$0.10) | EVM underprices cryptography by >1000x. |
Cost of Storage Write (SSTORE) | 20,000 gas (cold) | Negligible (witness generation only) | EVM overprices simple state updates. |
Parallelization Potential | Sequential (single-threaded EVM) | Massively Parallel (GPU/ASIC proving) | Gas model cannot monetize hardware efficiency. |
Fee Market Dynamics | Competition for block space (EIP-1559) | Competition for compute/GPU time | Base fee does not reflect prover's real resource cost. |
Prover Cost at 100 TPS | Not applicable | $0.05 - $0.20 per transaction | L1 gas revenue insufficient to cover proof generation. |
Required Solution | None (incumbent model) | ZK-Native Fee Market (e.g., Proof of Efficiency) | New economic layer (like EigenLayer for proving) is inevitable. |
deep-dive
THE EVM MISMATCH
Architecting a Proof-Cost Fee Market
The EVM's gas model is fundamentally incompatible with ZK scaling, requiring a new fee market based on proof generation cost.
EVM gas is compute-centric. It prices opcodes, not cryptographic proof generation. This creates a fatal economic mismatch for ZK rollups like zkSync and Scroll, where the dominant cost is the SNARK proof, not the simulated execution.
Proof cost is data-dependent. A transaction's fee must reflect its circuit complexity, not its EVM gas. A simple transfer and a complex Uniswap swap have vastly different proving costs, which the EVM model obscures.
Fee markets must decouple. Users pay for L1 settlement and data, while sequencers/provers pay for proof generation. Protocols like StarkNet and Polygon zkEVM are pioneering this separation, creating a secondary market for proof batching.
Evidence: A zkEVM proof for 1000 simple transfers costs ~$0.05, while a proof for 1000 complex swaps can exceed $5. The EVM gas model would price these identically, guaranteeing prover insolvency.
counter-argument
THE ARCHITECTURAL MISMATCH
Counterpoint: The Compatibility Trap
EVM gas accounting is a legacy bottleneck that actively sabotages the performance and cost-efficiency of ZK-rollups.
EVM gas is a simulation tax. Every ZK-rollup must prove the execution of a gas-metered EVM, forcing expensive ZK circuits to replicate the L1's state and opcode pricing. This creates a prohibitive proof overhead that limits throughput and inflates costs, as seen in early zkEVM implementations.
True scaling requires native ZK architectures. Protocols like Starknet and zkSync Era demonstrate that moving to custom VMs (Cairo, zkEVM) with ZK-friendly opcodes reduces proof costs by 10-100x. The future is ZK-VMs, not ZK-wrapped EVMs.
Compatibility is a performance anchor. The industry's obsession with bytecode-level EVM equivalence sacrifices optimal proving for developer convenience. This trade-off is unsustainable for scaling beyond a few thousand TPS.
Evidence: A simple SHA256 hash costs ~1M gas on Ethereum but requires ~20,000 constraints in a ZK circuit. Forcing ZK-provers to track gas for this single opcode adds millions of unnecessary constraints, directly increasing proof time and cost.
protocol-spotlight
THE GASLESS FRONTIER
Who's Building the Post-Gas Future?
The EVM's per-opcode gas model is a bottleneck for ZK scaling. These projects are pioneering the abstraction layer that kills it.
01
The Problem: Gas is a UX and Scalability Prison
EVM gas forces users to think in wei, not value. It's a front-running vector and a ZK proof overhead nightmare. Every opcode cost must be proven, bloating circuits and capping TPS.
- ~70% of L2 gas spent on proving overhead
- UX dead ends: Failed txs still cost gas, wallet pop-up hell
- Inflexible: Can't amortize or sponsor costs for complex apps
~70%
L2 Overhead
0
User Clarity
02
The Solution: Intent-Based Abstraction (UniswapX, CowSwap)
Shift from gas-for-ops to declarative intents. Users sign what they want, solvers compete on how to achieve it best. Gas becomes a backend concern.
- MEV protection: Solvers internalize cost, no front-running
- Cost abstraction: User pays in output token, no native gas needed
- ZK-friendly: Proving a solved intent is simpler than proving execution
100%
Gas Abstracted
-99%
Failed Tx Cost
03
The Solution: Parallel Fee Markets (Fuel, Monad)
Ditch the global gas queue. Enable parallel execution with localized fee markets. Each shard or execution context manages its own resources, eliminating congestion spillover.
- Horizontal scaling: Throughput scales with cores, not gas limit hikes
- Predictable pricing: App-specific fee markets, not network-wide auctions
- ZK-native: Parallel state proofs are independent and cheaper to verify
10k+
Theoretical TPS
-90%
Price Volatility
04
The Solution: Session Keys & Sponsored Transactions (ERC-4337, Pimlico)
Decouple payment from action. Session keys let users pre-approve a set of actions, while Paymasters allow apps to sponsor gas. The gas model becomes invisible.
- 1-click UX: No pop-ups for sequences of actions (gaming, trading)
- Business model: DApps can pay for user onboarding
- ZK efficiency: A single proof can cover a sponsored session
1
Sign Per Session
$0
User Gas Cost
05
The Solution: State & Storage Rent (zkSync, Starknet)
Attack the root cause: perpetual state bloat. Charge rent for storage instead of one-time fees. This aligns costs with resource consumption and reduces the proving load of infinite state.
- Sustainable scaling: Incentivizes state cleanup, reducing proof size
- Fair pricing: Pay for what you use, not a one-time fee
- Long-term ZK viability: Makes proving historical state tractable
-80%
State Growth
10x
Proof Efficiency
06
The Arbiter: Universal Settlement Layers (EigenLayer, Espresso)
The final abstraction. Decouple execution from settlement and consensus. Let rollups and solvers run their own gas-free environments, with a shared security layer enforcing correctness.
- Sovereign execution: Each app chain can implement its own fee logic
- Shared security: No need to bootstrap a new validator set
- ZK aggregation: Batch proofs from many systems for final settlement
1
Settlement Layer
N
Gas Models
takeaways
THE EVM GAS MODEL IS A LIABILITY
Key Takeaways for Builders
The legacy gas model is the primary bottleneck for scaling with ZK. Here's what to build instead.
01
The Problem: Opcode-Level Metering is a Bottleneck
EVM's per-opcode gas accounting forces ZK circuits to prove every tiny state transition, creating massive overhead. This is why native ZK-VMs like zkSync's zkEVM and Starknet's Cairo abandoned it.
- Proving cost is dominated by proving gas logic itself.
- ZK-unfriendly ops (e.g.,
KECCAK256, storage writes) become prohibitive. - Limits design space for new cryptographic primitives.
~40%
Proof Overhead
10x+
Cost Penalty
02
The Solution: Resource-Based Fee Markets
Decouple execution cost from proof cost. Charge for abstract resources (compute units, bytes) post-execution, like Fuel Labs and Aztec do. Let the sequencer/ prover handle optimization.
- Provers batch proofs of homogeneous work, achieving ~1000 TPS per shard.
- Users pay predictable fees based on intent complexity, not opcode minutiae.
- Builders can introduce new precompiles without breaking fee markets.
Predictable
User Fees
Homogeneous
Proof Batching
03
The Architecture: Native Account Abstraction & Session Keys
Without gas, transactions are just signed intents. This makes native Account Abstraction (ERC-4337) mandatory, not optional. Protocols like Starknet and zkSync have it baked in.
- Session Keys enable gasless UX for games and social apps.
- Paymasters (sponsored transactions) become the default business model.
- Atomic composability shifts from chain-level to intent-level.
Gasless
User UX
ERC-4337
Native
04
The New Bottleneck: State Growth & Data Availability
Killing gas shifts the scaling limit to data. Your ZK-rollup now lives or dies by its DA solution. This is the real battleground (EigenDA, Celestia, Avail).
- ZK-proofs compress execution, but state diffs must be published.
- Cost model becomes
(Proof Cost) + (DA Cost per Byte). - Validity proofs are useless without available data to reconstruct state.
$0.01-0.10
Per MB DA Cost
Core Limit
State Growth
05
The Tooling Gap: No More `eth_gasPrice`
Entire tooling stacks (wallets, explorers, oracles) break when the gas oracle disappears. New primitives are needed for estimating resource costs and proving times.
- Wallets must estimate abstract resource costs and relay through paymasters.
- Indexers must track proof inclusion latency, not just block times.
- Oracles (like Pyth, Chainlink) must feed proof market data.
New APIs
Required
Tooling Reset
Necessary
06
The Endgame: Specialized ZK-VMs Win
General-purpose EVM equivalence is a trap. The future is parallel VMs optimized for specific domains: RISC Zero for generic proofs, SP1 for speed, Jolt for developer ease.
- App-chains will choose VMs based on workload (gaming, DeFi, AI).
- Interop moves to proof-based messaging (LayerZero, Polymer).
- EVM becomes a compilation target, not the runtime.
100k TPS
Specialized VM
Multi-VM
Ecosystem
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