Privacy First Governance Using ZKPs
Privacy First Governance Using ZKPs
We explore the design space around how we can leverage zk-snarks in crypto governance.
Understanding why we need privacy in governance
In the previous post, we did a scenario analysis of Red Bean Coffee’s governance proposal on Azuki. During the governance event, there were two proposals put up at the same time, despite that RBC’s proposal failed to reach quorum. There were two reasons for that.
a) Lack of campaigning before putting up the proposal.
b) Backlash from influential members of the community.
For a second, let’s ignore the former and focus on the dissent. The severe backlash against the proposal from influential whales in the community meant that many people abstained from voting. One way to solve this issue is by offering incentives to increase governance participation. Whilst token incentives can increase governance participation, it still doesn’t solve the underlying problem— the lack of privacy primitives to protect an individual during a governance event.
As on-chain communities evolve into full fledged network states, the need for privacy primitives only increases.
Which is why I decided to explore this design space, where I’ll be looking into some of the challenges faced by on-chain communities during governance events, and finally how we can solve them by leveraging zk-snarks.
Some of the biggest challenges faced by on-chain communities are-
a) Social voting
Social voting is when individuals base their voting decisions on the opinions or endorsements of influential figures or peers within the network.
When Red Bean Coffee put up their proposal up on twitter, there was severe backlash from community members on the proposal. This coupled with public voting meant, voters felt trapped, as voting ‘for’ might reflect poorly on their image whilst voting ‘against’ meant it could likely affect the chances of their proposals going through in the future.
b) Credibility
Red Bean Coffee had previously launched coffee products by leveraging the Beanz IP. The community wanted to know about the brand’s past financial performance in order to verify the brand’s credibility & track record.
The team was reluctant, as they didn’t want to reveal sensitive information about their business. Which bought me to the question-
How do we verify the credibility of a crypto native brand without compromising on their privacy?
c) Voter participation rates
One of the biggest challenges in crypto is all the votes are public by default. Which means in a community with high network density, there’s always a social cost associated with voting ‘against’ or ‘for’ someone, often leading to low voter participation rates.
People refraining to vote during RBC’s governance events, is an example of the same.
Can we increase voter participation rates by protecting an individual’s opinion on-chain?
d) Freedom of expression
One of the major pillars of a democracy is free speech. The same should be applicable in on-chain communities. Community members often hold back their true thoughts, as they are afraid of being controversial, and the social cost associated with it. This is dangerous as it leads to political turmoil, often ending in a death spiral for the community.
The social cost of expressing an opinion during a governance event should be zero.
These problems are not limited to the Bobu governance forum, it is prevalent across on-chain communities. Now, that we have understood why we need privacy infrastructure for governance, let’s take a look at how we can leverage zk-snarks and address each problem. Starting with assessing the credibility of an on-chain brand using zk-snarks.
Credibility & selective disclosure using zk-proofs
In the earlier proposal, the community weren’t interested in knowing the financials of RBC, instead they wanted to make an informed choice about the proposal. Which bought me to the question-
Is there a way the brand can selectively disclose information that proves their credibility whilst bringing transparency?
On-chain brands can leverage zk-snarks to selectively disclose information to bring more transparency during governance events. Sismo was one such protocol.
Sismo let users aggregate their data across the web & then selectively disclose it to applications via an SSO. It had three core components-
a) Data Vault
Sismo comes with a local, sovereign, & private identity aggregator known as the Data Vault. The repository stores Data Sources, ensuring that users have full control over their data and who can access it. You can think of it as a suitcase that holds all your secret files with an encrypted lock.
b) Proving Schemes
Cryptographic circuits implemented within Sismo facilitate users in proving ownership of their Data Sources and their membership in Data Groups. These schemes provide robust methods to establish credibility without compromising sensitive information.
c) The Sismo Hub
Serving as Sismo's data infrastructure, the Sismo Hub enables users to create Data Groups. This feature empowers individuals to make trustworthy claims about their personal data, ensuring transparency and accuracy.
As you can see, by leveraging zk-proofs RBC could’ve selectively disclosed information, thus bringing more transperency to the governance event.By leveraging zk-proofs, an on-chain brand can cryptographically prove the validity of their credibility without exposing sensitive data, thereby ensuring transparency whilst preserving privacy.
Now, that we’ve looked at the need for privacy in the proposal stage, let’s move on to the voting stage.
Private Voting
One of the best things about the pseudonymous economy is the proliferation of ideas over race, creed, religion or financial background. Private voting allows voters to cast their ballots without revealing their identities or personal preferences publicly.
At the core of a private voting system are three components-
Anonymous identities
Confidentiality of vote
Confidentiality of Outcome
Snarks can be employed to verify the correctness of a vote without disclosing the specific vote itself, thus maintaining the integrity of the voting process. Let’s take a look at how it would work on mainnet.
Conditions: The conditions for voting, such as ownership or delegation of the NFT, the choice between 0 or 1, and the restriction to vote only once, are defined.
QAP Construction: The conditions are converted into one or more quadratic arithmetic programs (QAPs). These programs are designed to be compatible with zk-SNARKs, which allow for succinct proofs of knowledge without revealing specific details.
Polynomial Conversion: The QAPs are further transformed into polynomials that enforce the desired conditions. These polynomials capture the mathematical relationships necessary to prove the validity of the voting process.
Prover's Evaluation: The voter, acting as the prover, evaluates the polynomials based on their vote. This evaluation reflects their choice while preserving the privacy of the specific vote details.
Proof Submission: The prover submits the proof of polynomial evaluation, along with other necessary parameters, to the vote-tallying smart contract. This proof serves as evidence that the voter's evaluation aligns with the defined conditions.
Proof Verification: The contract verifies the submitted proof using zk-SNARK techniques. It checks the validity of the proof without requiring access to the voter's specific vote or compromising their privacy.
Vote Tally and Outcome Determination: When the voting period concludes, the contract tallies the votes based on the accepted proofs and determines the outcome of the proposal.
Scenario Analysis
Even if both voting addresses and ballots are kept private, achieving true privacy during a governance event on the blockchain is still a challenge. Let’s start by looking at three possible scenarios.
Unanimous Vote
In this scenario, we have three voters with different voting weights: Voter A has 50 votes, Voter B has 30 votes, and Voter C has 20 votes. If all three voters unanimously vote for the same option, the final tally would be 70 votes for that option. Since each voter's weight is distinct and the total matches the sum of their individual weights, it becomes evident that all voters chose the same option. This unanimous voting pattern compromises true privacy because it reveals the individual choices of the voters despite the voting process being private.
Whale Dominance
Imagine a scenario where a community member has built up his reputation over time by contributing to a project, and now has significant voting power. For the sake of this example, whale X has 500, A has 50 and B has 30.
During a governance event, all three participate and vote for the proposal. In this case, the influence of the whale on the proposal becomes apparent and his anonymity is jeopardised.
Mixed Vote
In this scenario, the same three voters (whale with 50 votes, and two others with 30 and 20 votes respectively) cast mixed votes. For example, the whale votes for option A, while the other two voters split their votes between options B and C.
The final tally might show 50 votes for option A, 30 votes for option B, and 20 votes for option C. Even though the votes are mixed, the whale's dominant voting weight makes it clear that they voted for option A.
The votes for options B and C can be traced back to the two smaller voters due to their distinctive weights. This scenario also fails to provide true privacy because the voting pattern and weight differences make it possible to deduce who voted for which option.
Is there risk associated with voting addresses being public?
Even with private voting and confidential ballots, there are instances where conclusions can be drawn. Especially true if you are a whale with significant voting power. Revealing voting addresses makes drawing conclusions easier, especially for influential voters ("whales").
In general, stronger voting power increases the likelihood of drawing consistent conclusions.
Governance Discourse
Now that we’ve explored private voting, let’s take a look at governance discourse in on-chain communities, especially around voicing opinions during a governance event.
One of the biggest challenges during a governance event is the social cost associated with any form of expression. This includes showing support on social networks, expressing opinions publicly on platforms like Discord, among other things.
How can we reduce the social cost of expressing an opinion in an on-chain community while preserving privacy?
Fear of controversy often silences valuable input on crucial proposals, posing a risk to effective governance. Furthermore, unexpressed opinions can fester into resentment and can lead to political upheaval, potentially triggering a destructive cycle over time.
Finding the right balance between complete anonymity and controlled anonymity is vital. While anonymity can shield personal privacy when sharing opinions, important viewpoints sometimes require a sense of accountability or personal investment from the individuals putting them forward.
One of the most interesting projects that’s working in this domain is Nyms.
Nyms was born out of Nouns DAO’s zero knowledge research sprint. To address the issue, they introduced a system of attaching zero-knowledge proofs of authenticity to messages. This allows users to express themselves credibly without fully doxxing their identities.
Nyms introduces a system where users can use random pseudonyms that gain reputation over time. This reputation-based approach enables significant viewpoints to be expressed with the credibility of the pseudonym, all while preserving a certain level of pseudonymous identity.
Between total anonymity and full exposure lies a range of options. Nyms was created to provide users with lasting symbols of reputation, maintaining a level of pseudonymity in the process.
Nymz cultivates an atmosphere where participants can openly share their thoughts and perspectives without concerns about negative social outcomes. It empowers individuals to contribute openly, fostering a varied and clear online community that aligns with our vision.
Although the project's origins revolve around nouns, I envision it’ll eventually expand to other on-chain communities as well.
Conclusion
The goal of the article was to explore the design space around the need for privacy in governance, rather than token incentives. Token incentives are great to drive metrics, but when it comes to efficient decision making we need to build efficient systems that empower the individual rather than driving vanity metrics. Moreover, within a public voting setup, an individual's safety decreases as the stakes increase.
By leveraging zero-knowledge cryptography, we can build a more efficient, inclusive governance environment on-chain that also protects the individuals privacy.
Credits, references and further reading-