perf(discv5): populate kbuckets & improved RLPx peering

[emhane]

Improves bootstrapping by starting to fill kbuckets at furthest log2distance from local node id, as these are easier to fill.

[emhane]

closed in favour of #7695

[emhane]

will still be useful to reverse this, to iteratively get closer to own node id

[Rjected]

Am I understanding correctly that this code is supposed to get discv5 to return a specific distance internally since it uses self.local_key.distance(target)? But instead of doing it for all log2 up to 255, we do it for half?

[emhane]

Am I understanding correctly that this code is supposed to get discv5 to return a specific distance internally since it uses self.local_key.distance(target)? But instead of doing it for all log2 up to 255, we do it for half?

exactly. it's unlikely to find peers for the closest buckets, 0-127. I think we should eventually extend it to cover all buckets though, if not already do that now tbh.

[emhane]

Metrics on outgoing RLPx connections back the hypothesis that pseudorandom FINDNODE target selection, explicitly targeting each kbucket, is more beneficial over time than a completely random target in lookup queries that aim to discover RLPx peers. Outgoing RLPx connections are important for nodes behind NAT to be successful, as @joshieDo has been strongly advocating for this week.

This pr was run between 16.04 21:30 - 17.04 12:30, although targeting all kbuckets, not only the top half (half furthest away from local node id as latest commit decreased it to in fear of too much overhead targeting all). Between 17.04 19:30 - 18.04 19:30, the node was ran with target generated by let tgt = NodeId::random(), which under the hood is let tgt: [u8; 32] = rand::random(). Both runs started with empty known_peers.json file (RLPx peers saved from prev run), and on new non-default ports with --instance flag.

This panel shows the number of successfully established outgoing RLPx connections over time.

Pseudorandom target selection, targeting each kbukcet index equal many times, outperforms random target selection. The former discovers equally many useful RLPx peers as the latter in almost half the time (15 hours as opposed to 24 hours).

Furthermore, pseudorandom target selection targeting each kbukcet is also cheaper than random target selection, as it leads to less peer churn.

This metric doesn't account for unique peers, it's hence likely that random target selection has higher peer churn than the given pseudorandom target selection as it re-establishes sessions with recently evicted peers (sigp/discv5 library stores sessions in an LRU cache). This assumption is strengthened by looking at the first panel, which shows that the increased peer churn isn't leading to more outgoing RLPx connections.

Based on these metrics, I will increase the targeted kbucket range in the lookup query to stretch over the whole kbucket range, since peer churn is less than the completely random target selection commonly used.

[Rjected]

lgtm, thanks for the additional docs and explanation with metrics!

[emhane]

lgtm, thanks for the additional docs and explanation with metrics!

kinda got the "metrics or go home" mentality from you guys