> We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery.
Bravo, because they always get it wrong.
DHTs used for decentralized DNS-like naming purposes have truly unique scaling requirements; you have to use a connectionless protocol (like bittorrent does) but everybody seems to be fixated on connection-oriented protocols like TCP, HTTP, and QUIC. The latter just don't work for this extreme use case.
No other use case on the entire internet requires such an extremely large out-degree for end-user nodes in the node connection graph. Allocating connection-state, even a very small amount, opens up the least-powerful nodes to easy DoS attacks. And from there it's easy for a motivated attacker to push the network away from decentralization and force it in to a highly-centralized state.
I might be crazy, but I got a side project to write a DHT using iroh. The key is to use QUIC 0-rtt connections to keep the connection overhead minimal.
But at this point it is just a toy project to push the limits of what is possible with iroh and 0-rtt. It is not used in prod and won't be any time soon :-)
Even 0-RTT connections still allocate connection state. IPFS learned this the hard way.
The mental model you need is the attacks that cause the Linux kernel to send SYN cookies. Learn how that attack works and you'll understand why you can't have connection state here (and neither does the Linux kernel during a SYN flood).
It's much worse for DNS-like services, which is why after all these years DNS still uses UDP. Imagine if the root zone servers had to allocate connection state!
But it all depends on what you're using the DHT for. If you've decided "let's write a DHT that won't be used for naming or DNS-like purposes" then you'll probably get away with it.
I love mainline and also really appreciate how lightweight it is by just using UDP packets. But UDP packets have their limits. With the maximum MTU you can expect to work, the payload can't be more than about 1000 bytes, which is the limit of bep_0044.
But there are some use cases where you want to store a bit more than 1000 bytes. Not giant amounts, but maybe 4 KiB. Mainline won't ever be able to do this.
Iroh 0-rtt is very lightweight. On the network level you see one or two UDP packets flying in one direction, one or two UDP packets flying back, and that's the end of the interaction. You close the connection, and all state you have to retain is a session cookie on the client side.
It is still much heavier than bare UDP packets, but much lighter than a normal 1-rtt QUIC connection, which is already pretty lightweight.
Here are some details about 0-rtt. The API has changed slightly since then, but the basics remain the same of course: https://www.iroh.computer/blog/0rtt-api
Bravo, because they always get it wrong.
DHTs used for decentralized DNS-like naming purposes have truly unique scaling requirements; you have to use a connectionless protocol (like bittorrent does) but everybody seems to be fixated on connection-oriented protocols like TCP, HTTP, and QUIC. The latter just don't work for this extreme use case.
No other use case on the entire internet requires such an extremely large out-degree for end-user nodes in the node connection graph. Allocating connection-state, even a very small amount, opens up the least-powerful nodes to easy DoS attacks. And from there it's easy for a motivated attacker to push the network away from decentralization and force it in to a highly-centralized state.