pub const MAX_PENDING_VERIFY_PER_PEER: usize = 8_192;Expand description
Per-source hard cap on pending_verify entries attributed to a single
hint_sender peer.
This is the actual D1 defence. Each pending entry records the peer that
hinted it (VerificationEntry::hint_sender); a single source may occupy
at most this many slots. A flooding peer can therefore consume only its
own quota — it can never deny slots to honest peers, because honest
sources are accounted independently. Set well above any legitimate
per-peer hint working set (a healthy neighbour syncs at most a few
thousand keys to us per cycle) yet small enough that
MAX_PENDING_VERIFY / MAX_PENDING_VERIFY_PER_PEER distinct malicious
peers would be required to approach the global cap.
Residual (accepted, follow-up): with the current ratio, ~16 distinct
PeerIds that are all simultaneously in the victim’s routing table
(gated by sender_in_rt) could still collectively reach the global
MAX_PENDING_VERIFY backstop. hint_sender is the cryptographically
authenticated connection identity (not a forgeable payload field), so
this requires running ~16 real Kademlia-adjacent Sybil nodes — a large
step up from the single-peer pre-fix attack, and the worst case degrades
only to the bounded memory backstop, not silent permanent starvation of
non-Sybil peers (each keeps its independent quota). A future hardening
(reserved headroom for under-quota sources, or a per-source cap that
scales with distinct-source pressure) is tracked as a follow-up and is
intentionally out of scope for this DoS fix.