Last week, Ethereum researcher ladislaus.eth published a walkthrough explaining how Ethereum plans to move from replaying every transaction to verifying zero-knowledge proofs.
The post describes this as “quiet but fundamental change,” and that framework is accurate. Not because this work is secret, but because its effects ripple throughout Ethereum’s architecture and are not obvious until the pieces are connected.
This is not “adding ZK” as a feature of Ethereum. Ethereum is prototyping an alternative validation path that would allow some validators to prove a block by validating a compact proof of execution rather than re-executing all transactions.
If it works, the role of Ethereum’s Layer 1 will shift from “payment and data availability for rollups” to “high-throughput execution that keeps verification cheap enough for home validators.”
What is actually being built?
EIP-8025, titled “Optional Execution Proofs,” is submitted in draft form and specifies mechanisms.
Proof of execution is shared across the consensus layer peer-to-peer network via a dedicated topic. Validators can operate in two new modes: proof generation or stateless validation.
The proposal explicitly states that it “does not require a hard fork” and will allow nodes to rerun as they currently do while maintaining backwards compatibility.
The Ethereum Foundation’s zkEVM team announced a concrete roadmap to 2026 on January 26, outlining six subthemes: execution monitoring and guest program standardization, zkVM guest API standardization, consensus layer integration, prover infrastructure, benchmarks and metrics, and security through formal verification.
The first L1-zkEVM breakout call is scheduled for February 11th at 15:00 UTC.
The end-to-end pipeline works like this: The execution layer client generates an ExecutionWitness, a self-contained package that contains all the data needed to validate blocks without preserving complete state.
Standardized guest programs leverage that monitoring to verify state transitions. zkVM runs this program and the prover generates a proof of correct execution. The consensus layer client then verifies that proof instead of calling the execution layer client to rerun it.
A key dependency is ePBS (Enshrined Proposer-Builder Separation), which is targeted for the upcoming Gramsterdam hard fork. Without ePBS, the proof window is approximately 1-2 seconds, which is too narrow for real-time proof. When ePBS provides a block pipeline, the window is extended to 6-9 seconds.
Decentralization trade-offs
As the optional proof and witness format matures, more home validators will be able to participate without maintaining a full execution layer state.
Raising gas limits becomes politically and economically easier because verification costs are decoupled from implementation complexity. Verification efforts no longer scale linearly with on-chain activity.
However, proofing comes with the risk of centralization. A February 2 Ethereum Research post reports that proofing a complete Ethereum block currently requires approximately 12 GPUs and takes an average of 7 seconds.
The authors express concern about centralization and point out that limitations remain difficult to predict. If proofs are still GPU-intensive and concentrated on a network of builders or provers, Ethereum may trade “everyone redo” for “few proofs, many verifications.”
This design aims to address this by introducing client diversity in the proof layer. EIP-8025 operates on a 3/5 threshold. That is, a verifier accepts the execution of a block as valid if it verifies three out of five independent proofs from different execution layer client implementations.
This maintains client diversity at the protocol level, but does not solve the hardware access problem.
The most honest view is that Ethereum is changing the decentralization battlefield. Today’s constraint is, “Can we afford to run an execution layer client?” Tomorrow it might be, “Do I have access to a GPU cluster or a prover network?”
Proof verification is likely to be easier to commoditize than state saving and re-execution, but hardware issues remain unresolved.
Unlocking L1 scaling
Ethereum’s roadmap (last updated on February 5th) lists “statelessness”, or validating blocks without storing large amounts of state, as a major upgrade theme.
Optional proofs of execution and witnesses are concrete mechanisms that make stateless verification practical. Stateless nodes only require a consensus client to verify proofs during payload processing.
Synchronization results in downloading proofs of recent blocks since the last finalization checkpoint.
This is important for gas limitations. Currently, each time the gas limit increases, it becomes harder for nodes to run. If validators can validate rather than re-run proofs, validation costs are no longer proportional to gas limits. Execution complexity and verification costs are decoupled.
The benchmarking and repricing workstream in the 2026 roadmap explicitly targets metrics that map gas consumption to validation cycles and validation times.
Once these metrics stabilize, Ethereum gains unprecedented power: the ability to increase throughput without proportionally increasing validator execution costs.
What this means for layer 2 blockchains
A recent post by Vitalik Buterin argues that layer 2 blockchains should be differentiated beyond scaling, explicitly tying the value of “native rollup precompilation” to the need for a built-in zkEVM proof that Ethereum already needs to scale layer 1.
The logic is simple. If all validators verify the execution proof, the same proof can also be used in the native rollup’s EXECUTE precompilation. The Layer 1 demonstration infrastructure becomes a shared infrastructure.
This changes the value proposition of Layer 2. If Layer 1 can scale to high throughput while keeping verification costs low, you can’t justify a rollup because “Ethereum can’t handle the load.”
New axes of differentiation are configuration models such as specialized virtual machines, ultra-low latency, up-front confirmation, and rollups based on fast proof-of-concept designs.
Scenarios where Layer 2 relevance is maintained are those where roles are split between specialization and interoperability.
Layer 1 will be a high-throughput, low-verification-cost execution and settlement layer. Layer 2 will be the feature lab, latency optimizer, and composability bridge.
However, this will require the Layer 2 team to articulate a new value proposition and Ethereum to execute on its proof verification roadmap.
Three paths forward
There are three possible future scenarios.
The first scenario consists of proof-first verification becoming commonplace. As optional proof and witness formats mature and client implementations stabilize around standardized interfaces, more home validators will be able to participate without running a full execution layer state.
Gas limitations increase because validation costs no longer match execution complexity. This path relies on ExecutionWitness and guest program standardization workstreams converging to a portable format.
Scenario 2 is when centralizing the prover poses a new challenge. Where proofs are still GPU-intensive and concentrated in networks of builders or provers, Ethereum moves the decentralization battleground from the verifier hardware to the prover market structure.
The protocol still works because one honest prover everywhere keeps the chain alive, but the security model has changed.
The third scenario is that Layer 1 certificate validation becomes a shared infrastructure. If consensus layer integration is strengthened and ePBS provides an extended validation window, the value proposition of Layer 2 will lean towards specialized VMs, ultra-low latency, and new configurable models rather than “scaling Ethereum” alone.
This pass requires that the ePBS be shipped to Gramsterdam on time.
| scenario | Must be true (technical prerequisite) | What can break/Main risks | Improvements (decentralization, gas limits, synchronization time) | L1 role results (execution throughput and verification cost) | L2 implications (new axis of differentiation) | “What to watch” signals |
|---|---|---|---|---|---|---|
| Proof-first verification becomes commonplace | Standards for Execution Witness + Guest programs will be integrated. zkVM/Guest API will be standardized. The CL certification verification path is stable. Proofs propagate reliably over P2P. Acceptable multiproof threshold semantics (e.g. 3-of-5) | Proof availability and delay become new dependencies. Validation bugs become dependent on consensus if/when It is relied upon. Client/certifier mismatch | home validator It can be proven without EL state. Synchronization time decreases (proof after finalization checkpoint); Easier to increase gas limits Verification cost is decoupled from execution complexity | L1 shifts to Running higher throughput and Fixed verification cost For many validators | L2 needs to justify itself beyond “L1 cannot scale”. special VMapp-specific execution, custom pricing models, privacy, and more. | Specification/test vector enhancements. Witness/guest portability between clients. Stable evidence gossip + failure handling. Benchmark curve (gas → validation cycle/time) |
| Centralization of provers becomes an issue | Proof generation is still GPU intensive. Integration of the proof market (builder/prover network). Limited “garage scale” proof. activation depends on a small set of sophisticated provers | “There are few who prove, and many who verify” concentrates power. Censorship/MEV dynamics intensify. Prover cessation creates survivability/finality stress. Geographic/regulatory concentration risk | Validators may still be able to verify cheaply, but decentralized shift: Easy to prove, difficult to prove. There is some gas-limited headroom, but it is limited by the economics of the prover. | L1 looks like this: execution scalable In theorybut is subject to the following practical limitations: Prover capabilities and market structure | L2 can lean to Base/Pre-confirmed Design, alternative proof systems, or latency guarantees – Potential for increased reliance on privileged actors | Prove cost trends (hardware requirements, time per block). Prover diversity index. Incentives for decentralized proofs. Failure mode training (What if proof is missing?) |
| L1 certificate verification becomes a shared infrastructure | CL integration is “hardened”. Proofs become widely produced/consumed. ePBS is shipped and provides a viable validation window. Interfaces enable reuse (e.g. EXECUTE style precompilation/native rollup hooks) | Cross-domain join risks: When the L1 certification infrastructure is under stress, rollup validation paths can also be affected. Increased complexity/attack surface | Shared infrastructure reduces duplicate certification efforts. Improves interoperability. More predictable verification costs. A clear path to higher L1 throughput without pricing validators | L1 evolves as follows. Proven execution + payment layer You can do that too Validate rollups natively | L2 pivots to Latency (preset)a special execution environment, and composable model Rather than “scale only” (e.g. fast proof/synchronous design) | ePBS/Gramsteldam progress. End-to-end pipeline demo (witness → proof → CL validation). Benchmark + Possible gas price revision. Deploying minimal viable proof distribution semantics and monitoring |
big picture
The integration maturity of a consensus specification indicates whether “optional proofs” will move from primarily TODOs to enhanced test vectors.
Standardization of ExecutionWitness and guest programs is the key to portability of stateless validation across clients. Benchmarks that map gas consumption to verification cycles and verification times will determine whether a ZK-friendly gas price reset is feasible.
Progress with ePBS and Gramsterdam will indicate whether the 6-9 second testing timeframe becomes a reality. The output of the breakout call reveals whether the working group has converged on an interface and minimum viable proof distribution semantics.
Ethereum has no plans to switch to proof-based verification anytime soon. EIP-8025 explicitly states, “You cannot upgrade based on this yet,” and the optional framing is intentional. As a result, this is a testable pathway rather than an imminent activation.
However, the fact that the Ethereum Foundation has shipped a 2026 implementation roadmap, scheduled breakout calls with project owners, and drafted an EIP with concrete peer-to-peer gossip mechanisms means that this work has moved from research relevance to delivery program.
This transformation will occur quietly as it will not include any dramatic changes to token economics or features for users. However, this is fundamental because it rewrites the relationship between execution complexity and verification cost.
If Ethereum can separate the two, layer 1 will no longer be a bottleneck pushing everything interesting to layer 2.
And once Layer 1 proof verification becomes a shared infrastructure, the entire Layer 2 ecosystem must answer the harder question: Are we building something that Layer 1 can’t do?