fix: defer using proposer duties v2 to gloas#9519
Conversation
There was a problem hiding this comment.
Code Review
This pull request defers the transition to the deterministic 1-epoch lookahead (EIP-7917) and the getProposerDutiesV2 endpoint from the Fulu fork to the Gloas fork to avoid depending on an endpoint that is not yet implemented by all clients. The review feedback points out that isForkPostFulu is still required in onNewHead to correctly determine the proposer dependent root during the Fulu fork, and suggests keeping its import alongside isForkPostGloas.
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: 1674755657
ℹ️ 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".
| if (isForkPostGloas(this.config.getForkName(computeStartSlotAtEpoch(nextEpoch)))) { | ||
| await this.pollBeaconProposers(nextEpoch); |
There was a problem hiding this comment.
Avoid v2 prefetch before the Gloas boundary
When the current epoch is the final Fulu epoch, nextEpoch already resolves to ForkName.gloas, so this branch calls pollBeaconProposers(nextEpoch) immediately and that method selects getProposerDutiesV2 for the requested epoch. That still hits /eth/v2/validator/duties/proposer before the chain has reached Gloas—the compatibility case this change is trying to avoid—and if the connected BN does not serve v2 yet the prefetch fails; the last-slot boundary poll is also skipped because slot + 1 is Gloas, leaving first-Gloas-slot proposer duties to a boundary-time race.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
that's fine, at this point every bn should have proposer duties v2 implemented as node operators have to upgrade before the fork happens, ideally multiple epochs before
Performance Report✔️ no performance regression detected Full benchmark results
|
per #9380 (comment), we cannot use getProposerDutiesV2 before gloas as clients might not have it implemented yet