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.

[residue-scaling]

From a security point of view: one goal of the current split between validator clients and beacons is for operators to isolate validator clients on machines/vms/containers with no internet access, so that in the event of a software bug on the validator client side or a security breach, validation keys potentially loaded in memory can't be easily accessed/exported to the outside.

Here we assume the validator clients have a way to source bids, is the intent here to source bids directly from builders and so, be open to the internet?

[eth2353]

Here we assume the validator clients have a way to source bids, is the intent here to source bids directly from builders and so, be open to the internet?

Yes, pretty much. It feels important to say this is all opt-in, anyone who doesn't want this can let the beacon node do the bid selection.

But the idea is indeed that validator clients would be able to source bids by connecting to builders directly. To do that, they don't need to be open to the Internet entirely, their firewall could still deny any incoming connections. But they would need that link.

In terms of security, validator clients do not need to have validator keys in-memory, they can also use remote signers that can be located on more isolated machines.

Many Vouch users already do something similar today where they set up Vouch as a sort of mev-boost service that beacon nodes connect to to get execution payload headers. This however requires some extra unnecessary hops:

1. Vouch requests block from BN
2. BN requests payload header from Vouch
3. Vouch asks relays for execution payload header
4. BN receives header from Vouch, includes it in block
5. Vouch receives block from BN

With this proposed change to the Beacon API the process (in Gloas) could look more like this:

1. VC asks relays/builders for bids
2. VC requests block from BN, providing its own bid for inclusion
3. VC receives block from BN

-> No extra unnecessary hops which is especially useful if the VC and beacon node are not running out of the same datacenter.