Background
The aim of this paper is to propose a methodology for the execution of an on-premise voting process on blockchain in a transparent manner while ensuring the anonymity of voters. This will be applied to the Annual General Meeting (AGM) of the Singapore Cryptocurrency and Blockchain Industry Association (ACCESS) on 10th January 2020.

Requirements
At the AGM, association members will place their votes for future appointment holders and agenda items on a blockchain, utilising the advantages of blockchain technology such as immutability, transparency, and traceability. In addition, anonymity is established through the disconnection between members and their vote, hence a vote cannot be traced back to its originator.

The key requirements are:
1. Due to constraints of the association’s constitution, voting is to be conducted on-premise at the AGM.
2. Anonymity. A member’s vote should not be trackable to his/her identity.
3. No double voting. Every member gets only one vote.
4. Transparency. Post voting, the process needs to be transparent and auditable.

For this application, we are using Ethereum as the blockchain network and Metamask as the Ethereum wallet to interact with the blockchain.

Process
Access Controls
Access to the smart contracts will be controlled by designating (or whitelisting) pre-defined public Ethereum addresses with the deployment of the contracts. Controls change according to the stage of voting. The actors are: 1. Admin, 2. Voting Machines. There are 3 stages where access controls are changing:

A. Pre-Initialization
Only the admin can invoke the Code Management and Voting Contracts
B. Voting
The voting machines can invoke the voting contracts.
Admin can invoke the end of the voting process
C. Post-Voting
No further invocation of contract functions
Open access to voting results

Voting Code Generation and Management
A list of voting codes are randomly generated, hashed and stored in a Code Management Smart Contract, before physical copies are printed as a QR code and randomly distributed to members upon registration at the AGM. It is important to emphasize that the codes are linked to neither voters nor their votes, providing anonymity. Also, it is extremely unlikely to reproduce the same code within the given time frame, hence it is fair to assume the authenticity of all submitted votes.

To ensure voters are only permitted to submit one vote, we track the status of each code in the Code Management Smart Contract too. There are three status, valid, used and invalid. Originally, all codes are valid and can be used for voting. On the other hand, used and invalid codes cannot be used to vote. The used status can only be invoked by the Voting Smart Contract in the event of a successful vote. The invalid status can only be invoked by the Admin account and is used to invalidate spare codes before voting starts.

Voting
The Voting Smart Contract is used to initiate and track votes. Once deployed, the Voting Smart Contract can be initiated by the Admin account. It will contain the positions, candidates running under each position and the number of seats available for each position.

Voters can then send their votes via generic machines (with a fixed blockchain address) to the Voting Smart Contract. Voters have to present an unused code before they are allowed to proceed with selecting candidates.

After all the votes have been received, the admin can terminate the voting process. This will then generate the voting results, with the majority displayed in green, ties in yellow and the remaining in black. In the event of a tie, tied candidates enter another round of voting until a consensus is reached. Voters are advised not to dispose of their code as it will be reused in every round of voting.

The flow of events to set up on-premise voting can be seen in the diagrams below:


Figure 1: Stages of on-premise voting on blockchain


Figure 2: Swimlane diagram of the on-premise voting process

Implementation
The process is implemented via deployment of the smart contracts on the Ethereum Main Net. The user interface is deployed as web applications, there are two UIs one for the admin and another of the voting machines.

The Admin UI (which only the whitelisted admin address can access), allows the admin to initialize voting by keying in the voting items and calling the voting smart contract. It also allows for the invalidation of unused codes and for the termination of voting.

The Voting Machine UI (which only whitelisted addresses for voting can access) allows a voter with a valid voting code to cast a vote via the voting smart contract. For ease of entering the voting codes, a QR code generator is used to create QR codes and printed on voting cards. A QR code reader is implemented on the UI. The code reader will pass the code, the code then gets hashed and checked against the Voting Code Management Contract for the code’s validity. Given that the codes are valid, the UI will collect the votes for each voting item and compile them into a transaction that invokes the Voting smart contract.

Conclusion
We have demonstrated a process utilizing a random code generator and two smart contracts above that allows voting to be done on-premise and recorded on the Ethereum blockchain with transparency and allowing for anonymity of voters at the same time. The method described allows for use cases where group consensus need to be collected physically on multiple issues and there is a need for a clear audit trail of the voter actions.

As some of the process is offline or off-chain, there is a need to ensure due diligence is done in the generation, distribution and voiding of codes; voting also need to be conducted in a proper manner and should be observed by neutral parties.

This paper is prepared by JEDTrade Pte. Ltd. Any queries may be directed to [email protected]

Appendix

Figure 3: Sample Voting Card with QR Code


Figure 4: Admin’s UI 1: Adding Positions


Figure 5: Voter’s UI 1: QR Code Scanning


Figure 6: Voter UI 2: Vote Casting


Figure 7: Results Page

 

 

Download the pdf here