EIP-8025: Optional Proofs

Proposal for Inclusion in Hegota

Francesco (@frisitano) / Ignacio (@jsign) — EF zkEVM

ACDC, May 14, 2026

TLDR

tl;dr diagram

Motivation

  • Benefits
    • Sublinear, stateless validation — node hardware requirements decoupled from gas limit & state size
    • Make block validation accessible — preserving decentralisation even as gas limit and state grow
  • Why "optional"
    • Mitigates the risk of introducing novel cryptographic technology into the protocol
    • Collect data, optimise, and build operational experience before potentially making proofs mandatory later on
    • Proof verification is not load-bearing on consensus — it sits outside fork choice and the state-transition function

Why in Hegota?

  • ZK technology has sufficiently matured — proving stacks have been running in production on L2 rollups for years
  • First step toward mandatory proofs — better taken early, with time to iterate
  • Both CL and EL specs are largely settled
  • Both CL and EL have client implementations
  • Fully opt-in → low risk for inclusion: validators that don't enable either mode see no change in behaviour, bandwidth, or attestation duties

Consensus Layer

  • Two opt-in modes (a node MAY enable either or both)
    • Proof-generating: on receiving a valid block, request a proof and broadcast it on a dedicated gossipsub topic
    • Proof-verifying: consume gossiped proofs, verify statelessly
  • Specs: consensus-specs
  • Client implementations:
  • E2E devnet: Lighthouse ↔ Prysm interop with GPU prover complete

ProofEngine + P2P additions

New ProofEngine interface, modelled on the Engine API, + gossip type.

class ProofEngine(Protocol):
    def verify_execution_proof(self, proof: ExecutionProof) -> bool: ...
    def notify_new_payload(self, request: NewPayloadRequest) -> None: ...
    def notify_forkchoice_updated(self, head: Hash32, safe: Hash32, finalized: Hash32) -> None: ...
    def request_proofs(self, request: NewPayloadRequest, attrs: ProofAttributes) -> Root: ...

# Gossip — `execution_proof` topic
class SignedExecutionProof(Container):
    message: ExecutionProof
    validator_index: ValidatorIndex
    signature: BLSSignature

Req/resp: ExecutionProofsByRange · ExecutionProofsByRoot · ExecutionProofStatus

Discovery: new eproof ENR key advertises execution proof support.

Infrastructure

  • Infra readiness: Kurtosis + ethereum-package GPU support landed
  • Observability: proof latency, sizes, and gossip behaviour measurable on live networks — Grafana dashboards: zkboost · lighthouse
  • Block explorer: execution proofs displayed in Dora
  • Run it: ethereum-package example configs — dummy proofs · 1-GPU · 8-GPU

Execution Layer

  • Guest program:

    • Which program execution proofs attest to.
    • High-level parts: [input validation and transformation] + [STF] + [public inputs commitment].

  • StatelessInput

    • Input to the guest program.
    • Apart from execution payload and auxiliary fields, it contains cryptographically verifiable data required for execution
    • Standardised to:
      • reduce the complexity of running a prover (single witness format across guest programs)
      • provide a stable interface for testing

  • Specs and tests — fully spec'd in execution-specs Amsterdam fork

Join the discussion

Slide 1: Title

Slide 2: tl;dr

Slide 3: Motivation

Slide 4: Why in Hegota

Slide 5: Consensus Layer

Slide 6: ProofEngine + P2P

Slide 7: Infrastructure

Slide 8: Execution Layer

Slide 9: Join the discussion