{"id":14656,"date":"2026-10-19T14:08:48","date_gmt":"2026-10-19T14:08:48","guid":{"rendered":"https:\/\/cryptonews.uk.com\/?p=14656"},"modified":"2026-10-19T14:08:48","modified_gmt":"2026-10-19T14:08:48","slug":"ethereum-proving-costs-face-vitaliks-worst-case-test","status":"publish","type":"post","link":"https:\/\/cryptonews.uk.com\/?p=14656","title":{"rendered":"Ethereum proving costs face Vitalik\u2019s worst-case test"},"content":{"rendered":"

<\/p>\n

\n

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.<\/p>\n

In his October 15 post, Buterin congratulated ZKsync\u2019s Airbender team and set out three formal-verification priorities: matching the mathematical representation of execution to Ethereum\u2019s specification, bounding prover cost relative to block gas, and securing the proof system itself.<\/p>\n

The cost requirement reaches beyond a speed leaderboard. Gas gives Ethereum a way to account for work and limit a block\u2019s 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.<\/p>\n

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.<\/p>\n

Fast proofs and the hardest permitted blocks<\/h2>\n

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.<\/p>\n

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\u2019s gas schedule.<\/p>\n

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.<\/p>\n

ZKsync\u2019s 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.<\/p>\n

The announcement also described separate live ETHproofs configurations using two and four GPUs.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\n

Related Reading<\/span><\/p>\n

Ethereum’s quantum race takes a new turn as zkSync courts banks and Starknet weighs exit<\/h3>\n<\/p>\n

<\/span> <\/div>\n

The workload matters because a unit of execution gas can correspond to different amounts of proving work. In January 27 measurements, Nethermind Research\u2019s 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n