advertising services on discv5 - benchmarks and optimisations

[emhane]

Describe the feature

advertising a random topic on discv5 is straight forward: the topic gets hashed, and that hash is then looked up using a FINDNODE request, just as a node_id. all the closest_peers of that hash are expected to store info on that service, like for example a directory of nodes that preform that service. however, when nodes are looking up the same topic hashes, for example hash("reth_node"), than the sorry nodes that by chance have a similar node_id to hash("reth_node") will be DoS:ed by benevolent peers that just want to connect to a reth node.

devp2p made progress on this research topic, summarised in this paper DISCv5: Robust Service Discovery in Ethereum Ecosystem. the research question was how to set the topic-radius, the log2distance from a topic-hash, described in this issue ethereum/devp2p#112. peers within the topic radius need to store info on the topic. the rule to uphold, is that info on a topic should be dispersed enough among the nodes surrounding it, so that a query for the topic resolves successfully before any peers are overloaded with queries for that same topic.

I implemented this for sigp/discv5 and tested it in testground. moving on, it would be nice to:

• benchmark the discv5 topics code
• implement kbuckets optimisation that allows for Robust Service Discovery to scale

benchmark the discv5 code

how to run a single testground test case.

it should be possible to figure out how to run the test cases topic-query and reg-topic by comparing it to the command, linked above, for running the find-node test case. note: I only got it to work with 30 instances max, could be due to this "Configure RAM settings before you run docker on Mac", I didn't get as far as to try out configuring docker.

implement kbuckets optimisation that allows for topdisc to scale

for topics to scale, we will have to implement a way for virtualising topic overlays on top of the original kbuckets. it's described in detail in sigp/discv5#193. (there is even a pretty diagram, in a linked issue).

the issue suggests implementing an AsNode trait, to avoid breaking the existing API used in kbuckets. but doing implementing Deref and DerefMut on some type RwLock<T> is likely to end up unsafe. we will probably have to break the used inside of kbuckets to access the fields of a node, by using the following design pattern. makes the diff a bit bigger, but no worries.

pub fn with_node<F, T>(&self, f: F) -> T
where
    F: FnOnce(&Node) -> T,
{
    f(&self.val.lock().unwrap())
}

pub fn with_node_mut<F, T>(&self, f: F) -> T
where
    F: FnOnce(&mut Node) -> T,
{
    f(&mut self.val.lock().unwrap())
}

Additional context

for continuing topdisc research, we are best of forking discv5 so we can manage our own prs and progress step by step.