# Anounamous- Private Governance for NounsDao: Vote Encryption

One possible method for encrypted vote tallying is “[Homomorphic Encryption](https://homomorphicencryption.org/introduction/).” There are varying levels of homomorphic encryption, though the type we need is “Partially Homomorphic Encryption” (PHE). PHE only allows one type of algebraic operation (either addition or multiplication), which can be executed an infinite number of times. In the case of vote tallying, we use addition to sum the votes. Thus, we need “additive homomorphism” which allows us to preserve the algebraic structure inside encrypted space while adding values together.

There are two options for additive homomorphism: [Pallier](https://deapsecure.gitlab.io/deapsecure-lesson05-crypt/21-paillier-he/index.html) and “in-the-exponent” ElGamal. Given small messages (vote weight + direction), ElGamal is an order of [order of magnitude more efficient](https://www.scitepress.org/Papers/2020/87709/87709.pdf) than Pallier. However, we understand that many teams are using ElGamal, and could just as easily implement Pallier for the purpose of experimentation. If accepted, we expect to drive this decision through conversations with both Nouns and other winning teams. Since we don’t make use of ElGamal’s DSA, the end-user functionality should be the same for both algorithms. This is called Genericness. Therefore, we are going to simply refer to the scheme as our PHE moving forwards.

In order to facilitate YES/NO/ABSTAIN vote options, we adapt a K-of-L voting scheme [Hirt10](https://crypto.ethz.ch/publications/files/Hirt10.pdf). Hirt10 proposes a ballot with L candidates and K votes. This can be repurposed such that there are three “candidates” one can vote for- yes, no, and abstain. A side-effect of K-of-L ballots is that a voter could theoretically split their votes between outcomes. If this is an undesirable outcome, it can be prevented in Zero Knowledge.

We want to sign and homomorphically encrypt our votes. However, ECDSA keys are not the same as PHE keys. Therefore, we propose the implementation of [Elliptic Curve Generalized *Signcryption*](https://eprint.iacr.org/2006/126.pdf) (ECGSC). Signcryption enables us to sign and encrypt (or verify and decrypt) our message in a single operation. PHE keys are not related to ECDSA keys, but our signature over the PHE encryption allows us to demonstrate an Ethereum account’s provenance over a PHE key.

[Nullifiers](https://hackmd.io/@liangcc/nullifier) are the mechanism for preventing double-spending in Zero Knowledge applications. While hashing is computationally binding, it requires an extra ‘trapdoor’ (private random hash salt). Meanwhile, [commitment schemes like Pedersen ](https://findora.org/faq/crypto/pedersen-commitment-with-elliptic-curves/) are perfectly hiding, generally with more efficiency. To that end, this proposal will repurpose the [Nullifiers used in ZCash's Orchard circuit](https://zcash.github.io/orchard/design/nullifiers.html), using the hash of the Voter’s address, voteId, and (maybe) checkpointId as the preimage of the commitment. Voting posts this nullifier on-chain, where future votes must prove they don’t reuse that nullifier.

Voting privately relies on a DAO-subsidized relayer (either via ERC2771 or ERC4337) which can reuse components of the vote proof to convince the relayer that a sender is entitled to having this transaction relayed for voting. This scheme is simple, but is not yet fully detailed due to the time constraint of the proposal submission.