Private, economic spam protection in Waku with RLN, Applied ZK - Day 1

[Music] right uh hi everyone i'm going to talk about private economic spam protection in vacuum with arlen somebody's most oscar i'm the protocol researcher at vac and we research peer-to-peer private and sensor persistent communication has it's already in the status app basically trying to improve the underlying protocols so you build things like vacuum but also other protocols so today we're going to talk about vacuum and some of the current problems it has and we're going to look into online and online relay and finally we look into some implementations and future work so first of all what is vaku so it's basically a set of modular protocols for peer-to-peer communication and by modeler we basically mean that you can sort of pick and choose the protocols and so how you use them depending on your specific constraints or trade-offs so for example privacy versus bandwidth usage uh has kind of a focus on privacy security and running in resource-detected environments such as browsers and mobile phones and it's kind of this spears successor to whisper where originally we had this kind of holy trinity back in the day with ethereum swarm and whisper so looking briefly at sort of protocol interactions in vaku vacuum so you have this kind of gossip domain with the vacuum relay which is based on liberty b gossip sub for peer-to-peer messaging and then you have this kind of helper utility protocol so for example you have a filter protocol which is for bandwidth restricted nodes to just receive a subset of messages they care about uh we have light pushed for forces of nodes with short connection windows to sort of push messages into the network and then we have a stored protocol for uh basically nodes that want to retrieve historical messages that have been sent to them while they were offline and this kind of a subset of protocols and if you instead you can check out the specs for more and then we also have how you actually discover these peers and so on so protocols for that um just briefly kind of an overview of how the network how you can think of it um it's kind of this open network where the nodes have different capabilities because you have browser nodes and mobile nodes and servers and clusters and whatnot um and you have different capabilities and here you see some of the red dotted line that's kind of this gossip domain a specific mesh pops up topic and you can have a different mesh that's disconnected or connected depending on the topology and then you have this kind of helper protocols request supply product goes on and it's a few problems here um so one big one is this is going to be the focus of today it's kind of spam because in this sort of open permissionless gossip network if anyone can send messages that means that they can also overwhelm the network and you can sort of you want to have a solution for that and basically how to deal with that uh those are also other problems in terms of incentivizing these service notes because uh some nodes are going to provide more utility to the network so for example storing historical messages so you want to have some way of sort of dealing with that yeah so dealing with network spam so i mean traditionally if you look at spam and how people deal with that kind of thing like you have with google and facebook and twitter accounts on you usually have like a phone number verification um an idea there right they said it's kind of expensive to get a phone number um and also yeah it's a way of knowing who the users are but it's also like a civil resistance civil resistance mechanism but it's centralized and it's not private uh in whisper originally there is this proof-of-work algorithm um but doesn't really work for heterogeneous devices or nodes because you're never going to be able to generate enough proof of work on a mobile phone it's going to drain your battery so you have to have the requirement set low enough which means that someone can just spin up an aws node and over on the network uh there's also things like peer scoring which is used in liberty gossip sub without a peer-to-peer layer for ethereum and others other networks um and blockchains and so on and it's useful uh but it also has some issues it's to some extent because of you it was a censorship and as a sort of simple attacks as well because you can always spin up multiple nodes and identities and so on the idea is basically to use this rln mechanism uh for private economic spam protection using cksnox and all land relay is basically the combination of the really p2p protocol basically gossip sub uh plus orlan so what is ireland uh stands for rate limiting nullifier and basically it's uh it's rate limiting just means that you can send n messages in a given period and this is anonymous rate-limiting mechanism based on cks and arcs and it can be used for things like spam protection in p2p messaging systems but also uh radio meeting in general so things like decentralized capture um and when we say it's an anonymous we basically mean that the message can't be linked to the publisher and it's going to be a dedicated presentation to all end later by bloggers so i recommend people check it out just briefly history of arlen originally was sort of this blog post by barry on if research a few years ago um and since then a lot of work has sort of happened in terms of various implementations and and performance improvements and the construct and so on so looking at sort of how the concept how it works there's basically three steps the first you sort of have some registration process where you're ready for some kind of group and then you have a signaling thing that happens you signal freeze message and then finally this of the verification and slashing and and the registration is basically it's based on some kind of capital at risk and this can either be economic or or social capital like we've seen with interrupt and so on and basically if you double signal you get slashed so the registration uses the register with some membership group in order to be able to signal and this can happen with the central server or it can happen with a smart contract and you have this identity commitment and sort of same thing idea with semaphore here that we heard about earlier um which is stored in some merkle tree uh and basically have this identity secrets that's generated somehow which is random for the two byte value and then you sort of hash it twice to get the identity commitment and then basically you have a multiple proof to prove membership and an idea is to make it economically or otherwise costly to register to have got against civil attacks so that can be the financial things the e for example or social stake so using interrupt for example where you can prove that you have a reputable social media account for the signaling so basically registered members they can signal once for a given period or end times in a given period uh which is kind of the external nullifier slash epoch and the users can store this membership membership tree either locally or get it from somewhere and then you generate this knowledge proof uh to prove membership and then basically have this the signal and and and which is and then you hash it you take a cache of sort of content actual thing that you want to signal as a mental model you can figure that kind of a voting booth where you can only vote once um verification and slashing so basically uh the verification is to ensure that the synonymous proof as well as some other parameters are are correct so you need to make sure that of the external files in the correct epoch so you're not sending messages in the future or in the past for example in the case of time-based epochs you want to make sure it's a non-duplicate check uh like have a non-duplicate check so you're not sending the same message twice uh you wanna make sure that zero knowledge proof is is checks out it verifies and then also finally you wanna check that it's um it's not a double signal link right so so you don't have a user sending more than uh one message in a given time period and then slashing so this is based on symmetry secret sharing which we'll look into a bit later and basically if you use double signals then you're able to reconstruct the secret key which enables the person or anti-identifies this to get their stake if there is this one to get so i'm not going to go into the circuit in detail here but but just roughly in terms of the the inputs and so on for proof generation so uh you have this basic identity secret which is this semaphore identity thing and then you have path elements and identity path index and this is just like a standard microproof and then you have these public inputs so epoch here is is basically the external nullifier it's usually like a time stamp or a period which is the kind of voting booth analogy where you can own signal once during that period and then you have x which is kind of the signal hash so the hash of the actual thing you said you're sending and all an identifier here is just uh for a specific online app uh and path element here is just one this is for simplicity it indicates the number of neighbors at that level uh circuit output so this is calculated locally um and here you have this y which is a share of a secant equation that will look soon and then you have this kind of internal nullifier and internal fire is a kind of unique fingerprint for a given app user and period combination and then you also have the root for the the mercury so how is this output with this y and internal normal fire calculated so this is the kind of samir using shamir's secret sharing where basically if you have a given identity um a0 here and a signal twice in an epoch then a1 will be the same right because the the hash of a0 and that external nullifier will be the same and then for given rnap so kind of that local context internal fire also stays the same because it's the hash of a1 and all an identifier an x is the single hash which is different and and y is a public output which means that we can basically reconstruct identity secret a0 and with this identity secret revealed then this gives access to the financial stake if it's stored in a smart contract for example so submit secret sharing and this can also be generalized but in this simple case it's based on the idea of splitting a a secret into shares and in this case we have two shares and since a0 and a1 stays the same uh for given user and and epoch uh and we sort of have x changing and sort of a single hash right because the signal is different we're able to reveal a0 which is just identity secret and also worth noting that if x is the same then you don't get any more information so that's also why we have a separate check for duplicate messages so the actual output message so that's what you're actually sending um so you have the signal itself which is the thing you're trying to communicate the proof there's an internal nullifier which is kind of this fingerprint thing uh the hash single hash and this is why public output we saw before for the smear secret sharing stuff all in identifier and then also this route to the microproof and then the external nullifier or epoch in order to sort of detect this this double signaling you do need to store some metadata because it's a sequence of messages here so so um and this can happen either at the server or in the peer-to-peer network it can happen for each client that needs to know and slash it can happen in in sort of a different few different ways here but basically one idea sort of how to store this method as you stored per external nullifier support epoch and then you have this kind of internal amplifier which is this fingerprint and then you have these x and y shares and with that you can sort of first of all detect double signaling so you know when to try to construct secret and then you can reconstruct the secret and then get the stake so the verification checks um you need to take sort of that external nullifier such periods of correct one and for example this can be like a 20 second window so you take the with the unix epoch time and then you divide it up into windows uh you want to discard duplicate messages um verify the same knowledge proof otherwise you just got a message and then check if there's more than one x y share combination per external nullifier and internal nullifier and if there is then we reconstruct a zero and sort of yeah get the sake and then finally you sort of want to store this this metadata for the next incoming message so how does this work together with the relay protocol so basically you have this contract that's on chain uh you have a publishing peer that sort of registers to some group and they lock up some funds um and then when a spammer they they try to sort of publish more than one message within a given epoch then it will relay this to its other peers and and that routing player can sort of identify this message as spam and sort of not relay it uh and it can also go to the contract and take their stake and sort of delete them or disable them or what have you it's a little worth noting here that this can be combined with traditional techniques like peer scoring because for example if maybe a spammer is sending like an invalid cq proof or they're sending a duplicate message or something like that so that doesn't allow necessarily the node to take the financial stake but you can still punish them in some way with the sort of by augmenting it with gear scoring so uh registration you have these notes uh and and basically you have to listen to the membership contract uh because you need to keep your own so you have to keep track of the local tree yourself uh there and then you generate this secret key public key thing and you register it uh to your contract and then that contract gets updated so insert that into a list or a tree and then you wait sort of for the block containing that insertion to be to mined and then events are emitted to all these nodes and they can sort of update their state for routing i don't know if you can see here it's a bit but basically you have your publishing node and all these other type of nodes and each node they need to keep track of this method we talked about earlier so kind of a nullifier map so they can detect if double signal is happening and so on and they also need to have keep track of an epoch so this can be like a not like a real-time clock but like soft roughly in sync with some real time um and then when you're publishing you construct this message and like add the epoch and the nullifiers and ck proof and so on and have that in a bundle that you then forward to to your next node and then it does all its checks right so it checks that the epoch is instead of not too far away in the future or in the past uh you check that the seeker proof verifies um and you check that it's not the duplicate messages on and not the double signaling and if all of those things pass then you forward the message yes just briefly on various implementations so we first started looking into this a while ago and and back then this was just like basically a circuit based implementation which was very slow basically only javascript and proof time was like almost a minute um and then there was also this bellman-based native rusty information by owner which is the one that's currently used in in nimbakku but since then like a lot of work has been done on circum itself and other performance implications with uh with wasm and whatnot so now the proof time is like under a second but basically now we have these two different implementations um which is not ideal from like a reuse compatibility audit and so on point of view and also the current spec is right now circum-based and it's like a lot more performant now with wasm and circum2 and all of these things so one thing we are starting to do is this library called circuit circuit which is basically using circum and rust with aux circum and the goal is basically get the best of both worlds here because on the one hand you have sort of the circumstantial javascript ecosystem shelling point where you get all these nice like solidity verifies and whatnot but on the underground you also have the rust sort of ck ecosystem with all the cool stuff and as context here one thing that's different here for maybe other applied ck stuff uh is that it vacuums like this peer-to-peer infrastructure thing right that's running in lots of different environments and there's implementations in nim in javascript in go and also someone sort of work in a rust implementation the slightly different kind of domain there and the goal is basically to enable people to leverage these circum-based constructs from non-javascript environments and is using these circum circuits the ark circum some rust for scaffolding and then basically expose the ac api and this also gives access to other parts of the rust seeking system with artworks but also opens the door to other constructs like halo 2 and whatnot and we also help sort of add circum2 support to to arc circumference some future work uh so currently basically we have this uh nimvaku test net which is like this peer to peer toy chat app uh and i don't have a demo but there is a demo this is a tutorial for how to run a demo if you're interested uh basically the worker progress as well to make this group management more dynamic and do some smart contract interaction around that and so on and then we want to migrate to use circuit for this sort of multi-client test net so the idea is that you have these nodes in in im that can sort of verify the proofs and really mess and so on but then you as a client or dap you would sort of use the vacuum js for example it's also some performance work around rln um when it comes to remote tree computation storage overhead efficient membership operation and so on as well as some smart contract tweaks and and and things there uh we also want to start looking into sort of using all them and interrupt for kind of a zero cost decent captcha that's likely a different kind of use case but it's very much related here uh and then also finally like if you remember the sort of connect network picture i showed earlier this is kind of online releases start here because we also need campus credentials and peer reputation to basically have this modular network where you can have uh privacy guarantees for like a sustainable network and so on uh here's some links there's a spec blago who's here uh did a great job with that uh we have the really spec uh tesla tutorial for funny baku uh write up on all lan relay uh this um seekikit um javascript circom code which is useful uh development-based implementation by owner and then circuit which is this sort of thing we're starting to do with using circle with oxycom for vacuum b2b um we also have a paper on this contract and so on coming out in july i think yeah that's it for me any questions [Applause] we can take two questions uh yeah good thanks brain has anyone uh like prototyped a chat application that uses waku or uh like how far would the lift be to do that from where you are currently sure uh so basically status is using uh vacuum production it's in the process of kind of because this is a vacuum version one and they're kind of in the process of moving over tobacco v2 um uh then there's also other people using vacuum not necessarily for human chat because this doesn't necessarily have to be used for human chats so i think it's a probably called railgun that are starting to look into using allen with vacuum vector js and so on and we have other products like world connect for example using vacuum so it's not just for for human chat kind of thing um but yes so there's a bunch but it's kind of still very early stays especially with this all in theme because to actually make it useful we need to bridge the gap between sort of javascript and implementation but yeah cool one more question barry uh just more of a comment on the last question um blagoy and nazi have implemented that yes black always here for zk chat and so it's like orlan based web browser chat all right thanks oscar [Applause] [Music] you