Currently when the VC requests a beacon block to sign from the BN, it passes information that helps the BN picking a payload, for example builder_boost_factor. After Gloas, the VC will still need to pass information that helps the BN pick a bid instead of a payload. But this information can now be much more granular.
Configuration vs endpoint
Clients for the most coded their own way of getting these flags from the node operator. This is something that has been a pain point for institutional node operators and staking pools and has been a constant request even from homestakers and educators, we should try to at the very least come up with a list of configuration flags that can be standardized across clients, and then some parameters that must be accepted and dealt with by the beacon node (for example the above mentioned builder_boost_factor). For the most part, these flags are passed in the validator client and they can be tweaked per validator key, that is, clients currently support chooseing a different builder_boost_factor per different validator key they track. The VC then has a map validator_key -> builder_boost_factor as its configuration. And when requesting a block to sign sends the correct builder_boost_factor to the beacon node. Clients are free to add a flag to default this value, that is if I do not specify a value that overrides the default boost factor, the map is self-filled with the default.
Per builder flag.
With Gloas, validator clients get to adjust bid selection on a per-builder basis. That is, the VC would now have a map validator_key -> (map builder_id -> builder_boost_factor). This is the main crux of the configuration problem, since the bid selection is made by the beacon node, but the configuration is at the validator client instance, the beacon node has to receive a map in the endpoint. Instead of getting a builder_boost_factor it needs to receive something equivalent to the information builder_id -> builder_boost_factor so that it can apply the correct factor to each builder.
Standard parameters.
Since we now can be more opinionated and nuanced on bid selection, I believe the endpoint thus needs to accept a map builder_id -> BuilderPreferences where BuilderPreferences is an object that collect the many different flags that are applicable on a per-builder basis. Examples of flags that I believe every node must handle are
builder_boost_factor a parameter that would make this builder more or less likely to be accepted.max_trusted_bid either discard any bid from a builder that offers an off-protocol payment higher than X or simply treat the bid value as if it were X disregarding if it's offering more.min_bid only accept bids from this builder if they offer at least this much.
There are many other possible flags that can be added as optional, and some that can be constructed simply from the above list that is the most skeletal I can think of that need to be implemented by all beacon nodes.
The default BuilderPreferences can be sent explicitly as a default to the endpoint or just be assigned to the builder_id being the max uint.
This means that the validator client now needs to take a configuration of having a map validator_key -> ( builder_id -> BuilderPreferences). And I believe now is the time to agree on a file format for this configuration file so that we lower the pain points of node operators. For most homestakers like myself I would simply use a default parameter on all keys with the same builder preferences, but more involved operators would want to case this by validator key.
Builder IDs
Notice that above I have purposedly mentioned builder_id rather than builder_index or similar. The reason for this is that there is still design space on how the beacon should get information of which builders to contact directly and even on which endpoint will trigger that contact. Prysm has a PoC implementation in which the call to direct builders is triggered on a call to get a beacon block, just as today. We believe this is the simplest approach as it involves replacing the call to Mev-Boost to a direct call to builders, but we are free to whatever other designs clients come up with, for example a separate endpoint could be added to inform the beacon to start calling direct builders.
In what follows I'm assuming just for the sake of simplicity that this information is passed to the beacon in the call to Produce block v4. In addition to the above per-builder map, the VC would have to pass an allowlist of builders to direct calls. Notice that with this we can already cover many different use cases
- Take only trustless bids over P2P: the operators has an empty
allowlist.
- Take only trusted bids from selected builders: the operator sets a default
builder_boost_factor of 0 and overrides it in the allowlist. In addition it only calls builders that do not provide trustless bids.
- Favor p2p bids over selected builders Set a default
builder_boost_factor of 100 and override it with a lower value on the allowlist.
- Take only bids from the selected builders if they are higher than a minimum set a default
min_bid of 0 and override it in the allowlist.
- Do not allow bids from some builders, set a default non-zero
builder_boost_factor and override it for the block list with zero.
The biggest problem here is what should builder_id be? One possible way of doing this would be to go with builder_pubkey. The beacon node will have to have a map of builder_pubkey -> URL to contact and also disregard the returning bid's pubkey (to allow builder key rotation on the external endpoint) and if the URL is missing in the map then the beacon is strict and treats that pubkey as a P2P builder instead of in the allowlist. This seems to me the simplest design but it's hacky.
Signed Auths
To contact the direct builder connections, VCs may want to send the signed authorization to allow the builder to verify the authenticity of the call if they so desire or request. In this case these signed messages can (and should) be cached beforehand by the validator client as soon as it knows it will be proposing in a slot. Signing these messages can be done off the hot path minutes in advance and getting these messages may not need a new endpoint since the VC can have all the information from the duties endpoint. However, the produce block v4 endpoint (or any other new endpoint if we do not go with the above design) that is in charge of calling the direct builders, also needs to get this list of signed authorizations to send to the builder. One possible way would be to put it as an optional parameter to BuilderPreferences since it actually makes sense to be treated in the exact same point.
Currently when the VC requests a beacon block to sign from the BN, it passes information that helps the BN picking a payload, for example
builder_boost_factor. After Gloas, the VC will still need to pass information that helps the BN pick a bid instead of a payload. But this information can now be much more granular.Configuration vs endpoint
Clients for the most coded their own way of getting these flags from the node operator. This is something that has been a pain point for institutional node operators and staking pools and has been a constant request even from homestakers and educators, we should try to at the very least come up with a list of configuration flags that can be standardized across clients, and then some parameters that must be accepted and dealt with by the beacon node (for example the above mentioned
builder_boost_factor). For the most part, these flags are passed in the validator client and they can be tweaked per validator key, that is, clients currently support chooseing a differentbuilder_boost_factorper different validator key they track. The VC then has a mapvalidator_key -> builder_boost_factoras its configuration. And when requesting a block to sign sends the correctbuilder_boost_factorto the beacon node. Clients are free to add a flag to default this value, that is if I do not specify a value that overrides the default boost factor, the map is self-filled with the default.Per builder flag.
With Gloas, validator clients get to adjust bid selection on a per-builder basis. That is, the VC would now have a map
validator_key -> (map builder_id -> builder_boost_factor). This is the main crux of the configuration problem, since the bid selection is made by the beacon node, but the configuration is at the validator client instance, the beacon node has to receive a map in the endpoint. Instead of getting abuilder_boost_factorit needs to receive something equivalent to the informationbuilder_id -> builder_boost_factorso that it can apply the correct factor to each builder.Standard parameters.
Since we now can be more opinionated and nuanced on bid selection, I believe the endpoint thus needs to accept a map
builder_id -> BuilderPreferenceswhereBuilderPreferencesis an object that collect the many different flags that are applicable on a per-builder basis. Examples of flags that I believe every node must handle arebuilder_boost_factora parameter that would make this builder more or less likely to be accepted.max_trusted_bideither discard any bid from a builder that offers an off-protocol payment higher thanXor simply treat the bid value as if it wereXdisregarding if it's offering more.min_bidonly accept bids from this builder if they offer at least this much.There are many other possible flags that can be added as optional, and some that can be constructed simply from the above list that is the most skeletal I can think of that need to be implemented by all beacon nodes.
The default
BuilderPreferencescan be sent explicitly as a default to the endpoint or just be assigned to thebuilder_idbeing the max uint.This means that the validator client now needs to take a configuration of having a map
validator_key -> ( builder_id -> BuilderPreferences). And I believe now is the time to agree on a file format for this configuration file so that we lower the pain points of node operators. For most homestakers like myself I would simply use a default parameter on all keys with the same builder preferences, but more involved operators would want to case this by validator key.Builder IDs
Notice that above I have purposedly mentioned
builder_idrather thanbuilder_indexor similar. The reason for this is that there is still design space on how the beacon should get information of which builders to contact directly and even on which endpoint will trigger that contact. Prysm has a PoC implementation in which the call to direct builders is triggered on a call to get a beacon block, just as today. We believe this is the simplest approach as it involves replacing the call to Mev-Boost to a direct call to builders, but we are free to whatever other designs clients come up with, for example a separate endpoint could be added to inform the beacon to start calling direct builders.In what follows I'm assuming just for the sake of simplicity that this information is passed to the beacon in the call to Produce block v4. In addition to the above per-builder map, the VC would have to pass an
allowlistof builders to direct calls. Notice that with this we can already cover many different use casesallowlist.builder_boost_factorof 0 and overrides it in theallowlist. In addition it only calls builders that do not provide trustless bids.builder_boost_factorof 100 and override it with a lower value on theallowlist.min_bidof 0 and override it in theallowlist.builder_boost_factorand override it for the block list with zero.The biggest problem here is what should
builder_idbe? One possible way of doing this would be to go with builder_pubkey. The beacon node will have to have a map of builder_pubkey -> URL to contact and also disregard the returning bid's pubkey (to allow builder key rotation on the external endpoint) and if the URL is missing in the map then the beacon is strict and treats that pubkey as a P2P builder instead of in theallowlist. This seems to me the simplest design but it's hacky.Signed Auths
To contact the direct builder connections, VCs may want to send the signed authorization to allow the builder to verify the authenticity of the call if they so desire or request. In this case these signed messages can (and should) be cached beforehand by the validator client as soon as it knows it will be proposing in a slot. Signing these messages can be done off the hot path minutes in advance and getting these messages may not need a new endpoint since the VC can have all the information from the duties endpoint. However, the produce block v4 endpoint (or any other new endpoint if we do not go with the above design) that is in charge of calling the direct builders, also needs to get this list of signed authorizations to send to the builder. One possible way would be to put it as an optional parameter to
BuilderPreferencessince it actually makes sense to be treated in the exact same point.