feat(p2p/dht): disable dht server on Light node

[walldiss]

Implementation ideas

Currently Light node is configured in the way it runs both client and server. This seems to be not necessary, as there are Full nodes and bridge nodes that already act as servers and have much more resources to do so. We can disable dht server on LN, in favour of making it lighter.

[Wondertan]

Currently Light node is configured in the way it runs both client and server.

This is not exactly true. The LN is configured to run in the AUTO mode, which becomes the server only if dialable(detected by the AutoNAT protocol). This, in turn, ensures that LNs are real dialable servers that can contribute to the DHT network. Such a case is quite common, as Rollup FNs are Celestia LNs.

Before proceeding with this, we should prove that keeping the mode to AUTO causes some real issues or harms LNs because, at this point, it does not look like that's the case.

[renaynay]

agree with a testing-first approach

[cortze]

Before proceeding with this, we should prove that keeping the mode to AUTO causes some real issue or harm LNs, because it this point it does not look to me.

I agree with having some metrics first, but with so many different purposes to run Celestia's LNs, each use case affects node churn in quite different ways, and it's hard to correlate the use cases to behaviours.

I'd say that the safest approach would be to set LNs as DHT Clients by default, making it up to the LN's configuration to alter that decision. It should be clear to Rollups' dev-teams that they should run those nodes with the DHT server flag activated to ensure an optimal performance

[walldiss]

I'd say that the safest approach would be to set LNs as DHT Clients by default, making it up to the LN's configuration to alter that decision. It should be clear to Rollups' dev-teams that they should run those nodes with the DHT server flag activated to ensure an optimal performance

Agree, that LN are not good for being dht servers simply because they are not reliable. They also might be running in resource constraint environment or on low-end hardware. Enabling AUTO mod can contribute to less stable dht because of it.

[yiannisbot]

Perhaps starting from a more fundamental question will help the discussion (and my understanding:): is high churn (nodes joining and leaving frequently) affecting the network operation in a bad way?

• If not, then you can leave things as they are. AutoNAT should do it's job of figuring out if a node is dialable. If the node is not stable (churning a lot), then it will just not be available much. In principle, this is not a great thing to have, but it also depends on what the node is expected to do, how many high-churning nodes/LNs are there etc.
• If yes, then you'll have to find a better way to choose who to "grant" server permissions to.