Summary

EIP-8025 (Optional Execution Proofs) introduces a path for Ethereum attesters to verify blocks via ZK proof verification rather than EL re-execution. Attesters that adopt this mode — zkAttesters — verify a 3-of-5 threshold of independent zkEVM proofs without running a full EL client. This is the first step toward eliminating mandatory re-execution from Ethereum consensus, dramatically reducing hardware requirements for validators and enabling higher gas limits without centralizing validation.

The Paradigm Shift

Today, every Ethereum validator re-executes every transaction in every block independently. This scales linearly with the gas limit: doubling the gas limit doubles the per-validator compute requirement.

ZK proofs enable asymmetric verification: one party (a prover) does the computation and generates a proof; many parties verify the proof at constant cost regardless of what was proven. Under EIP-8025, provers generate zkEVM proofs; validators verify rather than re-execute.

Pipeline

EL client → ExecutionWitness → Standardized guest program → zkVM → Proof
                                                                      ↓
CL client (zkAttester) verifies proof instead of calling EL
  1. ExecutionWitness: self-contained package of all state needed to validate a block without holding full state
  2. Guest program: standardized computation that validates the state transition given the witness
  3. zkVM: hardware/software that generates a proof of correct execution (ZisK, RISC Zero, openVM, etc.)
  4. Threshold verification: CL client accepts block execution if ≥3 of 5 independent proofs from different EL implementations verify correctly

Key Properties

3-of-5 Multi-Client Proof Threshold

  • Proofs come from 5 different EL client implementations (Geth, Nethermind, Besu, Erigon, Reth)
  • Attester accepts if ≥3 verify correctly
  • Preserves client diversity as a structural protocol feature, not just a cultural norm
  • Prevents any single client implementation bug from halting consensus

zkAttesters Don’t Need EL State

  • No need to sync the full execution chain
  • Syncing = downloading proofs for recent blocks since the last checkpoint
  • Sync time: minutes instead of hours
  • Hardware requirements: dramatically lower (no state storage or re-execution)

Optional, Not Mandatory (Initially)

  • Validators can still re-execute as today
  • Phased adoption: early zkAttesters coexist with traditional validators
  • No hard fork required for deployment
  • Gradual migration as prover infrastructure matures

Dependency on ePBS

Without ePBS (EIP-7732), the proving window is ~1–2 seconds — too tight for real-time ZK proving. With ePBS (Glamsterdam H1 2026), the window extends to 6–9 seconds (block pipelining separates consensus from execution), making real-time proving feasible.

Who Benefits

ActorBenefit
Solo stakers / home validatorsRun as zkAttesters without a full EL; sync in minutes; lower hardware costs
EL client teamsBecome proving targets; client diversity structurally enforced
L2 / rollup teamsSame zkEVM proving infrastructure shared for native rollup proofs
UsersHigher gas limits without centralizing validation; more decentralized network

Prover Economics (Concern)

  • 1-of-N liveness: one honest prover anywhere keeps the chain live
  • Simplest model: block builders also prove (familiar with state access patterns)
  • Risk: concentrates proving alongside block building — already centralized
  • Open question: distributed proving networks, garage-scale hardware feasibility

Status (Feb 2026)

  • EIP-8025 landed in consensus-specs features branch
  • L1-zkEVM roadmap announced Feb 2026
  • Six sub-themes: witness/guest standardization, zkVM-guest API, CL integration, prover infrastructure, benchmarking, formal verification
  • First breakout call: Feb 11, 2026

Hegotá Inclusion Proposal (May 14, 2026 — ladislaus0x)

The L1-zkEVM team proposed EIP-8025 for inclusion in Hegotá at ACDC on May 14, 2026 as a non-headliner. Argumentation:

  • Optional ≠ consensus-critical: attestation duties remain driven by EL re-execution; proofs are a supplementary check. A zkAttester that doesn’t receive a valid proof in time falls back to local re-execution. Proving is altruistic during this phase — late/missing proofs only cost the prover timeliness rewards.
  • Validators who don’t opt in see zero change — no behavior, bandwidth, or attestation-duty differences. Inclusion is low-risk.
  • Both CL and EL specs are largely settled; client implementations exist.
  • Two opt-in roles (refined naming from prior post):
    • Provers generate proofs and gossip them (proof-generating mode).
    • zkAttesters = stateless attesters in proof-verifying mode.
  • The EVM is not modified. EIP-8025 introduces only one EL-side artifact: the guest program (block-execution logic that runs inside the zkVM and is the computation being proven).
  • Proposing now anchors the work inside the protocol upgrade process — gives client teams, zkVM teams, tooling maintainers, and spec writers the mandate to allocate sustained resources.

Two companion EIPs

These may land in Hegotá or later — EIP-8025 works without them but is cleaner with them:

EIPPurpose
EIP-7709 (BLOCKHASH ↔ EIP-2935)Last opcode that implicitly assumes statefulness; reroute through the system contract for self-contained witnesses
EIP-8200 (EVMification)Replace a few low-usage precompiles with EVM bytecode → cuts worst-case proving time (avg-case single-digit-second proving is meaningless if attackers can craft minute-long blocks)

Parallel work

  • Multi-client devnet running EIP-8025 on Lighthouse + Prysm spinning up.
  • EF commissioning an on-prem GPU prover cluster for benchmarking.
  • Follow-up devnets will adapt on top of Glamsterdam features once stable: BALs (let provers fetch state and parallelize) and ePBS (extends the proving window between block availability and attestation deadline).

Engagement venues

  • Magicians thread for EIP-8025
  • Monthly L1-zkEVM breakout call (protocol calendar)
  • Eth R&D Discord: #l1-zkevm-protocol (protocol) + #l1-zkevm (zkVM-specific)
  • zkevm.ethereum.foundation

Key Sources

  • Ethereum’s Next Big Shift: From Re-Executing Every Transaction to Verifying ZK Proofs (@ladislaus0x, Feb 2026) — architecture overview; EIP-8025 summary; 3-of-5 threshold; stakeholder breakdown; ePBS dependency