Add specs for proposer preferences - #4777
Conversation
| `is_builder_withdrawal_credential(state.validators[bid.builder_index].withdrawal_credentials)` | ||
| returns `True`. | ||
| - _[REJECT]_ `bid.execution_payment` is zero. | ||
| - _[REJECT]_ `bid.fee_recipient` matches the `fee_recipient` from the proposer's |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
|
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. |
|
I've reverted the We can/should debate this in a separate PR, if/when this PR is merged. |
| 07. Set `bid.gas_limit` to be the gas limit of the constructed payload, that is | ||
| `payload.gas_limit`. | ||
| The proposer's preferred fee recipient can be obtained from their | ||
| `SignedProposerPreferences` for `compute_epoch_at_slot(bid.slot)`. |
There was a problem hiding this comment.
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
| `preferences = signed_proposer_preferences.message`: | ||
|
|
||
| - _[IGNORE]_ `preferences.proposal_slot` is in the next epoch -- i.e. | ||
| `compute_epoch_at_slot(preferences.proposal_slot) == get_current_epoch(state) + 1`. |
There was a problem hiding this comment.
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)
|
|
||
| #### Broadcasting `SignedProposerPreferences` | ||
|
|
||
| At the beginning of each epoch, a validator MAY broadcast a |
There was a problem hiding this comment.
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)
|
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. |
Follow up to #4777 which allows proposer preferences to be broadcast for the current epoch in addition to the next epoch. Currently proposer preferences are restricted to the next epoch which means if a node restarts, a new validator activates, or keys are migrated, the proposer has no way to communicate preferences to builders for the current epoch. This also should simplify client implementation as it aligns p2p more closely with how proposer caches work in clients. And overall makes the trustless builder path more robust. This was discussed on discord, see [thread](https://discord.com/channels/595666850260713488/1483497365594832917)
4 participants
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_preferencesgossip 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 beSLOTS_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.