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