pub trait LockingBlobsTravelWithTheLock: CorrectValidator + CorrectValidatorAvailability { }Expand description
Lemma (A locked block’s blobs travel with the lock). Whenever a correct validator holds a locking block, it also holds the blobs that block requires, and any node that can reach it can obtain them.
This is what makes LockRecovery executable rather than merely permitted. Re-proposing a
locked block means proposing the block itself, which cannot be done without the blobs it
publishes and reads — and the party that has to do it is often not the party that created the
lock.
Proof. Three parts.
The validator keeps them. ChainManager writes the required blobs into
locking_blobs in the same transition that installs the lock, clearing the map first, so it
always describes the current lock and never an earlier one. ManagerSafetySnapshot carries
locking_blobs alongside the lock, so a restore cannot reinstate a lock without its blobs.
They are reachable. ValidatorNode::download_pending_blob resolves through
ChainManager::pending_blob, which consults the proposer’s blobs and then locking_blobs.
So a lock held by a reachable correct validator is a lock whose blobs are downloadable, without
the original proposer being involved at all.
A recovering client collects them. In Client::synchronize_chain_state, installing a
ValidatedBlockCertificate on the local node fails with LocalNodeError::BlobsNotFound when
they are absent; each missing blob is then downloaded from the remote node, installed with
handle_pending_blobs, and the certificate retried. The proposal path does the same for a fast
lock. ∎
Re-proposal itself does not fetch. ChainClient reads the blobs for a re-proposal from its
own local node, and fails with an internal error rather than a retry if they are not there. The
fetching happens only in the synchronization above, so this lemma is a statement about that
path having run, not about a fallback at proposal time.