Bootstrap and recovery
A new node does not replay the chain from genesis. It could not: most nodes have pruned the data a genesis replay would need, and post-quantum signature volume makes full replay impractical anyway.
Instead it verifies a certified checkpoint chain and restores a snapshot.
How it works
Section titled “How it works”genesis committee digest already trusted — it is in the genesis block ↓ verifiescheckpoint chain hash-linked, quorum-signed by checkpoint roots ↓ authorisesblock-key schedule each delegation checked against the roots ↓ anchorsverified state snapshotThe joining node:
- Fetches the checkpoint chain from a peer.
- Verifies it against the committee digest recorded in genesis — not against the peer’s word.
- Installs the block-key schedule, with every delegation entry verified against the checkpoint roots.
- Restores a verified snapshot at the checkpoint’s position.
- Follows normally from there.
The critical property is step 2. Trust bottoms out in the chain definition the node had to have in order to be on this network at all. The serving peer is not trusted — it is a data source, and everything it provides is checked.
Weak subjectivity
Section titled “Weak subjectivity”This is a proof-of-stake chain, so the standard caveat applies and it is worth stating plainly rather than burying.
A node joining from a checkpoint cannot independently verify the entire history back to genesis, because it does not have the signatures on old blocks. It verifies that a quorum of the genesis-pinned committee certified a chain of checkpoints leading to the state it is adopting. That is a strong guarantee, and it is not the same as replaying everything.
The residual assumption is that no committee checkpoint-root key set has ever been compromised. Root signatures do not expire, so stolen root keys could certify a competing history — the classic long-range attack.
Block keys are outside this assumption. They expire and rotate, so a stolen block key is a bounded, revocable exposure rather than a permanent one. That narrowing is one of the main reasons the key tiers are split.
Falling behind
Section titled “Falling behind”Restart after downtime. The write-ahead journal reconciles against the execution layer’s head and the node resumes. Blocks the execution layer lost are re-driven from replayed commits. See Running frost-node.
Beyond the retention window. If a node has been down longer than peers retain consensus history, it cannot catch up incrementally. Bootstrap it from a checkpoint again — a fresh join, not a repair.
The node halted on a hash mismatch. This is not a “restart and hope” situation. It means a rebuild produced a different block hash than the journal recorded, which means nondeterministic execution. Investigate before restarting: check that the binary matches the recorded digest for the pinned commit, and that the consensus parameters compiled into it are the network’s.
A node running different consensus-critical parameters does not degrade gracefully — it splits. See Requirements.
Checkpoint freshness
Section titled “Checkpoint freshness”Nodes follow the chain only while the checkpoint chain remains fresh. If it falls behind, a node alarms and then halts.
The reasoning: a stale checkpoint chain means block-key delegation authority is no longer being confirmed. Continuing to follow blindly, on the authority of delegations nobody is currently certifying, is precisely the failure mode this guard prevents.
If you see freshness alarms, the problem is usually network-wide rather than local — check whether checkpoints are being certified at all.
Restoring an archive node
Section titled “Restoring an archive node”A state-archive node is rebuilt mechanically rather than synced: replay full-witness blocks from the cold object-store archive in archive mode.
Everything from the archive is hash-verified against the chain’s own commitments before use. The storage is treated as untrusted, so corruption or loss is detected rather than believed.
This is a rebuild-from-scratch operation, not a repair. Budget time for it.
What to back up
Section titled “What to back up”Keys — especially checkpoint root keys. They cannot be regenerated, and losing them means losing the ability to certify checkpoints.
Manifest and config — small, and annoying to reconstruct.
Not chain data. Bootstrap exists precisely so that chain data is reconstructible from the network with full verification.
- Monitoring
- History and storage — what is retained and why.