The Cost of RLN Memberships: Diversifying the Entrypoints

Waku
1

In Explanation series - Waku Service Marketplace I hinted that RLN membership’s “deposit to play” model is the vanilla version of membership acquisition.

Let’s expand on this.

Why do we need a cost to membership?

RLN’s membership system is a rate limiting strategy to ensure that no user can come in and DoS other users out of Waku Relay. You can learn more about it in Explanation series - RLN Relay

The cost to acquire an RLN membership is a security measure to ensure that an attacker does not flood the network for a cheap price.

It is used in lieu of PIIs traditionally employed to protect Internet systems (phone number, IP address, email address), which are usually invasive to user’s privacy (as originally explained in Privacy-preserving p2p economic spam protection in Waku v2 | Vac Research).

Other strategies such as CAPTCHA are inherently centralized, which does not align with our principles either.

Finally, the total number of RLN memberships are capped on the smart contract at any point in time - more on that at the end.

tl;dr:

  • we don’t want to use centralized or intrusive privacy to DoS protect Waku networks
  • so we ask people to put a deposit down to get a RLN membership
  • We prevent potential attackers to flood the network
  • We prevent potential attackers to hog all the memberships

Phase 1: Deposit

In phase 1, users deposit an amount, proportional to the rate limit they get, in the RLN smart contract to get a membership for a period of time.

Proposed parameters are:

  • $0.05 per message in the rate (e.g. $5 for 100 msgs per 10 min)
  • For 180 days
  • After 180 days, they can either withdraw their deposit, and renew the membership by sending a transaction that would re-use the existing deposit.

Phase 2: Diversify

The deposit is a deliberate friction so that potential attackers don’t just “grab all memberships”. However, we can easily imagine how many kind of off-chain action could be warrant access to a RLN membership:

  • User staked X SNT token. This could allow a short term membership (e.g. 1 month); membership rate limit could be related to number of staked token;
  • User owns an ENS on Ethereum L1 or ENS chain; and proves it; the membership length could even be related to ENS expiry time;
  • User has bridged tokens on Status chain
  • User has some sort of other onchain history; e.g. Funds were added more than a year ago
  • User swapped assets in Status wallet within the past month
  • User owns a farcaster account
  • User spent $100 on Codex storage
  • User used dApps on Status chain
  • User deposited assets to a RAILGUN smart contract
  • etc

Of course, each of those needs to be carefully reviewed to ensure that potential attackers cannot cheaply accumulate entry tickets to potential attack the network

Conclusion

While the initial RLN model involves users depositing assets to get a membership, we understand that onboarding friction is undesired.
This model is the first version of RLN, and as RLN integration progresses in application, we expected a diversification in the requirements to acquire an RLN membership.

global rate limit

The global rate limit is tightly linked to the network capacity, which itself is linked to the number of shards in the network.

The intent isn’t to cap the total number of user per se. But instead, to be able to predict and plan network capacity increase by monitoring the memberships in the smart contract, actual traffic on thje network and eventually increase the number of used shards.

4 Likes
2

Another note here, is that the above also applies to Explanation series - Waku Service Marketplace

Whether you are giving free RLN memberships or free credits to users, there must be some cost or friction to limit the access to a limited pool of resources.

3

Another point is that subsidies or free RLN membership can either be distributed:

  1. via onchain events, that can be verified by a smart contract which in turns distribute subsidies. Project such as wormhole can help give free RLN membership based on events from a different chain
  2. via off-chain data, meaning that a centralized entity has to distribute the fees. Said data could be a mobile phone number (not ideal).

A 3rd option is looking at oracle solutions where off-chain data becomes onchain event. But this is tricky when talking about individual data here.
Something such as Twitter or GitHub reputation was considered but existing solutions were inadequate.

1 Like
4

Another potential entrypoint: GitHub - rarimo/passport-contracts: Decentralized Identity Issuance Contracts (your passport!)

5

I fully support this direction. The friction is intentional, but its form can be adjusted.

I look at the problem like this:

Modeling Protection

RLN addresses two key issues:

  1. Excessive message protection – Managed via Account-Based Rate Limiting .
  2. Sybil Resistance – Account-Based Rate Limiting is ineffective if users can create unlimited accounts.

Sybil Resistance depends on two factors, with the strongest protection optimizing this equation:

Sybil Resistance = Difficulty(in acquiring an account) x Cost(of losing the account)

When account Difficulty is lowered to improve onboarding, there is a corresponding drop to network protection — if the Cost is not increased.

Phase 1 - Collateral

In Phase 1, the Difficulty is performing a transaction, and the Cost is forfeiting the funds. To be effective, the total Cost of memberships must be sufficiently high, as accounts are trivial to generate. In handwavy terms the model follow this equation:

\sum_n^? ({Cost_a(n)}) > E(Reward_a)*n

The network is only ever protected if the costs of performing an action a , strictly exceeds the expected reward for performing that action n times.

As mentioned, solving this sufficiently increases friction on users.

Phase 2 - Vouchers

In Phase 2, the Difficulty is building an onchain presence, and the Cost is losing access

In many of these cases I would argue the Difficulty has increased — particularly if there is a historical component required. From a large-scale attack perspective, acquiring enough qualifying accounts would likely be more expensive than using the collateral-based approach. Choosing parameters that leverage users’ existing efforts while making large-scale exploitation difficult increases Difficulty without adding friction.

While the Cost is less than in Phase 1, the difficulty of amassing accounts offsets this.

Implementing this provides easy access to some, but may be limiting to others, given the Difficulty required to achieve Sybil Resistance.

Balance

The two approaches complement each other.

  • Collateral: Open and Inclusive, but has strict penalties.
  • Vouchers: Easier onboarding, but not as inclusive.

By providing both options, this allows each sets are parameters to be tuned to their specific use cases.

  • Phase 2 can optimize onboarding and usage for a subset of low-risk accounts
  • Phase 1 can be focus on being being a secure general solution
1 Like
6

Who are Users

For clarity I would suggest in this context, the “users” are really app developers — Those developing the software that interact with the network. Similar to a more traditional api-rate limit; App developers are ultimately responsible for the number of messages sent onto the system.

Whether they choose to sponsor the fees themselves, pass them directly to their “users”, or some other solution entirely is up to them.

This distinction matters when considering UX and risk profiles. Taking a stance similar to Account abstraction and Paymasters, ensures the most flexibility for developers on the network, while also embracing Decentralized and Permission-less operation.

1 Like
7

At this point in time, we do not intend to implement slashing for RLN Relay. Meaning that there is no onchain cost of an attack.
However, an attacker would have spent resources (bandwidth, nodes, IPs, CPUs) to do an attack and ultimately get disconnected from the network via gossipsub peer scoring.
They can re-attack after an epoch, but the resources are lost.

The question is whether this would be enough to deter an attacker. Do note that we have not made any decision that would prevent the introduction of slashing at a later stage.

In terms of using various entrypoint (other than a deposit) in RLN. Slashing remain an option. When slashing, the RLN secret is revealed and unlinkability between the smart contract interaction (eg Ethereum account and any info you may have pushed, such as proving you own a keycard and its cert) are lost.
Meaning that the spammer will get identified.
Slashing could then lead to a “ban” on a smart contract for this specific identifier, Stopping the attacker to re-join and them to acquire another way to join the membership set.

Interep is a good example for this. While we don’t think interep is worth integrating, we did look into it (should be find some traces in this present forum),

8

While agree with this statement, I think it’s important to remember that to ensure long term decentralization and permissionlessness of the network, spam protection needs to remain at the edge (your own words :slight_smile: ).

App developer should strong be encouraged for RLN membership ownership to be the default/preferred path for users.

Solutions such as RLNaaS, where a project runs a flight of light push nodes that attach RLN Proof to users’ message are an option. But it would weaken the security model and could potentially lead to what email provider are today: a cartel controlling entry to new comers via spam protection mechanisms.

1 Like