Builder api to construct envelope from their execution payload

[nflaig]

I think this API assumes that the execution payload and blobs are built locally. This might not be the case for a builder who builds the block using custom block building software. The builder will have the execution payload, blobs bundle and execution requests ready with them, they will require a beacon-api which will construct the ExecutionPayloadEnvelope for them to sign.

It would be desirable to also be able to pass in the bid, beacon block, execution payload, blobs bundle, execution requests to get the ExecutionPayloadEnvelope corresponding to the bid sent by the builder.

Originally posted by @bharath-123 in #552 (comment)

[nflaig]

we should probably add builder specific endpoints to /builder namespace instead of /beacon or /validator, we used this namespace before so that builders could get expected withdrawals /eth/v1/builder/states/{state_id}/expected_withdrawals but this endpoint as been removed in favor of getting this information from payload attributes event

[nflaig]

Raised by @bharath-123

Do we have to send the blobs bundle? The KZG commitments are anyways included in the bid and we don't have to add it in the envelope, maybe we can skip it.

might be needed if builders want this to be stateless? not sure if that's a concern for them

[bharath-123]

Raised by @bharath-123

Do we have to send the blobs bundle? The KZG commitments are anyways included in the bid and we don't have to add it in the envelope, maybe we can skip it.

might be needed if builders want this to be stateless? not sure if that's a concern for them

I don't think there is any blob related aspects in the ExecutionPayloadEnvelope, so maybe we don't have to send blobs bundles? I am not sure how the blobs bundles will be used in generating the ExecutionPayloadEnvelope

Also how does the beacon api return the SignedExecutionPayloadEnvelope, I assume the API impl will call the validator client to fetch the signature of the envelope. Because I think we should probably return an ExecutionPayloadEnvelope and let the builder handle the signing of it?

[bharath-123]

we should probably add builder specific endpoints to /builder namespace instead of /beacon or /validator, we used this namespace before so that builders could get expected withdrawals /eth/v1/builder/states/{state_id}/expected_withdrawals but this endpoint as been removed in favor of getting this information from payload attributes event

I agree, builders can just use payload attributes to get the withdrawals IMO

[nflaig]

Also how does the beacon api return the SignedExecutionPayloadEnvelope, I assume the API impl will call the validator client to fetch the signature of the envelope. Because I think we should probably return an ExecutionPayloadEnvelope and let the builder handle the signing of it?

the beacon node doesn't return a signed envelope, the builder needs to sign it after getting the ExecutionPayloadEnvelope from the endpoint

I agree, builders can just use payload attributes to get the withdrawals IMO

they already do, the other withdrawals endpoint doesn't exist anymore, was just an example of a /builder endpoint we had before

[nflaig]

I don't think there is any blob related aspects in the ExecutionPayloadEnvelope, so maybe we don't have to send blobs bundles? I am not sure how the blobs bundles will be used in generating the ExecutionPayloadEnvelope

yes, it's not required to send them for the purpose of constructing the ExecutionPayloadEnvelope

[nflaig]

this is no longer required due to ethereum/consensus-specs#5094, builders should be able to easily construct the ExecutionPayloadEnvelope themselves as it is no longer required to do a state transition to compute the state_root