Skip to main content

Module possession

Module possession 

Source
Expand description

Delayed possession verification for fresh replication (ADR-0003).

After a node fresh-replicates a chunk, every close-group peer responsible for it is checked 5-15 minutes later for actual possession. The check is a single-key cryptographic AuditChallenge: the probed peer must return BLAKE3(nonce ‖ peer_id ‖ key ‖ bytes) computed over the chunk it claims to hold. It cannot produce that digest without the bytes, so — unlike a self-reported presence flag — a peer cannot escape the check by falsely asserting possession. A peer that holds the chunk earns nothing — storing what it was paid to store is the baseline expectation, not meritorious; a peer that returns the absent sentinel, or a digest that does not match the checker’s canonical copy (cryptographic proof it lacks the bytes), is penalised at AuditChallenge severity. Delivery of the original push is irrelevant: a peer the push never reached is still checked and penalised if it lacks the chunk.

A peer unreachable at check time is penalised immediately at audit severity, matching the responsible-chunk AuditChallenge path. A matching bootstrap claim uses the shared bootstrap-claim grace/abuse tracker; peer-side malformed, rejected, or mismatched responses are audit failures.

Structs§

PossessionCheckEvent
A scheduled possession check for one freshly-replicated chunk.

Functions§

random_delay
Pick a randomised delay in [min, max] to wait before a possession check runs. The bounds come from ReplicationConfig (defaulting to POSSESSION_CHECK_DELAY_MIN/MAX) so tests can shorten them.