Closed AgeManning closed 5 years ago
Isn't discv5 very different from the "official" libp2p Kademlia?
If so, my personal approach would be to create a different crate and copy-paste Kademlia's code there. And once it's mostly done, if there's still a lot of code in common between libp2p-kad
and libp2p-discv5
, then move it in some common denominator crate.
Yeah cool. Of course discv5 lives in it's own crate, was going to reference kbuckets etc modules rather than copy-paste.
The DHT part of discv5 is modeled off Kad. It's over UDP so there's going to be some significant differences between libp2p-kad
and the kad-like DHT in discv5, but figure libp2p-kad
is the closest place to start from as it's already written in a rust-libp2p
structure.
Will copy-paste code and maybe later try and find common ground.
Cheers.
It's over UDP so there's going to be some significant differences between libp2p-kad and the kad-like DHT in discv5
Discv5 is supposed to be for Ethereum 2, right? Libp2p can't support UDP (unless we put something reliable on top), so any issue should be brought back to the protocol designers.
One notable difference in rust-libp2p-kad
compared to the basic Kademlia paper is that instead of pinging a node to determine whether it's alive, we connect to it instead. In the buckets we put the nodes we're connected to on top of the nodes we're not connected to.
The protocol I'm working on (Discv5) uses Keccak in various parts which is causing a few headaches when integrating in current libp2p.
It requires a kad-like DHT. Figured it would be best to re-use what I can from the libp2p-kad protocol. The keys in kad are sha256: https://github.com/libp2p/rust-libp2p/blob/master/protocols/kad/src/kbucket/key.rs#L64. I can fork kad, to use keccak, but figured it would be nicer to minimize code duplication (if at some stage we want discv5 as a protocol in libp2p). What are your thoughts on adding a
new_keccak()
function, to thekbuckets::Key
struct?