Ethereum Foundation Opens evm.fast Challenge to Bound Validator Work

The Ethereum Foundation has opened evm.fast, a public challenge asking entrants to establish a certified upper bound on the steps needed to validate a stateless Ethereum block in a defined software model. The bound is intended to quantify the evaluator’s workload across eligible inputs.

The challenge calls the bound K. It counts startup steps as well as execution and must cover every input in scope. An upper bound need not be the exact number of steps the program will use in its worst case; it must provide a ceiling that applies to all covered inputs.

To qualify, an input must declare a gas limit of 200 million or less, and submitted code must fit within a 128 MiB program window. These limits define which inputs the challenge evaluates; the gas cutoff does not change Ethereum’s gas rules. Entrants must provide RISC-V code with a Lean proof that it matches the fixed Pancake guest. Passing execution tests alone does not meet that requirement.

K is measured in Flapjack’s 64-bit RISC-V model. It represents the evaluator’s step count, not Spike’s hardware instruction count or the time required to produce a proof. The distinction keeps the result tied to a specified software environment rather than elapsed time on a particular platform.

At 1:06 a.m. ET (06:06 UTC) Nov. 3, the baseline was infinity, with no promoted submissions. Infinity means no single finite K has been established across the covered inputs. A kernel replay was accepted, while end-to-end verification of the initial submission remained incomplete; certificate regeneration and the full audit were still in progress.

Ethereum is moving execution proofs from optional use toward expected and eventually mandatory use. These proofs are intended to let validators check block execution without repeating it. A separate Sepolia proof-generation test examined turnaround time, with one block taking 6 to 7 seconds; evm.fast instead seeks a step ceiling across its eligible inputs.

Any finite result would apply to the challenge’s fixed guest and Flapjack’s RISC-V model. It would not establish that the guest fully implements Ethereum’s consensus rules or that the model matches a particular zkVM or production platform.