The Ethereum Foundation has released a step-by-step plan to enable the Ethereum mainchain to validate blocks using zkEVM proofs, reducing the need for validators to re-run each calculation themselves. The proposal, shared via
zkEVM on L1 – the plan
– Tomasz K. Stańczak (@tkstanczak) January 15, 2026
Ethereum L1 moving towards zk proof-based validation
Already in July last year, the Ethereum Foundation announced its “zk-first” approach. Today, Ethereum validators typically verify a block by rerunning transactions and comparing the results. The plan proposes an alternative: validators could verify cryptographic proof that the block execution was correct.
The paper summarizes the planned pipeline in simple terms: an execution client produces a compact “witness” package for a block, a standardized zkEVM program uses this package to generate a proof of correct execution, and consensus clients verify this proof when validating the block.
The first step is to create an “ExecutionWitness”, a block data structure containing the information needed to validate the execution without rerunning it. The plan requires a formal witness format in the Ethereum runtime specification, conformance testing, and a standardized RPC endpoint. He notes that the current debug_executionWitness endpoint is already “used in production by Optimism’s Kona”, while suggesting that a more zk-friendly endpoint might be needed.
A key dependency is to add better tracking of which parts of the state are touched by a block, via block-level access lists (BAL). The document states that as of November 2025, this work was not treated as urgent enough to backport to previous forks.
The next step 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 repeatable constructs and compilation according to standardized goals so that hypotheses are explicit and testable.
Beyond Ethereum-specific code, the plan aims to standardize the interface between zkVMs and the guest program: common targets, common ways to access precompilations and I/O, and agreed-upon assumptions about how programs are loaded and executed.
On the consensus side, the roadmap calls for changes so that consensus clients can accept zk proofs as part of beacon block validation, with accompanying specifications, test vectors, and an internal deployment plan. The paper also notes that execution payload availability is important, including an approach that could involve “putting the block into blobs.”
The proposal treats proof generation as an operational problem as well as a protocol one. It includes steps for integrating zkVMs into EF tools such as Ethproofs and Ere, testing GPU configurations (including “zkboost”), and tracking reliability and bottlenecks.
Benchmarking is designed as ongoing work, with explicit goals such as measuring witness generation time, evidence creation and verification time, and the network impact of evidence propagation. These measures could fuel future gas repricing proposals for heavy zk workloads.
Security is also considered perpetual, with plans for formal specifications, monitoring, supply chain controls such as reproducible builds and artifact signing, and a documented trust and threat model. The paper proposes a “go/no-go” framework for deciding when proof systems are mature enough for wider use.
One external dependency stands out: ePBS, which the paper describes as necessary to give provers more time. Without it, the plan says the prover has “1 to 2 seconds” to create a proof; with him, “6 to 9 seconds”. The document adds a two-sentence framework that conveys urgency: “This is not a project we are working on. However, it is an optimization we need.” He expects the ePBS to be deployed in “Glamsterdam”, planned for mid-2026.
If these milestones come true, Ethereum would move toward proof-based validation as a practical option on L1, while the timing and operational complexity of proof remains the driving factors.
At press time, ETH was trading at $3,300.
Featured image created with DALL.E, chart from TradingView.com
Editorial process as Bitcoinist focuses on providing thoroughly researched, accurate and unbiased content. We follow strict sourcing standards and every page undergoes careful review by our team of top technology experts and seasoned editors. This process ensures the integrity, relevance and value of our content to our readers.
