Ethereum researcher ladislaus.eth published a walkthrough last week explaining how Ethereum plans to move from re-executing every transaction to verifying zero-knowledge proofs.
The post frames it as a “quiet but fundamental transformation,” and the framing is accurate. Not because the work is secret, but because its implications ripple across Ethereum’s entire architecture in ways that won’t be obvious until the pieces connect.
This isn’t Ethereum “adding ZK” as a feature. Ethereum is prototyping an alternative validation path in which some validators can attest to blocks by verifying compact execution proofs rather than re-running every transaction.
If it works, Ethereum’s layer-1 role shifts from “settlement and data availability for rollups” toward “high-throughput execution whose verification stays cheap enough for home validators.”
What’s actually being built
EIP-8025, titled “Optional Execution Proofs,” landed in draft form and specifies the mechanics.
Execution proofs are shared across the consensus-layer peer-to-peer network via a dedicated topic. Validators can operate in two new modes: proof-generating or stateless validation.
The proposal explicitly states that it “does not require a hardfork” and remains backward compatible, while nodes can still re-execute as they do today.
The Ethereum Foundation’s zkEVM team published a concrete roadmap for 2026 on Jan. 26, outlining six sub-themes: execution witness and guest program standardization, zkVM-guest API standardization, consensus layer integration, prover infrastructure, benchmarking and metrics, and security with formal verification.
The first L1-zkEVM breakout call is scheduled for Feb. 11 at 15:00 UTC.
The end-to-end pipeline works like this: an execution-layer client produces an ExecutionWitness, a self-contained package containing all data needed to validate a block without holding the full state.
A standardized guest program consumes that witness and validates the state transition. A zkVM executes this program, and a prover generates a proof of correct execution. The consensus layer client then verifies that proof instead of calling the execution layer client to re-execute.
The key dependency is ePBS (Enshrined Proposer-Builder Separation), targeted for the upcoming Glamsterdam hardfork. Without ePBS, the proving window is roughly one to two seconds, which is too tight for real-time proving. With ePBS providing block pipelining, the window extends to six to nine seconds.
The decentralization trade-off
If optional proofs and witness formats mature, more home validators can participate without maintaining full execution layer state.
Raising gas limits becomes politically and economically easier because validation cost decouples from execution complexity. Verification work no longer scales linearly with on-chain activity.
However, proofing carries its own risk of centralization. An Ethereum Research post from Feb. 2 reports that proving a full Ethereum block currently requires roughly 12 GPUs and takes an average of 7 seconds.
The author flags concerns about centralization and notes that limits remain difficult to predict. If proving remains GPU-heavy and concentrates in builder or prover networks, Ethereum may trade “everyone re-executes” for “few prove, many verify.”
The design aims to address this by introducing client diversity at the proving layer. EIP-8025’s working assumption is a three-of-five threshold, meaning an attester accepts a block’s execution as valid once it has verified three of five independent proofs from different execution-layer client implementations.
This preserves client diversity at the protocol level but doesn’t resolve the hardware access problem.
The most honest framing is that Ethereum is shifting the decentralization battleground. Today’s constraint is “can you afford to run an execution layer client?” Tomorrow’s might be “can you access GPU clusters or prover networks?”
The bet is that proof verification is easier to commoditize than state storage and re-execution, but the hardware question remains open.
L1 scaling unlock
Ethereum’s roadmap, last updated Feb. 5, lists “Statelessness” as a major upgrade theme: verifying blocks without storing large state.
Optional execution proofs and witnesses are the concrete mechanism that makes stateless validation practical. A stateless node requires only a consensus client and verifies proofs during payload processing.
Syncing reduces to downloading proofs for recent blocks since the last finalization checkpoint.
This matters for gas limits. Today, every increase in the gas limit makes running a node harder. If validators can verify proofs rather than re-executing, the verification cost no longer scales with the gas limit. Execution complexity and validation cost decouple.
The benchmarking and repricing workstream in the 2026 roadmap explicitly targets metrics that map gas consumed to proving cycles and proving time.
If those metrics stabilize, Ethereum gains a lever it hasn’t had before: the ability to raise throughput without proportionally increasing the cost of running a validator.
What this means for layer-2 blockchains
A recent post by Vitalik Buterin argues that layer-2 blockchains should differentiate beyond scaling and explicitly ties the value of a “native rollup precompile” to the need for enshrined zkEVM proofs that Ethereum already needs to scale layer-1.
The logic is straightforward: if all validators verify execution proofs, the same proofs can also be used by an EXECUTE precompile for native rollups. Layer-1 proving infrastructure becomes shared infrastructure.
This shifts the layer-2 value proposition. If layer-1 can scale to high throughput while keeping verification costs low, rollups can’t justify themselves on the basis of “Ethereum can’t handle the load.”
The new differentiation axes are specialized virtual machines, ultra-low latency, preconfirmations, and composability models like rollups that lean on fast-proving designs.
The scenario where layer-2s remain relevant is one in which roles are split between specialization and interoperability.
Layer-1 becomes the high-throughput, low-verification-cost execution and settlement layer. Layer-2s become feature labs, latency optimizers, and composability bridges.
However, that requires layer-2 teams to articulate new value propositions and for Ethereum to deliver on the proof-verification roadmap.
Three paths forward
There are three potential scenarios in the future.
The first scenario consists of proof-first validation becoming common. If optional proofs and witness formats mature and client implementations stabilize around standardized interfaces, more home validators can participate without running the full execution layer state.
Gas limits increase because the validation cost no longer aligns with execution complexity. This path depends on the ExecutionWitness and guest program standardization workstream converging on portable formats.
Scenario two is where prover centralization becomes the new choke point. If proving remains GPU-heavy and concentrated in builder or prover networks, then Ethereum shifts the decentralization battleground from validators’ hardware to prover market structure.
The protocol still functions, as one honest prover anywhere keeps the chain live, but the security model changes.
The third scenario is layer-1 proof verification becoming a shared infrastructure. If consensus layer integration hardens and ePBS delivers the extended proving window, then Layer 2s’ value proposition tilts toward specialized VMs, ultra-low latency, and new composability models rather than “scaling Ethereum” alone.
This path requires ePBS to ship on schedule for Glamsterdam.
| Scenario | What has to be true (technical preconditions) | What breaks / main risk | What improves (decentralization, gas limits, sync time) | L1 role outcome (execution throughput vs verification cost) | L2 implication (new differentiation axis) | “What to watch” signal |
|---|---|---|---|---|---|---|
| Proof-first validation becomes common | Execution Witness + guest program standards converge; zkVM/guest API standardizes; CL proof verification path is stable; proofs propagate reliably on P2P; acceptable multi-proof threshold semantics (eg 3-of-5) | Proof availability / latency becomes a new dependency; verification bugs become consensus sensitive if/when it’s relied on; mismatch across clients/provers | Home validators can attest without EL state; sync time drops (proofs since finalization checkpoint); gas-limit increases become easier because verification cost decouples from execution complexity | L1 shifts toward higher-throughput execution with constant-ish verification cost for many validators | L2s must justify themselves beyond “L1 can’t scale”: specialized VMs, app-specific execution, custom fee models, privacy, etc. | Spec/test-vector hardening; witness/guest portability across clients; stable proof gossip + failure handling; benchmark curves (gas → proving cycles/time) |
| Prover centralization becomes the choke point | Proof generation stays GPU-heavy; proving market consolidates (builders / prover networks); limited “garage-scale” proving; liveness relies on a small set of sophisticated provers | “Few prove, many verify” concentrates power; censorship / MEV dynamics intensify; prover outages create liveness/finality stress; geographic / regulatory concentration risk | Validators may still verify cheaply, but decentralized shifts: easier attesting, harder proving; some gas-limit headroom, but constrained by prover economics | L1 becomes execution scalable in theory, but practically bounded by prover capacity and market structure | L2s may lean into based / pre- confirmed designs, alternative proving systems, or latency guarantees—potentially increasing dependence on privileged actors | Proving cost trends (hardware requirements, time per block); prover diversity metrics; incentives for distributed proving; failure-mode drills (what happens when proofs are missing?) |
| L1 proof verification becomes shared infrastructure | CL integration “hardens”; proofs become widely produced / consumed; ePBS ships and provides a workable proving window; interfaces allow reuse (eg EXECUTE-style precompile / native rollup hooks) | Cross-domain coupling risk: if L1 proving infra is stressed, rollup verification paths could also suffer; complexity / attack surface expands | Shared infra reduces duplicated proving effort; improves interoperability; more predictable verification costs; clearer path to higher L1 throughput without pricing out validators | L1 evolves into a proof-verified execution + settlement layer that can also verify rollups natively | L2s pivot to latency (preconfs), specialized execution environments, and composable models (eg fast-proving / synchronous-ish designs) rather than “scale-only” | ePBS / Glamsterdam progress; end-to-end pipeline demos (witness → proof → CL verify); benchmarks + possible gas repricing; rollout of minimum viable proof distribution semantics and monitoring |
The bigger picture
Consensus-specs integration maturity will signal whether “optional proofs” move from mostly TODOs to hardened test vectors.
Standardizing the ExecutionWitness and guest program is the keystone for stateless validation portability across clients. Benchmarks that map gas consumed to proving cycles and proving time will determine whether gas repricing for ZK-friendliness is feasible.
ePBS and Glamsterdam progress will indicate whether the six-to-nine-second proving window becomes a reality. Breakout call outputs will reveal whether the working groups converge on interfaces and minimum viable proof distribution semantics.
Ethereum is not switching to proof-based validation soon. EIP-8025 explicitly states it “cannot base upgrades on it yet,” and the optional framing is intentional. As a result, this is a testable pathway rather than an imminent activation.
Yet, the fact that the Ethereum Foundation shipped a 2026 implementation roadmap, scheduled a breakout call with project owners, and drafted an EIP with concrete peer-to-peer gossip mechanics means this work has moved from research plausibility to a delivery program.
The transformation is quiet because it doesn’t involve dramatic token economics changes or user-facing features. But it’s fundamental because it rewrites the relationship between execution complexity and validation cost.
If Ethereum can decouple the two, layer-1 will no longer be the bottleneck that forces everything interesting onto layer-2.
And if layer-1 proof verification becomes shared infrastructure, the entire layer-2 ecosystem needs to answer a harder question: what are you building that layer-1 can’t?