Gloas: external builder API (payload bid selection and block production)

[ethDreamer]

Issue Addressed

Closes #9590.

Adds support for the Gloas (ePBS) external builder API: the flow by which a proposer solicits
execution payload bids from off-protocol builders, ranks them against its local build and
gossip-relayed bids, commits to a winner, and forwards the signed block to the winning builder so it
reveals the execution payload envelope.

Implements the relevant parts of:

• beacon-APIs #630 — produceBlockV4, builder-preferences endpoint, Eth-Builder-Url
• builder-specs #165 — getExecutionPayloadBid, submitBuilderPreferences, submitSignedBeaconBlock, request auth
• consensus-specs Gloas p2p / state transition for ExecutionPayloadBid

Proposed Changes

A Gloas proposer now considers three payload sources — its local EL build, gossip bids, and bids
fetched directly from configured builders — selects the most profitable eligible one, and (for a
direct builder) forwards the signed block back for envelope reveal.

The branch is organized as a bottom-up, dependency-ordered stack of commits so it can be reviewed one
layer at a time:

1. consensus/types — the builder request-auth signing domain
   (compute_domain(DOMAIN_REQUEST_AUTH)) for authenticating Gloas builder-API requests.
2. builder_types — shared SSZ/JSON wire types (builder config & entries, proposer preferences,
   request auth, builder URL).
3. eth2 — beacon-node HTTP client methods for produceBlockV4, submitting builder preferences,
   and the Eth-Builder-Url response/echo header.
4. builder_client — the Gloas Builder API HTTP client and a stateless Builders service that
   fans getExecutionPayloadBid / submitBuilderPreferences / submitSignedBeaconBlock out across
   a proposer's configured builders. The pre-Gloas relay client is relocated here.
5. execution_layer — adopt the relocated pre-Gloas client; drop dead error variants.
6. beacon_chain (verification) — direct-builder bid verification and gossip-bid refinements,
   sharing the state-dependent consistency checks.
7. beacon_chain (selection + production) — a unified BidCandidate /
   BidSource { Local, Gossip, Direct } model and select_payload_bid, wired into Gloas block
   production. All bid value math lives on BidCandidate, computed on demand: ranking is the trusted
   value scaled by builder_boost_factor, in wei, so the local EL block value compares directly and
   builder_boost_factor == u64::MAX ("always prefer") is a plain multiply. min_bid is a ranking
   tier — a below-floor bid wins when it's the only option (e.g. the local build failed) but loses to
   any floor-clearing candidate. Direct-bid BLS verification runs on a blocking thread (off the async
   executor), and gossip bids are re-validated against the production state at selection time so a bid
   that has gone stale since gossip verification can't win selection and then fail block processing.
8. client — construct the Builders service (honoring --builder-user-agent /
   --builder-disable-ssz) and wire it into the chain.
9. network — gossip validation and peer scoring for payload bids and proposer preferences.
10. http_api — produceBlockV4, POST /eth/v1/validator/builder_preferences, and the
    Eth-Builder-Url publish round-trip. The winning builder's URL travels back to the VC as a
    response header and is echoed on publish, so forwarding the signed block works even when the
    publishing beacon node isn't the one that produced it.
11. validator_client (signing) — sign builder request-auth and preferences.
12. validator_client (config) — builder configuration store + docs.
13. validator_client (services) — the builder-preferences submission service and v4 block
    production / publish.

Additional Info

Best reviewed commit-by-commit: the commits form a bottom-up dependency layering (types → wire types
→ clients → beacon_chain → node / network / API → validator_client), each a coherent per-crate
change.

[mergify]

Some required checks have failed. Could you please take a look @ethDreamer? 🙏

[eserilev]

thanks for breaking it up into commits like this! im wondering if you would be willing to convert this into stacked PRs?

We did this here: #9764

I think it makes reviewing big PRs much easier and hopefully more maintainable for the author. Lmk what you think

[dapplion]

🤖 automated (dapplion's agent): min_bid ranks as a tier. It does not reject. A bid below the floor still wins when it is the only candidate. The behavior is correct. This line and line 49 are wrong.

[dapplion]

🤖 automated (dapplion's agent): This makes Eth-Consensus-Version required, but the comment above says the body is not fork-versioned and uses no such header. post_validator_blocks_v4 omits it. One of the two must change.

[dapplion]

🤖 automated (dapplion's agent): builder_boost_factor == u64::MAX no longer means always prefer the builder. A plain multiply ranks a zero-value bid at 0, so any non-zero local build wins. This differs from the pre-Gloas contract. Document it.

[dapplion]

🤖 automated (dapplion's agent): This awaits one signature per builder, in sequence. On a cold cache this is up to 64 serial remote-signer round trips, on the proposal critical path. The signatures are independent, so use join_all.

[dapplion]

🤖 automated (dapplion's agent): ssz_response is dropped here and forward_signed_block hardcodes false, so every submission is JSON. The doc comment on GloasBidResponse says the opposite. Thread it through, or delete the field.

[dapplion]

🤖 automated (dapplion's agent): expose_full() puts the full builder URL into a response header that travels BN to VC to BN in cleartext. An API key in the URL reaches every proxy log. Document that credentials belong in auth_data.