The validator client submits proposer preferences and builder preferences once per proposal slot within the SUBMIT_BEFORE_PROPOSAL_SLOTS window and tracks submissions per dependent root, so a successful submission is never repeated unless the proposer shuffling shifts.
The beacon node keeps preferences in memory only. A restart between the submission and the proposal empties the pool, and peers do not re-gossip preferences they already sent, so bid validation at the proposal fails with No proposer preferences found for gossip and builder api bids alike, forcing a self-build even though builders hold the preferences and are bidding.
Options, not mutually exclusive:
- resubmit every slot within the submission window and rely on pool dedup instead of tracking submitted slots in the validator client
- resubmit when the validator client detects a beacon node restart
- persist the preferences pools on the beacon node
Related to #9919 since a combined service would only need the fix once.
The validator client submits proposer preferences and builder preferences once per proposal slot within the
SUBMIT_BEFORE_PROPOSAL_SLOTSwindow and tracks submissions per dependent root, so a successful submission is never repeated unless the proposer shuffling shifts.The beacon node keeps preferences in memory only. A restart between the submission and the proposal empties the pool, and peers do not re-gossip preferences they already sent, so bid validation at the proposal fails with
No proposer preferences foundfor gossip and builder api bids alike, forcing a self-build even though builders hold the preferences and are bidding.Options, not mutually exclusive:
Related to #9919 since a combined service would only need the fix once.