Decentralised Private Voting

2022-12-21 by Rebekah

There are several ways to achieve secure decentralised private voting, which we will go through within the document. Decentralisation is being stressed in the title of this blog post and within the document due to the fact that many voting schemes that exist in the current body of work rely on a trusted party for vote integrity, or voter privacy, or for a combination of these two alongside availability of the voting system itself. Helios is one such voting scheme, which is used for private voting in, for example, IACR elections. However, in Helios an authority needs to be trusted for privacy. We do not wish for this to be the case in the scheme that we adopt.

We will be using an Ethereum smart contract as a bulletin board and vote counter, but a constraint imposed by this model is that the contract cannot have any private state at all, which means that any system in which the ‘authority’ needs to generate some private randomness is not available to use in this situation. This means that we need to provide a protocol where anyone who sees the votes can compute the final result themselves, without being able to reveal any information about the votes (except that which is revealed by the final vote itself). A final constraint is that computation is very expensive on Ethereum, and so we desire a protocol with a verification step that is as lightweight as possible. There are existing papers that provide a thorough overview of currently implemented and deployed cryptocurrency based voting schemes, for example Nomana Ayesha Majeed’s brilliant Review on Blockchain based e-Voting Systems.

The document linked below talks through several different approaches to achieving private decentralised voting, and their trade-offs. The approaches are linkable (private) membership proofs (SNARK-based or not SNARK-based, depending on the computational power expectations of the voters); plain digital signatures and tallyable encrypted votes; membership proofs + tallyable encrypted votes; commit and reveal (in the case that privacy is not desired). The document explains more details about each of these, and can be found here. But as a summary, we will provide some guidelines as follows.

If you’re doing ‘one person, one vote’ based protocols, non-snark membership proofs seem to offer the best efficiency, while guaranteeing privacy. If the aim is token weighted voting, use a special purpose encrypted voting protocol, with specific instationations given as recommendations within the linked note. These schemes are more complex in terms of implementation and computational complexity for the prover and verifier than non-snark membership proofs, but are required to maintain privacy while users are voting with different numbers of tokens. If the aim is to support arbitrary different voting functionalities (eg weighted, one person one vote, and non-linear tallying) all with the same overall framework, SNARK based voting solutions would be preferable, as using SNARKs minimises the infrastructure changes needed with a change of voting system. Hope you find the note helpful, and feel free to reach out with any questions or comments!