feat: allow proposer reorgs at epoch boundaries - #9769
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3ae54fba14
ℹ️ 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".
| return {prelimProposerHead, prelimNotReorgedReason: NotReorgedReason.AtEpochBoundary}; | ||
| } | ||
|
|
||
| // No reorg if headBlock and parentBlock are not ffg competitive |
There was a problem hiding this comment.
For a Gloas proposer reorg at the first slot of an epoch, this now selects the weak head's parent, but isBidCompatibleWithHead() in packages/beacon-node/src/chain/validation/executionPayloadBid.ts:63-66 still rejects every bid building on that parent when bidSlot is an epoch boundary. Because both gossip and API bid validation use that predicate, no matching bid reaches the pool queried during block production, forcing the proposer to discard valid builder bids precisely when this new reorg path is taken.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
yeah this is valid, and I was aware of it before, not sure we can solve this easily
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7337408c02
ℹ️ 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".
| return {prelimProposerHead, prelimNotReorgedReason: NotReorgedReason.AtEpochBoundary}; | ||
| } | ||
|
|
||
| // No reorg if headBlock and parentBlock are not ffg competitive |
There was a problem hiding this comment.
On a network whose proposal slot is still pre-Fulu, reorging out the final block of an epoch can change the effective balances used to derive the next epoch's proposer schedule. The validator duty is obtained from the weak head branch, but getProposerHead() can now build from its parent, where a different validator may be expected, producing a block with an invalid proposer signature or RANDAO reveal. Retain the boundary restriction until Fulu, where proposer lookahead makes the schedule deterministic across these branches.
AGENTS.md reference: AGENTS.md:L200-L203
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
On a network whose proposal slot is still pre-Fulu
we don't care about that, all networks are post-fulu and we don't need to support proposing on a pre-fulu network at this point
twoeths
left a comment
twoeths
left a comment
There was a problem hiding this comment.
looks good to me
I'd like to add a log in PrepareNextSlot when we reorg through epoch boundary
and when we produce a block as well
|
as discussed, since other clients do this already, there isn't much benefit of us not doing it, the proposer might orphan the slot 0 block if attesters are slow to compute the epoch transition on the parent of previous head but that's something clients can optimize separately, and for the proposer, there is no risk of having to compute another epoch transition since in that case we pre-compute the epoch transition on the right head, which only in really rare cases could be predicted incorrectly |
github-project-automation
Bot
moved this from In Progress
to Done
in Lodestar Team Coordination
The shuffling stability check was removed for all forks in #9769, but the spec only removes it from Fulu. Keep the check through Electra and allow epoch-boundary reorgs from Fulu. Tested with the targeted unit tests and minimal/mainnet `get_proposer_head/epoch_boundary` spec tests.
**Motivation** - starting Jun, we see more epoch transition when processing epoch boundary block, which correlate to lighthouse's release of v8.2.0, where it enabled epoch-boundary reorg by default - we also did that via #9769, Prysm enabled it but it was not in their release yet **Description** - prepare for epoch-boundary reorg if we find weak head at the last slot of an epoch Closes #9843
|
🎉 This PR is included in v1.47.0 🎉 |
4 participants
see ethereum/consensus-specs#5492superseded by ethereum/consensus-specs#5547