-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Get the right head state when proposing a failed reorg #13579
Conversation
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.
Given the bug description and the amount of critical code changed, we might want to add a unit test for this one. It might not be easy though
head, err := vs.HeadFetcher.HeadState(ctx) | ||
// process attestations and update head in forkchoice | ||
vs.ForkchoiceFetcher.UpdateHead(ctx, vs.TimeFetcher.CurrentSlot()) | ||
headRoot := vs.ForkchoiceFetcher.CachedHeadRoot() |
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.
why not just derive the parent and head root in getParentHeadState
and do all the checks in there ? You wouldn't need to call this in the main GetBeaconBlock method.
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.
it's harder to test, but I can split it up in yet an extra layer.
if err != nil { | ||
return nil, err | ||
} | ||
if head.Slot() >= slot { |
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.
this would be a failure condition, no ? You wouldn't be able to process the block if the head slot is more than our wanted slot
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.
can never happen
This fixes the following bug:
The node is about to propose block N+1. It syncs block N, based on N-1, and is late, the node head remains being N-1 and will attempt a reorg. If at the beginning of the slot N+1 the node N has shown to be strong, the node relents and starts building a local payload immediately on top of N.
The node obtains the blockroot of N from forkchoice and requests the corresponding state advanced to N+1.
If the node also has a cache miss (in the NSC) then the node will advance the head state to N+1. Here's the bug since this would produce the state based from N-1, instead of N as we want.
cc @nisdas