What is the definition of full nodes and light nodes?

[s-tikhomirov]

The reason why I want to get this classification straight is that #21 says that for now we think that full nodes can function even without explicit incentivization (purely on P2P reputation, sticky defaults, etc), while light clients need to be incentivized. I want to make sure I fully understand the distinction.

Currently, I have this mental model:

• there are a bunch of two-party protocols between a client (aka requester) and a server (aka responder);
• a full node can play both roles;
• a light node can only play the client role (i.e., it can ask for prior messages via store but can't respond to others' requests).

If this is true, then the full / light node distinction is per protocol, not per node?

Maybe we shall abandon the full / light node terminology altogether and talk only in terms of protocols? For example: how do we incentivize the store protocol such that the client rewards the server for its services? In this framing, we don't care whether the client can itself respond to others' store requests. We also don't care what other protocols these nodes run and whether they're considered "full" or "light" from that protocols' point of view.

[alrevuelta]

while light clients need to be incentivized

Well, light clients dont need incentives. They need to incentivice full nodes so that they get some services from them in exchange.

Currently, I have this mental model:

Correct

If this is true, then the full / light node distinction is per protocol, not per node?

The definition is a bit loose, mainly because waku is a suite of protocols that you can pile up like lego blocks to create your own node. So we don't really have 2 types of nodes, because with the protocols we have, the permutations are more.

But I can give some examples:

• If your node mounts filter and/or lightpush -> light node.
• If you mount store and relay -> imho full node.
• If you mount store+relay+filter (server) + lightpush(server) -> definetly full node.
• If you mount only relay (and not store) -> ???

Agree that we need consensus on this.

Maybe we shall abandon the full / light node terminology altogether and talk only in terms of protocols? For example: how do we incentivize the store protocol such that the client rewards the server for its services? In this framing, we don't care whether the client can itself respond to others' store requests. We also don't care what other protocols these nodes run and whether they're considered "full" or "light" from that protocols' point of view.

Few things here:

• afaik @jm-clius doesn't like this full/light node? But imho its quite useful because its a widely use terminology.
• The problem with abandoning this terminlogy, is that it is simple and understood by everybody, even if the definition is a bit loose. The protocol has to be understood not only by the core team but also by users, devs, etc. And full/light comes in very handy.
• Agree with the framing, but not sure how it affects to light/full terminology.

So

What is the definition of full nodes and light nodes?

If your node mounts relay and store, its a full client. If you just mount client filter/lp, then you are a light node. Everything in between, TBD.

[s-tikhomirov]

If you mount only relay (and not store) -> ???

Ethereum's terminology may be relevant here. From what I understand, full nodes in Ethereum are those that have independently validated all state transitions, and that can serve recent history to other nodes. Archival nodes, in addition, can serve older parts of history as well. Similar terminology may be used for Relay nodes with / without Store.

[alrevuelta]

Similar terminology may be used for Relay nodes with / without Store.

Perhaps we can use "archival" as the analogy with "store". So waku with just relay is considered a full node. But you can be a full node with or without store (same as you can be full node with/out archival).

In waku "independently validated all state transitions" would be "independently receive and send messages".

[jm-clius]

afaik @jm-clius doesn't like this full/light node?

I think (well I've realised) that it's inevitable that people are going to use these terms as they're so common in the domain. My point is simply that there isn't really a definition of a true "full" node or "light" node as it's almost always possible to make your node more resource-heavy by configuring more services or lighter by removing redundancy and using resource-restricted protocols. Waku prefers referring to "adaptive nodes", as it's possible to configure protocols over a continuum (see e.g. diagram at https://waku.org/about/architect/). I can see that "full" and "light" may be useful shorthand to refer to nodes that can run relay + store and those that can't, but I wouldn't want loss of nuance by being too binary here.

[s-tikhomirov]

I guess @jm-clius 's comment pretty much sums it up, thanks! I'm closing the issue.