Explanation series - Light protocols and edge nodes

This post is part of a series focusing on Waku's features. The goal is to help developers understand how they can leverage Waku for their own applications and projects.

History has consistently shown that centralised infrastructures are susceptible to censorship, particularly during critical periods when public access to information is the most crucial.

The Waku RLN Relay makes participation in the peer-to-peer network more feasible for household broadband by capping bandwidth. However, mobile and browser access still presents challenges for several reasons:

• The need for long-lasting connections to be well-connected in gossipsub or discover enough peers with discv5.
• Being mostly offline and unable to receive messages from gossipsub.
• Usage of UDP or TCP protocols which are not accessible in the browser.
• Most importantly, capped bandwidth requirements may not be low enough for mobile data plans to keep up with demand.

End users on mobile, browsers, or lower-capacity broadband connections, must also be able to use Waku in permissionless manner, without relying on a centralised party that may de-platform them or be shut down.

For this purpose, Waku defines a number of request-response protocols that mitigate these issues.

These protocols put browser and mobile devices at the edge of the network, outside of the more intensive Waku relay network, while enabling them to access data without trusting a single third-party. These request-response protocols are commonly referred to as light protocols.

Waku edge node

A non-relay node or edge node is a node that can send and receive messages to the Waku network without participating in the Waku relay network. A Waku edge node:

• Sends messages by requesting one or several service nodes to forward them to the relay network using the light push protocol.
• Subscribes to a subset of messages from the relay network by asking one or several service nodes to filter on content topic using the filter protocol.
• Discovers new peers by requesting service nodes to share the peers they found on discv5 using the Waku peer exchange protocol.
• Retrieves missed messages due to being offline or poor connectivity by requesting them from a service node using the store protocol.
• Performs various checks and redundant operations to ensure high message reliability.

Edge node caveats

The main caveat for a Waku edge node is weakened privacy compared with using gossipsub. By sending a message via a service node, the service node can link the edge node's IP address with the message metadata (content topic). However, using RLN means the service node cannot link the IP address to the user's wallet address.

Similarly, with the filter protocol, it enables the service node to link the edge node's IP address with their content topic of interest. Content topic is metadata that could be used to identify a potential user. To mitigate this, it's essential to design content topics appropriately. Aiming for one content topic for all messages in your application is an easy first step.

These caveats can be mitigated by placing a mixnet between the edge node and their service nodes. While this concept is not yet implemented, a raw specification is available.

The role of incentivisation

Relay nodes contribute to the network thanks to the tit-for-tat model of gossipsub. A relay node that attempts to be greedy with bandwidth will ultimately be disconnected by other peers.

However, this does not apply to edge nodes, as light protocols are designed to reduce edge node consumption of resources. Edge nodes consume resources from the network and do not contribute in return.

A project may run their own Waku infrastructure to support users with edge nodes. However, this may not be desirable if they wish to preserve decentralisation or avoid assigning devops resources.

While an altruistic model might work, we cannot solely rely on it to build a reliable and scalable network. A node consuming resources needs to be able to pay for them. This is the philosophy behind our ongoing work on incentivisation for light protocols. Our intent is to:

• Incentivise operators to run nodes to support edge nodes.
• Enable edge nodes to pay for the resources they consume on the network.

We can read more about it here and there. This is a work in progress.

Relay node usage of light protocols

In addition to benefiting edge nodes, light protocols also provide value to relay nodes. For example:

• A relay node that was previously offline may request missed messages from a service node using the store protocol.
• If a relay node does not subscribe to a specific network shard, it may request another relay node to forward a message using the light push protocol.
• A relay node seeking a quicker bootstrap process may request peers from a bootstrap node, rather than waiting for discv5 to run, using the Waku peer exchange protocol.
• Relay nodes may leverage a combination of light protocols to ensure high message reliability.

Adaptive nodes

The distinction between relay and edge nodes is a gradual concept. A relay node may participate in gossipsub for some shards (for example, where it expects to receive messages) but act as an edge node for other shards (for example, where it solely sends messages for another peer). You can read more about this adaptive node concept here.

As Waku is integrated into the Status application, we will establish usage patterns that balance privacy, bandwidth usage, and network stability. For example, a relay node may also be a service node on some light protocols, such as peer exchange, filter and light push, as Status Desktop does in relay mode.

Conclusion

The Waku protocols empower all devices to participate in a permissionless manner within the Waku network. Nodes with limited bandwidth or uptime capabilities can still access the network without the need for centralised gateways, which historically have been susceptible to being shut down when most needed.

Light protocols enable edge nodes to benefit from Waku's properties while also providing specific features for relay nodes, such as enhanced reliability.