Skip to content

Define recursive EIP-8025 execution proof guest - #5534

Draft
frisitano wants to merge 13 commits into
ethereum:masterfrom
frisitano:frisitano/recursive-proofs-eip8025
Draft

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

Conversation

@frisitano

Copy link
Copy Markdown
Contributor

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)

@github-actions github-actions Bot added testing CI, actions, tests, testing infra eip8025 Optional Execution Proofs labels Aug 11, 2026
Comment on lines +140 to +144
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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +122 to +64
- _[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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

eip8025 Optional Execution Proofs testing CI, actions, tests, testing infra

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants