fix(validator): vote for the justified checkpoint when the target walk lands behind it - #1207
Open
adust09 wants to merge 1 commit into
Open
fix(validator): vote for the justified checkpoint when the target walk lands behind it#1207adust09 wants to merge 1 commit into
adust09 wants to merge 1 commit into
Conversation
…k lands behind it produce_attestation_data asserted source.slot <= target.slot. The target walk is bounded by the safe target and the finalized checkpoint, never by the head's justified one, so on a sparse chain the justifiability walk can select a block behind the source and the assert fires. A three-node devnet produced the head chain 62 -> 59 -> 51 -> 50 -> 49 -> 45 -> 42 with finalized 42 and justified 49: the lookback reaches 50, neither 50 nor 49 is justifiable after 42, and the walk lands on 45. Every lean client already clamps the target up to the justified checkpoint here, outside the spec. Make the spec say so: when the source is after the target, the vote's target is the justified checkpoint itself. The target walk and the fixtures that check it are unchanged. Closes leanEthereum#1206 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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
1 participant
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.
Description
produce_attestation_dataassertedsource.slot <= target.slot. The assert is reachable: the target walk is bounded by the safe target and the finalized checkpoint, never by the head's justified one, so on a sparse chain the justifiability walk can select a block behind the source.#1206 has the head chain from a three-node devnet that does it (
62 -> 59 -> 51 -> 50 -> 49 -> 45 -> 42, finalized 42, justified 49: the walk lands on 45).Every lean client already clamps the target up to the justified checkpoint in this case, outside the spec (survey in #1206). This makes the spec say so: when the source is after the target, the vote's target is the justified checkpoint itself. It is on the head chain and justifiable by construction, and the vote keeps its weight in fork choice instead of being dropped.
The clamp sits in
produce_attestation_data, not inget_attestation_target, so the target walk and the fixtures that check it throughattestation_target_slotare unchanged.Tests:
tests/spec/forks/lstar/test_validator_duties.pybuilds that chain on a genesis store. The first test fails onmainat the assert and passes here; the second checks a target at or after the source is left as the walk selected it.Closes #1206