Add produceBlockV4WithBid

[eth2353]

Multi-node validator clients may ask several beacon nodes to produce a block at the same time. Having every one of those beacon nodes request bids from the same set of builders at the exact same time is completely unnecessary and puts unnecessary load on beacon nodes and builders.

Instead, with this endpoint, the validator client can request bids from builders directly, pick one, and ask each beacon node to produce a beacon block with the supplied bid.

This should be a separate endpoint from produceBlockV4 which is already getting complex enough if we add something like #625 . Supporting both flows in the same endpoint would add more optional parameters and if/else branching.

The bid supplied by the validator client is included best-effort. The beacon node may replace it if its circuit breaker is active or if the bid is invalid, then continue with another viable bid or a local payload.

[michaelsproul]

I think optionally including this in the POST body (with #625) is actually simpler and cleaner isn't it? It save us copy-pasting the whole endpoint spec (which creates maintenance burden), and aligns with how this will probably be implemented in BNs (as an if inside a generic implementation of produceBlockV4).

[eth2353]

I think optionally including this in the POST body (with #625) is actually simpler and cleaner isn't it? It save us copy-pasting the whole endpoint spec (which creates maintenance burden), and aligns with how this will probably be implemented in BNs (as an if inside a generic implementation of produceBlockV4).

Well, it does lead to multiple optional parameters in an already quite complex endpoint, especially if #625 is merged in its current proposed state. I agree that BN side implementation will likely be shared for the most part among the two endpoints.

I don't have a strong opinion on separate vs one endpoint, open to changing it.

[AntiD2ta]

Supporting @eth2353 's initiative from the perspective of multi-beacon-node validator clients such as Vero/Vouch.

I think a dedicated endpoint is defensible here. These are materially different block-production pathways:

• produceBlockV4 delegates bid acquisition and selection to the beacon node.
• produceBlockV4WithBid makes the validator client responsible for acquiring and selecting the bid, while the beacon node validates it, applies circuit-breaker or fallback behaviour, and constructs the block.

That difference affects ownership, required inputs, failure semantics, observability, and implementation behaviour. Representing the flows as separate operations makes capability discovery, conformance testing, metrics, and future evolution clearer. It also avoids turning produceBlockV4 into an increasingly complex matrix of optional or mutually exclusive inputs.

The additional specification-maintenance burden is a valid concern though. A possible mitigation is refactoring much of the common request and response structure into shared OpenAPI components to reduce duplication and the risk of drift. A small amount of specification duplication seems preferable to leaving an important multi-BN capability implementation-specific.

That said, the exact URL is less important than standardizing the functionality. Adding a mutually exclusive SignedExecutionPayloadBid input to a POST version of produceBlockV4 could also satisfy the core requirement. I important that the final API explicitly supports submitting one preselected bid to multiple beacon nodes.