RLN and RLNapplications in the real world, Applied ZK - Day 2

[Music] hi everyone my name is blackway and i am part of the privacy and scaling exploration team and i work on the rln primitive today i'm going to talk about rln high level overview and additionally rn application and what we can do with it in the real world so uh rln is a zero knowledge uh gadget which is uh which enables rate limiting and can be very useful for uh spam prevention in uh privacy preserving uh environments so it enables uh spa spam uh protection protocol level and it is a very useful for uh let's say uh free frequency uh frequency based spam protection and rate limiting so it enables objective uh objective spam protection so in use cases where we we know uh certainly what's uh spam it does not help with a content-based spam protection so how it's implemented it's a basically it's a multi-component gadget it has a zika circuit but additionally it has like uh external components which are uh which are basically logics used for verification and for uh the detecting uh what spam and what's not and some additional metadata so uh it works in a few phases the first phase is registration the second is signaling and the authorities verification so in order for the users uh to be able to to send valid uh zk rla and zk proofs and to be to participate in the application that uses sarah land for spam protection let's say they need to be a part of a membership merkle tree so rln works on the concept of anonymity set so a user is part of a of a set but so basically they can do certain actions but they they do not reveal their identity and also this serves as an uh anticipated gadget and so for example the cost of the registration can be app specific and uh determined by the requirements of the application but the goal is to have let's say uh strong uh anti uh anticipate protection and for example uh an example for registration can be a smart contract which takes a stake so users need to stake certain amount uh when their identity commitment is decided into a merkle tree or or maybe uh it can be a social stake so they can use uh something like like interrupt the the goal is to is to basically enable um some kind of hardened registration for for this step and after the users are registered uh basically they can interact with with the applications and additionally the requirement here is that with with each signal a user must generate a valid zk zk proof and additionally sent some uh some metadata with with the proof uh so basically the message the proof and some other metadata such as the x and y shares which are necessary for for verifying the proof and also necessary to to enable this spam protection mechanism so the zika circuit has two phases the first one is the membership markov tree inclusion verification and the second phase is construction of this uh linear equation where we basically encode the user secret in the first coefficient of the polynomial and we use uh shamir secrets uh sharing scheme for example to uh to be able to reconstruct uh the user's secret from multiple shares if so so this happens for example if uh if the user breaches the the spam uh the spam protection rules and sends more than one message per epoch so yeah this is how the the messages look like so the user sends a signal and then they say the proof an internal modifier talk a bit about that later and x y shares and the ireland identifier so this is like uh a part of the ireland rfc which is uh at this link below and here is how we construct basically the this linear equation so the a so a0 is basically the identity secret and then then we construct the uh a1 coefficient and additionally the internal uh nullifier in this way we have an additional parameter which is called uh rln identifier and that's used to enable for example cross application protection for the user because it might happen that a user sends a proof a valid proof for two different applications with the same epoch or externally far and that way they can get slashed as um well the the third part is the verification so this part uh is is basically uh what enables the the spam uh protection so first uh the common scheme is that the applications check for for duplicates uh for example if a duplicate message is being received and and basically the the same external notifier the same internal modifier and the x and y shares were seen before then that message can be safely discarded because it's a duplicate then the next step is proof verification if the proof is invalid the message should also be discarded but if the proof is valid and and x y shares uh are different for the external modifier and internal modifier that means that the user has breached the spam protection rules and that we can reconstruct uh their their secret and basically from the user secret uh that their identity commitment is is generated so basically this works in a way that in in the circuit we enable like this kind of secret encoding so that later on externally we can we can have this kind of system that basically enables uh spam protection so that for example if we can reconstruct the user secret we can have let's say a smart contract or maybe some kind of an external system that if we can prove to that we can uh basically regenerate the identity user's identity commitment we can like exclude them uh either from uh we can exclude them from the market uh tree either uh like uh removing them from the smart contract and taking their stick or or maybe or maybe if i'm not uh smart contract is used just remove them from the merkle tree um and so we also work on uh improving this uh this gadget so next things we we plan to do is like improve uh the the circuits like improve the prover time and this can be necessary for uh for some uh applications which are a very let's say latency sensitive currently the proof generation time takes around like one second for uh market tree of depth 32 and additionally we we plan to implement a generalized smart contract architecture and experiment with uh on chain proof verification uh and traditionally uh expand the usage of this primitive and work on on getting it more into the gnome okay so i will talk a bit about the applications and how this gadget can be related to real world applications so basically this gadget can be useful for any application that that has some kind of frequency so that the users frequently sent messages to interact with but also require some kind of privacy preserving environment so that the users preserve their privacy and we've worked on a few projects and prototypes and traditionally we've found some additional use cases which we think are are quite important so the first such project is ethereum consensus their validator anonymity so currently [Music] validators on the ethereum consensus there are susceptible to metadata analysis attacks so this means that their physical ip address can be found and they can be ddosed so this means so this is a risk certainly for let's say network destabilization and can have some impact so maybe not an impact for the large let's say um staking providers uh where they manage like advanced networking setups but maybe for small validators this can be problematic and maybe can lead to centralization in the future so so how how we think about solving this issue is enabling a private network so that the validator the validators can obfuscate themselves so the original uh let's say consensus there a message sender for example the validators here have multiple can have multiple rows for example block proposer a tester they can also do aggregation uh attestation aggregations um and that kind of stuff so uh the the goal is to both busquet the validator and how we plan to solve this is by introducing a private network where only the validators can register and can can send messages to this private network we plan to use the dandelion methods for for this uh and the the problem in this network is that it's not um it's not spam resistant so we can enable let's say spam resistance by enabling rln so it can also serve as an let's say uh a way for registration of of the validators uh and then uh we can uh we can detect spam here and also additionally if we detect spam on this network or at this part of the network this might translate to let's say have some useful properties later on uh to the network and maybe some kind of optimizations to the consensus there itself can be made an additional use cases like peer-to-peer protocols in general uh so oscar gave a presentation on waku yesterday and there they have let's say privacy preserving peer-to-peer protocol where they uh they want to replace the gossip sub uh extended validators and peer scoring rules with with ireland as a let's say a stronger mechanism for preventing spam and having some kind of more global and stronger stronger spam prevention additionally this can be useful for instant messaging complications so for example we can also enable let's say application level spam protection uh if we have let's say a messaging application which requires user anonymity there we all the users on are anonymous and we can uh basically we cannot figure out like uh which should we uh uh let's say remove or additionally if we have identifiers so for example as the status application status i am we can this can also be helpful because like there we have very very uh let's say uh weak uh uh anticipate measures so the the application is constantly spammed for example here are some uh like examples for from the status application uh but additionally we've worked on a project called the zika chat which is basically anonymous uh uh chat uh chat applications and we have several use cases there for example a private and public rooms and we use interweb for registration so let's say currently uh an example use case is a let's say a group of let's say people that have a twitter account with five okay followers can register uh and then uh they can chat into into this application in anonymous way and we might extend this to to to other groups and use cases um another interesting use case is a capture replacement so captures are a huge burden uh ux burden both for the users and businesses and a lot of time is spent on solving uh solving this but but captures exist because they prevent basically bots for uh for using content so basically they help distinguish uh distinguishing humans uh uh from bots but uh we can solve this by using zk proof instead of instead of uh capture basically uh and and this can be a good uh can have a better ux because the users themselves do not need to do anything uh a zika proof can just be uh by by their broad browser and and this can be achieved with rln because the latencies are not so big for for this use case and an additional use cases api request rate limiting in general so basically uh services that work on an api on api key request basis so for example if you uh if you need to access to be authorized to access their services you're given an api key but in certain scenarios let's say rln can enable a good spam uh protection and uh overuse of these services so for example if we take let's say if europe for um they have a free let's say free package where you have let's say 100k requests per day but you can generate multiple such keys and you can rotate them and abuse their services for example but if you have let's say a stronger civil measurements and anticipated measurements and and you have a stronger spawn protection you can uh you can prevent this [Music] and yeah so that's it but additionally there are some certain other use cases uh that we've used so for example key exchange bundles rln can be useful for that kind of use cases and additionally maybe uh mempool spam prevention for for for for certain let's say uh protocols and i believe there are other use cases that can be solved by ireland so we have put some resources here that you can check yeah so that's it [Music] good