Trusted Editorial content, reviewed by leading industry experts and seasoned editors. Ad Disclosure
The Ethereum Foundation has published a step-by-step plan to let Ethereum’s main chain validate blocks using zkEVM proofs, reducing the need for validators to re-run every computation themselves. The proposal, shared via X on Jan. 15 by Tomasz K. Stańczak, Co-Executive Director at the Ethereum Foundation, lays out the engineering work needed across Ethereum’s execution and consensus clients, plus new proving infrastructure and security processes.
Already in July last year, the Ethereum Foundation announced its “zk-first” approach. Today, Ethereum’s validators typically check a block by re-executing the transactions and comparing results. The plan proposes an alternative: validators could verify a cryptographic proof that the block’s execution was correct.
The document summarizes the intended pipeline in plain terms: an execution client produces a compact “witness” package for a block, a standardized zkEVM program uses that package to generate a proof of correct execution, and consensus clients verify that proof during block validation.
The first milestone is creating an “ExecutionWitness,” a per-block data structure containing the information needed to validate execution without re-running it. The plan calls for a formal witness format in Ethereum’s execution specifications, conformance tests, and a standardized RPC endpoint. It notes that the current debug_executionWitness endpoint is already “being used in production by Optimism’s Kona,” while suggesting a more zk-friendly endpoint may be needed.
A key dependency is adding better tracking of which parts of state a block touches, via Block Level Access Lists (BALs). The document says that as of November 2025, this work was not treated as urgent enough to be backported to earlier forks.
The next milestone is a “zkEVM guest program,” described as stateless validation logic that checks whether a block produces a valid state transition when combined with its witness. The plan emphasizes reproducible builds and compiling to standardized targets so assumptions are explicit and verifiable.
Beyond Ethereum-specific code, the plan aims to standardize the interface between zkVMs and the guest program: common targets, common ways to access precompiles and I/O, and agreed assumptions about how programs are loaded and executed.
On the consensus side, the roadmap calls for changes so consensus clients can accept zk proofs as part of beacon block validation, with accompanying specifications, test vectors, and an internal rollout plan. The document also flags execution payload availability as important, including an approach that could involve “putting the block in blobs.”
The proposal treats proof generation as an operational problem as much as a protocol one. It includes milestones to integrate zkVMs into EF tooling such as Ethproofs and Ere, test GPU setups (including “zkboost”), and track reliability and bottlenecks.
Benchmarking is framed as ongoing work, with explicit goals like measuring witness generation time, proof creation and verification time, and the network impact of proof propagation. Those measurements could feed into future gas repricing proposals for zk-heavy workloads.
Security is also marked as perpetual, with plans for formal specs, monitoring, supply-chain controls like reproducible builds and artifact signing, and a documented trust and threat model. The document proposes a “go/no-go framework” for deciding when proof systems are mature enough for broader use.
One external dependency stands out: ePBS, which the document describes as necessary to give provers more time. Without it, the plan says the prover has “1-2 seconds” to create a proof; with it, “6-9 seconds.” The document adds a two-sentence framing that captures the urgency: “This is not a project that we are working on. However, it is an optimization that we need.” It expects ePBS to be deployed in “Glamsterdam,” targeted for mid-2026.
If these milestones land, Ethereum would be moving toward proof-based validation as a practical option on L1, while the timing and operational complexity of proving remain the gating factors.
