This article proposes a proof-of-concept that leverages zk-SNARKs to achieve the next frontier of governance: gasless, verified, and binding on-chain governance.
The technical content of this proposal has also been posted to the Ethresear.ch forum here for community discussion.
As a leading digital governance project, Aragon Labs invests heavily in researching and innovating governance models. We have identified various layer-2 governance solutions that exhibit potential but also leave open several technical questions. We have been able to achieve gasless voting processes on our specialized Voting Blockchain – Vochain, as well as designing and implementing a method for using Ethereum Storage Proofs to bridge ERC20 token-based censuses from Ethereum back to Vochain. Until now though, the possibility of bridging results back to Ethereum has been an open research question.
To this end, Aragon Labs has been conducting experiments into a new design that would allow for the results of an off-chain voting process to be bridged to Ethereum, without using subjective oracles or any other trusted component.
The core innovation behind such a proposal is clear: no system we know of is able to organize a voting process off-chain and trustlessly execute actions on Ethereum based on the results of such a process. The use-cases for this proposal potentially include all governance processes that execute binding actions based on the results, such as (but not limited to) DAOs voting on asset allocation or smart contract changes. These governance processes must currently take place on Ethereum mainnet, incurring substantial gas fees for every voter. Alternatively, voting could take place off-chain, but trust an external component to accurately and honestly relay the results back to Ethereum.
Our proposal would allow voting processes that take place wholly off-chain to execute results on Ethereum with the same integrity as on-chain governance, at a fraction of the cost.
Before devising a technical solution, we defined parameters for our research proposal:
The requirements were for the voting protocol to be:
As a proof-of-concept design, we accepted the following limitations on the proposal:
Under the design of this proposal, when creating a new voting process, organizers submit a transaction to Ethereum specifying the contract address of an ERC20 token to use as a voter census. The Storage Root Hash of this address, at a specified block height, becomes the census root for this process. Anyone who holds the given token can prove their eligibility by providing a Merkle Proof (via EIP1186) of their balance for the token. They can then cast a vote by sending the proof (siblings) and a signature to a zk-SNARK rollup relayer, which will compute a proof of the final results.
One potential problem is that the actor computing the zk-SNARK proof (coordinator) for the results could, in theory, censor the result by deciding to exclude votes. We address this problem by enabling anyone (not just the coordinator) to submit new votes: any user can generate and submit a rollup containing their vote if they detect that a coordinator has not included it.
Our proposal uses zk-SNARKS for the following purposes:
On the above schema, we can identify 2 main problems:
ERC20 Storage Proofs are very complex to verify within a SNARK. This is partly due to their use of Recursive Length Prefix (RLP) parsing and multiple Keccak-256 hash verifications, both of which are inefficient to compute in state-of-the-art SNARK rollup technology. This problem is difficult to hack around so for the moment we solve this using optimistic validation.
One current cryptographic standard that we could use to verify user signatures is ECDSA using a BabyJubJub key derived from an Ethereum signature, using the signature as a raw private key, which allows a user to recover their address. Because this method relies on a user signature, it is vulnerable to malicious agents tricking users into signing fraudulent transactions in their Web3 wallet. This vulnerability exists wherever a browser wallet is used to sign a transaction. One potential solution could be to derive a private key using the web address as a derivation path.
An additional challenge is proving that each token owner’s Ethereum address approves the BabyJubJub key for voting at the block height of a voting process’ creation. We achieve this with a ‘singleton’ smart contract that maps Ethereum addresses to BabyJubJub public keys, where a user must add their key to the smart contract via a standard transaction. The mapping of an address to a key can be challenged via an optimistic storage fraud proof (since we have already opened the door to the optimistic validation of Storage Proofs). This solution also solves the data availability problem with a reusable design, as it is expected that these authorized keys will be used multiple times in different voting processes.
In summary, we can handle most verifications within a SNARK, but not all:
A zk-SNARK will aggregate a list of cast votes. The zk-SNARK proof is valid based on a given list of votes, a census root, an election identifier (electionId) and an aggregated result.
The inputs of the smart contract function call for uploading the coordinator results are:
We have implemented the minimum viable smart contracts and circuits to check the costs and viability of the solution here. This PoC only includes the user registry, vote aggregation, and fraud proofs verification.
Our testing incurred the following gas costs:
user key registry deployment 258,536 registration 68,956 voting deployment 6,673,159 new voting 25,989 aggregate rollup 291,801 fraud proof-1 574,574 (babyjubjub key not registered) fraud proof-2 908,822 (account ERC20 balance is zero)
In measurements to estimate a feasible number of votes to aggregate, using a standard server with 32GB RAM / 8 CPUS we found that it is possible to aggregate up to 300 votes (with a 64-level Merkle tree accumulator and ~3.8m constraints), taking 450 seconds to create the proof and consuming 30GB of RAM. For the proofs, we used Groth16 with Circom, witness generation in C++, and rapidSNARK.
On the positive side, the proof that needs to be computed to generate a fraud proof is small enough (50k) to be generated in a browser. This allows users to challenge a voting batch without downloading any specialized software.
Building on this research we would like to explore the following ideas in more depth:
Aragon is building the future of decentralized governance for Web3 communities & organizations. Deploy a DAO on Aragon Client or Aragon Govern, manage your community on Aragon Voice, resolve disputes in Aragon Court and run enterprise-level votes on Vocdoni, all within our open-source stack. See the latest at aragon.org, subscribe to our monthly newsletter, join the conversation on Discord, or follow us on Twitter.