pub trait BlobValidityRestsOnCertificates: ContentAddressingProvesIntegrity { }Expand description
Lemma (A blob’s validity rests on certificates, not on its hash). A blob held by a correct validator is one that a confirmed block published — and so paid for — and every later block that uses it re-attests that it is still owed. Its hash establishes which bytes it is; its certificates establish that it is entitled to exist.
Proof. BlobState records exactly this and nothing more:
| field | what it proves |
|---|---|
origin | BlobOrigin::Published { chain_id, block_height } names the confirmed block that published it, which is where publication was charged; BlobOrigin::Genesis is the one exception, holding for blobs every node has from the genesis config |
last_used_by | the hash of the most recent certificate that published or used the blob — a later quorum’s attestation that it is still required |
epoch | the epoch of that certificate, so the attestation can be weighed against which committees are still trusted |
Publication is charged by the block that performs it, at blob_published per blob and
blob_byte_published per byte, and admission is bounded in count and size — that is
BlobAdmissionIsBounded. Use is re-recorded through maybe_write_blob_states, which carries
forward the certificate that last needed the blob. ∎
Re-certification is the same mechanism as elsewhere, applied to bytes. A blob’s entitlement
does not expire with the committee that first certified it, because each subsequent use is a
fresh attestation under a fresh epoch — the pattern
linera_chain::proof::checkpoints::CheckpointRecertifiesReferencedBlocks applies to blocks an
outbox still references. BlobState’s epoch field is what makes it checkable.
What this does not give is availability. Nothing here obliges anyone to still hold the bytes:
a validity proof establishes that a blob should be retrievable, not that it is. That gap is
BlobRetention, which is currently discharged by omission, since nothing deletes blobs. The
shape of BlobState is what a retention policy would have to be keyed on — a blob whose
last_used_by certificate is in a still-trusted epoch is one some live block may still require,
which is a different question from how old it is.