Light clients shouldn't insert themselves in the DHT

[tomaka]

EDIT: (see description below)

[expenses]

This seems fairly simple, but it's not super clear where a client adds itself to kademlia.

substrate/core/network/src/discovery.rs

Lines 105 to 108 in eda5fe5

	let mut kademlia = Kademlia::new(local_id.clone(), store);
	for (peer_id, addr) in &user_defined {
	kademlia.add_address(peer_id, addr.clone());
	}

Here?

[tomaka]

No. Nodes insert you in their buckets when you connect to them. That code is in libp2p-kad.

This issue is IMO extremely complex to tackle and requires some research efforts.

[expenses]

Oh ok, good to know! Do you thing you could mark this issue as Q5-substantial or above?

[tomaka]

To give some context.

We use the DHT in order to discover nodes to connect to.

Right now, full and light nodes are both present in the DHT. What can happen at the moment is that, by randomly walking through the DHT to discover nodes, if the number of light nodes compared to the number of full nodes is high enough, then we might only discover light nodes.

This is bad, because what we need is connections to full nodes in order to function properly. Light nodes are purely parasites at the moment.
Similarly, light nodes also need to connect to full nodes in order to function. A light node connecting to another light node is totally useless, and they can't do anything with that connection.

We also have no way to know whether a node is full or light when we find it in the DHT. We have to connect to it and ask.

In order to solve that problem, the solution that this issue title implies is that only full nodes are present in the DHT. Both light nodes and full nodes would find only full nodes to connect to through the DHT. Light nodes would also therefore never connect to each other directly.
There could, however, be other solutions to this problem.

cc @infinity0 @burdges

[tomaka]

This issue isn't urgent at the moment because the ratio of light nodes per full node on the existing networks is something like 1 to 100. Nobody uses light clients at the moment, except occasionally someone who tries if they work.

However if we start advertising light clients, or releasing a UI containing a light client for example, then this issue will need to be tackled first.

[expenses]

So I suppose a solution would be to allow nodes to send a message saying that they shouldn't be added into the DHT?

[burdges]

What are the key and record for this DHT? If our key or record includes a cryptographic key, then we could ask that DHT entries be signed by their key, so nodes must explicitly ask for inclusion.

We're maybe worried about adversarial spam DHT entries eventually, which makes everything harder. We could however privilege buckets whose key played some on-chain role and randomly drop others when the DHT came under excessive load, but.. We've have many roles for the relay chain already with some that sound tricky to recognize, ala fishermen. And parachain specific roles make this much worse. If this becomes our approach then we could still punt on classifying the roles for quite a while.

We cannot easily recognize a "full node" in such an adversarial setting. I could find some tricks like using H(KEX(bucket_holder_key,bucket_maker_key) || time) to identify some chain state the bucket maker must tell the bucket holder that the bucket holder should already know and can verify as correct.

Anyways, my first question is simply: How far will simply asking the DHT entries be signed go? Even if we ask for nothing about the signing key?

[tomaka]

What are the key and record for this DHT?

Anyways, my first question is simply: How far will simply asking the DHT entries be signed go? Even if we ask for nothing about the signing key?

We're not using the key/value system of Kademlia, but only the FIND_PEER messages.

The keys are therefore the identities of the nodes, and there's no associated value.
When a node connects to us, we (try to) insert it in our buckets. That's the only situation where we add an entry to the buckets.
Therefore the key is already signed through the encryption handshake.

[burdges]

I see. You want nodes to make claim about their roles or desired roles when introducing themselves initially then?

[tomaka]

You want nodes to make claim about their roles or desired roles when introducing themselves initially then?

Yes, that's one possibility.
But that would solve only light nodes vs full nodes, and it might have implications on how the DHT behaves. For example, if nodes sometimes report that they are light and sometimes full, then the record storage system might not work properly, and that could make it possible to hide validator identities (we're storing validator identities in the DHT).

I also feel like there should be a way to extend this mechanism for nodes belonging/collating for parachains for example. I would therefore put this issue in the "DHT research" bucket.

[infinity0]

I thought w3f/parity wrote its own version of libp2p in rust, isn't this simply a case of pinging the author of that and ask him to provide a knob to do what this issue requires (i.e. for certain nodes to not add themselves to the DHT)?

[burdges]

We change rust-libp2p as we see fit :) which makes @tomaka the relevant author.

[infinity0]

Ultimately the DHT needs an access policy that prevents light clients from adding themselves even if they tried to.