Conversation
| - Validator | ||
| - ValidatorRequiredApi | ||
| parameters: | ||
| - name: slot |
There was a problem hiding this comment.
while implementing this, I noticed the slot alone is not definitive enough (eg. in case of forks), we should consider also passing the beacon_block_root here
There was a problem hiding this comment.
hm, what do you think about making it optional to pass beacon_block_root like in 0c45859? pretty sure the VC already computes the block's tree hash root during signing, so passing it here should be straightforward
There was a problem hiding this comment.
Yes, we do already compute the block root on the vc side. I am not a big fan of optional parameters, so I'd rather have it as required or remove it if it's not needed, so far it makes our implementation simpler, maybe get more feedback from others who already implemented the apis
| description: "Slot for which the execution payload envelope is requested." | ||
| schema: | ||
| $ref: "../../beacon-node-oapi.yaml#/components/schemas/Uint64" | ||
| - name: builder_index |
There was a problem hiding this comment.
Will this endpoint be used for all builders outside of self building? I think the pipeline might endup being very different which makes me question if we would ever be caching more than just the current slot's payload envelope. terence asked this internally and I didn't have a good answer.
There was a problem hiding this comment.
this endpoint is only meant for self-building if you are the proposer or the "act as a builder" mode where you build the payload for another proposer
builders that produce payloads outside of the beacon node would get their own endpoint which would be under the /builder namespace (at least that's how I am thinking about it right now)
it should be sufficient to only cache the current slot as you consume the cache within the same slot, maybe if that's the case my comment here #580 (comment) is also not needed but I feel like the block root is useful to specify, not just the slot
There was a problem hiding this comment.
After thinking about it more, maybe we keep the current apis under /validator to be only used by proposers, which means we can remove builder_index here as it's only used for self-building
There was a problem hiding this comment.
makes sense, removed builder_index in 0c45859
| operationId: getExecutionPayloadEnvelope | ||
| summary: Get execution payload envelope | ||
| description: | | ||
| Retrieves execution payload envelope for a given slot and builder, which can then be signed by a validator. The envelope contains the full |
There was a problem hiding this comment.
can we specify this is not used for general payload envelope returns and they should expect a 404 if it's not for the current proposer? i.e. we aren't going to go get from execution for older slots
3 participants
Introduces the block production and execution payload envelope endpoints for post-Gloas (ePBS) forks. These were separated out from #552 to be discussed and reviewed independently. Prior discussion in PR 552 thread and shane-moore/beacon-APIs#2 as well.
New endpoints:
GET /eth/v4/validator/blocks/{slot}— Post-Gloas block production endpoint (produceBlockV4).Supports an
include_payloadquery parameter that controls whether the execution payload envelope and blobs are returned inline (stateless multi-BN operation) or cached by the beacon node for separate retrieval (stateful single-BN operation).GET /eth/v1/validator/execution_payload_envelope/{slot}/{builder_index}— Fetch a cached execution payload envelope for signing and publishing (used in stateful mode or by builders).POST /eth/v1/beacon/execution_payload_envelope— Publish a signed execution payload envelope to the network.Open Questions
BlindedExecutionPayloadEnvelope(omitting transactions) should replace the full envelope in the stateful POST flow for both proposer self-building and builder envelope submission, since the beacon node already has the data cached (see discussion)