pub trait CheckpointPreservesBlobAvailability: SequentialChainState { }Expand description
Lemma (A checkpoint leaves blob availability unchanged). Checkpointing neither strands a blob the chain can still reach nor silently requires one a bootstrapping node cannot obtain.
Proof. Two directions.
Nothing is stranded. Blobs live in storage shared across chains, addressed by content and owned by no chain’s view. What a checkpoint prunes is this chain’s history — its older blocks and the events they published — which is not where blobs are kept. So no blob becomes unreachable by checkpointing, and the retention obligation is exactly what it was before.
Nothing is silently required. ExecutionStateView::apply_checkpoint records an
OracleResponse::Checkpoint carrying used_blobs, read from the system state’s used_blobs
set: every blob the chain references at that moment. An oracle response is part of the block’s
outcome and covered by the block hash, so the list is certified rather than advisory, and a
bootstrapping node knows precisely which blobs it must hold in shared storage before applying
the checkpoint — otherwise a later operation could read blob content it does not have. ∎
The state dump is itself a blob, on the ordinary terms. The execution state is split at the
current epoch’s maximum_blob_size and published through add_created_blob, so a checkpoint’s
snapshot is published by its block exactly as any other blob is: priced by the block that
publishes it, bounded in count and size, and retained on the same footing. A checkpoint buys a
node the right to skip replaying history; it does not buy free storage.