Ethereum's Proving Costs Face Vitalik's Hard Limit Challenge

Vitalik Buterin has called for a hard ceiling on Ethereum proving costs per unit of block gas. Buterin congratulated ZKsync's Airbender team in an October 15 post and identified three formal-verification priorities: matching execution's mathematical representation to Ethereum's specification, bounding prover cost relative to block gas, and securing the proof system. Gas accounts for execution work and limits block resource consumption, but a useful proving bound must connect that allowance to proof-generation resources, including deliberately difficult workloads. The Ethereum Foundation set out a security-focused phase in December 2025.

EIP-7904's current compute-cost analysis recommends no compute gas-cost changes and specifies no changes to Ethereum's gas schedule. EIP-7904 is an Informational proposal in Last Call as of October 18, with a November 1 deadline. EIP-7904's analysis targets 100 million gas per second on optimized native execution clients. EIP-7904 attributes its changed conclusion to optimizations enabled by Block-Level Access Lists, including parallel work that accelerates previously problematic operations. However, EIP-7904 covers execution on a bare CPU and expressly excludes specific consideration of ZK-SNARK proof generation, which imposes different workloads.

ZKsync reported on October 13 that one NVIDIA RTX PRO 6000 Blackwell proved 99% of 7,200 consecutive Ethereum mainnet blocks in under 10 seconds each, including witness preparation. ZKsync reported that every sampled block finished in under 12 seconds. ZKsync also described separate live ETHproofs configurations using two and four GPUs. However, a maximum-cost guarantee must cover every permitted workload within stated assumptions, including blocks deliberately assembled to be expensive to prove. A typical block may fit a small setup, while a difficult permitted workload determines the reserve capacity an operator needs to produce proofs on time.

Nethermind Research's Lin Oshitani found in January 27 measurements that cryptographic precompiles and several modular arithmetic or division operations were relatively expensive to prove per gas. Oshitani's measurements showed that costs varied by prover and that ZK-cycle counts did not translate into uniform elapsed proving time across operations. The study estimated marginal proving time by varying operation counts while holding surrounding execution context constant. The study tested SP1 v5.2.3 with sp1-cluster and RISC0 v3.0.4, using reth v1.9.3 and four NVIDIA GeForce RTX 4090 GPUs. RISC0 used the RISC0_KECCAK_PO2=15 setting. The measurements used fixed representative or best-effort worst-case inputs, omitted block-header validation and accidentally omitted BLOCKHASH. A full investigation of argument-dependent costs remained future work.

The Ethereum Foundation's January worst-case benchmarking framework relates required proving throughput to a chosen block gas limit and proving deadline. The framework requires a difficult block to fit the intended hardware and time budget. The framework explains that operation-level estimates need end-to-end checks because proof generation has fixed overhead, aggregation can be nonlinear, and hardware configurations and security parameters affect performance. The set of execution clients and proof systems expected to participate also matters.

Improving an expensive circuit or execution path could reduce proving work without changing transaction execution gas units, allowing operators to use fewer resources for the same workload. Nethermind's study also outlined weighted ZK-gas metering with a per-block ceiling that could constrain proof-heavy operations before the ordinary execution-gas allowance was exhausted. The protection from weighted ZK-gas metering would depend on how accurately the weights captured difficult inputs. A resource cap can limit admitted work without determining application-user payments or prover earnings. Charging for a proving resource would require additional design choices. EIP-7999 remains a Draft multidimensional fee-market proposal that separates calldata into its own resource.

Opcode repricing would assign more gas to expensive operations, allowing fewer such operations into a block at a fixed gas limit. Applications using repriced operations could consume more gas for the same successful execution. EIP-1559's execution-fee mechanism multiplies charged gas by the effective gas price. An application charged more gas for the same successful transaction would pay more at an unchanged positive effective gas price.

EIP-8025 remains a Draft optional execution-proof proposal that provides no prover incentives and retains re-execution even when proofs are available. The Ethereum Foundation's September priorities place mandatory proofs later, with fork ordering under review. EIP-7904's November 1 review deadline concerns CPU analysis, while independent provers need a bound tied to explicit workloads, implementations, security settings and hardware assumptions. Such a bound would turn a gas allowance into a dependable limit on the proving resources an operator must be ready to supply.