feat: reorg weak head when the proposer equivocated - #9929
Merged
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: d4e105d65c
鈩癸笍 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".
Contributor
Performance Report鉁旓笍 no performance regression detected Full benchmark results
|
Member
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. Reviewed commit: 鈩癸笍 About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
Member
Author
we need to keep this at least until after gloas since we cannot be sure that ELs allow to reorg back to parent block, I also don't really like that we do a FCU for a block that we know with high certainty that we will reorg anyways. After gloas this won't matter since right now we call FCU all the time when importing the execution payload and going back to EMPTY rather would depend on PTC votes |
github-project-automation
Bot
moved this from In Progress
to Done
in Lodestar Team Coordination
This was referenced Sep 1, 2026
Member
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implement the proposer equivocation branch of
get_proposer_headfrom ethereum/consensus-specs#4807, which reorgs a weak previous-slot head whose proposer is known to have equivocated:This is the proposer side of the builder reveal safety argument that #9233 implemented the attester side of. A builder reveals once it sees a block with enough weight and no equivocation. If the proposer then publishes an equivocating block and the next proposer extends it, attesters withhold the boost via
should_apply_proposer_boost, but for the equivocating block to actually be reorged the next proposer has to build on the parent, which is this branch. It lives in the phase0 spec so it applies pre-gloas as well.getProposerHeadreturns the parent when the head is weak, from the previous slot and another block at the same slot from the same proposer is in fork choice, skipping the regular reorg conditions (head_late,ffg_competitive,finalization_ok,proposing_on_time,parent_strong). The boost worn off check stays a precondition for both branches, the spec asserts it before eithershouldOverrideForkChoiceUpdatemirrors the branch so the fcu skip at import and the payload attributes prediction inprepareNextSlotfollowgetProposerHead. It does not checkis_head_weak, the head slot's attestations are still queued when it runs so the head is assumed weak, same as the regular branchhasEquivocatingBlocktakes aptcTimelyOnlyflag,should_apply_proposer_boostonly counts PTC-timely siblings whileis_proposer_equivocationcounts any known blockparentBlockis already resolved viagetParentPayloadStatusis_proposer_equivocation,should_apply_proposer_boostandrecord_block_timelinessspecrefs to their implementations and bump theget_proposer_headspec link,v1.4.0-beta.4predates this branchThe existing check order and
notReorgedReasonvalues are unchanged, the new branch only runs ahead of them. Equivocating blocks reach fork choice since #9805, before that this could only trigger for blocks fetched via unknown block sync.There are no spec vectors for this branch upstream, coverage is via the
getProposerHeadandshouldOverrideForkChoiceUpdateunit tables. The four reorg cases fail onunstableand pass here, and theget_proposer_head,reorg,should_override,ex_anteandshould_apply_proposer_boostfork choice spec tests still pass.Closes #9764