Offchain Voting with Onchain Trustless Execution
ETHBarcelona 2022 · July 2022 · 22:31
Arnau Cube presents a way to vote offchain while still executing the result onchain without trust. The talk covers how offchain voting keeps costs low while trustless execution protects the outcome. It addresses the cost and trust trade-off that DAOs face when running votes. Presented at ETHBarcelona.
Speakers
Topics
From ETHBarcelona 2022, hosted by ETH Barcelona.
Transcript
hello and welcome to the forest stage here at east barcelona i wanted to introduce to you our now cube from aragon zk research in the hand [Music] thank you very much so hi um i'm from the aragon zika research team and and today i'm here to talk to you about like a research project that we've been working on for these last past four months more or less which builds on other previous stuff that we've been researching and the main idea is that we we are building this um protocol or scheme which we call a vote
and the idea is that it's a off-chain boating with unchained execution and yeah so well we will go through these things that you see us on the top so the main motivation of this project is that currently in ethereum as everybody knows now the gas costs are very high so it's not it's hard for people to interact with dogs and so on so we have these systems where people delegate boats or people vote in a in a polling system and and then um others like boat on chain and so on so for example we have this direct unchained voting which is like this this i mean people is spending tons of gas just to express their voices then and
this is these triggers that our fans movement but also we have these other schemes where like people vote on an off-chain poll which is known by sorry non-binding and and then we obtain this result but this is not directly binded to the ethereum smart contract so then we need like this small subset of users which are like the multisig owners of that dao who at the end they encode in a multi-seek uh the result of that off chain polling and they execute this on chain through uh ethereum transaction um as you can imagine this i mean these people can screw it into any moment and they can censor if if there is something that the community wants but it's not aligned with their
incentives so that's why we are building this about um project so the main idea is that obote is a layer to design for voting using validity proofs also known as zika rollup or zika zika snark relapse um the main idea is what i was saying that uh boats are aggregated off-chain and then prove it and chain through as zika is not proof uh so what we achieve with this is that we can aggregate thousands of uh boats and signatures and and sensors proofs from users into a single ethereum transaction so as you can imagine this um reduces a lot like the gas costs so a bit of context here like we started this project like four months ago but we
are building on um research that we've been doing for the more than one year now uh in in bogdoni and and we aim that this can be like a contribution to the aragon ecosystem also take in mind that this is a research project with a very specific scope with the aim to be like a fierce practical step towards this feature of zk technology for for voting and house but we crop it a lot the scope in order to be able to build something in a few months but we plan to keep iterating that and having privacy and other stuff so how it works the main idea is that so we have on on the left there is this triangle this represents the census tree basically you
can understand this as so you have the list of public keys and weights related to each public key and then this is what will build the sensors in the in the shape of a miracle tree what we call sensor stream this is this is happening off chain then when you create a new voting process for your dao uh you send the sensor's route to the about smart contract then what happens here is you create this process so people can start sending their votes plus the signature plus the census proof to the oval nodes um and then this oval node is the one who will aggregate all those votes and generate a valid zk smart proof that as we will see later
this proves that everything is computed correctly and the result the climate result is is correct then this is sent to the smart contract on ethereum and just with this single transaction containing the zika proof um the smart contract can verify this and if everything is fine this means that all the votes that are computed for this result are the correct ones for valid users so this can trigger execution on chain like and for example moving um the dao fans or whatever then so how these sensors works we are using uh the same sensors that we've been using in the past in in bogdoni and we are using like the same cryptographic primitives that uh we had in item three and also in armies so this
medical tree is a sparse binary miracle dream where basically the ideas that we put we place on the leaves like the public key and the weight of each uh eligible voter so then we can prove through the numerical proof that a certain user belongs to the to the sensors so how the flow works more or less the main first of all we have this sensors and process creation phase where all the users they generate a new public and private keys and they send the public key to the organizer the organizer then will take this all these keys and we'll build the sensors as we as we have seen the the american tree the census 3 and once everything is
ready um the organizer can send an ethereum transaction to the smart contract to create the new process where the organizer specifies like the numerical route but also like a transaction hash and other stuff the transaction hash is the cash of the transaction that this new process aims to execute if everything goes well then once the process has been created we enter to the boats boats casting phase the idea here is that the the voters they first get the siblings the siblings is like the miracle proof so also then they sign the vote option and they send the vote plus the public key the weight and the sensor's proof and the signature to the about node then the um
after the oval node gathers enough proofs and votes the oval node what will generate the zika snark proof and then anyone any user can claim or get retrieve these results plus the um zk snack proof and then anyone can send this proof to the ethereum smart contract which will verify the the correct computation of everything and if everything is fine we'll execute the unchain configured transaction and moving funds or whatever so here like a little bit of like how this timeline looks uh so this is like the the line of the smart contract uh
block timeline let's see then uh so the first moment we have the the organize organizer sends an ethereum transaction containing this uh data like the transaction has census rule sense of size minimum of participation this is the threshold of how many voters you need to to have this this this results accepted and also important here like the results publishing star block and also results publishing window this is as you see from the block and and to the block n plus w this is the the window of time where any about node can send a valid zig-zag proof claiming a specific result so as soon as we are in the multisig mode as soon as um there is a valid proof that times a a result that has
enough support then this will be verified and trigger on chain transaction we have another mode that it's a bit more complex um later you can check the the full document that we have online but uh the idea is that this is a more like a referendum mode where the idea is that um you you're not thinking into account only that you have enough support you want also to balance on how many users are voting no and how many users are putting yes like a referendum so for example let's say that you have like 1000 users and you and you set a threshold of minimum participation of um 100 users out of this 1000 then if there is like 100
users voting yes and 50 voting no then it's a yes at the end so this will trigger transactions but in this case if later appears as another gk proof proving a result that is like let's say um 100 positive votes but then 300 negative votes um in the overall percentage this will not pass um will not pass sorry um it's a bit more complex to explain sorry but um we have this well explained into the document that later i will link but yeah just take in in mind that there are to mount like the multisig mode and referendum mode and so you can combine these into different kinds of voting processes then um the results mode sorry results publication uh the idea is
that you can have multiple nodes so if there is a node that is acting in a bad behavior uh it's censoring boats or whatever you could see like people could organize and boat through another node uh which will gather and act honestly uh so it's it's fine if there is one node that is it's not acting honestly also like just to put some numbers like this the current snark proof verification it takes like uh 262 uh k of gas and then the full resource publication for the multi-sig node sorry multisig mode it takes like 400 but then the referendum mode it takes like almost um 1000k so one one million then okay like the circuit this is a bit tricky but the main idea is that the
circuit ensures the zika proof uh sorry the the circuit through the zika proof ensures the correct result computation so the idea here is that the circuit is ensuring and checking that the each boat that is included on the proof and computed for the final result each vote is signed by a valid public key and this public sorry by a valid private key and this private key it's assigned public key is on the miracle 3 with a specific weight and this is in under the census root of the of the census tree um so the main idea is that we are ensuring through the circuit that everyone who is voting uh has the rights to vote and as we are
balancing uh with the weight of of the of the public key and and also that everything is fine that there are no no votes repeated and so on in the documentation it's it's more extended so you can check it there also then regarding properties so this is the properties that we have for this current design iteration which is the first one but we aim to keep iterating this and doing new newer designs and so on but basically what we have now is this universal verifiability also for informability translates and binding execution this is what we were aiming for like to have this big scalability but on the same time be having this translated system and with binding execution that can trigger on chain transactions then also
because of that we have this off chain gasless voting so the idea is that we can aggregate thousands of boats like let's say 10 000 votes in a single ethereum transaction so you can do numbers and see like how we are saving uh big numbers on gas costs and so on so we have this scalability and also because of the ch the sensors is built of chain we have these chain agnostic sensors so you could have your dao with specific sensors and then you could use these sensors in ethereum magnet or also in polygon or in any other chain the main idea is that in order to verify the zika snack proofs we need to compute pairings and chain so all the ebm like chains they have this and probably for
some cosmos networks also then okay properties that we are not covering here but we aim to cover in the next months and years in future design iterations so there is no water privacy this is very important but so for this first iteration we focus it into highest scalability but next thing is privacy also no token based booting but also it's not on the scope but we understand that most of those are based on this model so it's something that we we look at in into the future for that also we are not currently we cannot aggregate different results of different uh over nodes this is something that we will also like to go for then what we are using so basically we are using the item three stack like the circumstances
rapid snark and so on so big big thanks to george belinda for that also we we use a custom implementation of a compatible vertical tree that we have which is arbo arbor is um three in esperanto so it's a medical tree that paralyzes in bicep by cpu so it's like quite fast and but it's compatible with the circumstance also then this is not just like a idea design project it's also like a we did an actual implementation of this uh so we have the circuits the smart contracts also the the the oppo node and then a small client lib to generate like the public keys and to sign and and so on so you can you can go and check all this code then okay direct use cases of this first iteration so we have as we saw the
multi-second chain results but also we have the uh off-chain referendum without chain results so these two modalities and then as an extra uh because of the characteristic of these sensors that we are using which is the same that we use in bogdoning in the blockchain so this sensors allows us also to use it for on-chain and anonymous voting this is what we have already in the bogdoni chain but we could use also this for an ethereum smart contract and so on but it's expensive to verify each user proof that's why for the moment we we are focusing into the stability scalability sorry but then we aim in the future to iterate this and also have privacy then feeder research okay one thing that we have like now in
the next thing to to look at is this about dao the main idea is that currently as we saw the the census is built of chain and so this organizer needs to gather the public keys of the people the idea here would be that people can deposit money to the smart contract and while doing this they are also um sending the republic key so then the smart contract can be building live on chain this census 3 with the weights based on the amount of money deposited by the by the users of the dow so then at the end what we have is like this live unchained census tree based on the deposits of people on the dow so then these people can go and vote through the about design and decide
what to do with this money that al them all of them are gathering together this is something that we we are looking for to to build uh we we just need to build a smart contract and but the rest is like what we already have then as a future more meat and long term research we have this proof recursion bringing signatures inside inside the smart circuit ring signatures is what monero is using and the idea is that we can have also uh anonymity inside the circuit so we could have this highest scalability but on the same time having the privacy and so on also ethereum stress proofs and ethereum signatures this will allow us to prove inside the circuit like a census based on the current state of ethereum so you have some tokens in the serial chain so you could prove
this directly without any intermediate step also like uh we look we look forward into like research on results aggregation uh from different nodes and also like other proving systems uh other than 16 which is the current one that we're using such as splunk and hello and so on so then uh that's all um as a main takeaway um we will this in in these last months and the ideas that this is a research project but with the aim to be close to the uh to a final product that we can build and and so on the main idea is that you can think of this as a zika roll up but for voting uh so you we have this highest scalability that jk labs has uh thanks to the use of zika snarks and then the main idea is that
the boats are aggregated off chain and then prove it and change through a single etherium transaction which contains the snark proof so we can scale up to thousands of users through a single system transaction so reducing massively like the gas costs so if if you want to check more details like this qr code but also like this url is the pdf like the paper the technical document that we have now on draft which explains this and more stuff more in detail and more extended so if you are interested just check it out and yeah so i don't know if um if there is questions or comments i mean i see here that we have three minutes but maybe i rush it too much so
sorry good question so the question is if we could add token based voting uh using this weight of the american trees absolutely that's the main idea but the thing is that currently with this field's design if somebody does this everyone else need to check that everything is well well computed like that the person who or the entity who is computing this medical deal with the weights based on the token holdings uh is acting well and is not adding fake users or fake token holders but if everything is fine uh then yes
we aim for this future the future iterations to have this in an automated way so that who builds the the sensors three is the smart contract itself so then we don't need this human interaction in the middle that as at the end is if there is a human interaction at some point other people needs to check it uh because but yeah oh you said the notes can censor some of the votes can they censor it by the address or can they censor it by the vote uh like no or yes they could do both but the idea is that if this happens like users can still like you go to the front end and then you could send your vote to multiple nodes so if there is this bad actor node
you can still uh like the rest of nodes uh the first one who gathers enough support to trigger the transaction uh will generate the proof and anybody can send this proof on chain so that that will um prevent the censorship attempt yeah but good point uh so one question i have is uh you mentioned uh the weight um can be calculated for example based on the token so is it gonna be like is something generic that for example we can have a smart contract that gives you a number and at some point is the number of tokens but in some more complicated cases it could be you know based on whatever we want to put in that the smart contract so it is still trustless but it gives flexibility is that something that you're thinking or just
going to be tokens yeah that's a that's a good point absolutely the idea is that to have this as the the i think very flexible so yes this this will fit very well uh also like for the fish so sorry so we have this for this first iteration then we aim for a second iteration where we have this smart contract that boils the sensors on chain but then from here yeah i mean also one thing that somebody asked us was that if we could when we go for this privacy thing if so there is the privacy of users but also the privacy of the dow itself maybe you know what happened with the constitutional doubt that they tried to buy in an option through a dao like a piece of the constitution so what happened there was that the there was a lawyer firm who they knew how much money
they had to bet so they could like go a bit higher and they knew that the dog would not answer that so if we can have a system where the dow can also not show publicly how much money they have uh this also is uh like uh something to look at so yeah all these things we aim to keep doing this this kind of research and iterating and yeah and privacy is important and and also like this flexibility and composability for sure so okay so i i see i i'm sorry for with the focus i don't see anything i saw a han i think but okay thank you very much
[Applause] so [Music]
you