Expand description
Holder-eligibility cache: which peers recently proved storage of which key, against which commitment.
Phase 2d of the v12 storage-bound audit design (notes/security- findings-2026-05-22/proposal-gossip-audit-v12.md).
When the auditor successfully verifies a commitment-bound audit for
peer P on key K (against P’s currently-credited commitment hash H),
it inserts (P, H, now) into recent_provers[K]. Reward / quorum
eligibility for P-as-holder-of-K then checks that this cache entry
still matches P’s currently credited commitment hash; if P rotates
the hash via fresh gossip, the cache entry becomes stale and credit
is denied until the next successful audit against the new hash.
Invariants enforced here:
-
Per-key cap: at most
MAX_PROVERS_PER_KEYentries per key, LRU-evicted byproved_at. Bounds the per-key working set so a well-replicated key cannot fill memory. -
RT-only: only peers in the caller’s routing table populate entries — the caller is responsible for filtering before
RecentProvers::record_proof; this module just stores what it’s told. -
Hash-bound credit:
RecentProvers::is_credited_holderrequires the cache entry’scommitment_hashto match the peer’s currentcommitment_hash. A peer who proves K under C1 then rotates to C2 loses credit until re-proving K under C2. -
TTL: entries older than
PROVER_ENTRY_TTLare ignored byRecentProvers::is_credited_holderon read, andRecentProvers::sweep_expiredreclaims their memory when a caller invokes it (e.g. periodically from the engine). -
PeerRemovedcleanup: the caller should callRecentProvers::forget_peerwhen a peer leaves the routing table to drop their entries immediately (faster than waiting for TTL).
Structs§
- Prover
Entry - One cached prover entry: who proved the key, when, and against which commitment.
- Recent
Provers - Per-key cache of recent provers, capped at
MAX_PROVERS_PER_KEY.
Constants§
- MAX_
PROVERS_ PER_ KEY - Maximum number of cached provers per key.
- PROVER_
ENTRY_ TTL - Maximum age of a cached prover entry before it is considered stale.