Ethereum Foundation Maps Path To zkEVM Proofs On Mainnet L1

bitcoinistPublished on 2026-01-16Last updated on 2026-01-16

Abstract

The Ethereum Foundation has outlined a detailed plan to enable Ethereum's mainnet (L1) to validate blocks using zkEVM proofs, reducing the need for validators to re-execute every transaction. The proposal, shared by EF Co-Executive Director Tomasz K. Stańczak, involves engineering work across execution and consensus clients, new proving infrastructure, and security processes. Key milestones include creating a standardized "ExecutionWitness" data structure per block, developing a zkEVM guest program for stateless validation, and updating consensus clients to verify zk proofs during block validation. The plan also emphasizes operational readiness, including proof generation integration, GPU testing, benchmarking, and security measures like reproducible builds and formal threat models. A major dependency is ePBS (enshrined Proposer-Builder Separation), which would extend proof generation time from 1–2 seconds to 6–9 seconds, and is targeted for deployment in mid-2026. If implemented, this would make proof-based validation a practical option on L1, though proving times and operational complexity remain key challenges.

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.

Ethereum L1 Moves Toward zk Proof-Based Validation

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.

At press time, ETH traded at $3,300.

ETH faces the 0.618 Fib, 1-week chart | Source: ETHUSDT on TradingView.com

Related Questions

QWhat is the main goal of the Ethereum Foundation's new proposal regarding zkEVM proofs?

AThe main goal is to enable Ethereum's main chain to validate blocks using zkEVM proofs, reducing the need for validators to re-execute every computation themselves by verifying cryptographic proofs of correct execution instead.

QWhat is an 'ExecutionWitness' as described in the plan?

AAn 'ExecutionWitness' is a per-block data structure that contains the information needed to validate execution without re-running it, including a formal witness format in Ethereum’s execution specifications, conformance tests, and a standardized RPC endpoint.

QWhy is Block Level Access Lists (BALs) important for this proposal?

ABlock Level Access Lists (BALs) are important because they enable better tracking of which parts of the state a block touches, which is a key dependency for generating the execution witness needed for zkEVM proof validation.

QWhat role does ePBS play in the implementation of zkEVM proofs on L1?

AePBS (proposer-builder separation enhancement) is necessary to give provers more time to create proofs, extending the proof creation window from 1-2 seconds to 6-9 seconds, and is considered an essential optimization for the plan.

QHow does the proposal address security concerns related to zkEVM proof validation?

AThe proposal addresses security through formal specifications, monitoring, supply-chain controls like reproducible builds and artifact signing, a documented trust and threat model, and a 'go/no-go framework' to decide when proof systems are mature enough for broader use.

Related Reads

Arbitrum Pretends to Be the Hacker, 'Steals' Back the Money Lost by KelpDAO

Title: Arbitrum Poses as Hacker to Recover Stolen Funds from KelpDAO Last week, KelpDAO suffered a hack resulting in nearly $300 million in losses, marking the largest DeFi security incident this year. Approximately 30,765 ETH (worth over $70 million) remained on an Arbitrum address controlled by the attacker. In an unprecedented move, Arbitrum’s Security Council utilized its emergency authority to upgrade the Inbox bridge contract, adding a function that allowed them to impersonate the hacker’s address and initiate a transfer without access to its private key. The council’s action, approved by 9 of its 12 members, moved the stolen ETH to a frozen address in a single transaction before reverting the contract to its original state. The operation was coordinated with law enforcement, which attributed the attack to North Korea’s Lazarus Group. Community reactions are divided: some praise the recovery of funds, while others question the centralization of power, as the council can upgrade core contracts without governance votes. However, such emergency mechanisms are common among major L2s. Despite the partial recovery, over $292 million was stolen in total, with more than $100 million in bad debt on Aave and remaining funds scattered across other chains. The incident highlights escalating security challenges in DeFi, with state-sponsored hackers employing advanced tactics and L2s responding with elevated countermeasures.

marsbit7m ago

Arbitrum Pretends to Be the Hacker, 'Steals' Back the Money Lost by KelpDAO

marsbit7m ago

iQiyi Is Too Impatient

The article "iQiyi Is Too Impatient" discusses the controversy surrounding the Chinese streaming platform IQiyi's recent announcement of an "AI Actor Library" during its 2026 World Conference. IQiyi claimed over 100 actors, including well-known names like Zhang Ruoyun and Yu Hewei, had joined the initiative. CEO Gong Yu suggested AI could enable actors to "star in 14 dramas a year instead of 4" and that "live-action filming might become a world cultural heritage." The announcement quickly sparked backlash. Multiple actors named in the list issued urgent statements denying they had signed any AI-related authorization agreements. This forced IQiyi to clarify that inclusion in the library only indicated a willingness to *consider* AI projects, with separate negotiations required for any specific role. The incident, which trended on social media with hashtags like "IQiyi is crazy," is presented as a sign of the company's growing desperation. Facing intense competition from short-video platforms like Douyin and Kuaishou, as well as Bilibili and Xiaohongshu, IQiyi's financial performance has weakened, with revenues declining for two consecutive years. The author argues that IQiyi is "too impatient" to tell a compelling AI story to reassure the market, especially as it pursues a listing on the Hong Kong stock exchange. The piece concludes by outlining three key "AI questions" IQiyi must answer: defining its role as a tool provider versus a content creator, balancing the "coldness" of AI with the human element audiences desire, and properly managing the interests of platforms, actors, and viewers. The core dilemma is that while AI can reduce costs and increase efficiency, it risks creating homogenized, formulaic content and devaluing human performers.

marsbit1h ago

iQiyi Is Too Impatient

marsbit1h ago

Trading

Spot
Futures

Hot Articles

Discussions

Welcome to the HTX Community. Here, you can stay informed about the latest platform developments and gain access to professional market insights. Users' opinions on the price of ETH (ETH) are presented below.

活动图片