Research: Discv5 feasibility

[decanus]

The purpose of this feasibility study is to investigate discv5s ability to function efficiently on resource restricted devices. The goal is to be able to judge both the bandwidth consumption and the ability to function within small windows of connectivity.

Acceptance Criteria

This feasibility study looks at various problems:

• bandwidth consumption
• ability to function in small windows of connectivity
• needle in haystack (how hard is it to find a node with certain characteristics)

It is supposed to provide insight on all of these problems allowing for us to form a conclusion on discv5s viability.

Method

The testing should be kept fairely simple, the configurable paramters are the following:

• nodes - indicates the amount of nodes.
• needles - indicates the amount of nodes which are needles in our haystack or set of nodes.
• window - indicates the window size in seconds for the searching node to be online.

A discv5 DHT should, n amount of nodes should be generated and added to the DHT of which there are an amount of nodes that fit the needle description. A mobile client is simulated that connects to the DHT in short bursts indicated by window. Bandwidth should be recorded while connecting and disconnecting and synchronizing packets. It should also be checked how many round trips are required to find the specified needles.

Notes

• The discv5 spec is currently in motion and always changing. Even though we have the nim implementation it may make sense to use the go-ethereum version for this reason.

[decanus]

ping @oskarth & @kdeme for comments

[oskarth]

Re topic radius estimation issue (h/t Jacek) https://d.n0.is/pub/doc/gnunet/gnunetbib/cache/2012_5.pdf

[kdeme]

Some further (perhaps obvious) parameters that might be considered as they will influence the test:

• Amount of bootstrap nodes
• Interval of doing lookups: higher will obviously fill the DHT faster, but cost more resources.
• Adding seeding from nodes that were online (and very active/useful?) in previous session.
• Topic advertisement (not possible now with nim-eth implementation)

Another item that is important for mobile devices is that the IP-address will change more often. This makes the IP-address registered in the ENR not so useful (if you even manage to get the external one), or it needs to get updated very often, but even then it will take a while to get propagated over the network. Practically this will probably mean that for devices that are briefly online, they will have to initiate contact to peers mostly and will not be able to receive as much incoming communication.

Also, currently it is advised in the specification to link a "session" (shared secrets after handshake) to a nodeid + ip addres + udp port. This means that for each change of IP-address, a mobile device will have to renegotiate handshake with its peers. This too might end up costly for mobile devices.

[oskarth]

Adding to April milestone. That doesn't mean it should take until end of month, IMO we should be able to timebox PoC to a week, create follow up issues, do a write up of results, and then call it a day. That's roughly what was needed for https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks

[decanus]

So as discussed on the call yesterday, we will test this without topic stuff too. This will allow us to measure bandwidth and allow us to see what it would be like if we run discv5 in isolation. @arnetheduck believes this could be a solution, in order to test that feasibility it should be checked how easy it is to pollute the DHT by running an ethereum node on the same server as a waku node.

[oskarth]

Perhaps we should clarify the issue, as I took it to be implicit: the problem isn't to see if mobile nodes can be useful for others in Discovery v5. The problem is if Discover v5 can be useful for mobilephones to find nodes they care about, under the restrictions of (a) short connection windows (b) possibly few nodes providing the service they care about (how many).

[arnetheduck]

we can probably quantify it mathematically how much churn discv5 can support (ie average "refresh" time etc)