EIP-8440 proposes recursive proofs for Ethereum execution sync

The Ethereum Magicians discussion states the goal plainly: standardize execution chain proofs so execution-layer chain sync can run in constant time.

That targets the genuinely expensive part of syncing from a weak subjectivity checkpoint. The Ethereum Magicians discussion says EIP-8440 would replace re-execution of roughly 1.1 × 10^5 payloads and 21 GB of payload data with a single verification. At roughly 110,000 payloads and 21 GB (where GB means 10^9 bytes), that works out to about 191 KB of payload data per payload on average.

Its structure is recursive. Each proof verifies the proof covering the previous full payload, then proves one additional payload. That creates a chain of proofs rather than requiring a verifier to replay the full execution history from the checkpoint.

The public input carries four commitments: the origin block root, the head block root, the chain ID, and the stateless input schema. Only the two block roots are gossiped. Consecutive proofs are bound through Ethereum’s consensus state, connecting the execution proof sequence to the consensus-layer record.

The proposal’s mechanism verifies a recursive proof chain whose endpoints are committed in the public input; the alternative described in the background is re-executing the payloads themselves. For light clients and cross-chain verification, the practical consequence is a smaller verification task tied to specified roots rather than processing the full payload history.

The implementation references existing Ethereum interfaces. The proof guest reuses the EIP-7732 payload envelope handler with the execution engine, while EIP-8440 builds on EIP-8025. The consensus-layer specification is tracked in ethereum/consensus-specs#5725, giving client and protocol implementers a separate specification target alongside the EIP text.

The pull request was marked ready for review and draft on October 9. It records approvals from “suckyourmomonoktagon” and “Deejae69,” with further approvals on October 10.

The practical exposure, if the draft ever advances, sits in software that must verify Ethereum execution history without replaying every payload: light clients, cross-chain verification systems, and implementations following the consensus-layer specification. According to the Ethereum Magicians discussion, the benefit covers roughly 110,000 payloads and 21 GB of payload data collapsing into one verification.