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.
I thought this might be interesting to people looking into DAO’s
The panel includes Joon Kim the Mina Foundation General Counsel.
Few thoughts on this:
- 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.
- Re next steps, yes DAOs want this
Cool, some thoughts on 1 & 2
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)
Could you explain the step where Mina reads the hash and voting power from Ethereum please? How can you pass infor from Eth to Mina without a bridge?
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
This developer Anthony, who’s building DAO voting tools, is very interested in this discussion and would like to get in touch with the technical team: https://twitter.com/A_Leutenegger/status/1477072583736582144?s=20.
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.
Here you can find the details of our design (with a working PoC): Binding Execution on Ethereum with zk-Rollups
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.
For now we have implemented keccack256 (with Circom) in order to understand the number of constraints required by the circuit (some optimizations are still pending): GitHub - vocdoni/keccak256-circom: keccak256 hash implementation in Circom
We are also making research with Halo2, here our franchise proof anonymization circuit: GitHub - vocdoni/halo2-franchise-proof
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
Ah! this is us Anthony works at Aragon Labs too.
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! 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.
Hello @o1-jason, nice to meet you.
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.
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)
- Voters send proofs to an aggregator
- Aggregator produces a big proof of all the votes
- Aggregator sends the big proof to the Snapp
(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.
Snapshot just announced their StarkNet-based solution Snapshot X: https://twitter.com/SnapshotLabs/status/1483168945234321408?s=20
and clearly aiming for the DAO voting market. Am curious as to what advantages the solution proposed by Mina or Vocdoni would have over Snapshot X please?
@lamps, that is a really good question, what are your initial thoughts on Snapshot X?
Hey friend, thought you and the team might like to read and comment on this. We are building (currently called Ovote - TL;DR: OVOTE is a L2 design for voting using validity-proofs (zkSNARK proofs), which is similar to zkRollups. The main idea is that the votes are aggregated offchain, and proved onchain through a zkSNARK proof , resulting in constant gas costs while scaling up to thousands of voters through a single Ethereum transaction.)