# RLNv2: enhanced spam protection for all peer-to-peer networks | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 52:29
- Watch: https://streameth.org/watch/yt-EH6zUu6AzlQ
- YouTube: https://www.youtube.com/watch?v=EH6zUu6AzlQ

## Description

RLN is a protocol designed to prevent DoS attacks in a privacy-preserving manner. It uses zero-knowledge proof to limit the number of actions a user can take. In a p2p network, it can be used to limit messages sent over a period of time by one sender. RLN’s latest upgrade limits to N (instead of 1) messages per epoch. Also, the Merkle tree is now built on-chain, greatly improving the UX.

Come learn how to use an implementation of RLNv2 to DoS protect a peer-to-peer network.

Speaker(s): Franck Royer, Alvaro
Skill level: Intermediate
Track: Cypherpunk & Privacy
Keywords: Privacy, Censorship Resistance, Decentralization, Zero-Knowledge, network, peer-to-peer

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] hello everyone well today we're going to be talking about waku H waku is a decentralized protocol for messaging that allows you to send a message from point A to point B in a privacy preserving way and rln you may have seen it in the title H stands for rate limiting nullifiers and allows you to rate limit the users in a network to prevent uh spam so first of all I would like to introduce you Frank Le of waku H he'll be he will be presenting the second part and I will start with an introduction and some small Workshop where I will I will show you how to join the waku network by running a a no and participating in in our Network so H this is the agenda for today um we will I will start with a waku introduction telling you what waku is uh what waku is not the future the problems we have already solved in the past years H then we will continue with uh the small demo that I told you before it's going to be a quick Workshop I will share the commands with you in case you want to run them and in case you want to become an operator in the waku network and relay traffic on it and then Frank will talk about uh yeah the need for a flexible rate limit in rln and the the economics behind the behind waku so uh before uh explaining what waku is h can you guys raise hands who knows what whisper is okay I see a bunch of hands up I think I know everyone okay so waku is some kind of fork of whisper and it fixes most of the problems that Whisper had originally back in 200 16 17 something like that so yeah waku uh right now is a suite of messaging protocols and it's meant to deliver as I said before a message from point A to point B or from point A to multiple multiple points like a group for example a group chat it does so in a privacy preserving way H without relying on a central entity and it's generalized for any use case uh you can build a chat application but you can also build any decentralized application that you can think of if you need to connect as I said before point a with point B in with these properties you can use waku so we are not really binded to a specific use case and uh yeah the coolest thing is that it's permission for for anyone anyone can join the network so um as I said before Whisper had some problems and waku has solved most of them in the last years first of all latency um so in a network with the properties of waku latency is very important because the messages don't go directly from point A to point B right they travel through many nodes uh jumping multiple times right so so to fix this we have limited the the message size to 150 kilobytes I will explain later why and um yeah for the latency there is also a trade-off between the replication factor and the bandwidth I will explain this later but yeah long story short um we can guarantee to some extent that every message in the network will arrive within one one second second problem that we have solved is the rate limiting so H in the web two world it's very typical to rate limit with an IP right so if I see that your IP is sending more than x requests per second I will stop you right because you are not making a a fair usage of the resources but in the web 3 world it's a bit more different because um waku H sorry um in in the web three world it's a bit more different because you don't have an IP to rate limit because you can't connect the messages uh to an IP so uh we are using rln uh which stands for rate limiting nullifiers uh this was originally designed uh by the etherum foundation the PS Group and we have adapted it and we have also uh some peer scoring so to every peer in the network that you connect to you keep assigning an score and if the score drops below a given threshold then we will kick out this pier from the network so the third problem we have solved is the offline notes so your note could be offline for a few hours days minutes or seconds and uh someone may have sent you a message during this offline time so for this we have a store protocol and store sync to fetch these messages that you missed while you were offline um so running the four problem we have solved is the running waku in resource restricted devices because um running a full node as you know in like in ethereum right uh you can't run a full note in your phone it will drain the battery and you will run out of memory uh super fast so for waku H we have designed light protocols they are called filter and light push these light protocols allows you to use the network and publish a message for example on behalf of uh another peer um this allows you to run waku in a mobile phone for example without consuming battery and and data uh yeah I will be talking about this on J Merkel thre a bit later and yeah last but not least we have scalability H we have sold the scalability of the network by shared in the network a multiple chart so we have splited the network in different sub networks so I will zoom in in each of the previous point that I have explained latency uh let's start with the diagram on the left H here we have in the lower axis we have the outbound degree D if anyone knows about gossip sub you will know this D this is basically the replication Factor so the the how many times uh the traffic that you inject into the network is replicated and on the other axis we have the amount of hops that a message will travel in the network H before arri to all the peers so the thing here is that let's say that you set an N of 1,000 noes this is the amount of notes this would be the the red uh the red plot right so let's say that you want uh a replication factor meaning like the the times that you replicate the the bank within the network of of six for example then you will have a worst case amount of hops of four meaning that a message after traveling four hops it will arrive to all the peers so as I said before there is a tradeoff in here between this and this right because you can't have um low low latency and also low bandwidth consumption so we we're playing with this so uh we have done some simulations you can check them here uh this is the distribution times of arrival of a message in the network we were using different sizes 2 kilobytes 25 100 and 500 and you can see this is the distribution so uh in these three first plots you can see that the in the worst case every message arrives uh within one second this is why we have limited the the maximum message size to 150 kilobytes as you can see in this case with 500 kilobytes the the average time goes quite quite up close to like 1.7 seconds and this starts to to go quite quite high so if you send in WhatsApp it takes less than a second to send a message to your friends right so we We should strive for something yeah similar cool let's continue with the rate limiting um as I said before we use rln write limiting nullifiers to write Li the users so a rate limit example could could be like okay we allow a user to send 100 messages every hour um the cool thing about rln is that it does so in a privacy preserving way using zero knowledge proofs and um we can also act upon the rate exceeded for example if we detect that a given user has exceeded the rate limit we can slash him or her H yes as I said before this was initially started by the PSC at the ethereum foundation so um I will explain more detail about rln what does it mean what what it's a membership so basically a membership it's your key that allows you to participate in the network um this membership it's stored in a merel tree that is on chain and anyone can register its public key on chain you have to only pay a fee H we have deployed it in in ethereum by now it's a sepolia it's a testnet which is called sepolia but anyone can do it after paying a fee so yeah basically we are storing this in the in the blockchain we have the this is your Leaf this would be you and we have a Merle tree representing all the memberships very easy so um the thing about um rln is that only the one who knows the private key of this public key can generate a proof right you can see this proof as some kind of a stamp that you will put to a letter you will stamp to a letter this stamp is in reality a zero knowledge proof and it allows every node in the network to verify that the message is correct and is respecting the rate limit so yeah uh it attach to the message and it makes it valid in the in the network you can think of it as an stamp that you have to buy in the post office and put it to your to your letter um since the Merkel root of the tree that I showed you before is public anyone in the network can verify that the message is correct so you get the root you get the message you verify the Z knowledge proof and you can H decide if you want to accept or reject the the message so yeah offline notes uh basically what I explained before if your note goes offline for some time you will have to to fetch the messages that you missed H we have two protocols a store and store sync and yeah the latter the later is um based in a Range based s reconciliation um regarding res restricted devices uh we have yeah we want everyone to be able to use waku even if you are running on a mobile phone so for this we have these two protocols light push and filter H light push allows you to send a message to the network via another node and filter allows you to receive you can think of it we call them light protocols or Edge nodes you can think of them very similar to what ethereum light clients are H if you have I heard before a talk about the portal Network so this is very similar to that because we we can't we can't assume that people are able to run both ethereum and waku in their mobile phones um we have H one feature uh that we deployed to the waku network quite recently that I think it's worth mentioning so um in order to generate a zero knowledge proof H you need to insert the as a witness if you know about Z knowledge proofs you have to inject the merel proof of your Leaf the thing is that if you're are a light client H you don't have this information right you would need to synchronize the whole tree locally and then be able to generate the merel proof so long story short we have done a modification in the in our contract and in this contract now we are storing the whole mer three and you can get both the merel root and merel proofs directly from the contract meaning that a light client or an ed node can go to the contract get whatever he or she needs and then generate the proof and send the message to the network so yeah as I said before uh you can generate proofs without syncing the tree locally this is very nice because syn in the tree as you may imagine you have to synchronize many events and this can take several minutes and um yeah this you can get the Merkel root and Merkel proofs from the contract and these calls are gas free because you are not writing you are not changing the state of the of the blockchain so um the cool thing about this is that the gas increase in the membership insertion is very reasonable so we we can deal with it h waku may move to Aller 2 to make H yeah to lower the fees but even right now the fees are not that crazy so yeah rln it's working for uh light protocols and yeah scalability nothing to add to what I said before H we split the network in multiple charts and right now in the waku network we have um eight charts basically if you know about uh gosip Saab we have one topic per chart okay demo time I hope this wasn't very painful 15 minutes not bad uh if you are interested in following along you can scan this QR code I will leave a few seconds you can also browse it it's uh Wu org and waku compose yes if you have any questions up here I can take few uh yes uh in the in the demo I will show you I will show yes yeah just a quick question uh you say you generate a zero knowledge proof every time someone sends a message yes correct how much time does it take to generate the proofs on average any idea yes H we we wrote a paper actually about this it depends on the platform blah blah blah uh around from 80 milliseconds to 150 milliseconds depending if it's a Macbook Raspberry Pi whatever but yeah 100 milliseconds it's the it's a very basic H cge proof because it's just ER proving that you are part of a given mercel tree and that you respect a given rate limit it's not like you know in ethereum they are trying to prove blocks and this takes like two hours right but yeah thanks don't be shy cool we will take also questions at the end so no worries cool so as a good engineer I don't realize on the internet so I have a video because I don't trust the internet so yeah what we are going to do now um we are going to ER run a Docker compos setup that that runs a waku node and we will also show you how to interact with your waku node with a simple front end and with this you will be part of the waku network and you will join other nodes relying traffic so let's start you can see that the terminal is open on the right side on the left side you have the QR code link we start with copying the configuration the environmental file now we open it and we have to modify couple of things we are using an ethereum endpoint H you have to provide your infura API key for example you can copy this it's fine you have to provide also your ethereum private key do it only for testnet you can this as well this is the account this account has to be funded with some ether in sepolia and now we are going to register your rlm membership this is a transaction that goes on chain to seoa and we'll give you the right to use the waku network it takes few seconds because it's also waiting until the transaction is validated by the nodes we will We I will show later the the fees we are paying for this uh you can see also that it will appear here right now H you register your membership for a given rate limit in this case we have 100 meaning that you can H send 100 messages every 10 minutes is the rate limit that we have defined but you know waku is open open source if you don't like it you can Fork it and have your own rate limit so yeah you can see that the credentials are persistent you can open the the key store it's a key store very similar to the ethereum one it's a bit different but yeah you can open it a bunch of exad decimal numbers now yeah this is the transaction uh this is the Smart contract the rln smart contract this transaction is the one that we just uh submitted we have 21,000 members in the tree and I will yeah open the transaction you can see that the gas is it's yeah wait one second yeah it's consuming 150k of gas this is quite reasonable even for ethereum mainnet the function that is being called is the register function this is your commitment so it's basically the the hash of your secret more less and the rate limit which is 100 as I explained before here we configure the store H size I said 1 Gigabyte meaning that I will store only one gigabyte of messages and now we are ready to spin up all the services this spins up uh some grafana promethus dashboards to monitor some metrics the waku node the most important things thing and also a front end that allows you to interact with your node you can check the logs if you are interested for now this is like you don't have to really understand it and yeah the first time that you start the note it will take some time because it has to synchronize the smart contract it will index all the events until it goes to the it reaches the latest head of the blockchain and once done uh your no is ready you will be relaying traffic of other people you will have the rln 3 synchronized yeah you can see here this is the front end Local Host 4,000 you can enter your username and then you can join a group I suggest if you want to join Defcon group you can talk with other people here you can input your message and when you click Send it will be sent to anyone to everyone that is subscribed to the topic Defcon you can see that the message is is there cool so this was the this was the demo uh if you have any problems with this uh later when we finish the talk we can help you if you are interested uh quick note before I pass the mic over to to Frank this is cool right but I mean I have WhatsApp it works that's the same the user interface looks nicer so why do you care about this so first of all H you are running a full node which is cool uh you are ring traffic in the network so you are helping others to communicate with each other you also store past messages and you have your own rlm membership you don't have to rely on anyone um yeah with this you are allowed to use the network up to a rate limit this is cool okay but yeah what's the advantage of using Wu so first of all the messages are not linked to any Identity or IP every time you send a message this zero knowledge proes doesn't connect your identity to the message and also since we are using gosip app H to some degree we can guarantee that no one will know your uh IP or will be able to connect your message to your IP also you are fully Sovereign you don't have to trust anyone in order to use this and uh it's decentralized because there is no single point of failure and you are connected to multiple nodes using H gossip stuff and uh yeah with this I will pass the the mic over to to Frank he will be speaking about rlm version two and the economics of of of waku thank you so yeah so R&V one is is what we actually presented at last Devcon I've been working on that for for a while and in the past year we have done several improvements and what we call R and V2 AV already touched upon the fact that now we have our merket tree on chain which means that you can just do a smart contract smart contract code to get your maret proof and generate your proofs another change change that we we have is around the rate limit so with as um as we mentioned the idea is that to proof and it's attached on Epoch so Neo is just a time stamp with a granularity of choice the first version of rln You Could Only R limit to one message per Epoch which means that um in term of smallest practical epoch once again would be the best under that would be difficult especially considering Network latency and anything above one second uh you know if you go for 10 second one minute then becomes uh impr practical for chat app right because if you the user has to wait you know 1 minute or 10 minutes uh to be able to send the next message uh not really useful so um also in terms of of traffic so why are we using r again the idea is to rate limit how many messages can the publisher send the network so that you can you can have you can cap the bandwidth on the network so that when you use waku on your mobile phone on your laptop on your household uh Broadband you know that you're not going to consume all your data as well as you know that you can still be part of the network if you let's say you have um you know 10 m per second at home and that's that's what your internet can support and someone comes in and inject a terabyte of data you will not be able to to receive all messages and afford them as goip sub tells you to do which means that we misbehave in term of Gip sub terms and then you get kicked out from the network all right so if we have unlimited bandwidth you know um there's no capping of the bandwidth on on the guu network or on any G sub Network then you may get kicked out which means that basically you are you have an outage you get um dust from the network right so with woku um asone mentioned we want to be able to have a decentralized peer top engines but also for laptop and and mobile we don't want people to have to use a centralized rest API so back to the to the numbers so with one message per second and let's say we have a 5 kilobyte message size average and let's say we have a thousand user so we think we can go up to 10,000 user on given chart but just let's say just 10% of user just continue to message you know non-stop you end up with 5 G per second of steady traffic so nonstop steady traffic and you can imagine when you go back to a mobile phone or just having this this non-stop traffic uh on your on your Broadband um is know a problem so with rv2 the um like from the technology point of view the Improvement is that now we can do n messages byok so we're able to choose a a number and that allow us to have a wider ook right so in our case so we we chose a number of parameters and we're going to start with that of course we can change them as we learn more as we use them in in various applications So currently on a smart contract we went for 20 to 600 messages per 10 minutes so we went for an EPO of 10 minutes where we can use 20 to 600 messages um in ter of whether it's 20 or it's 100 it's up to the user when they insert a membership um they insert the public key to the smart contract uh they can decide what rate limit they want to pay for so we also have um a rate limit on the contract so on the smart contract we have a parameter which is the number the total number of messages uh byoc so we set to 160,000 message byoc and on on the network layer so more as a a consensus between the operators on the gossip sub layer we went for 150 kilobyte Max message size so now we have um more of a an API token like all right so when you go for to infura and you get a free token to for your RPC API or when you pay for something uh usually you're not going to get you know we can do one request per second it's more like you can do X request per hour or per day or per months and sometimes actually a bit of boss so now we have an API which is pretty much the same so like you can buy a membership and this give you let's say 100 messages per 10 minutes all right so just to to go back to um we see here there you go so the EPO are sliding right so 10 minutes so for everyone an Epoch starts and then last for 10 minutes and during this EPO we can send you can attach new proof to each message uh each proof will be different and every n in in the network knows that this um this this key uh has used one 10 up to 100 Proof because we use Z technology you we don't have um we don't know what message is all right are linked to the same proof to the same key okay so you still have this uh this anonity so someone ow sing the traffic can't see that all these 10 messages are coming from the S sender from using the proof but we do have the right limit in place um and then when after 10 minutes when a new EPO start um then we can forget about all these Pro messages and we can start to count again so with r& V2 so the for a node to verify that someone is not exceeding their rate limit they need to remember the nudifier so nudifier is a is a piece of data in the proof so for every message that goes through the network um they can check the proof and then store the unifier for this Epoch until the epoch finishes the unifier is 128 by so one looking at you know why 10 minute question why not doing certain message per day for example which will be much more flexible for a user right um a user most you know if let's in the context of a chat app you use your chat app you know 6 12 hours a day and overnight you're not using it so um every 10 minute at night that you're not using it you can lose the opportunity to use the chat up right so ideally 24 hours will be better but we do have some limitation and and that is around storing unifier for the epoch so if we look at um let's say 600 messages for an Epoch which is maximum rate limit for one publisher this would be around 7 5 kilobyte per user which means that for 10,000 users it should be 700 megabyte so 10,000 user why 10,000 is because we think this is um um kind of a good maximum size for a go sub Network so for one given Network you have to remember you have to keep in memory up to 700 megabyte of data um for this Epoch and if you if you if you can't keep that in memory it means that you can't verify proof anymore and if you can't verify proof it means that you might forward spam and you might then get disconnected but other not that did so the the memory usage is very important in term of just we clear here this is about node on the RO Network in our case it's both node as no VPS in the cloud as well as on the desktop uh on mobile we don't for traffic so we don't need this on mobile but um but so yeah so if you know if you R by piie if you start to use more several G of data we try to be very lightweight client so that's why we went for 10 minutes for now we could always increase the APO size or or reduce it depending on you know when we use it um with with users and getting control getting a feedback another another thing with a 10 minute which is good is that if you go for a rate limit per day so per 24 hours one risk you may have is someone uh injecting like publishing all the messaging he can uh at once and in this case you can have a peak of traffic and this peak of traffic may again lead to do protection we think for with this numbers we think it's fine um however if we were one day able to let's say you know compress the or something like that and move to 24 hours then most likely we may have to have like a dual rate limit where uh we we may say we can do s message per day and a and you know 100 message per time minute or something like that so yeah so basically like a lot of parameters to to think about when when deciding for red limit all right so just trying to to uh to do some prediction try to do some um um some statistics so in average in average uh just doing some uh some distribution we could look at a traffic of 266 message per second and average message size of 4 kilobyte so the maximum message size is 150 kilobyte but we we don't expect every single users to to send maximum message message side all the time and actually 4 kilobyte looking at the status uh chat application that uses worku is actually a good average that we can see in our in our infrastructure um so goip Sub goip sub we use goip like ethereum uh six the the out degree is basically number of peers that you're connected to and foring message to and also number and this PE also for the message to you so which means that with this number numers we can we get around like a 6 megabit per second Network right and we split our Network as I mentioned with spitter Network per Shard um in eight Shard so which means that now we assuming uniform distribution between The Shard so assuming that network is uniformly distributed between The Shard we end up with um a traffic of 75 or 0.75 so much much lower that's what we discussed before with the one one um one message per second um and that again you know here it's um these are statistics right so that what we think would happen um but then of course it depends on the application that use the network all right any question so far on RN V1 versus R and V2 so V1 we had to do one message per Epoch and now we can do any message per OC and it's much more flexible so um yeah so that's one of the so we basically three three main Improvement one was the message size the message number of messages and the second one is the market Tree on chain and the last one is we have defined some economics around the memberships so the just going back one second so what's the point right so the point is when you want to send messages to the network you have some rate limit so you don't overwhelm the network you don't overwhelm participant in the network and and practically uh does them out of the network so if we have a system where anyone can just and grab any membership then you end up having the same problem right someone can come in and take all the memberships or take a high number of membership and attack the network so you have to have some friction to ensure that you have to r liit that as well right in some way or another have some friction to ensure that no one just come in and grab all the memberships in web two right in in the normal classical I would say uh word you usually have some rate limit by IP um and that's why quite often you know when I try to use VPN or tour you you may have to have capture capture is another rate limit right so uh rate by IP rate limit by capture and sometime you do have to provide some personal information uh your phone number your email address social security number and all of that um so in the case of of waku we are trying to build privacy Anonymous censorship resistant um infrastructure and of course so we want it to be decentralized for that so don't really want to collect people's phone numbers to allow them to have a membership and that's why we use Smart contract so now in ter of smart contract um I think there is many ways to do it right so we are currently looking at pure Financial solution um but that's just like one example that get us going without making too many assumption but you could definitely have things such as um actually I will mention it at the end all right so economics so we we know assume we're going to make people pay to buy membership so we went for for six month membership you have to buy a membership and it's valid for six months and the end of six months you have a one month CR period at the moment we went for a linear price all right so we say okay let's pay 5 Cent per message per EPO for your limit so if you go and buy the lowest membership which is 20 message per 10 minutes you pay $1 and if you went for the highest rate limit uh you pay $30 in term of gas cost so um I think about demonstration was using a contract that didn't have yet the economics in there so now actually we just look at the test and it's around 232,000 um gas uh to insert the membership on the smart contract with the economics in there which is around $10 Manet um which is you know for 6 months it's not the end of the world um looking at A2 it will be more like around 70 cents of course depending on the A2 and the current gas price so as the end of six months the membership can be extended during the gr period um at this point in time we are not trying to look in money like to make money from that so it's a deposit all right so at the end if you want to extend your membership you just close the contract you're going to pay gas to close the contract but you don't need to to put more deposit in um and if you want you can also withdraw uh your deposit during the grass period during after the grass period um the if if if people just in membership and they just leave it there as I mentioned there is a rate a global rate limit on Smart contract right so smart contract will not accept uh membership above a given limit which was th000 message um per so if there's no more space in the market tree then a color can override expired membership in there so that if people don't renew um we don't have to ex to extend the membership on the contract we can just as the coder can just override uh a quick mention so we do have you know cap on the number rate on the contract what happen if we have a network with that many users right as we we do split the traffic in eight shards so the idea is that if we end up at a point where the smart contract is full and we do see this traffic on the network then it's always possible to potentially deploy new smart contract or maybe modify the current one um that change some parameters and add new shards and to add new shards is just a consens between operators so just saying okay operators let's have a new Shard on the network uh maybe new smart contract with a higher he limit so that we can scale the network and get more users in in cool so all right so that's that's the current um uh the current status we have we are still refining the smart contract more or less ready um we we try to deploy it on Manet very soon probing an audit first in terms of um of the future so we went for six month membership probably we can do one year membership but it's still quite early on and we don't want to know look in parameters and having to try to get people to migrate if we change things drastically but most likely uh a yearly membership we make more sense um at the moment we have linear pricing right so um you know 5 Cent per per message per Epoch we could have nonlinear pricing so actually we already prepare the smart contract for that so that for example you could have a bug discount uh if you go on the higher end or on the or contrary for try to make it more expensive to have a higher rate limit um now we need to basically get it used so we can get some feedback one of the change so the reason W was buat was for the status chat app which is a chat application both mobile and desktop uh new version 231 just released so go give it a go um so right now the next step to have rln um used is um for us to get it in the statu chat app and the main challenge here is to look at the current chat protocol understand what would be the impact to uh to reduce to rate limit know to add this this hard rate limit all right so another point is that you know especially when you think about chat application um I know WhatsApp used to cost $1 a year long time ago I don't if you remember that it sounds it sounds you know okay um anyone you know any one project developer that wants to build on waku and want to take advantage of this decentralized peer-to-peer Network might say I don't want my user to pay and to do onchain transaction before they can use application which is which is a fair command so we we have considered having you know message going for free on the network but it would just Mak the network more unreliable so instead we you know how do we question is like how do we how can we offer a free membership to users which is counterproductive right because again it is a right limit to avoid people floing the network but there there are some options so one t soltion is St commitment so St commitment allow you to have someone else uh iner membership for you and revealing very little information about your uh your own membership um could use pay Master right so if you um if you look at you know at Layer Two uh you could deploy a play Master to say all right if someone tried to inert a membership and and they have some unchain history for they already they already bought ens name or they do have some e or they have some specific token that uh you are interested into related to your project you could say okay this user has onch activity they already part of my ecosystem uh when they go and try to buy membership I will pay the gas pay the fee for them referral system so one one I think very interesting one is um at the end the day you you just have to enter specific specific number in smart contract like the public key and there is way to do that as well without ring too much about it so you could have a referral system where someone that is already uh already has an wallet already has gas is to pay gas uh could ins the membership for someone else uh again once the membership is inerted you don't have to do anything on chain anymore all you have to do is do some uh calls on the contract to get mer proof to get um your uh your index and then you can generate proof and publish on the on on the worku network all right so that's that's the most part for the presentation part um any questions on cost and membership don't be shy or Crystal Clear ah yes Q&A I are you doing it or all right awesome questions awesome no question if you're not closes often do you need to reink every time before sending no so you do not need to reink messages per se before sending at least as a writing layer Okay so um you if you miss messages from the network then you miss messages and then it just depend on what is your application and in this case um uh and then it's up to application if your application is a chat application then maybe you will want to retrieve messages because there are chat messages you're interesting in in ter of the smart contract when you uh when you restart you you do need to um to check the latest me proof from a smart contract because you do need to have the latest Market proof uh to generate the proof right if you use an old Market proof the new message may may be rejected so you do have to uh recall smart contract to double check um what to to get the latest maret proof and you do have to watch the smart contract as well right because every time someone inserts a new membership the market proof change uh sorry the market route change and hence you have to have a new market proof uh you have to use a new Mar proof to generate your proof locally so you don't need to do a big ring per se to question done is a deposit necessary since the transaction is needed anyway would just a gas paid be in a friction yes no that's that's a good point um it's a good point especially on menet where it does cost uh some money to uh to interact with smart contract however the here the question is about security assumption right so how much should people pay to get a membership and send on the on the network uh that's not something that that's something that we know we have some theory around it but we need to see practically what happened um and most likely you want you prefer to you know use the L2 so see can go faster like you know most application more and more are using l2s and on L2 it's very very cheap and hence you know question become smooth um so because our aim is to deploy L2 then we we deploy we develop this uh this strategy if indeed someone wants to use rln on the L1 they might decide that the gas cost is enough and that's no fair enough so I think I this one is there a way to pay the membership for another user such account as a way to onboard web to users for example yes absolutely so um so buying a membership you you just interacting with a smart contract right and you are sending just sending a a commitment right so you're just sending a number to the smart contract um with the payment to have the rate limit so you you can get this number directly from your um uh from your from your friend and then do the SMART contract call for them all right as long as they know to check the smart contract they don't have to pay gas and with test commitment you can also have a bit more privacy around this this action so yes absolutely you can onboard other users um and and pay their gas fees and their membership fee are you considering limiting by n megabyte per Epoch rather than messages count per Epoch so so yes we actually uh we actually thought about that and we should look into that uh if I remember correctly and I'm looking at my uh researcher yes or no uh is that it just it just make it more complex much more complex right it makes it much more complex uh so that's why we instead instead we went for message count and we uh as think vory right would help for that as well or am I confusing maybe okay so yeah it's much much more complex uh so instead we we have an agreement between not operator of the message size so that they can decide to drop messages which are too big from the network and and you have the message count on the smart contract is there can you scroll down please I think I reped all these questions I think there was yeah there's more yeah scroll down a bit more scroll down yeah okay are there any more use cases that can be applied with RNN yeah absolutely absolutely um so again you know RNN comes from the privacy and scaling um exploration uh group from uh from EF so at the end of the day with RN is you you you rate limit the number of valid proof you can generate for a given number you know in your case number is an Epoch and we use that uh so as a time stamp right but um let's say you could do uh voting right you could have a proposal the number is a the number is a proposal number and and you can say okay only you can do one vote per uh per membership and and you could vote in a Anonymous manner um I haven't looked lately about our applications but yeah it can definitely be used for other applications how we consider RIS taking to secure this in instead of introducing a new token economy so yeah that's an interesting question we haven't we haven't that's the short answer but could be interesting actually there you go would upgrading from rv2 to V3 in the future be a breaking change that would make nodes on the previous versions not work with the new ones okay so first not sure we would ever upgrade to V3 but in any case um it it is a consensus right so in short you you when you run a goip sub node all right you are going to have rules to validate messages and any everyone needs to have the same rule because otherwise uh you get spam and you're going to say okay this guy is sending spam so I'm going to disconnect from him um so whenever you want to upgrade the network and change a smart contract there are sever ways to do it you can just start to point to the new contract and you're going to disconnect people that still pointing to the old contract and connect to people that pointing to new contract uh you could have and I think that's basically like the main the main strategy here um because as soon as you I mean you you could have strategy as well where you um where you say okay from this point you know from this time stamp or this from this block we are going to start considering messages valid from a new contract or from a different contract so it is somewhat of a breaking change but goip sub does has uh safe healing properties right so it would not last you know for days and you have a hard fork or anything as that um it would be more about the question of having the gosip peer scoring mechanism U to to kick off and and heal the network can you scroll down please yeah yeah all right do we pay in e or some other token how is it 30 USD paid yeah it was on the slide but I didn't mention it so at the moment so erc2 erc20 token all right um this is a parameter of smart contract so when you deploy the smart contract you can decide uh which s20 token you want to use um in our case we thought it was important to use a stable coin so we went for D because we are know decentralization maxi so we went for a decentralized coin so we suggest to use di but it is a parameter of smart contract and you can just choose whatever you want when you deploy it potential way can feed the tree with member ship very quickly is there way to mitigate it I I'm remembering the discussion we had quite a few discussion on that so yeah at the end of the day a way could come in and filling the tree and this is one of the reason um I think expire is very important right because if they do um then we have to cost enough that they do it again and again and again so in term of security at the end of the day um any security problem the question is what is the you know what is the cost opportunity um versus what could you gain right um quite early stage here so someone would do that it would be just quite annoying but we just deploy a new smart contract and just get the notor to to point to the new smart contract we we did we did think as well about um limit like you know saying okay one membership per ACM address for example per wallet right but this could be uh could still go around by just you know dispatching your your money on wallet so I I think at the they expir do play there I wonder if um they has more to say about that about the W problem no okay it is a fair it is a fair command it is a fair command okay I think no more question more question from here awesome anyone has tried the enaku compose all right now do you want some help is it working or you tried it in the past do you need some uh is yeah we can we can help so okay cool I think we can stop the presentation for now and then we can help anyone that wants some help on some questions good thank