erigontech / erigontech/erigon
cl/beacon: implement spec-compliant ProduceBlockV4 BuilderConfig
- Dominant language
- Go
- Stars
- 3.6k
- Forks
- 1.5k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 455
Description
Follow-up to #23583.
## Problem
Caplin currently registers `/eth/v4/validator/blocks/{slot}` as a GET alias of `GetEthV3ValidatorBlock`. That handler accepts the ProduceBlockV3 `builder_boost_factor` query parameter and has no required ProduceBlockV4 `BuilderConfig` request body.
The V3 factor controls the choice between a legacy relay header and the paired execution node. It is not the Gloas p2p-bid preference. #23583 therefore keeps the V3 factor on the legacy path and uses the default 100% comparison for Gloas p2p bids until the V4 request model is implemented.
## Required work
- Register a separate `POST /eth/v4/validator/blocks/{slot}` handler instead of delegating to the V3 GET handler.
- Require and validate the Gloas `Eth-Consensus-Version` header and the `include_payload` query parameter.
- Decode the required `BuilderConfig` request body from JSON and SSZ.
- Apply the top-level `min_bid` and `builder_boost_factor` only to p2p bids.
- Request bids for the configured `BuilderEntry` values and enforce each entry's URL, authentication, accepted builder public keys, maximum counted execution payment, minimum bid, and boost factor.
- Compare the local payload, p2p bid, and Builder API bids using overflow-safe weighted values, with the local payload winning ties.
- Implement the V4 response rules for `include_payload` and `Eth-Builder-Url`, including the corresponding publish flow.
- Keep ProduceBlockV3 and its query parameter limited to pre-Gloas forks.
## Tests
- JSON and SSZ `BuilderConfig` decoding and invalid-request responses.
- P2p `min_bid` and boost factors `0`, `100`, and `2**64 - 1`.
- Per-entry payment caps, minimum bids, boost factors, and builder-key filtering.
- Local, p2p, and Builder API winners, including equal-value ties.
- `include_payload` response variants and `Eth-Builder-Url` propagation.
- Confirmation that V3 relay preferences cannot affect Gloas p2p selection.
## Specification
- [ProduceBlockV4](https://github.com/ethereum/beacon-APIs/blob/master/apis/validator/block.v4.yaml)
- [BuilderConfig and BuilderEntry](https://github.com/ethereum/beacon-APIs/blob/master/types/gloas/builder_entry.yaml)
- [Validator block-production flow](https://github.com/ethereum/beacon-APIs/blob/master/validator-flow.md)
Review context: https://github.com/erigontech/erigon/pull/23583#discussion_r3885629438
Contributor guide
Assessment
This issue has not been assessed yet.