add flag to include payload in produceBlockV4

[shane-moore]

Resolves comment in the epbs standardized PR by adding a flag to produceBlockV4 to respond with the payload envelope, blobs, and kzg_commitments alongside the CL block in the self-building case as to continue supporting multi beacon node setups

[nflaig]

in ethereum#519 the conclusion was to leave it up to clients to support blinding the response, eg. in Lodestar we have a flag --blindedLocal and corresponding query param to tell the bn to not return full block contents but rather cache them which makes the block production stateful but there is no drawback in a 1:1 setup

I think it would be good to standardize this kind of query parameter in produceBlockV4 and leave it up to clients whether the wanna implement it or not, ie. if a client doesn't wanna implement it they can always set the query param to false

[nflaig]

something to consider, if we return both the beacon block and execution payload here, do we also want an api to publish both, or are we fine with having 2 separate publish apis

[Bez625]

Speaking on behalf of Vouch, we find this approach preferable to maintain the statelessness of the REST API and allowing us to leverage multiple clients in block production.

something to consider, if we return both the beacon block and execution payload here, do we also want an api to publish both, or are we fine with having 2 separate publish apis

This would be ideal for the stateless flow.

[nflaig]

This would be ideal for the stateless flow.

does it matter for that to have a single publish api call or 2 separate ones? but I can see that it's simpler for beacon node to process the data since you need to process the beacon block before you can process the execution payload to which the beacon block committed

[Bez625]

does it matter for that to have a single publish api call or 2 separate ones? but I can see that it's simpler for beacon node to process the data since you need to process the beacon block before you can process the execution payload to which the beacon block committed

Is the submission process stateful, I.e. do you have to submit the payload to the same BN that you submit the beacon block to? If it's stateful then a single submission endpoint for both would make sense to keep the API stateless, but if it's not stateful it might be more consistent (for MEV and local production) to keep them separate.

For my benefit - is the worry that, if you submit the block to one BN and then the execution payload to a second BN, that the second client might not have seen the block yet?

[nflaig]

Is the submission process stateful, I.e. do you have to submit the payload to the same BN that you submit the beacon block to?

For my benefit - is the worry that, if you submit the block to one BN and then the execution payload to a second BN, that the second client might not have seen the block yet?

the BN needs the beacon block first to validate and process the execution payload however it's not required to submit both via the api

there will be a queue mechanism in clients for gossip as you can't be sure that you receive the beacon block before the execution payload there

so for api, it could be similar, BN shouldn't care if it receives the beacon block/payload via gossip or api

but if it's not stateful it might be more consistent (for MEV and local production) to keep them separate.

this is kinda what I wanna avoid, it's a implementation detail but I think we might be fine with keeping the 2 apis separate, and not have a specific publish api for local blocks

[eth2353]

do we also want an api to publish both, or are we fine with having 2 separate publish apis

I'd just keep the 2 separate publish endpoints, that seems cleaner to me, they are two different objects being submitted.

That way we can also push out the BeaconBlock first, quickly, and follow it up with the ExecutionPayloadEnvelope right after (or even in parallel).