Add Proposer config file specification

[StefanBratanov]

Related to the proposer config file format discussion in flashbots/mev-boost#154

[ralexstokes]

some questions/thoughts:

do we require all CLs to support this format? I don't know if it adds much to require them to do so and would require buy-in from all the CL devs

if we go down this road, then we will want to specify precedence for how data from this file interacts with the information in the ValidatorRegistration

it looks like the main addition here is a mapping from proposer key to set of acceptable relays -- should we consider just including this information in the ValidatorRegistration?

[michaelsproul]

I'm loosely against making the proposer config format mandatory, but wouldn't be opposed to it being standardised here if there's sufficient uptake amongst clients.

In addition to being used to configure the relay assignments in mev-boost this config is also being used to set fee recipients and gas limits on validator clients. Presently there's no other standard way to set the gas limit on a validator client, although we could add a keymanager API as in this PR: ethereum/keymanager-APIs#39

[StefanBratanov]

some questions/thoughts:

do we require all CLs to support this format? I don't know if it adds much to require them to do so and would require buy-in from all the CL devs

if we go down this road, then we will want to specify precedence for how data from this file interacts with the information in the ValidatorRegistration

it looks like the main addition here is a mapping from proposer key to set of acceptable relays -- should we consider just including this information in the ValidatorRegistration?

No, It should be optional in my opinion. I will try to reword it in a way to make it more obvious.

My understanding is that CL either communicates directly with a relay or mev-boost. Sending this additional information as part of the ValidatorRegistration will let other relays knows what relays a certain validator is using. I guess that is a problem?

[StefanBratanov]

I'm loosely against making the proposer config format mandatory, but wouldn't be opposed to it being standardised here if there's sufficient uptake amongst clients.

In addition to being used to configure the relay assignments in mev-boost this config is also being used to set fee recipients and gas limits on validator clients. Presently there's no other standard way to set the gas limit on a validator client, although we could add a keymanager API as in this PR: ethereum/keymanager-APIs#39

Agree, it should be entirely optional. I think though standartization will help with setting up and maintaining builder architectures.

[ralexstokes]

so I think what @metachris said here is worth calling out: flashbots/mev-boost#154 (comment)

which implies we should remove all of the preference data from any standardized config and just focus on the unique concern here: mapping proposer public key to relay preferences

and personally at this point, it just feels like mev-boost specific configuration but if enough other people see value in standardizing this then I'm very open to it

[StefanBratanov]

so I think what @metachris said here is worth calling out: flashbots/mev-boost#154 (comment)

which implies we should remove all of the preference data from any standardized config and just focus on the unique concern here: mapping proposer public key to relay preferences

and personally at this point, it just feels like mev-boost specific configuration but if enough other people see value in standardizing this then I'm very open to it

I agree. It would be worth spending more time on standardizing it only if people see the value in it. I would drop a suggestion to discuss this in the CL call agenda issue.

[tersec]

1. What does yet another source (with what precedence versus other BN and VC sources of this information, that I believe all the CLs already have) of per-proposer fee recipient information provide? This isn't a particularly uniquely MEV-related concern.

2. Nimbus does not use a file like this for this, but to better support the dynamic key manager API, does so differently. This would not be a necessarily compelling per-recipient keymanager change, apropos (1), from a pure standalone perspective (for example, it presents scaling challenges with numbers of per-node validators in modifying keys on nodes supporting thousands of validators either in reading or writing them: it requires additional caching on both ends to function well in that context). There are other critiques here, but fundamentally a MEV change is just ... an unexpected place to find this.

3. Until there are multiple public builder API relays for a network that's not mainnet (too high-stakes to test with initially), this is not feasible to test in the wild end-to-end, and at least as of a couple of weeks ago, the purely local relay test story was less than ideal.

[metachris]

Is there any recent thoughts, conversations or developments about this?

[beetrootkid]

It seems there will be at least 2 public relays for mainnet on the Merge. I also think, given some of the discussions around txn censorship and OFAC, some proposers will want their blocks to just come from the public mempool via the attached Execution Layer. I understand this can be achieved by simply leaving the relay url for a particular validator address empty and then the request reverts to the EL.

[StefanBratanov]

Is there any recent thoughts, conversations or developments about this?

I did have one more thought about this change and I think it makes more sense to add this information to the mev-boost docs rather than the builder specs since it is more specific to the mev-boost architecture. There the config file structure can be described (the relay configuration) and also mention that it is compatible with the proposer config of other clients (Teku, Prysm). What do you think?

[ricardolyn]

As customers can dynamically change the relays on a staking platform, the MEV boost should be able to read from a remote URL, similar to what Teku does and automatically update the relayers for each validator. Is there a plan to include that approach in this PR?

[StefanBratanov]

closing this PR after discussion that let me to think that this is more mev-boost specification