-
-
Notifications
You must be signed in to change notification settings - Fork 478
fix: recompute head before proposer boost dependent root check #9813
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -534,7 +534,11 @@ export class ForkChoice implements IForkChoice { | |
| * Run the fork choice rule to determine the head. | ||
| * Update the head cache. | ||
| * | ||
| * Very expensive function (400ms / run as of Aug 2021). Call when the head really needs to be re-calculated. | ||
| * Cost is dominated by the `computeDeltas()` scan over every validator, so it is flat no matter how | ||
| * many votes actually changed: ~4.6ms at 1M validators, ~9.5ms at 2M, plus ~30% if the proto-array | ||
| * has grown to a day of non-finality (measured Aug 2026 on a M3 Mac, see | ||
| * `test/perf/forkChoice/updateHead.test.ts`). Only call when the head really needs to be | ||
| * re-calculated. | ||
| * | ||
| * ## Specification | ||
| * | ||
|
|
@@ -759,12 +763,17 @@ export class ForkChoice implements IForkChoice { | |
| // The store field `this.proposerBoostRoot` and `updateCheckpoints()` are mutated only after | ||
| // `protoArray.onBlock()` succeeds | ||
| const isTimely = this.isBlockTimely(block, blockDelaySec); | ||
| const isProposerBoostBlock = | ||
| const isProposerBoostCandidate = | ||
| this.opts?.proposerBoost === true && | ||
| isTimely && | ||
| // only boost the first block we see | ||
| this.proposerBoostRoot === null && | ||
| this.isProposerBoostSameDependentRoot(this.head.blockRoot, parentRootHex); | ||
| this.proposerBoostRoot === null; | ||
| const isProposerBoostBlock = | ||
| isProposerBoostCandidate && | ||
| // Cached `this.head` may be stale especially after epoch transition. | ||
| // Need to updateHead() here to get the correct head | ||
| // This code only executes when block is timely. So minimal exposure to minor regression | ||
| this.isProposerBoostSameDependentRoot(this.updateHead().blockRoot, parentRootHex); | ||
|
Comment on lines
+775
to
+776
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
this comment is really misleading, the case where give the above, there are several pre-conditions for this to even be relevant, we might be able to narrow this down so we only need to re-compute our head if it's really necessary
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you are right comment is bad |
||
| // Candidate boost root used for protoArray.onBlock's best-child weighting. Committed to the | ||
| // store only after the insertion succeeds. | ||
| const proposerBoostRoot = isProposerBoostBlock ? blockRootHex : this.proposerBoostRoot; | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a targeted test where an epoch transition changes fork-choice weights while
this.headstill points to a branch with a different shuffling-dependent root, then verify that the first timely block receives proposer boost based on the recomputed head. This consensus-critical bug fix changes only production code, so the stale-cache scenario can regress without a focused test despite the repository requiring a failing regression test for bug fixes.AGENTS.md reference: AGENTS.md:L377-L382
Useful? React with 👍 / 👎.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have already conducted test and the performance impact is minimal as noted in the code comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ensi321 I am surprised by this, I don't see this can be minimal, it should have a measurable impact I would expect this to affect our block processing time
did we run this on a live mainnet node, or how was the evaluated?