owned this note
owned this note
Published
Linked with GitHub
# R: RLN
## Introduction and discuss the issue (fully anonymous environments, why it's hard to find a spammer) and abstract explanation of RLN (5 minutes)
## Some details on SSS and range trick (10 - 12 minutes)
## Use cases, infrastructure (libraries, contracts, etc.) (3 minutes)
## Current status (that we're in production , trusted setup, KZG-RLN mention, etc., call for contributions) (5 minutes)
## Q & A
# A: Using RLN in a peer to peer network
## How Waku/other p2p networks are affected by DoS (3 minutes)
- notes on DoS Prevention in web2, how they use ip tracing, kyc etc, which are not privacy preserving
- how Waku can make use of Semaphore / RLN, which is better suited for this purpose
- Why Waku goes with RLN instead of Semaphore, since RLN includes interpolation of spammers secret
- Some screenshots of spam (https://twitter.com/saulcarlin/status/1705251157478875620?t=cSJ8dVILxvM5KJAyvBGexg&s=19)
## The solution to anonymous DoS prevention, rln-relay (5 minutes)
- rln-relay is a libp2p pubsub validator that verifies rln proofs attached to messages that other peers have sent
- waku-rln-relay uses their own version of the rln-contract, which allows users to register for free (for now!)
- Animations of rln-relay from the logos research call
- Implementations in nwaku and go-waku (explain dependency tree)
- 
- Show performance graphs from simulations (https://github.com/waku-org/research/issues/23)
## Problems that were faced with rln-relay (2-3 minutes)
- Since the tree is stored off-chain, need to deal with async syncing of new memberships, by accepting proofs that refer to a merkle root from the last 5 state changes
- Persistent storage for the merkle to prevent re-syncing from scratch every time, using pmtree, persisting metadata (chainId, contractAddress, past roots, etc) of the same to prevent corruption to the tree
- Secure manner to store rln credentials, deriving from the bls keystore
- Tuning of database (sled db via pmtree) parameters to optimize for this usecase (x insertions every 12 seconds)
## How can you get started with Waku-RLN-Relay? (1 minute)

## Future work (2 minutes)
- Optimizations to zerokit for proof generation time.
- Incrementing tree depth from 20 to 32, to allow more memberships.
- Optimizations to the smart contract.
- An ability to signal validity of a message in different time windows.
## Q & A