Vitalik Buterin has called for a hard ceiling on Ethereum proving costs per unit of block gas, adding a resource-accounting test to the push for faster zero-knowledge proofs. For independent prover operators, the issue is how much work the hardest permitted block could demand, even when ordinary blocks finish quickly.
In his October 15 post, Buterin congratulated ZKsync’s Airbender team and set out three formal-verification priorities: matching the mathematical representation of execution to Ethereum’s specification, bounding prover cost relative to block gas, and securing the proof system itself.
The cost requirement reaches beyond a speed leaderboard. Gas gives Ethereum a way to account for work and limit a block’s resource consumption. A useful proving bound would have to connect that allowance to the resources needed to produce a proof, including for deliberately difficult workloads.
Security was already a priority. The Ethereum Foundation set out a security-focused phase in December 2025. The current question is whether the accounting that supports higher execution capacity can also keep the proving burden predictable.
Fast proofs and the hardest permitted blocks
The current compute-cost analysis in EIP-7904 recommends no compute gas-cost changes. As of October 18, it is an Informational EIP in Last Call, with a November 1 deadline.
Its analysis targets 100 million gas per second on optimized native execution clients. The document attributes its changed conclusion to optimizations enabled by Block-Level Access Lists, including parallel work that makes previously problematic operations faster. It specifies no changes to Ethereum’s gas schedule.
That conclusion has a defined scope: execution measured on a bare CPU. EIP-7904 expressly says it does not specifically address ZK-SNARK proof generation. CPU execution and proof generation impose different workloads.
ZKsync’s single-GPU evaluation demonstrates the progress on the proving side. In its October 13 announcement, the company reported that one NVIDIA RTX PRO 6000 Blackwell proved 99% of 7,200 consecutive Ethereum mainnet blocks in under 10 seconds each, including witness preparation. Every sampled block finished in under 12 seconds.
The announcement also described separate live ETHproofs configurations using two and four GPUs.
The sample records performance on those blocks. A maximum-cost guarantee must cover every permitted workload within its stated assumptions, including blocks deliberately assembled to be expensive to prove.
For an operator budgeting hardware, that distinction matters. A typical block may fit comfortably within a small setup while a difficult legal workload determines the reserve capacity needed to keep producing proofs on time.
The workload matters because a unit of execution gas can correspond to different amounts of proving work. In January 27 measurements, Nethermind Research’s Lin Oshitani found that cryptographic precompiles and several modular arithmetic or division operations were relatively expensive to prove per gas. Costs varied by prover, and 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. It 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. They omitted block-header validation and accidentally omitted BLOCKHASH; a full investigation of argument-dependent costs remained future work.
A stronger bound needs a specified performance envelope. The Ethereum Foundation’s January worst-case benchmarking framework relates the required proving throughput to a chosen block gas limit and proving deadline. Under that approach, a difficult block must still fit the intended hardware and time budget.
The framework also explains why an operation-by-operation estimate needs an end-to-end check. Proof generation has fixed overhead, aggregation can be nonlinear, and hardware configuration and security parameters affect performance. The set of execution clients and proof systems expected to participate also matters.
How the choices reach operators and users
The engineering response determines where the burden lands. Improving an expensive circuit or execution path could reduce proving work while leaving the transaction’s execution gas units unchanged. Operators could then need fewer resources for the same workload.
Nethermind’s study also outlined weighted ZK-gas metering with a per-block ceiling. Such a system would count proof-heavy operations against a separate allowance, potentially constraining a block before its ordinary execution-gas allowance was exhausted. Its protection would depend on how well the weights captured difficult inputs.
Economically, a resource cap and a payment rule answer separate questions. A cap can determine how much work is admitted without specifying what an application user pays or what a prover earns. Charging for a proving resource would require additional design choices.
EIP-7999’s multidimensional fee-market proposal remains Draft and separates calldata into its own resource.
Opcode repricing would operate through the existing gas allowance. Assigning more gas to expensive operations would allow fewer of them into a block at a fixed gas limit. Applications using those operations could consume more gas for the same successful execution.
Under the execution-fee mechanism specified by EIP-1559, charged gas is multiplied by the effective gas price. At an unchanged positive effective gas price, an application charged more gas for the same successful transaction would pay more.
The current optional execution-proof proposal, EIP-8025, remains Draft, provides no prover incentives and retains re-execution even when proofs are available. The Foundation’s September priorities place mandatory proofs later, with fork ordering under review.
EIP-7904’s November 1 review deadline concerns its CPU analysis. For independent provers, the consequential next step is a bound tied to explicit workloads, implementations, security settings and hardware assumptions. That would turn a gas allowance into a dependable limit on the proving resources an operator must be ready to supply.
