Ethereum co-founder Vitalik Buterin has called for the establishment of a hard ceiling on Ethereum proving costs per unit of block gas, adding a critical resource-accounting test to the broader industry push for faster zero-knowledge (ZK) proofs. For independent prover operators, the fundamental issue centers on how much computational work the hardest permitted block could demand, even when ordinary, routine blocks finish quickly.
In a public post on October 15, Buterin congratulated ZKsync’s Airbender team for their recent technical milestones while outlining three core formal-verification priorities for the network. These priorities include matching the mathematical representation of execution precisely to Ethereum’s official specification, bounding prover costs relative to block gas limits, and securing the underlying cryptographic proof system itself.
The requirement for a strict cost boundary reaches far beyond a simple speed leaderboard or performance benchmark. The gas mechanism has long given Ethereum a reliable way to account for computational work and limit a block’s overall resource consumption. However, for zero-knowledge systems to integrate seamlessly into the core protocol, a useful proving bound would have to connect that native gas allowance directly to the physical resources required to produce a valid proof, including for deliberately difficult workloads designed to stress the system.
Security has naturally remained a primary focus for core developers. The Ethereum Foundation previously set out a dedicated security-focused phase in December 2025 to harden infrastructure. The pressing question now facing researchers is whether the advanced accounting mechanisms that support higher execution capacity can simultaneously keep the operational proving burden predictable for independent nodes.
Fast proofs and the hardest permitted blocks
The current compute-cost analysis outlined in EIP-7904 recommends no changes to native compute gas costs. As of October 18, the document sits as an Informational EIP in Last Call status, carrying a November 1 deadline.
The analysis specifically targets a performance benchmark of 100 million gas per second on optimized native execution clients. The document attributes its revised conclusions to efficiency optimizations enabled by Block-Level Access Lists, which include parallel processing capabilities that make previously problematic operations significantly faster. Crucially, the specification outlines no changes to Ethereum’s existing gas schedule.
That conclusion, however, possesses a strictly defined scope: execution measured purely on a bare CPU. EIP-7904 expressly notes that it does not specifically address ZK-SNARK proof generation. Standard CPU execution and zero-knowledge proof generation impose fundamentally different workloads on hardware.
ZKsync’s single-GPU evaluation demonstrates the rapid technological progress happening on the proving side. In an announcement on October 13, the company reported that a single NVIDIA RTX PRO 6000 Blackwell GPU successfully proved 99% of 7,200 consecutive Ethereum mainnet blocks in under 10 seconds each, a timeframe that included witness preparation. Every single sampled block finished processing in under 12 seconds.
The announcement also described separate, live ETHproofs configurations utilizing two and four GPUs working in tandem.
While these sample records track impressive performance across typical blocks, a maximum-cost protocol guarantee must cover every single permitted workload within its stated assumptions. This includes blocks that are deliberately assembled to be computationally expensive to prove.
For an infrastructure operator budgeting expensive hardware, that distinction matters immensely. A typical block may fit comfortably within a modest hardware setup, whereas a difficult legal workload determines the reserve capacity required to keep producing proofs reliably on time.
The workload matters deeply because a single unit of execution gas can correspond to drastically different amounts of actual proving work. In measurements published on January 27, Nethermind Research’s Lin Oshitani found that cryptographic precompiles and several modular arithmetic or division operations were relatively expensive to prove per unit of gas. Costs varied significantly by prover architecture, and ZK-cycle counts did not translate into uniform elapsed proving time across different operations.
The study estimated marginal proving time by varying operation counts while holding the surrounding execution context constant. It tested SP1 v5.2.3 with sp1-cluster and RISC0 v3.0.4, using reth v1.9.3 alongside four NVIDIA GeForce RTX 4090 GPUs. RISC0 was operated using the RISC0_KECCAK_PO2=15 configuration.
These measurements utilized fixed representative or best-effort worst-case inputs, though they omitted block-header validation and accidentally left out BLOCKHASH, meaning a full investigation of argument-dependent costs remained work for the future.
A stronger boundary requires a well-defined performance envelope. The Ethereum Foundation’s January worst-case benchmarking framework relates required proving throughput directly to a chosen block gas limit and a strict proving deadline. Under this systematic approach, a difficult block must still fit comfortably within intended hardware parameters and time budgets.
The framework also explains why an operation-by-operation estimate requires an end-to-end check. Proof generation carries fixed overhead, cryptographic aggregation can behave nonlinearly, and specific hardware configurations and security parameters heavily impact performance. The diverse set of execution clients and proof systems expected to participate in the network further complicates the equation.
How the choices reach operators and users
Ultimately, the chosen engineering response determines precisely where the economic and computational burden lands. Improving an expensive circuit or optimization path could reduce overall proving work while leaving a transaction’s execution gas units entirely unchanged. Operators could then require fewer hardware resources for the exact same transaction workload.
Nethermind’s research study also outlined weighted ZK-gas metering equipped 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 fully exhausted. The protection offered by this design would depend entirely on how accurately the assigned weights captured genuinely difficult inputs.
From an economic perspective, a resource cap and a payment rule answer two entirely separate questions. A strict cap can determine how much work is admitted into the network without specifying what an application user must pay or what a prover earns. Charging directly for a proving resource would require additional, complex design choices.
EIP-7999, which proposes a multidimensional fee-market framework, remains in draft status and isolates calldata into its own distinct resource category.
Opcode repricing, meanwhile, would operate directly through the existing gas allowance. Assigning higher gas costs to computationally expensive operations would allow fewer of them to fit into a single block under a fixed gas limit. Applications relying heavily on those specific operations would consequently consume more gas for the exact same successful execution.
Under the execution-fee mechanism specified by EIP-1559, charged gas is multiplied directly by the effective gas price. At an unchanged positive effective gas price, an application charged more gas for the same successful transaction would ultimately pay more.
The current optional execution-proof proposal, EIP-8025, remains a draft, provides no direct incentives for provers, and retains native re-execution even when valid proofs are readily available. Meanwhile, the Ethereum Foundation’s September protocol priorities place mandatory proofs further down the roadmap, with fork ordering actively under review.
The upcoming November 1 review deadline for EIP-7904’s CPU analysis marks an important milestone. For independent provers, the consequential next step remains the establishment of a rigorous bound tied to explicit workloads, client implementations, security settings, and hardware assumptions. That transition would successfully turn a standard gas allowance into a dependable limit on the proving resources an operator must be prepared to supply.
