Context
Summit tracks validator-set changes through finalized-header deltas and pending transition queues in consensus state. A checkpoint importer should only install pending add/remove queues that are consistent with the signed terminal header and the finalized history used to reconstruct the active participant set.
Claim
Checkpoint verification applies finalized-header validator deltas to a temporary participant set, but does not bind the decoded checkpoint state's pending added_validators and removed_validators queues to the transition history authenticated by the signed finalized headers.
A malicious checkpoint provider that can provide an otherwise valid finalized-header chain whose terminal header already signs the supplied checkpoint blob can include pending validator-transition queues that are not bound to the signed terminal header deltas. A passive public distributor cannot add or change these queues in an honest checkpoint without changing sha256(checkpoint.data) and failing terminal-header verification.
Flow
The verified-chain path requires checkpoint import/verification, a finalized-header sequence accepted by the checkpoint verifier, a terminal header that authenticates the supplied checkpoint bytes, and decoded checkpoint state whose active membership still passes the final membership check while pending add/remove queues diverge from the header-authenticated transition history.
Impact
A checkpoint can verify against the finalized header chain while carrying pending add/remove queues that produce a different next committee after import. The node can then diverge from the validator set reconstructed from finalized headers, undermining checkpoint soundness and future certificate verification.
Root Cause
Checkpoint verification authenticates active membership through the finalized headers but omits an equality check between serialized checkpoint transition queues and the terminal header's committed validator deltas.
Code
Related Issues/PRs
Related issues cover adjacent checkpoint queue, epoch-boundary state-root, and pending-state omissions that can leave transition state under-bound.
Fix
- Compare decoded transition queues against the terminal finalized header's committed validator deltas and expected post-boundary state.
- Reject checkpoint states with pending add/remove queues inconsistent with the verified header chain.
- Add negative tests where a signed terminal header has one validator transition set but the checkpoint state carries another.
Context
Summit tracks validator-set changes through finalized-header deltas and pending transition queues in consensus state. A checkpoint importer should only install pending add/remove queues that are consistent with the signed terminal header and the finalized history used to reconstruct the active participant set.
Claim
Checkpoint verification applies finalized-header validator deltas to a temporary participant set, but does not bind the decoded checkpoint state's pending
added_validatorsandremoved_validatorsqueues to the transition history authenticated by the signed finalized headers.A malicious checkpoint provider that can provide an otherwise valid finalized-header chain whose terminal header already signs the supplied checkpoint blob can include pending validator-transition queues that are not bound to the signed terminal header deltas. A passive public distributor cannot add or change these queues in an honest checkpoint without changing
sha256(checkpoint.data)and failing terminal-header verification.Flow
The verified-chain path requires checkpoint import/verification, a finalized-header sequence accepted by the checkpoint verifier, a terminal header that authenticates the supplied checkpoint bytes, and decoded checkpoint state whose active membership still passes the final membership check while pending add/remove queues diverge from the header-authenticated transition history.
Impact
A checkpoint can verify against the finalized header chain while carrying pending add/remove queues that produce a different next committee after import. The node can then diverge from the validator set reconstructed from finalized headers, undermining checkpoint soundness and future certificate verification.
Root Cause
Checkpoint verification authenticates active membership through the finalized headers but omits an equality check between serialized checkpoint transition queues and the terminal header's committed validator deltas.
Code
added_validatorsand current removals into the Summit block header: https://github.com/SeismicSystems/summit/blob/ed2c5c8/finalizer/src/actor.rs#L962.checkpoint_hashto equalsha256(checkpoint.data), so public redistribution alone cannot alter the queues in an already-signed checkpoint: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/checkpoint.rs#L263.checkpoint_state.added_validatorsandcheckpoint_state.removed_validators: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/checkpoint.rs#L282, https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/checkpoint.rs#L317.Related Issues/PRs
Related issues cover adjacent checkpoint queue, epoch-boundary state-root, and pending-state omissions that can leave transition state under-bound.
Fix