Conversation
| description: | | ||
| Retrieves execution proofs known by the node. | ||
| parameters: | ||
| - name: new_payload_request_root |
There was a problem hiding this comment.
Why new_payload_request_root versus beacon root?
There was a problem hiding this comment.
Good question. I had used new_payload_request_root as that had been the theme of this batch of PR's. Now I take a moment to think, I see value in using the beacon root here and also for p2p req/resp in the CL specs. What is your opinion?
There was a problem hiding this comment.
I lean more towards beacon root since this is used in a lot of other places like DataColumnsByRoot
There was a problem hiding this comment.
I agree, I will update it. Does it also make sense to migrate to beacon root for p2p req/resp?
There was a problem hiding this comment.
Checking the flow, I think having it in p2p requires/resp also makes sense in terms of simplicity -- my thinking was that the CL will need to have a map from beacon root to new_payload_request_root or whatever the public input is for the proof anyways
There was a problem hiding this comment.
Agreed. I think the beacon root is generally more available. For example, in the context of performing sync we are more likely to have the beacon root available than the new_payload_request_root.
apis/prover/execution_proofs.yaml
Outdated
| schema: | ||
| type: array | ||
| items: | ||
| $ref: '../../beacon-node-oapi.yaml#/components/schemas/EIP8025.ExecutionProof' |
There was a problem hiding this comment.
Just leaving a comment here if we need to add ProofGenId for proper connection from the request? (mentioned here)
| @@ -0,0 +1,30 @@ | |||
| post: | |||
| operationId: submitExecutionProofs | |||
There was a problem hiding this comment.
Maybe basic question from my side: should this have the same name?
There was a problem hiding this comment.
They are in different contexts, so it's fine to have different names imo. Above, we have the HTTP endpoint that the prover receives requested proofs from the proof engine. Linked is the p2p req/res api. I think it's reasonable to have different naming.
3 participants
Implements the beacon and prover API's for EIP-8025.
CL PR: ethereum/consensus-specs#4828