This Proof of Concept is a project designed during Gitcoin’s “Protect Privacy Hackathon” for Maker’s “Privacy in Governance and Voting” bounty.
Whenever a user makes a transaction on the Ethereum blockchain, the amount of ETH, contracts used and addresses involved, is registered for posteriority. And even though an Ethereum address is in essence private, there are ways in which the owner of the address could be identified be it through data leaks or reverse social engineering. Privacy is of the essence both to preserve user’s anonymity and to protect more vulnerable populations, both in terms of money transfer and governance.
User goals
Users should be able to vote without revealing voting addresses and/or the poll option/executive voted for.
Currently, tornado.cash has become one of the most popular ways to transfer/anonymise ETH by breaking the on-chain link between sender and recipient addresses using zkSnark technology.
User Flow
MKR Contract Set Up
What if, deciding on MKR ––also ETH, and other ERC20 tokens could follow this pattern––governance was made anonymous through a contract that allowed locking the users’ tokens during the voting period, generating an anonymous ballot for the value of the locked tokens that can be used to cast votes without traceability from another wallet. Having voted or not, tokens are unlocked at the end of the voting period. This process requires 2 wallets, wallet#1, the MKR holding wallet, and wallet#2, the private/temp voting wallet.
Because the MKR tokens never change wallet, the ballot isn’t a withdrawal note, but a bMKR generator code that when used to vote with wallet#2, creates and votes with the equivalent bMKR as the amount locked in wallet#1. Once the lock up period is up, all the bMKR tokens generated during that period are automatically burned.
Setting up the voting contract starts the same way as it’s currently designed, by agreeing to the Terms of Use and then Granting Permission to the chosen wallet. What changes, is that instead of locking MKR as is, the next step generates a MKR Ballot when locking MKR so that the user can vote, be it with the current wallet or with another one that has no connection to the wallet that has the locked MKR.
Anonymity means voting from any wallet
To fully protect privacy, when wallet#1 generates the ballot, and much like it happens with tornado, MKR could be locked in set amounts (0.1, 1, 10, 100, 1000 or 10000MKR) informing the user of the anonymity set.
Another step to ensure anonymity is to establish predetermined lock-up periods. That makes sure that the lock-up period termination for users wallets, coincides on a weekly basis for all generated ballots. Assuming lock up periods of 1 week, after every lock up reset, there should be an initial anonymity set provided anonymously by MKR, ensuring privacy for all users at all times. This way, it’s not possible to trace the Ballot to the original wallet, as it’s not connected to wallet#2.
Owning an MKR Ballot allows the user to use it with the same wallet it was generated from, de facto and willingly cancelling anonymity, or from a second wallet that ideally has no transactional connection to the generator of the Ballot. Once that second wallet is set up, the MKR Ballot can be used to vote––or withdraw a vote––in as many proposals as a user sees fit during the lock up period established.
Because anonymity doesn’t only rely on wallet privacy, there needs to be a clear and short message that helps the user increase untraceability––changing IP, deleting Cookies and using different wallet providers can be effective.
Pseudonymous identity
In those occasions when a user wants to signal their vote with an alias or a nickname, I see two possible ways. The first, by assigning an ENS domain name to wallet#2. The other, by having user’s wallets connected to PeepETH accounts. This way, pseudonyms could easily be displayed on the “Top Supporters” list for any given Executive Vote.
It’s unclear however, if this kind of signalling would have any value, unless the voter expressly verifies their vote through their “known” social media, as it would otherwise be relatively easy to impersonate other users with similarly written names. This method, would in a way require a systematic approach by the user, who would have to “assign” a wallet for all their public voting.
Final thoughts
One of the issues I don’t approach enough in this design is the overall user experience of MakerDAO governance. With current design, from set up to casting a first vote (assuming no clogging of the network) can take around 10min which, in time, should be addressed. Having to agree to terms, connect the wallet, lock MKR, vote and finally unlock said MKR tokens (4 separate transactions), which becomes an even lengthier process when one adds the MKR Ballot process I designed as 2 accounts need to be set up. I would like to see for MakerDAO and other projects in the ecosystem a streamlining of blockchain interaction. As a user, being able to cast a vote right from the proposal screen where 1 or 2 clicks allowed the process to happen behind curtains in a simpler and more efficient way, is where I would like to see blockchain interactions be at in a few years time.
