How WE.Vote works¶
The voting process in WE.Vote is divided into four main stages. This section describes how the system elements work for each stage. User scenarios are given in the How to use the service section.
1. Creation of a voting and inviting prticipants¶
Voting process¶
Administrator creates voting in the WE.Vote client. The voting contains following data:
voting descryption;
voting date and time;
list of questions and answers;
list of voting participants;
additional documents for voting participants.
Voting date and time are transferred into the blockchain in an open format.
Voting description, list of questions and answers, as well as additional documents are hashed up, their hash sums are also published in the blockchain. This process allows to prevent data forging:
with data change, its hash sum is also changed;
data forging is detected on the participant side by comparison of data with its hash sum published in the blockchain.
The public keys of invited participants are also sent to the blockchain when voting is created. At the same time, the personal and contact details of the accounts are not transmitted to the network: during voting, the transaction is signed with the participant’s private key, and the public key becomes his or her only public identifier.
The raw data published in the blockchain in the form of hash sums are also not transmitted over the network for privacy reasons: they are stored in the local server database and are only available to voting participants upon successful authentication. This makes it possible to reliably limit access not only to the results of the vote, but also to its agenda.
2. Generating and publishing a voting MainPublicKey¶
The master server receives data from the blockchain about the preparation of a new vote, and then determines the list of available cryptographic services on the servers. To each of them, the master server sends a request to create a key pair for voting. In response to the request, each cryptographic service returns the public part of the created key (see section Key generation).
The master server generates a MainPublicKey from the received public keys and publishes it in the blockchain to the voting address. The shared public key is then used by participant encryption services to encrypt completed ballots.
After the formation and publication of a MainPublicKey, the system receives all the necessary data to initiate voting:
the original voting data are stored locally in the database of each server;
hash sums of the data are published in the blockchain and serve to control the integrity of voting materials;
the MainPublicKey needed to encrypt the votes of participants is also published in the blockchain.
In this case, none of the participants has any common private key, with which it would be possible to decrypt the ballots. Accordingly, neither the organizer of voting, nor the participants themselves have a possibility to tamper with the data in the ballots, and the votes are counted by homomorphic addition of the encrypted results with preliminary and subsequent data integrity control (see Encryption and Zero Knowledge Proofs).
3. Conduct of voting¶
Voting process¶
After the public key is generated and published on the blockchain, the system waits for the pre-set voting start time. Each of the voting participants invited by the administrator receives an e-mail notification of the vote.
After registering and gaining access to their account (see section Account registration), the participant can read the questions and voting materials. In doing so, the participant’s client application requests the server to save the voting data. The request is signed with the corresponding key given to the participant during registration.
Upon receiving the voting metarials from the server, the participant’s client application calculates their hash sums and compares them to the sums stored in the blockchain during the voting creation phase. This ensures the participant’s data integrity.
When voting begins, the participant is given the opportunity to respond to the questions on the agenda:
the participant fills out a ballot;
the client application encrypts the completed bulletin using a shared public key;
the client application encrypts the completed ballot using the participant’s public key;
The data published on the blockchain is publicly available. Therefore, the transaction of publishing an encrypted ballot is available to all voters. However, none of them can view the published responses because they do not have a private key equal to the MainPublicKey of the voting.
When publishing an encrypted bulletin, the cryptographic service checks that the set ranges are correct, without decrypting the ballot data (see section Zero-Knowledge Range Proofs). If data spoofing is detected, the transaction is rejected.
During the voting process, each participant has the ability to change their answer choices. At the same time, the client application encrypts and publishes the participant’s new ballot on the blockchain using a repeated transaction. Only the last encrypted ballot published by a participant is accepted for counting.
After the voting period, which was defined by the administrator when it was created, any transactions from voting participants are rejected by the system.
4. Summing up the voting results¶
Final counting of the results¶
After voting is completed, all servers in the system independently count the votes. The votes are counted without decrypting the voting results, since no cryptographic service has a common private key for decryption.
The voting results for each of the questions are counted by homomorphic addition of the encrypted values (see Encryption). As a result, each cryptographic service independently obtains the encrypted value of the sum of participants’ votes for each of the questions.
Then, each cryptographic service proceeds to the preliminary decryption of the voting results. For that, the service uses its own private key, which was used at step 2 to generate the common public key. As a result of the decryption, each service gets an unreadable preliminary voting result.
At this stage, the integrity of the decryption results is checked using the ZKP Chaum-Pedersen algorithm (see section Zero-Knowledge Decryption Proofs). This ensures that the voting data has not been compromised by any of the cryptographic services.
Pre-decrypted voting results from each service are published to the blockchain via transactions to the corresponding nodes.
The master server collects the preliminary decryption results published on the blockchain. The cryptographic service of the master server then summarizes the obtained preliminary voting results and finally decrypts them. The final voting results are published to the blockchain.
At the same time, in case one or several servers fail, the master server is able to collect and decrypt the final results of the voting, thanks to the Shamir secret sharing scheme. If N servers participated in the formation of the common public key, it is enough to collect K < N pre-decrypted voting results to decrypt the results.