The Ethereum Foundation has published a step-by-step plan to enable the Ethereum main chain to validate blocks using zkEVM proofs, reducing the need for validators to re-run all calculations themselves. The proposal, shared via X on January 15 by Tomasz K. Stanczak, Co-Executive Director of the Ethereum Foundation, lays out the engineering work required across Ethereum’s execution and consensus clients, as well as new proof infrastructure and security processes.
zkEVM for L1 – Plan https://t.co/KLz7PoH6q9
— Tomasz K. Stanczak (@tkstanczak) January 15, 2026
Ethereum L1 moves towards ZK proof-based verification
Already in July last year, the Ethereum Foundation announced its “ZK First” approach. Currently, Ethereum validators typically check blocks by re-executing transactions and comparing the results. The plan proposes an alternative in which validators can verify the correct execution of a block with cryptographic evidence.
This document summarizes the intended pipeline in plain language. The execution client generates a compact “monitoring” package for the block, a standardized zkEVM program uses that package to generate a proof of correct execution, and the consensus client verifies that proof during block validation.
The first milestone is to create an “ExecutionWitness”, a per-block data structure containing the information needed to verify execution without re-execution. The plan calls for a formal witness format for Ethereum’s execution specifications, conformance testing, and standardized RPC endpoints. It states that the current debug_executionWitness endpoint is already “used in production by Optimism’s Kona,” suggesting that a more zk-friendly endpoint may be needed.
A key dependency is enhanced tracking of which parts of state are touched by a block via a block-level access list (BAL). The document states that as of November 2025, this work was not deemed urgent enough to be backported to the previous fork.
The next milestone is the “zkEVM Guest Program”. This is described as stateless validation logic that checks whether a block produces a valid state transition when combined with a monitoring function. This plan emphasizes reproducible builds and compiling to standardized targets, so assumptions are explicit and verifiable.
The plan aims to move beyond Ethereum-specific code and standardize the interface between zkVM and guest programs: a common target, a common way to access precompilation and I/O, and agreed upon assumptions about how programs are loaded and executed.
On the consensus side, the roadmap calls for changes to allow consensus clients to accept zk proofs as part of beacon block validation, along with accompanying specifications, test vectors, and internal deployment plans. The document also flags the availability of the execution payload as important, which could include a “block into a blob” approach.
This proposal treats proof generation as an operational problem as well as a protocol problem. This includes milestones for integrating zkVM with EF tools like Ethproofs and Ere, testing GPU setups (including “zkboost”), and tracking reliability and bottlenecks.
Benchmarking is structured as a continuous effort, with clear goals such as measuring witness generation time, proof creation and verification time, and network impact of proof propagation. These measurements may factor into future gas pricing proposals for zk-heavy workloads.
Security is also marked as permanent and includes planning for formal specifications, monitoring, supply chain controls such as reproducible builds and artifact signing, and a documented trust and threat model. This paper proposes a “go/no-go framework” for determining when a proof system is mature enough to be widely used.
One external dependency stands out. ePBS. The documentation explains that it is necessary to give the prover more time. Without that, the plan says it would take a prover “1 to 2 seconds” to create a proof. “6 to 9 seconds.” The document adds a two-sentence framework to express urgency: “This is not a project we are working on, but it is an optimization we need.” It is expected that ePBS will be introduced to Gramsterdam in mid-2026.
Once these milestones are achieved, Ethereum will move towards proof-based verification as a viable option at L1, although proof timing and operational complexity will remain gate factors.
At the time of writing, ETH was trading at $3,300.
Featured image created with DALL.E, chart on TradingView.com
