Add POST /eth/v1/beacon/execution_payload_envelope#605
Closed
pk910 wants to merge 1 commit into
Closed
Conversation
pk910
force-pushed
the
pk910/publish-execution-payload-envelope
branch
from
37d0a89 to
bd5d148
Compare
Adds the missing reveal-publish counterpart to the bid POST added in ethereum#552. External builders that build the `ExecutionPayload` out-of-process need a beacon-API endpoint to publish their signed envelope; today every Gloas CL invents its own path (or none) for this. The request body is a new `Gloas.SignedExecutionPayloadEnvelopeContents` wrapping the signed envelope together with the `blobs` and `kzg_proofs` arrays the beacon node uses to derive and broadcast the `DataColumnSidecar`s for the revealed payload. External builders MUST supply the full arrays. The arrays MAY be empty only when the same beacon node built the payload itself and can reconstruct them from its local self-build cache; in that case the node MUST reject with 400 if the cache miss. Non-empty arrays MUST match the committed `blob_kzg_commitments` in length and order, and the node MUST verify the blobs against the commitments before broadcasting. Issue ethereum#575 raised an envelope-construction endpoint for builders to sign against. That issue was closed without conclusion; the publish side it implied remained unspecified. This PR addresses that publish gap. (Construction is not needed: the current envelope is fully derivable client-side from the Engine API output plus the standard beacon-block lookup.) Prysm already ships this endpoint with this wrapper struct (`api/server/structs/block.go: SignedExecutionPayloadEnvelopeContents`) on its glamsterdam-devnet-3 branch, and ethpandaops/buildoor already calls it. Goal of this PR is to converge the surface before more CLs implement it divergently.
Contributor
|
I believe its already been specified here: https://github.com/ethereum/beacon-APIs/pull/580/changes#diff-962ea34dc6ec0e65d4e1d6c8682e97c547e6e0d2f1168925210ff7ee47ef6ce0R109 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
PR #552 standardized the bid POST and envelope-by-block GET but left the envelope publish path unspecified. Issue #575 raised an envelope construction endpoint for builders to sign against; it was closed without merging, and the publish path it implied was never spec'd.
Result: every Gloas CL that wants to support external builders today either ships its own path under its own conventions (Prysm exposes
POST /eth/v1/beacon/execution_payload_envelopewith a wrapped body; Lighthouse exposes the same path but takes only a bare envelope and ignores externally-supplied blobs; Lodestar accepts the same path but only for the self-build cached case) or does not expose any REST publish path at all (Grandine, Nimbus, Teku). External builder tooling - e.g.ethpandaops/buildoor- already targets the Prysm-style endpoint.This PR specifies that endpoint so the surface converges before more clients ship divergent variants.
Changes
New endpoint
POST /eth/v1/beacon/execution_payload_envelopeEth-Consensus-Version: gloas(required).application/json(Gloas.SignedExecutionPayloadEnvelopeContents)or
application/octet-stream(SSZ).publish and bid publish conventions.
On 20x the beacon node has gossip-validated the envelope and broadcast it on the
execution_payloadtopic; it is also expected to integrate the envelope viaon_execution_payload_envelopethough it MAY broadcast before integration completes.New type
Gloas.SignedExecutionPayloadEnvelopeContentswraps:signed_execution_payload_envelope: SignedExecutionPayloadEnvelopeblobs: List[Blob, MAX_BLOB_COMMITMENTS_PER_BLOCK]kzg_proofs: List[KZGProof, MAX_BLOB_COMMITMENTS_PER_BLOCK]The wrapper name and field names mirror Prysm's existing
SignedExecutionPayloadEnvelopeContents.Blob array semantics
The envelope itself, gossiped on the
execution_payloadtopic, does not contain blobs - blobs ride onDataColumnSidecargossip, which the publishing beacon node derives from these arrays. So this endpoint is also the only path the beacon node has to obtain blobs from an external builder.blobsandkzg_proofsarrays. This is the primary use case.blobsandkzg_proofsarrays; the beacon node MUST reconstruct from its local self-build cache and MUST reject with 400 if it cannot.When non-empty,
blobs.lengthandkzg_proofs.lengthMUST equalExecutionPayloadBid.blob_kzg_commitments.length, the entries MUST be in the same order, and the beacon node MUST verify them against the committed commitments before broadcasting.kzg_proofsare cell proofs, matchingcompute_cells_and_kzg_proofs(the same shape used byDataColumnSidecar.kzg_proofs).Related
/builder. If that lands, this PR's endpoint can move alongside it as a follow-up.