Ethereum wants home validators to verify proofs but a 12 GPU reality raises a new threat

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.”