What
produce_attestation_data asserts justified_source.slot <= target_checkpoint.slot. The assert is reachable from a store the fork-choice rules themselves produce, so the reference validator can crash on the attestation duty, and a client that transcribes the assert as a rejection skips the vote.
How it is reached
get_attestation_target bounds its first walk by max(safe_target, finalized) and its second walk (justifiability) by finalized only. Nothing bounds either walk by the head's justified checkpoint, which is what the source is taken from.
Observed on a three-node devnet (4 s slots, one proposer per slot, many orphans). The persisted head chain was
62 -> 59 -> 51 -> 50 -> 49 -> 45 -> 42
with latest_finalized at 42 and the head state's latest_justified at 49. The lookback walk from 62 takes three steps to 50. Neither 50 nor 49 is justifiable after 42 (deltas 8 and 7), so the justifiability walk continues to 45, which is behind the source at 49. The assert fires.
Any sparse chain where JUSTIFICATION_LOOKBACK_SLOTS steps span more than five slots past the justified checkpoint can do this; the gap between 45 and 49 comes from the justifiability rule, not from the walk length.
What clients do
Every client I checked already deviates from the spec here, in the same direction:
| client |
where |
shape |
| ethlambda |
crates/blockchain/src/store.rs, get_attestation_target_with_checkpoints |
after the walk, target below justified → target = justified ("not in the spec") |
| ream |
crates/common/fork_choice/lean/src/store.rs |
same |
| zeam |
pkgs/node/src/forkchoice.zig, getAttestationTargetUnlocked |
same, returns latest_justified |
| gean |
internal/attestation/produce.go |
after GetAttestationTarget, source.Slot > target.Slot → target = source |
| lantern |
src/consensus/state.c, lantern_state_compute_vote_checkpoints |
same |
| qlean-mini |
src/blockchain/fork_choice.cpp, getAttestationTarget |
first walk bounded by max(safe_target, justified); the second walk is unbounded, so the case above still reaches it |
So five of six clients vote for the justified checkpoint when the walk lands behind it, and none of them can be matched against the spec as written.
Proposal
Make the spec say what the clients do: in produce_attestation_data, when the source is after the target, vote for the justified checkpoint as the target. It is on the head chain, it is justifiable by construction, and the vote keeps its weight in fork choice instead of being dropped.
Keeping the clamp in produce_attestation_data rather than in get_attestation_target leaves the target walk, and the fixtures that check it through attestation_target_slot, unchanged.
PR to follow.
What
produce_attestation_dataassertsjustified_source.slot <= target_checkpoint.slot. The assert is reachable from a store the fork-choice rules themselves produce, so the reference validator can crash on the attestation duty, and a client that transcribes the assert as a rejection skips the vote.How it is reached
get_attestation_targetbounds its first walk bymax(safe_target, finalized)and its second walk (justifiability) byfinalizedonly. Nothing bounds either walk by the head's justified checkpoint, which is what the source is taken from.Observed on a three-node devnet (4 s slots, one proposer per slot, many orphans). The persisted head chain was
with
latest_finalizedat 42 and the head state'slatest_justifiedat 49. The lookback walk from 62 takes three steps to 50. Neither 50 nor 49 is justifiable after 42 (deltas 8 and 7), so the justifiability walk continues to 45, which is behind the source at 49. The assert fires.Any sparse chain where
JUSTIFICATION_LOOKBACK_SLOTSsteps span more than five slots past the justified checkpoint can do this; the gap between 45 and 49 comes from the justifiability rule, not from the walk length.What clients do
Every client I checked already deviates from the spec here, in the same direction:
crates/blockchain/src/store.rs,get_attestation_target_with_checkpointscrates/common/fork_choice/lean/src/store.rspkgs/node/src/forkchoice.zig,getAttestationTargetUnlockedlatest_justifiedinternal/attestation/produce.goGetAttestationTarget,source.Slot > target.Slot→ target = sourcesrc/consensus/state.c,lantern_state_compute_vote_checkpointssrc/blockchain/fork_choice.cpp,getAttestationTargetmax(safe_target, justified); the second walk is unbounded, so the case above still reaches itSo five of six clients vote for the justified checkpoint when the walk lands behind it, and none of them can be matched against the spec as written.
Proposal
Make the spec say what the clients do: in
produce_attestation_data, when the source is after the target, vote for the justified checkpoint as the target. It is on the head chain, it is justifiable by construction, and the vote keeps its weight in fork choice instead of being dropped.Keeping the clamp in
produce_attestation_datarather than inget_attestation_targetleaves the target walk, and the fixtures that check it throughattestation_target_slot, unchanged.PR to follow.