Anonymous OpenGov

A prominent problem with OpenGov today is that all referendum votes are fully public, which makes individual voters vulnerable to external pressure, coercion, or retaliation. When others can verify how you voted, they can influence you through social pressure—forcing you to act in their interests rather than in Polkadot’s. Zero-knowledge proofs solve this by allowing a voter to prove that their vote was valid and included in the final tally without revealing the vote itself or their stake. This brings true anonymity to OpenGov, making it infeasible for any third party to confirm or credibly threaten based on an individual’s vote, thus restoring independence and integrity to the decision-making process.

The protocol provides a method for implementing an anonymous on-chain voting system that fully supports all features of OpenGov, including arbitrary DOT staking amounts, conviction levels, vote splitting, abstentions, delegation, as well as origin and track selection.

By leveraging modern cryptographic methods, such as Zero-Knowledge (ZK) proofs and Homomorphic Encryption, the proposed protocol imitates the same behavior as the original OpenGov protocol. It’s been deliberately decided not to use Trusted Execution Environment (TEE), as it is not secure inherently. Multiparty Computation (MPC) is also not explored in this proposal as it is complicated to ensure security guarantees as it requires non-colution of the MPC parties, which cannot be proven mathematically but has to be based on trust only.

Roadmap

This section presents a road map for anonymous voting extension of OpenGov.

1. Implementation of the “Open Vote Network” Protocol as a Palette

Duration 1 Month

Goal Implement “Open Network Vote” protocol as a palette

Result End-to-end voting web application that runs as a palette

This milestone is the first integration of anonymous voting in the Polkadot ecosystem and the third milestone of the PolkaVote Web Summit hackathon winner. The protocol will be refactored into a palette. Based on the previous implementation of the protocol. For the repository, click here.

2. Academic Research and Survey

Duration 3 Month

Goal Academic survey, research and highlighting the most potent methods and approaches.

Result An academic paper, and a few potential protocols and approaches to solve the problem for the next milestone.

This milestone focuses on the academic research that was done so far, in particular - Zero Knowledge, Fully Homomorphic Encryption and Multiparty Computation. During this milestone, an elaborate academic survey will be conducted and concluded into a paper. The survey will specifically focus on the OpenGov setup, highlighting techniques and methods that are the most applicable and with the most similar setup (and with the best security guarantees) to the OpenGov.

The protocols will be measured asymptotically, following parameters would be taken into consideration:

1. Circuit size
2. Rounds of communication
3. Peers run time
4. Peer storage
5. On chain run time
6. On chain storage 

3. Experiments and Benchmark

Duration 2 Month

Goal Implementation of the most promising candidates, and benchmark.

Result Select a solution that fits the problem best, based on concrete run time and resource consumption results.

In this step, the devised (from previous step - step 2) solutions will be implemented and benchmarked. At the end of the experimentation it will be clear which of the approaches solves the solution best, from a practical perspective (and not from a theoretical perspective). Parameters that will be benchmarked:

1. Required time to generate a proof in browser
2. Operations/time consumption for proof verification on chain
3. Trusted setup
4. Rounds of communication (peers with blockchain, peers with other peers, or other metric of communication in case it is needed)

4. Deployment of The First Track

Duration 2 Month

Goal Integration of the most promising approach to a fork (of OpenGov) UI.

The best (or several once) solution will be integrated to a fork of the OpenGov, for testing.

5. Auditing

Duration 2 Month

Goal Protocol overview and elimination of potential exploits.

Result Secure code and robust voting protocol.

During this milestone the source code will be handed to an auditing company to ensure that the code is secure and safe to use.

6. Implementation of All The Possible Tracks

Duration 2 Month

Goal Partial integration to OpenGov and implementation of all the other viable setups and tracks.

Result New features introduction to OpenGov and first utilization of anonymity extension in OpenGov.

Conclusion

Thank you very much for your time and patience. I hope you find this discussion interesting. If you are interested in the topic and share the vision of anonymous voting on OpenGov, your support would be greatly appreciated.

This could include helping to identify which track might be the easiest to implement, sharing perspectives on anonymity, highlighting general challenges within OpenGov, or presenting new ideas for its future (whether they align with anonymity or not). It could also involve helping to finalize the full draft of this discussion—pointing out any missing steps in the roadmap or areas that are not properly documented.

References

1. Full discussion draft (WIP)
2. PolkaVote (Hackathon winner), repository
3. The implementation is based on “The Open Vote Network” protocol.
4. Open Vote Network Protocol Research Paper
5. Milestone 1 Homomorphically additive ZK Voting - documentation
6. Milestone 2 "Open Vote Network" Voting Protocol - documentation
7. Closed Polka Grant - discussion
8. Similar proposal: https://forum.polkadot.network/t/private-voting-on-referenda/3001

• The main difference in this new proposal is that TEE will not be considered by any means. The goal is to produce a voting protocol that is cryptographically secure both in theory and practice, by leveraging modern cryptographic methods.