ENS-Like NFTs for RLN

Waku
1

Looking at our current RLN solutions and the properties we may want to have, it seems that having ERC-721 API for RLN could assist in a number of cases.

Disclaimer: this is about discussing a specific idea and does not make any guarantee that this will or must happen.

Some context around RLN usability:

RLN performance and DoS protection mechanism:

Security Assumptions

Current assumptions for RLN as the Waku Network DoS protection mechanism:

  • 10k users/membership per shard
  • All users active at the same time doesn’t DoS network

Do note:

  • With RLN Sepolia contract no user cap is set
  • Currently it’s one RLN contract for all shard, there is no hard cap per shard.

We could probably increase user cap and assume % of users are active.
E.g. 50% of users are active at the same time, user cap can be increased to 20k per shard. Let’s call it A%.

As long as coordinated attacker doesn’t own more than said A%, network is assumed safe. Back of the napkin assumption. Attacker could own B%<A% and attack the network at busiest time. Also, parameters change with RLNv2

Slashing is questioned and from simulation assumes unnecessary at this point in time. Gossipsub peer score and the fact that spam messages are dropped seemed to be enough.

Hence, staking is not considered necessary at this point in time.

However, price of entry is needed to ensure attacker doesn’t easily acquire A% of membership. Or could use protocols such as proof of humanity but very high barrier of entry.

Price of entry needs to be:

  • low enough so that users/projects/etc buy membership
  • high enough so it deters attackers.

Cost of Attack

In terms of deterring attackers, a proper study would be needed to understand what price would deter attackers to acquired a bunch of RLN memberships and attempt to flood the network.

Some case studies may be interesting:

Game Stop short squeeze as a historical occurrence of deplatforming by Discord. The Discord had around 250-300k users ([1], [2]) and cost around $6 billion to short sellers.

Is is unclear in this situation, whether one of the involved entity would have aimed to take down the communication network. After all, nobody DDoS Discord

DDoS of Telegram during HK unrests.

Standard cost of buying a fleet of Zombie bots on darknet.

Cost to User

In terms of price of entry, looking at market examples (only looking from a user PoC):

  • Whatsapp used to be $1/y.
  • Cheapest ENS is $5/y.

Not that gas needs to be taken in account.

Further analysis should be done once store protocol is incentivized and comparing to infra price (e.g. firebase) or other chat apps (Slack, Discord).

Other Potential Issues

Accumulated Abandoned Memberships

If there are no recycle system for unused memberships, then we may end up in a situation where we are unable to truly understand the activity volume and relation to members, e.g. A%. It may also be more difficult to handle a membership capped being reached if the network operates well within capacity.

Securing Credentials

Securing RLN credentials is a whole problem in itself. If done poorly, we may need to re-invent the while and a decade of wallet management to ensure users do not loose or compromise their RLN credentials.

Do note this starts to matter from the moment the user spends mainnet asset to get said membership.

Also note that we currently accept that credentials are passed to webapp code. Meaning a fraudulent webapp could simply steal the user’s credentials.
The only ways around that are:

  • one set of creds per app; assuming user does not pay
  • RLN credentials are handled like private keys: only in a browser extension. whether it’s a Waku one or PSE one.

Credentials Management

Beyond securing credentials, users might want to be able to easily transfer ownership or sell their credentials. Especially if the acquisition price is high enough that they may want to recover funds.

Also note that in scenarios where Alice pays for Bob (e.g. Alice is project dev or community owner), then Alice may want to recycle Bob’s credentials if Bob becomes inactive, stops being a user (e.g. does not own RAILGUN note) or gets banned.

Credentials Accumulation

Unsure if this is a real problem. In a scenario where one could:

  • steady acquisition of membership over time (buying when price/gas is low)
  • theft/hacks stealing user credentials.

Then this could be similar to a zombie bot process: Slowly accumulate creds over time and sell them to the highest buyer to DoS a specific shard/app.

Ideal Properties

As a summary of the above, the ideal properties for RLN credentials are:

  • User pays a fee.
  • Fee is a stable (E.g. USD vs ETH) and configurable by contract root (e.g. DAO proposal to change fee are possible
  • Fee is time limited
    • to recycle unused creds
    • to avoid accumulation of creds over time
  • Security leverage existing frameworks (e.g. wallets)
    • Protect users against themselves and hacks
    • Recovery is easy
  • Ownership is transferable and re-usable
    • Because of its value
    • Enabling recycling when end user does not pay

Proposed Solution: ENS-Like NFT

Pricing

  • To acquire credentials, by a NFT for a time period: e.g. $1/y
  • Oracle is used for pre-set price in USD, payable in ETH/chain native token.

NFT ERC-721 API

  • NFT can be transferred or sold
  • Owner of the NFT can register in RLN contract
    • Owner of NFT #42 can register membership #42 (impl detail)
    • can also edit #42 in case of user ban, creds loss to web app, creds loss to faulty storage, NFT transfer
    • some mapping is needed, Maybe rln tree is pre generated and NFT # matches membership # that can be edited.
  • leverage existing NFT tech. Membership rights fully secured by Wallet, hardware wallet etc. No new tech stack to secure creds.
  • Right API to batch mint and update RLN credentials (maybe just on lib)
    • or maybe API similar to ENS setText is used on NFT contract to set creds which then delegate to RLN contract. Meaning from wallet dev PoV, very similar API to ENS, easier to integrate.
  • community owner/project can batch buy/secure 100 NFT. Keeps ownership. Can edit any membership (add or ban member).
    • when banning user, rln slot is not lost, can re use it for another user.
  • same for app building on Waku or any user.
  • anyone has the security that they can sell their NFT if doesn’t work out/stop using RLN.

Security

  • NFT owner can delegate RLN rights to another address.
    • Meaning RLN NFT can be done by secure wallet (e.g. hardware)
    • Delegates RLN creds edit/registration to address with minimal gas.
    • Said address can have private key passed to Waku node for RLN insertion.
    • If compromised, only gas is lost.
    • Most likely betterthan using UI and pass RLN keystore to node.
    • RLN credentials become less sensitive
    • If credentials passed to a scam web dApp, only gas to edit is lost.
      – If scam stole lots of credentials, just need enough users to reset them.

Expiry logic

  • NFT expires a la ENS
  • No need to clean up per se, from expiry, prev owner cant edit membership
  • expired NFT are next in line next time someone “mint”/“buys” a fresh membership (ie, not from second hand market).
  • RLN contract owner may be able to clean up expired NFT but not sure it matters

This way, there is a clearer metrics of the true # of users (# of active NFT).

Renew logic

  • ENS has some cool down period where price is 10x
  • RLN are not as interesting so probably cool off where only previous owner can renew. Then can be normal price.
  • Could be 10x in case pool is full but allocating more shards should probably be better action.

Clout

Doesn’t really matter but clout effect where one can brag Waku user by own NFT.
Could be use in some way at events for social etc.
Careful with privacy.

Slashing

May still be possible, using secret on RLN contract could lead to allocating matching NFT to slasher?

Conclusion

There seems to be a number of benefit from user security, user experience and network insight on using a ERC-721 API for interaction with the RLN contract.

We need to better understand how RLN is received by developers and what are the main friction points before considering such a solution.

4 Likes
2

Couple of points I want to emphasis.

  • The keys used to BUY the membership CANNOT be the same than for creating proofs. That would be impossible to have good enough security. Copying around your secret keys is not safe, not to mention that it can’t be done with hardware wallets. Also, if some valid keys are leaked publicly, it would mean that valid proofs could be created by anyone.
  • The OWNER of the membership should not have to be the user. Delegation is a must.

Overall, a system similar to ENS seams promising.

3

I would like to build upon your idea with what I envision a Harberger tax on RLN membership would look like.

To me your idea of NFTs is great except the ownership model.

Instead of a fixed price, ALL NFTs (membership slots) would be on sale at all times, used or not. The price would be determined by the buyer if unused or the owner.

The trick is that owning a slot means paying a % of the chosen price in tax each month. Tax revenue go to a Waku DAO.

This Harberger tax optimize for allocation efficiency over other metrics. It seams to be a system where all incentives are aligned. Devs are rewarded with tax revenue only if they build useful protocols. Only people who find Waku useful would buy memberships. As usefulness of Waku increase price increases.

The system is simple but has very wide ramification. It can also feels weird to not actually own anything but I believe that if it’s clear how the system work people will be ok with it. We live in cryptoland let’s experiment!

4

Interesting. With Harberger tax, you get to a state where everyone just pays tax on the price that is marginally higher than unused/new membership - such that it is never optimal for a newcomer to buy out their membership. (It gets more interesting only when memberships become scarce.) In this form, I think it is quite equivalent to an ENS model where you only introduce additional complexity and risk for users.

One problem I see here is the risk of a targeted attack. I am not sure I envision the implementation the same way as you but I think this can be potentially harmful: If I see that my favourite CT antagonist has an RLN membership in his wallet, I can buy it off (prob for x-times the normal price) and strip him of his identity or the ability to post in WN. It makes him potentially money but it’s annoying.

5

I like the idea. One thing to note is that ERC1155 might be a more suitable standard than using the normal ERC720. It implements batch transfers that can simplify the operations for community owners.

6

With Harberger tax, you get to a state where everyone just pays tax on the price that is marginally higher than unused/new membership - such that it is never optimal for a newcomer to buy out their membership. (It gets more interesting only when memberships become scarce.)

Each shard has a limit on members but at first you are right that’s what would happen.

One problem I see here is the risk of a targeted attack. I am not sure I envision the implementation the same way as you but I think this can be potentially harmful: If I see that my favourite CT antagonist has an RLN membership in his wallet, I can buy it off (prob for x-times the normal price) and strip him of his identity or the ability to post in WN. It makes him potentially money but it’s annoying.

I was assuming that owners could be anonymous maybe it’s not the case I’m not sure.

7

Not sure I understand your statement.

So there is key A which is the private of the blockchain account used to buy the membership.

There is secret B, which is the RLN secret used to generate proof (the RLN membership is the poseidon hash of the secret)

Are you saying that A and B should be different?

I think that’s expected as we do not expect users to directly use their account private key as RLN secret.

Are you also saying that we should not derive B from A, for example, by using the hash of the signature of a message signed by key A?

This is one of the benefit of this approach. Ethereum private key A used to buy the NFT can be secured by a hardware wallet, as usual.

Now, secret B could even be generated in the browser and given access to the JS code.
If this key is compromised, then the user can register new RLN credentials by only paying gas.

Do note that I am also planning some exploration around securing RLN credentials. But even with the least secure way of using RLN credentials, the proposed strategy still allows minimal cost of recovery to the user.

So yes, one of the advantage of this approach is that one could have:

  • Wallet A, hardware wallet, very secure, used this to buy the NFT, or even buy several NFTs (e.g. could be one per dApp or just want access to higher rate limit)
  • Delegates “RLN edit permissions” wallet B, which is a software wallet (extension, mobile) with minimal asset on it (just enough to pay gas to edit RLN membership).

I don’t think it has to be this way though as we don’t want a user to have to edit their RLN membership too often. Wallet A could have full power.
But delegation does enable a more advanced security setup.

Am I missing something?

The issue is that once the RLN membership is set in the group, then there is no way to know if the NFT is “used”, is there? Please define “unused”.

Looking a the RLN design patterns currently identified I am not sure I see the space for a monthly payment by the user.
Maybe if a community owner pays for the membership then they could pay monthly, the same way they would pay Slack or AWS usage monthly. But we do need flexibility and I imagine in the case a user pays for their own membership, a yearly or even 3-5 yearly membership is likely to be more appropriate.

Also do note that if we see usage of the Waku network, then I’d expect we upgrade the network by releasing more shards.
In this case, we would then also increase the cap of memberships (whether or not the memberships are set per shards or globally as it is today).

So we need to take that in account with a Harberger tax. E.g. backlash if a portion of users paid premium to get memberships when full and we shortly release more memberships.

Yes, this is definitely a potential path to sustainability. However, I think it is sensible to adopt a similar approach to ENS DAO where the price is set as a deterrent to domain name/RLN membership hogging, and not purely set as a revenue stream (at least that my understanding of ENS fees, happy to be told otherwise).

Interesting. Yes, makes sense.

In the proposal above, the right to a membership is represented by an NFT, so it’s visible what address owns it.
Which is the same than today: you can see what addresses interacted with the RLN contract and inserted a membership.

Not sure if you had a different idea to NFTs for the Haberger Tax.

8

I think that’s expected as we do not expect users to directly use their account private key as RLN secret.

Yes exactly. I wanted to emphasis what you said.

Are you also saying that we should not derive B from A, for example, by using the hash of the signature of a message signed by key A?

The ownership should be private IMO. How, is another matter.

Do note that I am also planning some exploration around securing RLN credentials. But even with the least secure way of using RLN credentials, the proposed strategy still allows minimal cost of recovery to the user.

Another problem, the system cannot prevent the sharing of RLN credentials. Only one membership could be sold and the credential shared publicly. Defeating the entire system (member video game piracy?).

The issue is that once the RLN membership is set in the group, then there is no way to know if the NFT is “used”, is there? Please define “unused”.

Used is when taxes are payed.

Looking a the RLN design patterns currently identified I am not sure I see the space for a monthly payment by the user.
Maybe if a community owner pays for the membership then they could pay monthly, the same way they would pay Slack or AWS usage monthly. But we do need flexibility and I imagine in the case a user pays for their own membership, a yearly or even 3-5 yearly membership is likely to be more appropriate.

When or how you pay are details. What matters is that not paying your taxes invalidate your membership.

So we need to take that in account with a Harberger tax. E.g. backlash if a portion of users paid premium to get memberships when full and we shortly release more memberships.

The price is determined by the owner and can be changed at anytime. If for whatever reason the value of the membership decrease then the price too. The only party hurt would be the tax collectors.

Also, new shard by definition don’t have users so no k-anonymity and thus less valuable.

9

I don’t really see this as a problem, it could even be a feature. As long as it’s done under the control of the payer.

For example. assuming we use RLNv2 set to 1000 msgs/days.
A Community owner buying 100 memberships basically buys a capacity of 10k msgs/day.

In this case, more flexibility the community owner has to use their membership, better it is. They could distribute 1 membership to every new comer, but then provide more membership to most active users. They could also recycle memberships for users that drop out or become less active.

In this model, then smaller memberships would make more sense. E.g. buying 1000 memberships at 100 msgs/days.

When you give a membership to a new user, you only “lock” 0.1% of your total bought capacity. The app can also have a social model similar to what is already done: as a user becomes more and more active, it gets higher in the social rank (newbie > engineer > hero > superhero etc) and each social rank could increase the number of memberships they are allocated.

1 Like