# Anounamous- Private Governance for NounsDao

<div style="text-align:center;">
<img style="max-width:50%" src="https://i.imgur.com/sA0CPNL.png" alt="Storage Slots">
</div>![]()

Zero Knowledge Cryptosystem for preserving the privacy of Nounsdao's Voters

Proposal by [Mach 34](https://mach34.space), a Web3 software consultancy specialized in the application of Zero Knowledge proof for privacy and scalability.

## Table of Contents
[1. Team](https://hackmd.io/@H5U2gXZmRRugoNU0zaLeIg/S1cN94Q1n)
[2. Aztec & Noir](https://hackmd.io/@H5U2gXZmRRugoNU0zaLeIg/H1ospwXyn)
[3. Optimistic Zero Knowledge](https://hackmd.io/@H5U2gXZmRRugoNU0zaLeIg/Sk_AnwX13)
[4. ECDSA](https://hackmd.io/@H5U2gXZmRRugoNU0zaLeIg/B1ZaeBQ13)
[5. Storage Proofs](https://hackmd.io/@H5U2gXZmRRugoNU0zaLeIg/HJ2pbOmJh)
[6. Vote Encryption](https://hackmd.io/@H5U2gXZmRRugoNU0zaLeIg/Hkv7KFQy3)
[7. Vote Tallying & Decryption](https://hackmd.io/@H5U2gXZmRRugoNU0zaLeIg/Bk0hsoXy2)
[8. Grant Work upon Proposal Acceptance](https://hackmd.io/@H5U2gXZmRRugoNU0zaLeIg/rkxMe6sQyn)

## Solution

Like most other protocols, our proposal consists of 3 steps:
1. Snapshotting Voting Power
2. Additively Homomorphic Encryption of Votes
3. Threshold decryption of outcome by Tally Committee

The novelty of our solution comes from our focus on wallet compatibility. Using Aztec Noir's UltraPlonk, Nouns voters can verify Ethereum signatures and storage proofs in their browser. These storage proofs rely on the existing `ERC721Checkpointable` to use *voting with delegation*. Combined with a newly released ECDSA threshold signature scheme, our proposal comes with *compatibility for hardware wallet and multisignature wallet out of the box*.

In order to provide the highest quality proposal we could, we include ZK Engineers and a NounsDao Builder on our team. Further, Aztec Network is advising us on best practices and supporting technical requirements of ZK primitives on their backend.

## Requirements Summary
YES: Included in this proposal
POSSIBLE: Proposal keeps expansion of scope in mind, is compatible with PoC work
CONDITIONAL: The requirement is met under certain assumptions or conditions

| Requirement | Satisfied | Solution |
| ------------|-------------|----------------------- |
| Privacy is preserved forever; e.g. designs where voter identity is exposed when counting votes, or at any point post vote casting are not acceptable. | CONDITIONAL | Homomorphic Encryption + Tallying Committee (maybe + mixnet). Dependent on non-collusion of tally committee. Verifiable Delay Functions can guarantee non-decryption until all vote period has ended. |
| At no point should the number of votes a voter has be connected to an on-chain vote; e.g. if one’s balance (voting power) is exposed on any on-chain tx, it becomes very easy to identify whale accounts. | YES | Homomorphic Encryption |
| Should be impossible to tally a proposal’s votes before the voting period ends; the reason is that if tallying is possible, whale votes become easily identifiable. | POSSIBLE | Integration of VDF (or time-lapse crypto as originally proposed by Aragon) |
| Should support delegates as well as token owners | YES | Storage Proofs of vote weight according to `ERC721Checkpointable.sol` |
| Double voting must not be possible. | YES | Nullifiers |
| Support multisig contract wallets; many Nouns are held in Gnosis Safes and other smart contracts and we’d like to preserve their privacy as well. | YES | Storage proofs to get gnosis safe addresses + GS23 ECDSA threshold signatures using asynchronous verifiable secret sharing. Note: this proposal is only compatible with Gnosis, but demonstrates what is needed for any multisignature scheme used by Nouns holders |
| Support hardware wallets. | YES | Aztec Noir UltraPlonk + ECDSA |
| Avoid centralized dependencies; any off-chain computation should run open source code and allow multiple parties to participate, to optimize for censorship resistance and redundancy. | YES | FOSS |
| Should not require a trusted setup / ceremony for every prop (voting round). | YES | PlonK universal trusted setup |
| Should be scalable, allowing for growth in the number of voters from roughly 100 today to 10K in the future. | POSSIBLE | This proposal is compatible with the novel "Nounism" optimistic vote proving pool proposed by the "Nouns Vortex" team. It should be implemented for this scheme in the future. |
| Not every token holder should be required to vote, and if a voter registration round is required, not every registered voter should be required to show up to vote. | YES | By default |
| Should not require an admin to trigger steps in the voting process. | YES | By default |
| Should not require voters to deposit collateral to be allowed to vote. | YES* | Without Nounism, no voting collateral is needed. Nounism scaling requires some sort of penalty for fraudulent proofs, which could be a voting ban instead of financial slashing. |
| The output must be the vote tally of each proposal: # for votes, # against votes and # abstain votes, with abstain being nice-to-have. The final decision whether a proposal passes or fails should be left to the DAO’s smart contract. | YES | k-of-n ballots allowing yes/no/abstain votes |
| Voters should not have to transfer their voting power (e.g. Nouns) from their wallets to a 3rd party smart contract. |YES | By default |
| Voters should not have to bridge their Nouns to a rollup or another chain. | YES* | By default |
| Voters should be able to vote with a single submission of an Ethereum tx / message signature / proof; more steps voters must take render suggested designs less attractive. | YES | ECDSA-based authentication + UltraPlonk (potentially + IVC recursion if it fits) + no registration = 1 shot voting. Multisignature accounts require additional coordination for distributed threshold key generation. |
| Voters should not be required to perform additional pre-voting steps. | YES | Storage proofs + ECDSA |
| Support some voters choosing to vote publicly. | POSSIBLE | Totally doable, but the scope is large so we are not immediately worried about servicing this requirement. |
| Voting (proof submission) should occur on Ethereum mainnet. | YES | UltraPlonk + ECDSA |
| Should rely solely on proofs, and not include a dispute period to achieve finality. | YES* | There is no requirement to use optimism with Zero Knowledge, however gas will be expensive. "Optimistic Zero Knowledge" does use a "dispute period", however the dispute can be done instantly by anyone who wants to spend the gas to run the proof through the onchain prover. |

## Future Expansions
Once Aztec Noir supports PCD recursion, there will be significant refactoring that can be done to maximize ease of use and efficiency. These changes would amount to a solution that is much different to the one proposed here.

We are interested in a ECDSA theshold signcryption scheme where a proposal's outcome cannot be decrypted without `t-of-n` (ex: 66 of 100) votes being cast. There are multiple difficulties, included the key generation phase and the vote weight not affecting the signature threshold. A practical solution to this problem would remove the need for a tally committee.