An open challenge asks contributors to prove a finite worst-case step bound for Ethereum block verification on a RISC-V model
The Ethereum Foundation has opened a technical challenge at evm.fast with an unusual target. The current best score is infinity.
The task is to prove a worst-case limit on how much computation it takes to verify an Ethereum block. Any finite answer, backed by a machine-checked proof, beats the existing record.
How the score works
The challenge measures a number called K. K is the certified upper bound on execution steps for a 64-bit RISC-V model, applied to every input the challenge covers. Startup steps count toward the total, so contestants cannot quietly skip the warm-up.
The model runs through Flapjack. Flapjack is a Lean 4 adaptation of the Pancake compiler, built for a 64-bit RISC-V architecture. Lean 4 is a proof assistant, software that checks mathematical proofs line by line. RISC-V is an open instruction set, the basic vocabulary a processor understands.
The baseline program, compiled by the verified Flapjack compiler, already proves that block verification stops eventually. What it does not prove is a uniform bound, one fixed ceiling that holds across all inputs. So the baseline claims a score of ∞.
The challenge is framed as open to contributors. No monetary prizes, deadlines or submission platforms have been announced.
Why worst-case bounds matter for zk proving
The effort fits into the Foundation’s broader zero-knowledge proof agenda. A zero-knowledge proof lets one party show a computation was done correctly without the checker redoing all of it. Systems that generate these proofs for general programs are called zkVMs. Many of them compile code down to RISC-V.
The Foundation’s 2025 to 2026 objectives include provable security, recursion soundness and predictable proving costs. Recursion soundness refers to proofs that verify other proofs, which need to stay correct as they stack up. Predictable proving costs is where this challenge plugs in most directly.
Speed has already improved sharply in this area. Latency has fallen from roughly 16 minutes to under 10 seconds for 99% of mainnet blocks on target hardware, in the context of real-time proofs of full Ethereum blocks.
Background on formal verification in Ethereum
The challenge sits alongside other ongoing Foundation work on security estimation, guest-program verification and RISC-V semantics in Ethereum execution. A guest program is the code a zkVM runs and proves, in this case the logic that checks an Ethereum block.
What this means
Real-time proving of full blocks only works if provers can budget for the hardest possible block, not just the typical one. A proven K gives that budget a mathematical foundation instead of an empirical guess.
There is a denial-of-service angle too. If an attacker could craft a block that takes vastly more steps to verify than expected, provers could fall behind. A certified ceiling makes that kind of surprise much harder to engineer, because the worst case is already known and documented.
Because the baseline sits at infinity, the first valid entry wins by default, even with a loose bound. After that, the real competition becomes tightening K toward a figure provers can actually plan around.
