Add specs for proposer preferences

[jtraglia]

There is currently no in-protocol method for proposers to provide their preferences (fee recipient and gas limit) to builders. I would like to suggest a new proposer_preferences gossip topic for this.

Proposers in the next epoch (as defined by proposer_lookahead) will broadcast their preferences to everyone (including builders). This means that there will only be SLOTS_PER_EPOCH (32) valid messages on this topic each epoch which is very minimal. There's plenty of time (a whole epoch) for the network propagate these messages too.

[ensi321]

Just want to point out that these rules are not enforceable at all.

eg. Proposer can still accept bid that has different fee recipient from ProposerPreferences and there is no consequence to it because process_execution_payload_bid will not check if the bid matches the preference. Ultimately proposer can choose whatever bid he is happy with, whether his preference has been met or not

[nflaig]

I think the purpose of this is just to protect the proposer itself so the beacon node doesn't select a bid that violates the preference

[bharath-123]

would it make sense to have a req/resp for proposer preferences too? I would assume a builder would want to fetch the preferences from a peer if it doesn't already have them and wants to build blocks for that proposer.

[jtraglia]

would it make sense to have a req/resp for proposer preferences too? I would assume a builder would want to fetch the preferences from a peer if it doesn't already have them and wants to build blocks for that proposer.

I would say no, it's not worth the complexity. This would only affect builders who were offline the previous epoch. In such situations, it would be okay/reasonable for them to wait one epoch (~6 minutes) before making a bid.

[jtraglia]

I've reverted the trusted_payments_accepted change.

We can/should debate this in a separate PR, if/when this PR is merged.

[nflaig]

since we switched to proposal_slot now, this should probably no longer use compute_epoch_at_slot, there are several other places like this, it's very unlikely but if a proposer has 2 slots in the epoch there could be 2 different preferences for the same epoch

[nflaig]

wouldn't it be better if we also allow to broadcast preferences for the current epoch, eg. if a node was offline for whatever reason it still gets a chance to submit the preference, in practice it really just needs to reach the builder 1-2 slots before the proposal

change this to something like

- _[IGNORE]_ `preferences.proposal_slot` is in the current or next epoch -- i.e.
  `compute_epoch_at_slot(preferences.proposal_slot)` is in
  `[get_current_epoch(state), get_current_epoch(state) + 1]`.

(there are few other functions we would have to update to support this)

[nflaig]

might be worth to clarify that if a validator does not broadcast a preference it means it does not accept trustless bids via p2p since we will anyways reject all bids on the execution_payload_bid topic, so there is no reason for builders to submit a bids if they haven't seen a proposer preference for the slot

or we could consider allowing fallback values but I don't think it's a good idea to for example use withdrawal credentials as fee recipient, rather a builder could receive the preference via out-of-protocol and still send the bid on p2p as fallback if http api fails for some reason (eg. cloudflare outage)

[jtraglia]

Thanks for the review @nflaig! These suggestions are great. The only one I'm hesitant about is allowing preferences be sent in the same epoch. I think it will complicate the proposer lookahead checks; regardless I'll think about it. The proposer could just self build in this situation.