Builder config flow: per-key config across the three specs - #1
Builder config flow: per-key config across the three specs#1JasonVranek wants to merge 10 commits into
Conversation
| A key that only ever builds locally. To guarantee this regardless of how the validator client is globally | ||
| configured, set `enabled: false` at the keymanager; it overrides any global builder setup for this key: | ||
|
|
||
| ```jsonc | ||
| // keymanager POST body | ||
| { "enabled": false } |
There was a problem hiding this comment.
what about p2p bids, there is currently no way for the validator client to communicate to the beacon node that it does not accept p2p bids, but I am unsure there should even be such an option
nflaig
left a comment
nflaig
left a comment
There was a problem hiding this comment.
Looks pretty good and complete to me, left few remarks, also to remind myself later
| external payload under any circumstances also sets `min_bid` (the bid floor, detailed in Example 2) to its | ||
| maximum, so every bid dies at the floor even when the local build fails. |
There was a problem hiding this comment.
I still haven't gotten feedback from staking pools if that's something they will need, but yes, effectively setting min_bid=2**64 - 1 should disable p2p bids, and then operators can override for direct builders in builders. but I like this lever much better as what we had before, generally, and ideally, p2p bids should always be used as a fallback unless the global circuit breaker is active
| The staking software `POST`s this `BuilderConfig` to the VC at `/eth/v1/validator/{pubkey}/builders` (`202`). The submission **replaces** the key's | ||
| stored config in full; the server does not merge with what was there before. Note what is absent from the | ||
| entry: no `auth_data`, no `builder_pubkeys`, no per-entry `min_bid` or `builder_boost_factor`. These are | ||
| optional in the keymanager body, and the VC resolves each before anything reaches the beacon node. |
There was a problem hiding this comment.
I am suspecting every client will add this, but for most operators simply setting global values via CLI should be sufficient, eg. --builder.urls, --builder.minBid, --builder.boostFactor, etc., for more advanced use case the keymanager api can come in, or a more complex proposer settings file (to be standardized)
also client will have "baked in" defaults, so really only setting builder urls should work for most users
|
|
||
| - `min_bid`, `builder_boost_factor`: an omitted entry value inherits this key's `BuilderConfig` default, and | ||
| if that is unset too, the VC's own configuration. | ||
| - `max_execution_payment`, `auth_data`: an omitted entry value inherits the VC's own configuration directly; |
There was a problem hiding this comment.
for auth_data shouldn't this just default to url as described above? I wouldn't know what auth_data a vc would set, so this doesn't make much sense unless I am misreading this
|
|
||
| When omitted, `auth_data` is VC-derived from the URL (the SHOULD convention from Example 3: UTF-8 bytes of the | ||
| URL exactly as advertised, hex-encoded). "Exactly as advertised" is the canonicalization rule (no | ||
| normalization); any divergence between what the VC signs and what the builder expects is a `400` at the |
There was a problem hiding this comment.
should it be a 401 in that case?
| normalization); any divergence between what the VC signs and what the builder expects is a `400` at the | |
| normalization); any divergence between what the VC signs and what the builder expects is a `401` at the |
|
|
||
| ### Omitted `auth_data` | ||
|
|
||
| When omitted, `auth_data` is VC-derived from the URL (the SHOULD convention from Example 3: UTF-8 bytes of the |
There was a problem hiding this comment.
I didn't quite follow that discussion but there was a canonicalize , what was the reason for removing that?
I don't think this will be a problem, but if there is a trailing / for example that shouldn't be there, could it cause auth issues?
| // three keymanager requests, one per stored state | ||
| { } // omit builders: follow the VC's global config | ||
| { "builders": [] } // builders: []: no builder-API bids, p2p only | ||
| { "builders": [], "builder_boost_factor": "0" } // local-preferred (Example 1) |
There was a problem hiding this comment.
could add another example for "local only"
{ "builders": [], "min_bid": "2**64 - 1" }| per-proposer-key. Which cap is communicated to a builder reachable at two URLs with two different caps is not | ||
| pinned; the per-entry cap is the authoritative BN backstop regardless. |
There was a problem hiding this comment.
why is that a open question? if it's 2 different urls you just handle them as 2 different builders, each having their own max_execution_payment?
| - **The local build's value.** Selection has a bid "compete with the local build" and the local build win a | ||
| tie, but how the BN derives the local build's value (and in what units it compares) is a BN-internal the | ||
| beacon spec does not pin. |
There was a problem hiding this comment.
worth point out that this is on the execution apis spec
blockValue : QUANTITY, 256 Bits - The expected value to be received by the feeRecipient in wei
| - **Boost overflow and builder-vs-builder ties.** The boost's overflow bound (saturate to what type?) and the | ||
| tie-break between two equal top *builder* bids are not pinned; only the local-vs-builder tie is. |
There was a problem hiding this comment.
do we just pick the bid from the builder which was received first/earlier?
2 participants
An implementer-facing explainer of how per-key builder configuration flows across the keymanager, beacon (
produceBlockV4), and builder-API specs, organized from the simplest config up.The three PRs it traces:
Posted for review: comments on any line welcome.