p2p - discovery with topic

[qcdll]

One of the issues that QuarkChain team noticed during testnet 2.0 is incompatible network id issues when a new network is being started (while there are some clusters running the network with the old ID, eg. 21, 22).

We purposefully make a cluster disconnect during p2p hello exchange handshake when network ID mismatch, and this is the correct behavior. However the p2p discovery layer does not know about the network ID, so discovery will keep feeding random connection candidates and we waste time before finally connecting to a peer with correct network ID. This problem goes away when everyone noticed that they should bump their network ID, but will bother us if we want to keep different network IDs over the long run.

Ethereum also suffers from similar issues for mainnet and its several testnet, as well as different types of clients (LES)

pyquarkchain incorporates py-evm's p2p layer, which already includes some discv5 features https://github.com/QuarkChain/pyquarkchain/blob/bb54e7970c8075ce7d9ba515ae3a9109abca0cf1/quarkchain/p2p/p2p_server.py#L55

We need to turn it on and test this feature. Note because our mainnet is not yet launched, any change can be made NOT backward compatible, that's the benefit of doing it now.

Another major benefit for topic discovery within QuarkChain is the possibility to discover peers that are interested in specific shards - for example, a miner that is mostly interested in mining shard 3 would be highly motivated to connect to other miners working on the same shard.

the following references for discv5 design are relevant: https://github.com/fjl/p2p-drafts/blob/master/discv5-eip.md https://github.com/fjl/p2p-drafts/blob/master/discv5-topics.md https://github.com/fjl/p2p-drafts/blob/master/discv5-packets.md

another good reference (mostly v4) https://gist.github.com/njgheorghita/0b93371be85bcbef74476ba3fbe954e5