Stealthdrop, Applied ZK - Day 1

[Music] so these days airdrops enable governance the idea that people can people who represent the protocol or care about the protocol can vote on the future of the protocol however the issue is that if you can see how everyone else is voting you yourself might be influenced by them if you even see that someone voted you might be influenced to spend more time or less time voting on that proposal in addition whether or not you sell your tokens can be a controversial issue and whether or not you vote can also be completely public which is maybe a feature that we don't always want introducing stealth drop the first way to do anonymous governance via zero knowledge airdrops so how does this work you can imagine that the airdropper first publishes a merkle root of a merkle tree of eligible addresses just like a normal airdrop however uh instead of claiming from your eligible address directly you claim from this anonymous address so in this case yush.eth is in the eligible addresses but instead i'm going to use my anonymous address to generate a zk proof that represents that i am in this merkle tree then when i send this to the contract the contract will make sure i can't double spend by adding me to a nullifier list and i'll receive my coin to the anonymous address instead so again your air dropper publishes the merkle root you create the zero knowledge proof and the on-chain contract verifies that and awards you the token now what exactly is the zero knowledge proof proving well we want to keep all aspects of our original identity completely private so that means our signature our public key and the merkle path have to be private inputs however what we do need to make public is all the aspects of the airdrop itself that the contract can check things like the merkle root being the same as the merkle root released by the airdropper the message that we're actually signing being the same message that they requested we sign as well as our nullifier the zk snark just verifies that all the information we inputted is actually calculated correctly the merkle path the signature the nullifier and the message that we saw in now you can see a demo here where first we connect the original wallet and then we can swap the wallet in metamask usually you would probably use a different computer or a different website a different tab and then you will generate the proof that your that you actually own that original address that you entered which will eventually claim and be sent from the anonymous wallet here the proof is cache so it loads very quickly but in reality the proof takes a couple of minutes then you can claim the token to your anonymous address wonderful let's see the transaction cool we also battle tested our uh airdrop idea with a hundred plus claims from the xerox park and hack lodge community um so and nolan we'll dive into more details about how we scaled that so one issue you guys might have noticed is that for our nullifier we use a hash of the signature however these signatures are non-deterministic meaning that even though you may assign with a deterministic ecdsa a verifier of that signature cannot actually verify that whether it was generated deterministically or not and as a result this would allow someone to generate infinite number of signatures and claim as many times as they want so there are a couple ways to fix this the easiest one is to just run the prift above circuit in your browser in which case you won't have to do reliance signatures at all and instead of your nullifier being a signature it must be a hash of your entire proof there are also other ways that we can get around this issue that requires slightly more complex technology such as releasing multiple lists or using mpc to generate randomness and we're happy to talk more about those solutions if you come up towards uh come up to us afterwards so i'm going to talk a little bit about sort of the internals of building salt drop so start off was built during this program called eat uni hack lodge which is just like a hack week so one of our goals at the time was to sort of maximize the amount of learnings you can do and uh just like have fun so for instance here this uh slightly questionable comment i made at 1am um anyway so uh when we started working on cell drop we saw that circum2 had been out for like a couple months at this point um and it seemed like the shiny new rust compiler and all these cool uh like tricks and things like that so we were like okay let's try using circum2 so when you started using circum2 it turned out uh the witness generation had bugs in it and so at this point we could either write stall drop circuits or fix this circum to itself so we decided we should actually fix our con too um so we took a detour and uh ended up fixing some of the bugs intercom too and a lot of those vrs were also merged so um all this is public now and uh besides this uh one of the big themes of using ecdsa in a snark is that the circuit is huge it's like 9 million constraints and along with that comes like all these problems of like scaling and um you have a proving key that's like six and a half gigabytes so how do you even run these proofs so the solution to that is using a remote snark mover for now um and we ended up writing this really neat uh zk note server as we called it um which has like a queue and there's like resource management and all these things sort of neatly in is just like a package in fact the zk pairing team which will demo tomorrow um is using a fork off this node server which is super cool um another idea at the time so we really wanted to do these proofs in browser but it just like with these huge z keys and these huge circuits is what just didn't seem possible at the time but one of the ideas he had was what if we take the proving key and chunk it into small pieces uh load these pieces in browser do whatever competition needs to be done and just like delete it or like re-download it or do like all some kinds of operations with it um so we ended up writing this patch for snark js which we call like chunk c keys um at the time it does reduce memory usage by a lot but at the time even with this it was not the ecdsa circuits are not good enough for uh doing proofs in browser uh but simultaneously during the last couple months or something the ecdsa team has been working on optimizing the ecdsa signature verification circuits um and they optimized it by like a factor of 6x almost and now it turns out that combining these two optimizations the ecds signature verification and chunking of z keys you can actually prove ec dsa signatures inside of zk snark in your browser and in fact there's a another team in their expert community working on zk reddit which is uh planning to use this uh combination of patches um another cool thing by by like poking internals of snot js and surcom and all these all this stuff we actually ended up discovering a couple of optimizations in uh um how snark js proves rick um and in fact one of these was uh this caching of z key curve computation um which uh almost cuts down by like a second flat for any circuit in browser proving um so it turns out for like smaller circuits maybe like thousand constraints or something this is in fact like a 30 of the time of your computation so it is like a pretty massive uh improvement um and actually this is the open pr right now so i know there's people in in this room that can help us get this word so wink wink um yeah i think those are like sort of the high level overview there's a lot more detail in the readme of our repository um and there's all our twitters and all of that and thank you to everyone in the xerxpark community for this idea and helping us execute all of this together thank you [Music] you