Project Name
How should we refer to your project?
PrivateVote
Background
What problems do you aim to solve? How does it serve our mission of a user-owned internet with more privacy and self-sovereignty?
Organizations (digital and otherwise) need verifiable, ungameable and secret voting mechanisms to be able to reach good decisions. This is especially of importance for DAOs and the governance of community projects. Solving this will increase the stability and resilience of organizations. Furthermore secret votes better insulate voters from the final decision made and prevent unwanted leaks of their preferences.
Project Overview
What solution are you providing? Who will it serve?
PrivateVote will provide a method to do voting on -chain that is secret (nobody but the voter knows the content of his/her vote) and publicly verifiable. It will be usable within and without smart contracts.
A voting scheme like this will help with managing DAOs and other areas of governance.
Furthermore the scheme allows shuffling of identity maps, which has applications such as attribute based identities, access control, and potentially more private transactions.
Scope
What are the components or technical specs of the project? What will the final deliverable look like? How will you measure success?
PrivateVote consists of five components:
- Smart Contract: Defines electorate (group of voters), quorum (number of participating voters for an election to be valid), and verifies and interprets the election result after certification. It temporarily stores all messages exchanged during the election process.
- BallotIssuer: Responsible for issuing blinded ballots to eligible voters of an election, and for concealing the election results until certification. Multiple BallotIssuers are operating in an M-of-N threshold to ensure reliable and secure operations. BallotIssuers communicate with the clients through messages that are temporarily stored with the contract.
- Client: Interacts with contract and BallotIssuer to cast votes and to certify the outcome of the election. This will initially be a CLI program but could at some point be integrated into a web client.
- Verifier: A standalone program to audit the election process. This will be integrated into the CLI client, but due to the amount of processing required it will not be suitable for web deployment. Future web clients will however be able to interact with a standalone Verifier to offload the majority of work required for auditing.
- Relay: This component receives messages from the BallotIssuer and the Client, delays them, and posts them to the chain. It’s purpose is to suppress metadata that could be used to link votes to clients. This will ideally be a mixnet - which is out of the scope of this project. At a minimum, a simple relay (without multiparty mixing) will be implemented. In addition, the possibility of using the Nym system and/or cooperating with Nym for implementation will be explored.
At the end of the project these components will be implemented, documented and tested. Furthermore a hosted pool of BallotIssuers will be created that can be used by organizations that are not able or willing to
operate their own BallotIssuers, Relays and Verifiers. An example smart contract will be deployed that makes use of the voting system.
The BallotIssuer, Client, Verifier and Relay will be implemented in Go. The Smart Contract in Rust.
An example election flow looks like this:
- The initiating party requests an election from a smart contract. The contract defines electorate (group of voters), quorum and timeout for the election. Furthermore the initiating party selects the subject of the vote and the valid options from the contract. The result is the Election Definition.
- Each voter exercises the following steps:
2.1 Voter requests the concealment keys from the BallotIssuers. The first request initiates key generation for the specific election and commits the public keys to the chain.
2.2 Voter commit to own choice, encrypts the choice to the concealment keys, blinds the result (Blind Ballot) and sends it to the BallotIssuers for signing.
2.3 BallotIssuers verify that the requesting party may participate in the election, sign the Blind Ballot, and commit the result on chain into the contract.
2.4 Voter unblinds the BallotIssuer signature and sends the unblinded ballot and the signature to the Relay. - With some delay, the Relay forwards the ballots to the chain, where they are stored with the contract.
- After the election timeout has been reached, the auditing and certification phase begins:
4.1 The Verifier(s) test the blind ballots and blind signatures, test the unblind ballots and unblind signatures, verify that blind ballots were only issued to valid voters, and verify that ballots have not been generally suppressed. The Verifier(s) then sign the result of the verification.
4.2 Optionally, capable clients execute the same verification as 4.1 locally.
4.2 The Voters, on basis of the first verification step result (4.1 or 4.2), verify that their own vote is included in the total of recorded ballots.
4.3 The Voters each sign the list of recorded ballots. Only those ballots included in the signature will be considered certified and valid for tallying. - As soon as equal or more than Quorum Voters have signed the ballot set, the BallotIssuers each reveal their concealment keys on chain. Triggering the tallying by the smart contract.
- As soon as M of N concealment keys have been revealed, the ballots can be decrypted and the result tallied by the contract.
- The contract prunes intermediate messages, leaving only concealment keys, ballots and voter signatures on chain.
- The contract changes state based on the election result. The election result may be pruned at this point.
Vote Delegation allows any qualified voter to select another person (who does not have to be a qualified voter) to vote on one’s behalf in a specific election or until a set date/time.
Budget and Milestones
What grant amount are you seeking? How long do you estimate that the project will take in hours? If the project is nontrivial, please break down the project into milestones, with a clear output (e.g., low-fi mockup, MVP with two features) and include the estimated work hours for each milestone.
The project will be implemented in three milestones:
- MS 1: Published protocol description, BallotIssuer and Client implemented using an abstract broadcasting channel for communication.
- MS 2: Delegated voting and naive relay. At this point the full protocol for voting is implemented without dependencies on NEAR, and can be tested and explored.
- MS 3: NEAR integration: Extract electorate data from the NEAR chain, use NEAR as broadcasting channel, on-chain data pruning. At this point manual elections backed by the NEAR blockchain will be usable with commandline tools.
- MS 4: Smart contract development: Integrate electorate definition, election definition and interpretation of results into a smart contract. At this point elections interacting with smart contracts will be usable with commandline tools.
Estimated hours per milestone:
- MS 1: 140 hours.
- MS 2: 140 hours.
- MS 3: 180-240 hours.
- MS 4: 180-240 hours.
Estimated total hours are between 640 and 900.
This translates to a minimum grant amount of 45,500 - 53,000 USD.
Team
Who is building this? What relevant experience do you bring to this project? Please share links to previous work. Are there skill sets you are missing that you are seeking from the community?
The main developer will be Jonathan “smuggler” Logan, with potentially hiring one other developer. Previous projects include SCRIT (design & implementation), Cypherlock, ShamirOnSalt, Mute dot one…
scritcash · GitHub , GitHub - JonathanLogan/cypherlock: Ratchet based key expiry tool against forced decryption and for expiring backups. & mute.
Potentially there will be a need for discussion on best-practice smart contract design and optimizing APIs for present use-cases.
Risks
What dependencies or obstacles do you anticipate? What contingency plans do you have in place?
The main current risk is that this is my first NEAR-related project. Learning curve and specifics of NEAR thus constitute the main unknown. I have reached out to NEAR developers for guidance and support in designing NEAR-specific components.
Community and Supporting Materials
Do you have previous projects, code commits, or experience that are relevant to this project and proposal? What community feedback or input have you received? How do you plan to share your plan and updates with the community as you proceed?
No previous code commits of relevance, this is a fresh project. So far discussions with some NEAR-focused developers were supportive.
All publishing/communication is going to be github centered to allow easy insight and response.
Licensing
Is your project open source? How do you plan to license it?
Yes. I plan to use a permissible open source license such as MIT, BSD or similar.
Contact Details
@risottoclash:matrix.org