Implementing RLN in Status: Why and How
One of the challenges in building a decentralized chat network with focus on privacy, is DoS protection. How do we prevent an attacker from joining the network and flooding it?
Effects of message flooding
The first question is: What happens when a user sends excessive messages on the network?
Because of the peer-to-peer aspect of the underlying Waku network, all users in the network would receive this message surplus. This would increase not only bandwidth usage for users, but also consume addition processor and memory resources.
On Desktop/relay mode, it would mean hogging the user’s bandwidth; it would also mean that the user’s Waku embedded node would not be able to keep up with the message flow and send messages to other nodes as per the libp2p-gossipsub protocol. Leading to peer descoring and ultimately getting disconnected from the network.
On mobile/light mode, the download bandwidth usage would also be impacted, as well as the memory and processor usage to process the incoming messages. Leading to both data plan and battery depletion.
Traditional Solutions
Traditional solutions to rate limiting, such as IP-based or email-based systems, are not suitable for a decentralized network. These solutions are often invasive to user privacy and can be easily circumvented by malicious actors. Instead, we need a solution that is both effective and respectful of user privacy. This was discussed in the original introduction of RLN.
Moreover, an IP-based solution does not work in a peer-to-peer system. Each Waku node do apply IP-based rate limit, but this would not prevent an attacker to connect to multiple nodes to flood the network.
Decentralized Solutions
Note that other peer-to-peer system such as BitTorrent or blockchain have their own mechanism to prevent this kind of attack, emerging from the nature of the data that can be transmitted. The key difference is that the data on those peer-to-peer network can be validated: is this transaction valid? Does this chunk belong to the right file? Whereas chat messages cannot be validated from their (encrypted) content; there is no meme police on the Waku network.
Farcaster is another great example, where rate limit, or storage fee, is applied to user’s data propagated on the hub network. The main difference with Waku and Status, is that data on Farcaster is not encrypted, user’s signature are in clear text, so it is easy to account the usage of each user.
Other decentralized chat systems do not have any solutions in place, as far as I am aware (feel free to forward me anything you find).
Introducing RLN: A Decentralized Rate Limiting Solution
RLN (Rate Limiting Nullifier) is a privacy-preserving rate limiting solution that uses a membership system to prevent abuse. In RLN, users deposit a small amount of assets to acquire a membership, which grants them a certain rate limit.
Each user is limited on the number of messages they can publish, across the whole network, per epoch. The current proposal is to set the epoch to 10 minutes.
RLN is setup to apply a global rate limit, which, coupled with a max valid message size, ensures that the total network bandwidth usage is capped.
By splitting the network in shards, or sub-networks, we are able to theorize the maximum bandwidth being used by a Status application instance.
Note that as usage of any Waku application grows, it would be possible to raise the global rate limit, in conjunction with the number of shards. It would enable more traffic and more users, while not increasing the traffic per users, as the number of shards a user should participate in remains limited.
Sybil Resistance
Note that another attack vector opens with a membership system. If an attacker can acquire enough memberships, to access a major portion of the globlal rate limit, they may be able to inject enough data to DoS the network.
Hence, it is important to have friction when acquiring an RLN membership, to prevent anyone from taking too many.
Phase 1: Deposit as Entry Point
In the first phase of RLN, users deposit a small amount of assets to acquire a membership. The proposed parameters are:
- $0.05 per message in the rate
- Membership lasts for 180 days, deposit can be re-used or refunded after his period.
From a user flow perspective:
- Users deposit $5 to a smart contract, and pays gas fee (if any)
- User can publish messages on Waku network (100msgs per 10min)
- After 6 month,
- user can either get their $5 back, spending some gas fee
- or, leave the $5 in the smart contract, and spend gas fee (if any) to renew membership
These are the parameters we implement for The Waku Network, we made educated guesses on appropriate values. Deciding on the right value is a difficult problem, the question being: what would an attacker be ready to pay to DoS the Waku network? Which answer is related to the applications using Waku. To give more insight, we set the lowest tier to 20 messages per epoch, and set a price of $1 to this. We then decided to keep it simple and have a linear relation between rate and cost. Hence, 5c per message in the rate ($0.05 * 20 = $1).
Of course, we can adjust these parameters for the Status application, and find a fine balance between cheap cost for legitimate usage, and unreasonable costs for potential attacks. Especially as we currently do not believe Chat protocols would be usable with 20 messages per 10min.
Phase 2: Diversifying Entry Points
We understand that most users expect to use a chat system for free. Hence, deposit assets, even if refundable, is a friction that we would want to remove as early as possible.
Again, friction is needed. The question is to design alternative entry points to acquiring RLN memberships. Without reducing the security of the system, or collecting private information from users.
There are many options for alternative entry points. Prioritization will need to take in account cost of implementation and what users actually want.
Proving on chain events or actions usually makes design easier, examples are:
- Staking SNT tokens
- Owning an ENS on Ethereum L1 or ENS chain
- Bridging tokens on Status chain
- Having some sort of onchain history (e.g., funds were added more than a year ago)
- Spent money on Codex storage
There are some off-chain data that can also be easily brought on-chain such as:
- Participated to some events (PSC, EF, etc) and can show POAP proof
- Owning a genuine keycard
- Used Status Wallet’s swap feature
- Own Android or iOS device with TEE.
RLNaaS: A Backup Solution
RLNaaS (RLN as a Service) is a backup solution that could allow Status to run a fleet of light push nodes that attach RLN proof to users’ messages. While this solution can provide a seamless experience for users, it weakens the security model. It also centralizes the infrastructure by necessity: rate limit needs to be applied “somewhere”. If not in the decentralized network, then a centralized entity can have their own traditional rate limit before attaching RLN proofs.
While not ideal, this is nonetheless an interesting, intermediary solution:
- This could be a stopgap solution until more decentralized and seamless solution are developed, potentially via Status Network, or some of the off-chain data examples above
- The intent would then to still get users to have their own RLN membership as early as possible, eg, on their first in wallet swap, or onchain interaction
- Blockage of the centralized infrastructure would only impact new, free, users, and would not impact sovereign user that acquired their own membership (whether at their own cost or via other pathways)
UX Implications of Rate Limit
Interaction with a smart contract has clear User Experience implications. Design will be needed, especially when going down the path of alternative entry points. However, I do not foresee anything specifically challenging in comparison to any other smart contract based application.
The main challenge lies in Implementing a rate limiting on messages sent by users. It has been decade since any form of rate limit has been lifted on SMS and other chat messages.
While every system do have rate limits in place. They are usually invisible to the most users, except in case of system failure.
A rate limit the author recently encountered
The end game will be to find a fine balance between setting a rate limit:
- high enough so it is invisible in “normal” usage of the application
- low enough so it does protect the network and users from DoS
The main challenge to this come from the existing chat protocols: How many Waku messages are generated in the background? How many Waku messages are generated when sending one chat messages in a one-to-one chat? In a group chat?
This the work being tackle by our new Chat research lead: define the behaviour of current private chat protocols (one-to-one chats and private groups), so we can quantify scalability and propose rate limit parameters.
Most likely, we will not be able to reach this fine balance at first. Simply because the current protocols are message hungry (MVDS, private group chats). But doing this work, will allow us to identify the biggest culprits and prioritize protocol upgrades.
Finally, it is unlikely we will be able to find a rate limit that is always invisible. Some power user are prone to reach the limit of whatever feels reasonable for the majority of users. Especially as we experiment and fine tune both the rate limit and protocols.
Traditional chat apps have some form of limit for new users: message length (Discord), number of available messages (Slack). The RLN rate limit may be an option here to encourage some form of premium usage of the app (e.g. Stake SNT tokens and you get higher Waku RLN membership - this is not a promise).
In conclusion, we need to design ux around RLN rate limit, probably aiming to keep it “invisible” in normal operations, and only enter a “slow mode”, etc, when the user gets close to the limit.
Roadmap
Because the chat protocols were not designed with rate limit in mind, we proposed to first implement a RLN-like local rate limit. Meaning a purely-software base rate limit. No zero-knowledge or smart contract just yet.
This would allow us to start working towards specific goals for the chat protocol, as well as iterating on the UX and UI.
Being a local rate limit means there can be flexibility on how it is applied, and potentially raised (it’s just a number in the code base).
The following step would be to consider upgrade path, which could first lead to just updating a number in the local DB. Later, it can become a tested way to increase membership rate of an actual RLN membership (or moving from RLNaaS to own RLN membership).
Once done, then the final steps will be to:
- Adjust the protocols and rate limit to reach this fine balance between usability and security, with the flexibility of a local/software rate limit
- Apply the rate limit at a network level, to get the actual security, by integrating RLN smart contract and zero-knowledge system.
Conclusion
RLN is the only existing solution to DoS protect a decentralized chat network, that aims to be both private and censorship-resistance.
The friction that RLN brings is intrinsic to its purpose. The same way that users nowadays have to provide email address and mobile numbers to join systems.
We acknowledge that most users expect usage of chat app to be free, and the intent is to leverage many blockchain and other technologies to enable smooth, yet secure and private, onboarding of users in the application.
No one has done anything like this before, hence we proposed staged roll-out where we focus on one problem at a time: rate limit on chat protocol first, then integrating zero-knowledge and smart contract interaction.
The involvement of the Status contributors on this endeavour will be critical in building a user friendly experience.
Please discuss any questions, concerns or feedback you may have.
