Define recursive EIP-8025 execution proof guest by frisitano · Pull Request #5534 · ethereum/consensus-specs

frisitano · 2026-08-11T18:03:35Z

Summary

introduce recursive execution-proof public inputs with immutable origin and advancing head checkpoints
define the guest private input, authenticated beacon lineage, recursive verification, and stateless execution transition
simplify the Proof Engine to proof verification and generation, removing payload and fork-choice notifications
keep execution-proof propagation gossip-only while retaining eproof peering discovery

Design notes

proofs are produced for full beacon blocks; intervening produced empty blocks are authenticated through the bid lineage, while missed slots require no witness
guest verification of bid and envelope BLS signatures remains a TODO; consensus clients retain the normal Gloas signature and state-dependent checks

Validation

make lint
make test fork=eip8025 (1366 passed, 6432 skipped)

jtraglia · 2026-08-11T22:34:11Z

+from the arguments. A typed implementation invokes
+`verify_stateless_new_payload` directly. A serialized zkVM implementation MAY
+invoke `run_stateless_guest`, decodes its output, and MUST check that the
+returned `new_payload_request_root` equals `compute_new_payload_request_root`
+for the constructed input before exposing the result. In both cases the logical


Other than the mismatched tense here, something about this sentence is a bit awkward to read. I would suggest splitting it up into two+ sentences as it's pretty long.

Suggested change

from the arguments. A typed implementation invokes

`verify_stateless_new_payload` directly. A serialized zkVM implementation MAY

invoke `run_stateless_guest`, decodes its output, and MUST check that the

returned `new_payload_request_root` equals `compute_new_payload_request_root`

for the constructed input before exposing the result. In both cases the logical

from the arguments. A typed implementation invokes

`verify_stateless_new_payload` directly. A serialized zkVM implementation MAY

invoke `run_stateless_guest`, decode its output, and MUST check that the

returned `new_payload_request_root` equals `compute_new_payload_request_root`

for the constructed input before exposing the result. In both cases the logical

Yep, agreed, I expect much of the prose will change in this PR. I'll mark the PR as ready for review when I have things in a better state.

Yep, just did a quick skim & wanted to mention this 😅 I'll do an in-depth review when its marked as ready.

That's appreciated. I just don't want you wasting your time reviewing trash 🤣

jtraglia · 2026-08-11T22:43:41Z

 - _[IGNORE]_ The proof has not already been processed -- i.e.
  `hash_tree_root(proof)` has not been seen before.
- _[IGNORE]_ The proof's corresponding new payload request (identified by
-  `proof.public_input.new_payload_request_root`) has been seen (via gossip or
-  non-gossip sources) (a client MAY queue proofs for processing once the new
-  payload request is retrieved).
+- _[IGNORE]_ The beacon block identified by
+  `proof.public_input.head.beacon_block_root` and its accepted
+  `SignedExecutionPayloadEnvelope` have been seen (via gossip or non-gossip
+  sources). A client MAY queue the proof until both are available.


Since Gloas gossip validation specs are now executable functions, it might be worth converting these to executable functions now too. Not sure if you'd want to handle this here or in a separate PR. Since it's just a single new gossip topic, I think it would be alright to do it in this PR. And no need to worry about tests.

Very nice addition to the specs! Yep, let's get it done in this PR

…nsensus-specs-pr-5534-recursive-execution-proof # Conflicts: # pysetup/spec_builders/eip8025.py # tests/core/pyspec/eth_consensus_specs/test/helpers/gossip.py

This PR simplifies the EIP-8025 consensus specifications by defining a more constrained baseline covering execution-proof types, gossip, verification, storage, and optional prover behaviour. Most notably, we remove the network req/resp protocol and introduce an `ExecutionProofEnvelope` type that uses the `beacon_block_root` to associate an execution proof with a block. Furthermore, we migrate to the updated gossip validation defintion pattern for execution proofs and introduce proof verification into the gossip validation pipeline to address concerns raised in #5502. This PR assumes that execution proofs are recursive - i.e. a proof for block n also attests to the validity of the chain prefix [weak-subjectivity..n) - the recursive guest design is drafted in #5534.

jihoonsong

I skimmed the p2p change. I can review other parts later when I have fresh brain.

Additionally, following this issue, I think we would need to detach tests from this PR to get it merged. We'd still need to find out what would be the best way going forward, but the tests could live in a forked repo, for instance.

jihoonsong · 2026-09-11T16:47:40Z

+
+    # [REJECT] The proof data is non-empty and within the size limit
+    if len(proof.proof_data) == 0:
+        raise GossipReject("execution proof data is empty")


Can we have each of these have comment? See this as a reference.

jihoonsong · 2026-09-11T16:49:20Z

+        raise GossipIgnore("verified proof already known for this head and proof type")
+
+    # [IGNORE] This is the prover's first valid or invalid proof for this key
+    prover_key = (head_root, proof.proof_type, validator_index)


Can we put Seen check at the beginning?

jihoonsong · 2026-09-11T16:51:38Z

+        raise GossipReject("execution proof's head block failed validation")
+
+    # [IGNORE] No verified proof is known for this head and proof type
+    if proof.proof_type in store.execution_proofs.get(head_root, {}):


I left this in another PR but leaving it also here to put it with other comments; execution_proofs could be DefaultDict.

specs: define recursive execution proof guest

2b43c7d

github-actions Bot added testing CI, actions, tests, testing infra eip8025 Optional Execution Proofs labels Aug 11, 2026

jtraglia reviewed Aug 11, 2026

View reviewed changes

frisitano and others added 9 commits August 12, 2026 15:31

Merge branch 'master' into frisitano/recursive-proofs-eip8025

8dc1727

specs: execute EIP-8025 gossip validation

9d9aa4c

specs: separate execution proof gossip and processing

178290d

specs: authenticate recursive execution proof inputs

277d11c

specs: keep proof type support in gossip

9388c88

specs: simplify chain config root naming

0b74a65

specs: simplify execution checkpoint naming

dbbcb0f

specs: delegate chain config binding to stateless guest

61796dd

specs: colocate guest public input

56abf67

jsign mentioned this pull request Aug 12, 2026

L1-zkEVM breakout #07, August 12, 2026 ethereum/pm#2184

Closed

1 task

frisitano added 8 commits August 13, 2026 03:22

specs: derive execution bid gindex from schema

939e250

specs: use configured chain root for proof processing

1613477

specs: group execution proofs by block root

2008790

specs: define recursive EIP-8025 execution proofs

2a05c0b

specs: add EIP-8025 feature profiles

3eac2da

specs: simplify EIP-8025 proof engine

1477816

specs: simplify EIP-8025 proof generation

e3d5530

Merge remote-tracking branch 'upstream/master' into worker/improve-co…

fabf8dc

…nsensus-specs-pr-5534-recursive-execution-proof # Conflicts: # pysetup/spec_builders/eip8025.py # tests/core/pyspec/eth_consensus_specs/test/helpers/gossip.py

frisitano mentioned this pull request Aug 25, 2026

Simplify execution proof handling #5566

Merged

4 tasks

frisitano mentioned this pull request Sep 11, 2026

Add weak-subjectivity execution proof sync #5332

Closed

jihoonsong reviewed Sep 11, 2026

View reviewed changes

Navigation Menu

Uh oh!

Define recursive EIP-8025 execution proof guest - #5534

Define recursive EIP-8025 execution proof guest#5534
frisitano wants to merge 18 commits into
ethereum:masterfrom
frisitano:frisitano/recursive-proofs-eip8025

frisitano commented Aug 11, 2026

Uh oh!

jtraglia Aug 11, 2026

Uh oh!

frisitano Aug 12, 2026

Uh oh!

jtraglia Aug 12, 2026

Uh oh!

frisitano Aug 12, 2026

Uh oh!

jtraglia Aug 11, 2026

Uh oh!

frisitano Aug 12, 2026

Uh oh!

jihoonsong left a comment

Uh oh!

jihoonsong Sep 11, 2026

Uh oh!

jihoonsong Sep 11, 2026

Uh oh!

jihoonsong Sep 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

frisitano commented Aug 11, 2026

Summary

Design notes

Validation

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jihoonsong left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants