Expand description
DHT bootstrap (ADR 022 §Bootstrap).
On node startup the routing table is empty. ADR 022 specifies:
- Build initial routing table from the on-chain registry peer list (same source as the peer table bootstrap in ADR 019).
- Issue
FindNode(self.node_id)to those initial peers — standard Kademlia self-lookup populates k-buckets with peers close to the local id.
Step 1 here reads from a StakerSet. The daemon supplies the
chain-backed ChainStakerSet,
projected from CapacityBond; ConfigStakerSet is the in-memory
implementation of the same trait that tests seed directly.
Step 2 runs in parallel against up to a small fan-out of the seed
set, with a generous timeout. Failures are non-fatal — a node that
can’t reach any seed at boot still has a populated routing table
from step 1; subsequent inbound traffic refreshes it via the
handler’s per-request note_peer_seen path, and the bucket-refresh
task (super::bucket_refresh) eventually fills the K-closest
buckets via FindNode probes of random per-bucket targets.
Structs§
- Bootstrap
Outcome - Summary of a bootstrap run, returned for logs + tests.
Constants§
- BOOTSTRAP_
FANOUT - Cap on the number of seed peers we probe in parallel during the initial self-lookup. The full staker set may be hundreds of nodes; fanning out to all of them at boot would generate a synchronised connection storm against the responding subset. The first few successful responses are enough to seed the k-buckets — iterative lookup (and the bucket-refresh task) will reach the rest at the rate ADR 022 §Routing Table prescribes (one refresh per bucket per hour).
Functions§
- bootstrap
- Seed the routing table and run the initial self-lookup. Returns a summary so the runtime can log a single high-signal startup line.