ZK11: ZkSnap - End-to-End Private Voting at No Cost to Users - Rahul Ghangas

Transcript

[Music] cool um thank you for being here I'm Rahul I'm the founder of Aries Labs um and today in some halfhazard manner uh I'm going to talk about how to build scalable ENT private voting protocols and we'll try to reduce the cost to the end user to approximately zero um so our mission is to empower Dows organizations and whatever the state-ofthe-art in voting protocols is to make them uh make important decisions uh with privacy and

integrity so uh if you consider current State ofthe art um probably everyone uses one of the either of the existing Solutions today um and I been um a dow uh member of a variety of dows um done voting there and we across time I I saw a variety of different problems um which was obviously centralization risk um a lot of these protocols uh exist on trust assumptions in the sense that um you know snapshots of eligible voters so eligible sets are completely um generated by these um protocol servers

themselves um there's the bandwagon effect um lack of privacy in voting leads to um a certain psychological phenomena um which is deemed as the bandwagon effect and it simply means that people tend to vote or follow uh whatever's the most popular right say if I'm holding a d vote today for a and um there are 90% of the vot in favor of yes and suddenly vital comes in and gives an argument um against whatever the favorable vote is um right now uh most people would shift

their votes without even considering what um without making their own opinion so that's band wag effect and obviously privacy has uh different concerns as well because you it can lead to coercion um you know I can always take a hammer if I know um if there's a poll in this audience if there's Paul and I I personally know Paul and I saw his address vote against my protocol uh against my proposal I can always go and like Whack Him in the head with the hammer with a hammer and then from the next time he will be well in a sense convinced to um either not vote or vote in my favor so this is uh the mow report and this is what the state-ofthe-art exist and um what features are guarantees

different voting protocols give you um out of these if you can see um the Aztec Aragon solution is the best one um however it lacks one thing private protection which today only Macy is able to provide uh we will try to build a protocol that will um over the next 7 minutes that will try to give all those guarantees uh from Aragon and Aztec um however we will try to bring down the end user cost for each user down to approximately zero so we we term this ZK snap as um let's say a bastardization of snapshot uh ZK version of it um just a

name so the first step is user privacy right user remains to uh needs to remain private they need to be able to prove that uh they're part of some membership set and they should be able to prove how much uh voting weight they hold in a certain uh D so uh the easy solution is uh build a commitment uh a m commitment to it and then you can a user can simply create you know uh Merle proofs um however that's not so great because you come back to the same problem of who creates this meral commitment how do we trust them and no user is going to iterate

over all members of the Dow and try to recreate the membership set to verify that it's correct so what we do is we Leverage storage proofs we try to use the blockchain as an arbitrary lookup database and then we can Define arbitrary predicates um on these and Define membership sets based on that so membership set could be you know a user says uh you know uh I was in LP in a a specific Unis swap pool over um 1,000 blocks from after blocks block 10,000 right I should be able to prove that however there's no way to prove that from just a meral commitment and then we need to be able to stop user users from

being able to vote again and again um so basically stop a double spend vote uh so we need to use another fire for that case plume comes to mind especially when building on ethereum um because it's state-ofthe-art for using ecdsa signatures to create um well using ecdsa uh public Keys um and private Keys uh to create deterministic signatures that can act as ifers in fact uh one of the authors of the um paper are presenting today uh for ZK mail um however Plum uh writing plume in circuit is fairly expensive um so can we do better so usually um plume makes the assumption that um the message can or cannot be

random however if you constrain the system to a certain um degree uh we you could potentially uh get away with this right and what we do using existing you know uh wallet tools that uh that are out there so what we do is uh instead uh ass assuming that every time for a specific proposal a unique message can be created a user can sign that message so that that's the signature they can append that message to their signature the concatenation and hash the whole thing and this will create a deterministic um uh nullifier for them and it's extremely cheap so uh using Spartan

ecdsa they've already shown that verifying ecds signatures can be as cheap as you know four 5,000 constraints and suddenly we bring down the cost from you know hundreds of thousands of constraints to a few thousand constraints which is okay you know because at the end of the day the entirety of the user proof needs to be created in the browser the second thing that we need is ballot privacy so the ballot should remain private and uh no one should be able to see the running vote um while the protocol is still going on so usually elgamal comes to mind because you know if if you encrypt it into the uh encrypt a value to the powers you can just multiply the two values and you should be able to do addition over encrypted over these encrypted values

however you need a lookup table for it and um especially if voting weights can if you talk about ethereum voting uh weights if um we use them by token balance they can be as large as a uh the largest value of a u 256 which is not great right you can't have a lookup table that great so maybe we can do use something else in this case we use the palier crypto system um pioneered by Pascal palier um and palier allows us to do uh addition over encrypted text uh in a very cheap manner using just a few multiplication and modular operations cool so as long as I have encrypted my values um and I give my

encrypted vote to someone let's assume this to be a semi honest party uh they should be able to take two users votes and add them together to create whatever the running tally of the ballot is going to be and um we should have an encrypted ballot that no one can see now the problem comes out to be who decrypts this ballot and how do you how do you make sure that no one withholds um the data or the what what the ballot value is once the the voting period ends so we use something called time locked encryption or delayed encryption and basically the the private key used for the homomorphic encryption we encrypt it using time locked encryption at the

start of the protocol and then we keep a running tally for using um running tally of the ballot using homomorphic encryption uh additive homomorphic encryption and at the end because we've defined the voting period and the time lock encryption of the private key to be the same as soon as the uh voting period ends the private key becomes public and anyone can just simply pull the current encrypted ballot and see what the final results are we also want susten verifiability and also we don't want uh you know retroactive attacks which is once uh users proofs should not be um public at the end such that um if if I have you

know 10 users proofs and once private key becomes public I can decrypt their balances although their identity is still Anonymous I can do a statistical analysis attack and still be able to figure out who voted what so uh we use recursive snugs um going back to our semi-honest uh person aggregator uh as long as we assume that they censorship resistant uh they can continually continuously um keep on rolling up these proofs and then you have a final proof that gives no other information other than um whatever the final ballot vote is and it also gives you sust verifiability in the sense you you know um you have a Gro 16 or kcg based proof at the end which you can

verify on ethereum um so a single proof uh gives you the validity of the entire voting protocol uh I'll quickly walk over what the application workflow looks like today uh before the en encryption we encrypt the secret via tle uh we provide a reference block number for for the storage proofs we provide an encryption election ID uh and some certain combination of plain text with election ID forms our unique message for um our deterministic nullifiers uh the election duration which is used to encrypt the private message and the encryption public key that is made public at the very start so the users can vote uh during election you have the

aggregator this is our semi-honest aggregator that keeps on taking user proofs um rolls them in a single proof and at the end you can put this final proof anywhere for the users to be able to verify you can put on ethereum you can put onfs you can put on ipfs so that all users can pull it and then put it on ethereum for verifiability as well and uh after election um the results are published and anyone can simply pull the private key from Dand and should they should be able to uh decrypt the ballot and see what the final vote is without any other information being uh leaked um this is what the circuits look like um you know user provides signature vote vote weight Sal storage proofs as

private inputs and all the other stuff uh as public inputs and then you you know um create a proof um aggregator takes the user proof so we use um IVC in this case so um you can think of it as um you know induction like um proof aggregation um in the sense St they take the proceeding aggregate proof verify it take the current user proof and aggregate it to new new proof uh future improvements are going to be to add fully homomorphic encryption uh multiple voting modes in fact fully homomorphic encryption would allow us to enable multiple voting modes because we won't be restricted to uh only addition anymore um and um we can have you know quadratic voting we can

have um uh weighted voting voting with weighted voting with uh linear backoffs or something else and obviously one one single thing that that still escapes um this protocol and including Aragon nasx is anti- collusion um is something that we need to take care of because the user could still create a public version of the same proof and uh I could have a smart contract uh where I publish you know give both the proofs public and private and um as long as the public proof proves to me uh that uh that uh um you know a user voted in a certain way I I release some funds to them and then they

submit the the one with private input to the aggregator thank you uh you can scan this to access the white paper and um a form to join the alpha wait list for the protocol cool thanks a [Applause] lot do we have any questions uh thank you I have a question that do you achieve Everlasting privacy in other words uh how do you prevent individual ballots to be encrypted decrypted after the voting yes so this is why I said the

aggregator needs to be semi honest in the sense they would not leak individual V uh user proofs later on so this can be implemented using multiple methods you can have it as a a te or it could be an NPC based Network or or something else um you could also have you know um uh encrypted Witnesses um and use those to generate uh the recursive proofs so again it's a trade-off space you can pick one or the other um however you need do need a semi-honest uh aggregator in order to do so okay thank you uh more questions maybe the next speaker can already uh go on a setup um could you explain how how you

use nullifier to not let people vote twice yes so um let's just take the example of plume plume allows you to create uh a deterministic nullifier for uh that ties a user to the public key and because it's deterministic a user whenever they created again it's going to be the same nullifier right which means if I add it to um an append only nullifier tree I can always uh I'll have to provide a proof of non-inclusion in order to vote and if a user is unable to do so that means their vote is not valid okay so let's thank rul again [Applause]