Bootstrapping fee recipient mapping to new relays/builders

[lightclient]

As we move to a p2p relay network, we need a mechanism that ensure that relays and builders who are new or go offline for a period of time are able to catch up to the latest. With the SetFeeRecipient method, this can be achieved roughly by sending announcements at regular intervals. However, this creates a lot of unnecessary network traffic. It would be better if there was a pull mechanism that a relay/builder could invoke when they wish to calculate the mapping. Here are a few ideas:

• Fee recipient bulletin -- there could be a smart contract on mainnet that validators submit signed announcements to and builders could process all events from the contract to calculate the mapping. Since there is still no BLS primitive on mainnet, the mapping couldn't be authenticated on-chain. Thus, it is more of a bulletin.
• Fee recipient DHT -- since the p2p network will likely already use discv5, we could use one of the extensions to store a mapping of validator to fee recipient. It's not clear how expensive it would be to iterate through this DHT, but at worst the relay/builder should be able to quickly get the proposers for the next epoch.
• Fee recipient syncing -- as each announcement is signed, it would be possible to create a syncing strategy to acquire the mapping. It could be ranged over either validator indexes or unix time (e.g. "get latest announcements for validators n...m" or "get all announcements from n...m).

Are there other approaches? I'm leaning a bit towards the syncing strategy as it seems simplest and most robust of the above ideas.

[james-prysm]

https://github.com/ethereum/keymanager-APIs we just recently proposed and merged an API spec for validator client linked here for setting the fee recipient.

i guess some context on this repo in general; to provide stakers/community that use GUI based commands we wanted to provide ways for those stakers to interact with the validator client ( this is how prysm had the only web front end due to these APIs). Post merge they are going to need a way to define fee recipients. Ideally, it's through an API similar to the keymanager APIs, you can see the most recent PR as of this comment.

[rolfyone]

https://github.com/ethereum/keymanager-APIs we just recently proposed and merged an API spec for validator client linked here for setting the fee recipient.

I think this is probably a really different use case to keymanager-api, that's validator management and highly privileged and trusted operations, but interested to see how this progresses. @tbenr

[lightclient]

Right, I think this issue is pretty unrelated to fee recipient management from a user perspective. This API is only used between the beacon node and builder client (mev-boost).

[mcdee]

The issue is that if the information sent through the keymanager API is unsigned then it wouldn't be possible for the beacon node to send on a signed setFeeRecipient to the builder client. If setFeeRecipient goes away as per this PR that may not matter, however if that doesn't happen, or whatever system that is introduced requires a signature from the validator, then this may still be an issue.

[lightclient]

@mcdee does the keymanager API not update the fee recipient that the validator client will use? In which case, the validator will be able to notify the beacon node (after we extend prepare_beacon_proposer) which will then notify the builder.

[mcdee]

Yes, that would be possible if the validator client has that capability. Less so if the information is passed directly to the beacon node.

(The original comment was more to make the different areas that are proposing fee recipient processes aware of each other, and the changes that may be coming down the line. If everyone knows about what each other is doing then my job here is done :) )

[metachris]

This was discussed at the mev-boost workshop on mev.day, and the conclusion was that we'll use builder_setFeeRecipient (now called builder_registerValidator) for the sake of simplicity for all parties (including validators).

• builder_registerValidator uses the payload from prepare_beacon_proposer (which needs an update to include timestamp, pubkey and signature)
• validators usually send this call between each slot and every other epoch
• mev-boost keeps resending it to the connected builders

Future approaches to mappings might be reconsidered in due time.

Closing this issue for now. If there's something missing, please comment, and we can also reopen.