A Mina Snapp which enables Ethereum DAOs to achieve anonymous voting
Audience:
Any DAO on Ethereum. But particularly DAOs where one may not want to expose their votes
Dependencies:
Mina verifier on Ethereum
Snapp Architecture, for a binary vote:
Snapshot:
The Ethereum DAO snapshots its state, as a hash [H] of the current participants and their governance power.
Snapp creation
A Snapp address on Mina is configured using the hash [H] and the verification key for anonymous DAO voting. The Ethereum DAO contract updates its state with the address of the Mina Snapp. Because Mina is fully proven on Ethereum, Ethereum can trust the state of the account
Voting
Participants that are in the snapshotted hash [H] create a snark proof of their vote
Counting the votes
Idea 1: Zerocash protocol
A zerocash shielded pool is instantiated, with:
Each participant gets an account in the shielded pool with tokens proportional to their voting power.
An address with a public private key for each of the options to vote for
Participants can send one transaction each, to one of the voting options.
After a time period, voting is closed, and anyone can update the snapp to show the results in its data field.
Idea 2: Offchain aggregation (if onchain is too costly atm)
Offchain aggregators compute aggregations of votes
The Mina Snapp holds in its data field the aggregation its seen so far with the greatest number of voters
After a time period, voting is closed, and anyone can update the snapp to make voting is done
Reading the result from Ethereum
The Ethereum DAO reads the results from the Mina Snapp. Because it knows that the Mina Snapp used the same snapshot it did, it used a verification key matching the known procedure, and Mina is fully verified by Ethereum, it can trust the results of the vote.
Next Steps:
Check the above proposal for feasibility with the O(1) Snapps and crypto teams
We see if anyone on Ethereum would want this functionality, and we build a prototype together.
While certain addresses can be known to be controlled by certain entities most of the blockchain is pseudo-anonymous even with domains. I don’t see this as a value to main dao structure. There might be some examples on extreme end which might require it(If there are some examples for this I really like to see please share). On the other hand, I see significant value on pool data not being available till the end and off-chain aggregation. Not gonna dive off-chain since that’s a clear issue for most chains. The pool is closed till the end is good for dao because people who cast votes mostly don’t do enough research etc. either follow the most popular option going in the community or just see the percentages, go for the option with a majority of the votes. I don’t believe this is going to solve these issues on its own but going to improve for sure. Rest depends on creating a better system for who to vote with which weight that will probably take a long time.
For step 6 - to prep the DAO for a new vote, there would have to be a new Snapp account created, with the updated state hash [H’]. Not a blocker, but subpar UX. An alternative would that the Snapp queries the state of the DAO via zkOracles when ready
If I understand correctly, DAO members will need their ETH private keys to vote, correct? If so snarkyJS will need to efficiently support keccak and seco256k1. O(1) will start to work on this soon.
Yeah makes sense. Do you mean we’d need the Eth → Mina bridge though? If it was Ethereum I think that’s what we’d need to move state back onto Mina, not zkOracles
Good point. One possible idea to get around this, is on the Ethereum DAO side, voters could sign their Mina public key. Now the hash of the DAO vote snapshot would include voters’ Mina keys, and on the Mina side, we could avoid adding any new cryptographic primitives (again perhaps a hit to UX though, users would then need a prestep of registering their Mina keys with Ethereum, probably good enough for a demo and worth it for some applications I’d hope still)
What can happen, is the Ethereum DAO commits to a hash of all the data needed to vote.
Then some operator creates a new voting snapp account on Mina, with the same hash as committed to on the Ethereum side.
The Mina side can’t verify that that hash actually came from the Ethereum side - but the Ethereum side can. Later, the Eth DAO can look at the Mina state smart contract on Ethereum, and make sure that the vote that happened on the Mina side and confirm that it used the same hash that it committed to earlier.
I’d imagine the full protocol as:
The Eth DAO commits to a hash of the voting information
An operator creates a Mina snapp, built off the hash the Eth side committed to
The Eth side commits to the Mina account loaded with the voting hash
Votes are submitted on the Mina side over a time period (say a week)
The Eth side reads the results from the Snapp account that it previously committed to on the Mina side
Hello.
I’m new to the Mina forum but I’ve been following the project since the early beginning. I’m CTO at AragonLabs and co-Founder at Vocdoni.io (project that was acquired by Aragon 1 year ago).
We are also working on a similar approach as the one described here by Evan and I’d like to share it in order to find possible collaborations and synergies. Our design follows mainly two big properties: “censorship resistance” and “gass-less voting”. Its not (yet) anonyous since this would require a level of recursivity, but that’s something Mina could probably solve.
We are still making research on that design, it’s not final, there are some improvements that can be done. For instance, if we could verify ethereum storage proofs within a Snark (keccak256 + Ethereum Patricia Trie + RLP encoding) that would make the solution almost perfect.
Our current status is “research” and soon we’d like to go for a production ready solution. It would be great if we can work on that issue together if it makes sense for both of us. Or final objective is to build the infrastructure for making EVM DAOs governance gasless, censorship-resistance, anonymous and with binding execution (without subjective oracles nor optimistic approaches). If using Mina as L2 for voting makes sense, we would love to use it aswell.
In case you want to discuss something more in private, DM on this forum or twitter @wildp4u
Anthony here!: Yes, but you are 100% the person they should be talking with! Very much hoping the Mina team can chat with P4u about this potential collaboration!
Hi @p4u , My name is Robyn and I work for the Mina Foundation. I have shared this with the rest of the team so we can set something up! Thank you @lamps for sharing this as it is much appreciated
Hi @p4u! I’m a PM at O1 Labs for snapps. Happy to hear of your interest in building with Mina.
This sounds like it would require the Ethereum Bridge, and likely the two-way Ethereum-Mina bridge, if you’d want to read ETH balances from Ethereum to be used during DAO voting process occurring using a Mina snapp.
Maybe we can set up a time to chat about specifics? I’d be interested to discuss more about the type of bridge you’d need (one way or two way) and the specifics of the functionality you’d need within SnarkyJS, so we can factor it into SnarkyJS’ roadmap. Will DM to coordinate.
The Mina Ethereum bridge seems like an interesting approach and I’d like to know more (specially regarding the current status and roadmap). However our current design do not require a Bridge. We use “ethereum storage proofs” which are Merkle Proofs of the Ethereum Patricia Trie proving that certain data is stored within the ethereum state for a specific block height. This data can be either an erc-20 balance or anything else stored inside a smart contract.
The voters will need to use a web3 in order to fetch their storage-proof (EIP1186). Then they can use the storage proof offchain to vote. The verifier (or aggregator) only needs to know the Ethereum State Root hash in order to verify that proof.
Ideally that offchain verification should be done within a zkSNARK, so when the election is finished the aggregator can just upload the zkProof to some Ethereum Smart contract that will verify it, proving that for an Ehtereum Height, for a ERC-20 contract address the results are valid.
We have already implemented a voting solution using the storage-proofs approach (details here Notion – The all-in-one workspace for your notes, tasks, wikis, and databases. and production frontend here https://voice.aragon.org) but instead of a zkSNARK aggregator we cast the votes into a Sidechain (https://explorer.vote). The problem is that in order to send back the results to Ethereum we need to use a trusted oracle (or something like chainlink). So that’s why we are working on this new approach (Binding Execution on Ethereum with zk-Rollups) which replaces the sidechain by a zkSnarks aggregator thus results can trigger binding trustless execution into any EVM based network.
Of course if there exist a trustless (not optimistic) Mina Ethereum Bridge that would probably simplify the approach. I’d like to know more.
@evan
Thanks for posting this. Very excited about the potential of this. Can you share how you see the offchain aggregator work?
Talking about step 1 in Idea 2 (Offchain aggregators compute aggregations of votes)
(I think) this is the same thing we did in the zk programming workshop in 2019
Note also that the aggregator could censor votes by not including them. I did mention in the proposal above voters could send votes to multiple aggregators, and the snapp could keep track of the most complete aggregation as a mitigation
Another option to prevent aggregator censoring votes could be by allowing users to optionally send the votes to L1, where the votes sent there must be included to the aggregated votes by the aggregator.
This is what zkRollups do to prevent censorship by the aggregator (eg: Hermez: (1) , (2) , (3)).
So if a user is censored, they always has the option to send the vote to L1 directly, and the aggregator is enforced (by the protocol itself) to include that vote in the aggregation (if it does not include it, the generated proof will be invalid). But this would require a design where the voting process is not aggregated in a single batch at the end, but in a more continuous fashion, although the process could have an extra window time right after the voting process is closed, where in this time window the users can check if their vote was included and if not, they can send their votes through L1.
In this way, even if all the aggregators are coordinated to censor specific users, the protocol allows those users to include their votes.
@o1emre mentioned that O(1) will start to work on keccak256 & secp256k1 support in SnarkyJS, I’m interested to know more about this (we implemented keccak256 in circom and we’re considering also the secp256k1), there is some github issue to follow or some other forum thread to keep track of? Thanks ^^
@o1emre mentioned that O(1) will start to work on keccak256 & secp256k1 support in SnarkyJS, I’m interested to know more about this (we implemented keccak256 in circom and we’re considering also the secp256k1 ), there is some github issue to follow or some other forum thread to keep track of? Thanks ^^
@arnaucube I just created two Github issues so you can follow progress on secp256k1 and keccak256 hash. We currently have them prioritized for after Snapps on Mainnet, but could be sooner if we finish other priority items more quickly. Open to receiving PRs for these too; if that interests you we could iron out any details on those threads.
Very much hoping the Mina team can chat with P4u about this potential collaboration!