Explanation series - RLN Relay

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.

Peer-to-peer networks, DDoS, and resource usage

Any system, including peer-to-peer networks, may face Denial-of-Service (DoS) issues, where users cannot access or use the system as intended.

Recommended strategies to mitigate DoS attacks can be challenging to apply when the entire infrastructure is not managed by one entity, such as in a peer-to-peer network.

Looking specifically at libp2p gossipsub, a DoS can occur due to:

• A node not having enough bandwidth to correctly run gossipsub, leading to a decrease in their score and disconnection from the network.
• A node not having enough resources (CPU, memory, etc.) to process all incoming messages and behave as expected from an application perspective.

Existing peer-to-peer systems have intrinsic and deliberate mechanisms to mitigate these scenarios.

For example, in blockchain systems, there are intrinsic protections:

• Most blocks and transactions are exchanged on the p2p layer.
• Blocks and transaction messages are limited in nature.

And deliberate protections:

• Block messages' sizes are limited, either explicitly or via gas limits.
• A cap on mempool can be set by default across implementations to ensure that transactions do not grow beyond a given threshold.
• Validation steps for incoming messages are purposefully implemented from cheapest to most expensive, ensuring that validation steps do not hog CPU or RAM.

Not all systems lend themselves to such rules. The most trivial example is chat applications, where any chat message could be considered a valid message.

Similarly, in an AI inference system, any prompt could be considered a valid prompt. While some size limit and encoding validation could be applied, this would not be enough to protect a network.

Finally, adding end-to-end encryption can make it difficult to implement these protections, as it may prevent nodes from validating incoming messages.

Waku RLN Relay

Waku RLN (Rate Limiting Nullifier) Relay solves the DoS problem for gossipsub networks by limiting the number of messages one can send over a given period of time.

This, combined with a message size limit, enables capping the traffic over the network.

With a capped bandwidth, one can ensure that all nodes in the network have enough resources to process all traffic and avoid being DoS'd.

This comes with a number of conditions:

Publishers must register with friction

Publishers must register to send messages, similar to acquiring an API key to access a REST API.

This registration must have some friction to protect the network, similar to a Web2 service asking for an email address or a phone number.

In the case of RLN, this is done by registering a membership on a smart contract. The proposed parameters are:

• Select a rate limit between 20 to 600 messages per 10 minutes.
• Price is $0.05 per message per epoch for 180 days. For example, to register to send 100 messages per 10 minutes, pay $5 every six months.
• The contract will be deployed on a specific Layer 2.

A maximum message size must be set

If message size is unbounded, it defeats the purpose of a rate limit.

For the Waku Network, we propose a maximum message size of 150 kilobytes.

A global rate limit must be set

A global rate limit must be applied to the network to enable DoS protection.

This limit can also be used as a guarantee of reasonable bandwidth usage.

For the Waku Network, we propose:

• A maximum of 160,000 messages per epoch of 10 minutes
• Network split into 8 shards

160,000 messages per 10 minutes means 266 messages per second. Assuming an average message size of 4KB leads to an average traffic of 6 Mbps. See Capped Bandwidth in Waku for details.

RLNaaS

RLN-as-a-Service (RLNaaS) describes a strategy where a service node holds membership and attaches proof to incoming messages via light client protocol. This approach enables end users to publish messages without interacting with the RLN smart contract.

This feature is available on the Waku Network, and dogfooding efforts are ongoing. While we are considering deploying RLNaaS in the Status app and using it for an incentivisation MVP, it is essential to note that this strategy has drawbacks.

First, it alters the network topology, forcing all publishers to become lightpush clients only, without also contributing as relay nodes.

Second, it shifts spam protection away from the network’s edge, potentially compromising openness, sovereignty, and permissionless access.

Waku’s principles

Waku is part of the Logos technology stack. It is designed to be decentralised, privacy-preserving and censorship-resistant. Those principles guide the choices made when designing Waku.

For example, an obvious rate-limiting solution would be for users to sign their messages and rate limit per public key. While this may work, it removes anonymity by enabling any observer to:

• link the sender of a message (signature) with the related Ethereum address
• link messages from the same sender (same public key)

It also removes censorship resistance, as a node could choose to drop messages signed with a specific public key. This is why a zero-knowledge solution was selected.

Alternative deployments

The parameters chosen are for the Waku Network, a shared permissionless network supported by thousands of volunteer nodes.

These parameters enable anyone to build meaningful applications and make them accessible to users in a permissionless manner. However, no given set of parameters can accommodate all use cases.

Waku defines light client protocols to reduce resource usage, especially for mobile and browser clients, though they do not contribute to sustaining the network.

There may be use cases where maximum bandwidth usage should be much lower, such as when users are in a geographical area with limited access to bandwidth.

On the other hand, if all nodes on a network are expected to run in data centres with gigabyte links, then the global rate limit, max message size, or max rate limit per membership may need to be much higher.

Finally, depositing assets as a way to acquire a membership is a generalised approach to introducing friction, and a system that can identify its users on-chain may choose an alternative method.

Projects may decide to use the RLN smart contract deployed by the Waku team or their own. Changing parameters must be considered carefully and account for the resources of the nodes in the network. Setting parameters to unbound the global rate limit defeats the purpose of having DoS protection in the first place. This is similar to selecting a rate limit for an API key or deploying Cloudflare to protect a centralised infrastructure.

Caveats

Deploying your own Waku network and RLN contract has a number of drawbacks.

There is strength in numbers. A smaller network of nodes can lead to reliability issues for gossipsub, as well as decreased privacy and censorship-resistance properties. This should especially be considered if most of your user base runs on browser or mobile, as they do not contribute to the network.

You may also need to run your own bootstrap nodes to allow your users to bootstrap in your network, or your own store node to support your end users.

Is RLN useful to my project?

Security measures may not seem necessary until harm is done, which is why DoS protecting a gossipsub network may be overlooked at first. From our experience, projects can fall into three categories:

1. Intrinsic DoS protection: Similar to a blockchain system, your users may already be limited in some way to send valid messages on the network. In this instance, RLN may be considered if the intrinsic limit is not enough. This could be the case if validating messages is costly, either due to computation or reliance on an external system.
2. Permissioned approach: Some systems have implemented a permissioned approach where new providers or nodes need to be whitelisted to participate. In this instance, only good actors are participating in this specific p2p network, reducing the risk of DoS. Such an approach brings a centralised component to the system, which may be an issue for various reasons, such as security, regulation, and resilience, as well as reducing competition opportunities. Using Waku RLN Relay can help remove this central authority while keeping the system secure.
3. Unprotected: As mentioned, security measures may seem necessary until they are. Some projects run on unprotected gossipsub networks, which are prone to DDoS. The question to ask is: what prevents a node from coming in and injecting tons of data? This is particularly relevant when encryption is used.

If your project falls into any of those categories and you are considering using Waku, we recommend visiting https://docs.waku.org or reaching out to the Waku team. Discord (https://discord.waku.org) or Twitter (https://x.com/waku_org) are currently the easiest ways to do so.