[Security][tentative] Medium (correctness): Checkpoint Finalized Header Is Not Seeded Into Finalizer DB

[evonide]

Context

Summit checkpoint startup lets a node resume from checkpoint artifacts instead of replaying all prior history. The syncer needs the checkpoint block artifacts to continue block synchronization, and the finalizer needs the checkpoint epoch's finalized header as the predecessor for future epoch-boundary headers.

Claim

Checkpoint startup passes the checkpoint finalized_header only to the syncer and never seeds it into finalizer storage. The broken invariant is that a checkpoint-joined finalizer can have no persisted predecessor finalized header, causing boundary aux-data generation to fall back to genesis instead of the checkpoint header.

A node operator starts from checkpoint artifacts that include a finalized_header, then the checkpoint-joined proposer reaches an epoch boundary before that header is seeded into finalizer storage; aux-data generation reads an empty finalized-header DB, falls back to genesis, and emits boundary blocks linked to the wrong prior header.

Flow

The path requires startup from checkpoint artifacts that include finalized_header, followed by proposing or building an epoch-boundary block before the finalizer DB has the checkpoint header seeded through another path.

Impact

A checkpoint-joined node can build future epoch-boundary headers whose prev_epoch_header_hash points to genesis rather than the checkpoint epoch header. Because boundary header-link verification is also weak, such headers can be accepted and make post-checkpoint finalized-header chains diverge from continuously running nodes.

Root Cause

Checkpoint import hands the finalized-header artifact to the syncer but not to finalizer storage, and boundary aux-data generation treats a missing finalized header as a genesis fallback.

Code

• Engine builds SyncCheckpoint from checkpoint_last_block and checkpoint_finalized_header for the syncer: https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/engine.rs#L341.
• Finalizer initialization receives consensus state and genesis hash, but no checkpoint finalized-header artifact: https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/engine.rs#L150.
• Boundary aux data loads prev_header_hash from get_most_recent_finalized_header, falling back to genesis when the DB is empty: https://github.com/SeismicSystems/summit/blob/ed2c5c8/finalizer/src/actor.rs#L944.
• The checkpoint docs list finalized_header as the finalized header for the checkpoint epoch: https://github.com/SeismicSystems/summit/blob/ed2c5c8/docs/checkpointing.md#L180.

Related Issues/PRs

Related issues cover adjacent checkpoint startup, import, restart, finalized-header export, and response sizing consistency gaps.

• [Security][tentative] High (attackable): Checkpoint Startup Accepts Unauthenticated Artifacts #214
• [Security][tentative] High (attackable): Checkpoint State Position Is Not Bound To The Verified Header Chain #215
• [Security][tentative] High (attackable): Checkpoint Verification Is Not Bound to Local Genesis #218
• [Security][tentative] Medium (correctness): Checkpoint Restart Drops Exiting Validators Early #238
• [Security][tentative] Medium (correctness): Checkpoint RPC Cannot Export Trustless Header Chain #239
• [Security][tentative] Medium (correctness): Checkpoint RPC Can Exceed Response Cap #240

Fix

• Seed the supplied checkpoint finalized header into the finalizer DB during checkpoint startup.
• Require consistency between checkpoint state, last block, and finalized header before seeding.
• Add an integration test that imports a checkpoint and verifies the next boundary header links to the checkpoint header.

[matthias-wright]

I don't think this is an issue:

• The header is seeded via the syncer at startup. The syncer calls store_finalization for the checkpoint's last_block synchronously in run(), before the consensus loop starts. The finalizer executes that block and, since it's an epoch-terminal, calls store_finalized_header.
• There is no race. The checkpoint sits at epoch E's penultimate block; last_block N is E's terminal, delivered finalized. The first boundary this node could propose is E+1's terminal, which is only reachable after block N is executed, by which point E's header is already in the DB.
• The genesis fallback is correct where it fires. get_most_recent_finalized_header() → genesis_hash is only hit on a genuine from-genesis start (empty DB, no checkpoint terminal delivered), which is exactly the intended behavior.

[sebastian-osec]

Got it. For the full checkpoint-directory path with both last_block and finalized_header, I agree the finalized header is indirectly seeded: the syncer stores the checkpoint terminal block/finalization, dispatches it to the finalizer, and the finalizer stores the finalized header when executing that epoch-terminal block.

So I agree this is not an issue for that intended full-checkpoint flow.

The only caveat I see is that this relies on the checkpoint terminal block being present and replayed. If checkpoint startup is allowed with only the checkpoint state, or with a finalized_header but no last_block, then this seeding path does not run. It may be worth documenting/requiring last_block + finalized_header for live checkpoint joins, or adding a test that a checkpoint-directory join stores the checkpoint epoch finalized header before the next boundary.

[matthias-wright]

Sounds good. I'm adding this test #435. The path for checkpointing without a last block + finalized header is covered by stake_and_checkpoint.rs and stake_and_join_with_outdated_ckpt.rs.