feat: broadcast proposer preferences before the gloas fork#9571
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the ProposerPreferencesService to enable broadcasting proposer preferences prior to the Gloas fork, ensuring caches are warm for the initial Gloas slots. The task now initiates when the submission window (slot + SUBMIT_BEFORE_PROPOSAL_SLOTS) reaches Gloas, and a check has been added to skip duties that are not post-Gloas. There are no review comments, so no feedback is provided.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af6acda441
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Start running once the submission window (`slot + SUBMIT_BEFORE_PROPOSAL_SLOTS`) reaches | ||
| // Gloas, i.e. already in the epoch before the fork. This allows builders to prepare and | ||
| // submit bids for the first Gloas slots. | ||
| if (!isForkPostGloas(this.config.getForkName(slot + SUBMIT_BEFORE_PROPOSAL_SLOTS))) { |
There was a problem hiding this comment.
Refresh upcoming Gloas duties before pre-fork submissions
Once this pre-fork path is enabled, the task consumes getProposersAtEpoch(currentEpoch + 1) while the clock is still in the final pre-Gloas epoch. I checked BlockDutiesService.onNewHead: in the pre-Gloas branch it only refetches currentEpoch, so if a reorg changes the dependent root for the upcoming Gloas epoch after the epoch-start prefetch, the cached Gloas duties remain under the old root. In that scenario these early submissions are signed with a stale dependentRoot, causing the beacon node to ignore/reject them and leaving builders without valid preferences for the first Gloas slots.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
but I don't think this edge case is worth handling, a reorg in the last SUBMIT_BEFORE_PROPOSAL_SLOTS of the pre-gloas epoch is very unlikely and we will still submit correctly at slot 0 of gloas
Performance Report✔️ no performance regression detected Full benchmark results
|
### Motivation Follow-up to #9571. The `submitted` map in `ProposerPreferencesService` tracks which preferences were sent per epoch but was never pruned, so it grows by one entry each epoch for the lifetime of the process. Raised in review by @twoeths. ### Description Drop tracking for past epochs at the start of each task run; only `currentEpoch` and `currentEpoch + 1` are ever processed.
As per ethereum/beacon-APIs#608
Also related to ethereum/consensus-specs#4947 but we already do this since we subscribe to new gossip topics 2 epochs before the fork (
SUBSCRIPTIONS_LOOKAHEAD_EPOCHS = 2).