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 Design Patterns - Practical Development and UX Best Practices · Issue #102 · waku-org/pm · GitHub
- RLN in resource-restricted clients · Issue #45 · waku-org/research · GitHub
RLN performance and DoS protection mechanism:
- Capped Bandwidth in Waku · Issue #22 · waku-org/research · GitHub
- Waku's maximum bandwidth for global adoption · Issue #31 · waku-org/research · GitHub
- RLN Key Benchmarks · Issue #23 · waku-org/research · GitHub
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
- 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.
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:
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.
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).
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 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.
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.
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.
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
- 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 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
setTextis 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.
- or maybe API similar to ENS
- 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.
- 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.
- 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).
- 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.
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.
May still be possible, using secret on RLN contract could lead to allocating matching NFT to slasher?
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.