New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

MACI - Private On Chain Voting - ETHGlobal London 2024

ETHGlobalWed, Oct 9, 2024, 12:00 AM

Join ctrlc03 from the Ethereum Foundation for a workshop titled, "Private On Chain Voting." This workshop explores what MACI is and how you can use it to conduct private polls, and took place at ETHGlobal London 2024, a 3-day hackathon held at the Truman Brewery in London from March 15 to 17, 2024. The event brought together the most skilled web3 developers, designers and product builders from all around the globe for a weekend-long adventure to advance the Ethereum ecosystem! ----------------- Follow us: https://x.com/ethglobal Check us out: https://ethglobal.co​m Email us at: hello@ethglobal.com

Transcript

[Music] um so ma stands for minimal anti-collusion infrastructure and basically uh it allows you to run private vots private PS on chain the main properties of it are collusion resistance so only the coordinator can be certain of the the validity of the vote you cannot prove behind any Reasonable Doubt how you voted to someone uh privacy so only you as the voter and the coordinator can decrypt your vote uh votes are not censorable and you cannot really edit of the lead vote but you can uh nfy it and finally the coordinator uh cannot produce false output um why do we need it um so there's a lot of like quadratic funding and quadar voting applications been built um and bribery is a very common problem uh because in these type of protocols um the majority of people can actually make a difference if uh collusion is easy then like in specifically for quary funding the funds might go to projects which uh do not really deserve them and at the same time if your votes are public you could also be condition um where whereas if you don't really know how anyone else voted you also might want to um do more research on the projects you're voting for um and finally which is kind of like the main gist of Macy is that because you cannot really prove to someone how you voted then why would they bribe you um okay so technical details the architecture uh we got like three main components so we got the smart contract this work only on uh evm compatible chains we got a circuits uh these are written in circom and we have a quadratic voting and non-quadratic voting flavor of it uh this are used to uh process messages and T the votes finally we got some typescript utilities which uh you can use to um play the coordinator and then uh process the votes interact with the protocol both as a user or as a um coordinator and some of the Primitives which you can use to build on top of it this include like uh Macy public Keys encryption algorithms and Ashen algorithms as well this is what the repo looks like um so if you do the side to H Macy you probably won't touch the circuits uh these are in red whereas what you'll be using the most are the ones in blue everything that is written in typescript So within the CLI you'll find the SDK um to be like a front end with it or whatever you choose so and the core will be the Clone or the smart contracts which is used to uh process messages and generate inputs for the circuits finally we got the smart contracts written um the one in the green and you'll find test deployment scripts and everything you need there so uh as a user the first thing you would do when you interact with Macy is you create a uh a Macy Keir so this is your identity in the Macy system and that is not to be confused with a ethereum public key uh this is the serialized form you can see it here um basically this is is a point on an elliptic curve won't di on the math part of it but when you register you send your public key and this is start on numerical Trion chain when you vote um you will take the key of the coordinator and you use ecdh to generate the share key um this way you encrypt um the message so whatever you send on chain is all encrypted but when the coordinator pulls the data of chain they'll be able to reverse the encryption you also sign your vote so no one can really publish a vote for you finally you might want to verify that everything was done correctly um so that would be after all of the uh processing is done and you'll be able to interact with the smart contract submit CK proofs to just verify that the result of the poll was um was conducted in a correct way um this is what the coordinator does um so fast forward to the end of a voting round uh the coordinator will merge the mer Tre like structures pull all of the events uh from the smart contracts and generate the state locally so this is like a copy of whatever happened on chain and from there they run this types code to process the messages uh so you decrypt the message you um you verify that the message is valid and then we going and generate snar proofs these proofs are submitted on chain to one of the smart contracts and there's some commitments to this data uh the same is done as well for the vot sing um we assume that the coordinator is honest uh but it's also true that what they could do is they could actually collude with bribers themselves um currently as the protocol stands there are some work in the pipeline to improve on that but technically they could decrypt the votes and just publish them or they could just decide to not conclude the vote but uh some of the good stuff is they cannot really censor any of the votes and that is is thanks to the smart contracts and they cannot perform any incorrect processing thanks to the zsn circuits um everything that is to consider the source of truth will be on chain so we will have the uh the root of a tree holding the signups the root of the tree holding the messages the number of user signed up the number of messages so whenever I use a user or the coordinator tries to verify the proofs this data will be pulled from um from the smart contracts and let's say the coordinator is trying to uh say I process all the messages but it only sends data for 99 messages when they were 100 uh the proofs will not validate and user would know that right so for the Aon um some of the stuff you guys could build if you wish to um like Quadra finding applications there's a few of these um we can take inir for them if you want like s fun for instance um Dow voting apps or tool Lings for Dow voting um some C resistance mechanisms for Macy so like Gatekeepers contracts there's some cool ideas like um using this proof of personhood uh like proof of passport what not so like all the users that uh using CK proof their human can join a ma poll or even like um build some front ends for them like um one to manage or one just to contribute we have a discussion here on GitHub I'll share this later on so you can just click on it and all of these projects are there and a few more as well in terms of how you can build on it um we're going to be looking at the Smart contracts yeah um so we got the user and the coordinator right so the coordinator deploys um the Macy smart contracts alongside this gatekeeper and invoice credit proxy you as a user or anyone as a user signs up with their key and the smart contract will make these calls and this simp simply answers can I sign up so do I P certain criterias which you decide or in this one how many votes credits to a g so like what is my voting power in this poll uh this can be like a cant value everyone gets the same some people get more because let's say in a quadar funding protocol they contributed money to the matching pool it's just up to you to decide as a builder then uh the coordinator can deploy polls um calling this function will basically trigger free deployments a poll contract a message processor and a tally um the PO one is where uh the votes are sent so you as the user will just call directly this Co contract and send your votes the message processor is for um coordinators to submit proofs of correct message processing and so is the tally but on top of that in the tally you can actually call some functions from the user perspective to verify that everything was done properly um so just one example here is a very simple um quar funding protocol I tried to build using Macy uh this is the main contract which inherits from ma So within the constructure we um pass all the parameter the Macy needs plus a few more that we need so because this is a quadratic funding we need a token uh so user can contribute to and a recipient registry is just um a list holding the addresses of the projects that um are part of this round um here something that you might do as well if you build and you change the contract see overriding the sign up function so as you see here we call in the normal Macy one but on top of that we are taking some funds from the user and storing how much they contributed there and again like if you change any of these uh this free cons to the show here you can extend the deploy pole function to do the deployment plus extra so I extended the tal contract to have an initialized function so here I can just call it as well and here is like the tally one uh so what's interesting here is as a user or well as a project part of a round if you want to when it's time to claim the funds so when all of the message have been processed and the ballots have been solid so the results are there publicly available uh anyone can trigger this functions and the snar proof the the vot option index so imagine an array of projects let's say we want to send the funds to the first project uh this will verify that the TK s proof is correct and however many funds or vots they will be uh receiving and um yeah in terms of bounties we got um five bounties but I just I thought the M those look cool so we got 1 2 three 2,500 for the first um then 1,500 1,000 four and fifth was split 1, 5050 software each and um you know if you do decide to build feel free to come to me um we can talk ideas and whatnot and um yeah again to conclude we think that um privacy is very important and especially private voting uh we hope there the future to this and we do hope the Macy can help make a difference um there's a lot of work that need to be done and it's nice to come to aaton and get your support or even if after this you guys are happy to just give some open source contributions we're always open sing your ideas and helping you collaborate if you want to reach out this um Discord invite for the PSC Channel um and yeah like if you got any questions now it's the time um yeah oh well I'm done yeah I mean if you have questions really yeah um sweet I just have a question regarding the could you say that again yeah I just have a question you generate a share secret between so a user and also the the contract let's go let go but I was curious about the private key that would be used for the share secet which one own it is it the deployer of the contract okay um right so you have your own private and public so that's the coordinator so the coordinator will publish their public key okay you when it's time to uh encrypt your vote you generate a random key at that time okay so for each vote you can generate the random key you take the private key and the coordinator public key use the CDH to generate the share key you encrypt to the share key and then you send alongside the message this random public key so the coordinator takes the message takes the random public key their own private key and they get the same encryption uh key does that make sense yeah sweet anyone else of course yeah correct yeah so we assume that the oh okay yeah and U to continue with that we just assume that the the one that going to deploy the the smart contract that going to generate sh secret it is trusted in the process right um yes so I mean technically the deployer doesn't need to be the this uh trusted party uh because they only need the public key right so anyone could deploy and then send um this coordinator public key but yeah we there's some level of Trust on this coordinator to do um yeah to do everything because they can equ the vote and can just share them uh with rers for instance um there's some work been done on preventing this uh but it's not there in production yet uh but yeah for now that's the case yeah good question though thank you by hello yeah in one moment of the process we register the all participants I mean when in the start I mean in one moment you have 20 address they're going to vote you need to it's a pro it's a moment where you need to register that that's correct um you as a voter you mean yes I have at least 20 voters uh in one moment before I can generate the proof I assuming is is a moment you can um you can register any time within the poll um duration so let's say the poll ends tomorrow midnight you can register any time before that and your votes for that poll will count because you signed up in the correct um yeah just before the deadline basically uh hi I wanted to ask you I was reading that there are some technical limitations to bigger amounts of Voters uh could you please explain a little bit about that if there are or and how how what are these limitations could you respond on that like what type of um issues so I was reading that there's limitations for bigger amount of Voters that's what I was reading on I think one of the repos or one of the Articles which is explaining it okay um yeah so basically the amount of wats is based on the capacity of the Merle tree so as the Merle tree goes larger in depth you can um accept more uh voters uh at the cost of like proven time so generating a proof will be um a bit longer for the coordinator because uh the circuit will have much more uh constraints so so yeah but technically like so we run a trusted setup ceremony for um the current version of the circuits and yeah the one that we have in production after ceremony is only maybe yeah 15,000 signups but for instance we could like run another ceremony with expanding well increasing this parameter to support 1 million uh the only cost there would just be um The Proving time basically any more questions okay so thank you guys for showing up uh thank you control C thank you and [Music]

Automatic transcript — names and jargon may be misspelled.