Protecting privacy in token voting

[JohnGuilding]

One point on token voting with MACI raised by Aragon is that if there is a signup that corresponds exactly to my token balance, it is easy enough to see onchain which way I voted. Given that token voting is still so ubiquitous for DAO governance, and we want to support DAO voting - do we need to think about the privacy implications of this in V4?

Even if there is no link between an account and a maci vote, the set of all token holders would be small enough, that if you could see the voice credits on signup, you could just search for the account with that balance. Or if it was not full credits voting for each token, calculate what the voice credit amount equals in token amount based on the onchain logic that defines this.

Individual voice credits amounts are already combined into yes, no, or abstain. The public outputs are just those 3 numbers, and then we have a zkp of correct computation - you only see the tally (sum of votes for an option which in full credits mode is the sum of voice credits spent for an option), not individual votes.

[JohnGuilding]

Idea from @ctrlc03:

imo that might be possible by doing this:

Do offchain census of who is elegible. For example I want to start a proposal, I take a snapshot of chain at this time, make a merkle tree of elegible addresses, call createProposal (MACI.deployPoll) with merkle tree root and make available the leaves for people to then be able to create inclusion proofs.

You can already see that this becomes prone to censoring as I could just decide to not include certain users. Sure you can see later that user come to you saying they have been censored, but maybe the proposal is already completed or there's no way to stop it by the time they realise.

You come to register and you provide a zk proof of owning the wallet part of that census tree without revealing which wallet (need to be able to prove ECDSA in a circuit which is not efficient AFAIK), then submit your already packaged state leaf = { MACIKey, token balance }

Or you can create bands of voice credits:
Holders of tokens between 0 and 10 get 5 credits, 10 - 20 get 10, 20-30 get 15, (or whatever), etc etc.. the larger the range, the larger your "anonimity set"

But then you gotta convince people that this is a good idea - why do i get same credits for holding more tokens than someone else

[JohnGuilding]

Instead of a merkle tree, could you do some kind of storage proof? E.g. prove balance at a certain block height. Trying to think of a way to prove I'm in some set of addresses in a permissionless way. So this would combat censorship.

The set of addresses wouldn't be collected by some third party in this case. The set of addresses would just be the set of all addresses on mainnet with that token, instead of some subset of addresses

One problem is that you would still need efficient ECDSA proving, but trust assumptions would be better

[JohnGuilding]

Comments on zk ECDSA verification (onchain) from @alxkzmn

This one is not verifiable onchain directy: https://github.com/personaelabs/spartan-ecdsa

This one is verifiable on-chain: https://github.com/vladfdp/p256-proving-benchmark

And here's a potentially faster version of it that should be verifiable onchain too: https://github.com/worldfnd/ProveKit/tree/main/noir-examples/p256_std (they don't have the numbers but we will bench it soon)

[JohnGuilding]

Example of onchain logic where token balance would currently be revealed

[JohnGuilding]

Another problem is that even if sign up credits were hidden, and you could successfully prove inclusion in some set of token holders, if MACI has a feature where you can see individual vote counts associated with a public key, you could just infer the account owner by looking at token balances that corresponded to the vote amounts.

From my understanding, this would mean private token would not be possible if we could associate maci public keys with votes. This could be mitigated by being able to turn individual vote counts off, or we could just not deliver individual vote counts as a feature - if we think supporting private token voting is important enough.

^ Above was based on incorrect assumptions about how MACI works

Or we have other options, such as voting bands/levels. E.g. 10 tokens, 20 tokens, 30 tokens etc. As mentioned, this could prove controversial as it would be deemed unfair for unequal token holders to be grouped together.

cc @ctrlc03

[ctrlc03]

if MACI has a feature where you can see individual vote counts associated with a public key

I'm not sure this would ever be a feature we need? or are you referring to a relationship between public key and voting balance?

[JohnGuilding]

I was basing that assumption on this PR, which appeared to add that functionality. I left a question there for my understanding.

I see the issue it contributes to is about counting individual voters numbers for each option, rather than individual votes for each maci identity. But wasn't sure exactly sure if the PR did something different.

or are you referring to a relationship between public key and voting balance?

If voting balance here means voting credits you get when you sign up, I'm making the assumption here that this link is broken. Instead I am referring to being able to tell whether at the end of a poll, you can see public key xyz voted for option A with 10 tokens

[ctrlc03]

oh right yea so that PR was the beginning of implementing a private count for how many people chose an option. So in the end on top of the tally rather than having just the results, you can also tell let's say 10 people voted for option 1, 2 people voted for option 3, etc. We stopped that work cause if we focus on v4 it'll be obsolete.

Instead I am referring to being able to tell whether at the end of a poll, you can see public key xyz voted for option A with 10 tokens

ok yes this should not happen (that would just be semaphore style voting with a twist for instance, you are pseudo-anonymous but votes are public at the end and you can just prove that is your vote enabling collusion/coercion confermation)