Add specs for EIP-8025 (Optional Execution Proofs) #4591
Conversation
|
(This still requires beacon-chain and p2p-interface changes) |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
| Verify an execution proof against a payload header using zkEVM verification. | ||
| """ | ||
|
|
||
| # Note: proof.beacon_root verification would be done at a higher level |
There was a problem hiding this comment.
this is not checked anywhere and is mostly useful for mapping the pending beacon block to a payload
| """ | ||
| # `retrieve_execution_proofs` is implementation and context dependent | ||
| # It returns all the execution proofs for the given payload block hash | ||
| execution_proofs = retrieve_execution_proofs(block_hash) |
There was a problem hiding this comment.
copied this from the blobs file -- proofs will appear from the ether. Note that zkevm.md has proof generation logic, though its not hooked up to generate_execution_proof
| # Verify all execution proofs | ||
| for proof in execution_proofs: | ||
| # Get EL program from proof system ID | ||
| # TODO: The proof system ID is really an ID for a proof system and EL combination |
There was a problem hiding this comment.
TODO is noting that proofID has a 1-1 mapping with subnet which is really a 1-1 mapping between EL and zkEVM combinations. Not just the proof system being used
|
|
||
| ```python | ||
| def process_execution_payload( | ||
| state: BeaconState, body: BeaconBlockBody, execution_engine: ExecutionEngine, stateless_validation: bool = False |
There was a problem hiding this comment.
main change is additional stateless_validation parameter. When set to false, nothing changes from the fork it was built upon
There was a problem hiding this comment.
This file is more akin to an api file than a naive impl. This is different to polynomial-commitments whereby it actually has a naive impl of proof generation and creation. Its not really possible in this case, but we can mock the behaviour
This comment was marked as spam.
This comment was marked as spam.
|
There should be a note on the fact that the specs uses one EL program but implementations should/can use multiple EL programs for their K out of N assumption |
|
The difference between an ExecutionProof and a ZkProof is a bit confusing; In the code an ExecutionProof is just a ZKProof but with added context about the CL |
kevaundray
changed the title
jtraglia
left a comment
jtraglia
left a comment
There was a problem hiding this comment.
Looks good enough for an initial spec to me! Thanks @kevaundray, exciting stuff. I expect there will be follow-up PRs with improvements/integrations. But no rush on that.
jtraglia
changed the title
2 participants
This PR adds the scaffolding needed to have zk stateless clients. Most of these changes have been integrated here: sigp/lighthouse#7755
Notes
TODO