Content uploaded by Hitesh Tewari
Author content
All content in this area was uploaded by Hitesh Tewari on Dec 14, 2017
Content may be subject to copyright.
IADIS International Journal on Computer Science and Information Systems
Vol. 12, No. 2, pp. 148-165
ISSN: 1646-3692
148
THE FUTURE OF E-VOTING
Pavel Tarasov and Hitesh Tewari
School of Computer Science and Statistics, Trinity College Dublin, University of Dublin, Ireland
ABSTRACT
Voting systems have been around for hundreds of years and despite different views on their integrity,
have always been deemed secure with some fundamental security and anonymity principles. Numerous
electronic systems have been proposed and implemented but some suspicion has been raised regarding
the integrity of elections due to detected security vulnerabilities within these systems. Electronic voting,
to be successful, requires a more transparent and secure approach, than is offered by current protocols.
The approach presented in this paper involves a protocol developed on blockchain technology. The
underlying technology used in the voting system is a payment scheme, which offers anonymity of
transactions, a trait not seen in blockchain protocols to date. The proposed protocol offers anonymity of
voter transactions, while keeping the transactions private, and the election transparent and secure. The
underlying payment protocol has not been modified in any way, the voting protocol merely offers an
alternative use case.
KEYWORDS
Blockchain, E-Voting, Zcash, zk-SNARK
1. INTRODUCTION
With blockchain technology steadily striving towards becoming the new system for
decentralized payment schemes, amongst other implementations, it is easy to imagine why this
technology can be considered an ethical liberator with regards to different application
domains. Blockchain, although a relatively new concept, has gained enough popularity for
applications to emerge, such as simplified methods for identification and authentication, the
widely known decentralized payment scheme, Bitcoin, and domain systems which reside
outside the control of the government or non-governmental organizations (NGOs) and many
more (Swan, 2015). The number of blockchain systems is steadily increasing, however the
electronic voting domain is very slow to adapt to changes in technology with a relatively low
number of systems devised so far, which introduce a fresh look on the electronic voting scene,
based on our observation of the state of the art.
THE FUTURE OF E-VOTING
149
Electronic voting has been a topic of active debate, with significant number of people
believing that electronic voting cannot be trusted enough to be used for significant elections
due to uncertainty in the authenticity and integrity of the machines, and the votes that have
been cast using them. On the other hand, people acknowledge that paper solutions are
significantly outdated and can be subject to serious manipulation from a coercer. The
emergence of blockchains has introduced a new way to construct secure systems which have
less inherent security issues present within the systems. It is a belief that a successful voting
system can be implemented using blockchains, or with a blockchain being one of the main
elements present in a hybrid electronic voting scheme (Bradbury, 2014). With many
applications switching to or created on the blockchain platform, why does voting have to stay
behind and not evolve with technology?
In our work, we investigate a new decentralized, anonymous payment scheme called Zcash
(Hopwood et al, 2016) and create a voting system without altering the inner working of Zcash
protocol with one of the targets being the creation of a cheaper voting alternative which is
simple in use to appeal to the younger population.
2. STATE OF THE ART
Electronic voting is a topic of much research and several viable schemes have been created to
attempt and solve the problem. Here, we present some influential voting protocols and other
viable voting schemes as well as the techniques they implement at the core of vote processing,
their security issues and analysis that have been done on some of the protocols in this domain.
Blockchain voting technologies that have emerged recently are also discussed here, with
attention to Ethereum (Wood, 2014).
2.1 Influential Electronic Voting Protocols
Electronic voting protocols have been implemented in different elections, ranging from
university to government based elections. Many viable protocols have been created since
Chaum (Chaum, 2004) first proposed Votegrity, one of the first end-to-end (E2E) verifiable
voting schemes. E2E verifiability means that the voter can verify that their own vote has been
cast as intended. The voter would be the assured that their vote has been counted correctly and
included in the final tally and that the public members can verify an election externally
without being involved in an election. These voting protocols, also provide a way to audit the
voter’s votes and the ballots prior to picking the candidate and casting the ballot.
Some of the most prominent examples that have stemmed from Chaum’s Votegrity, which
also provide E2E verifiability, are Neff’s Markpledge (Neff, 2004), Prêt à Voter (Ryan et al,
2009), Helios (Adida, 2008), Scantegrity (Carback et al, 2010) and STAR-Vote (Bell et al,
2013). Markpledge was one of the first E2E voting protocols which has been proposed
alongside Votegrity, influencing the development of the other schemes mentioned above and
more. Helios, a university voting scheme, has undergone security analysis, which uncovered
security vulnerabilities with a potential to affect the outcome of the elections. This led to the
development of Helios 2.0 (Adida et al, 2009) and Helios 3.0 versions, attempting to fix the
vulnerabilities posted by Estehghari and Desmedt (Estehghari and Desdedt, 2010). This is a
good example of a security vulnerabilities in a voting protocol. A possible attack on Helios 2.0
IADIS International Journal on Computer Science and Information Systems
150
included cross-site scripting (XSS) through the usage of a browser rootkit, a script capable of
monitoring user traffic, capturing passwords entered by the user and get access to the DOM
tree of the web page.
Some E2E protocols use public web bulletin board (WBB) for posting all the cast ballots
for the public to see. Web bulletin boards are used as an authenticated public broadcast
channels which, display the cast ballots to the public in an encrypted form, and serve as an
important stage for any E2E protocol. Typically, after the voter has cast their vote and
received a receipt encrypting their choice in a way that is dependent of what voting protocol
used, the encrypted vote is propagated to the WBB (Parsovs, 2015; Heather, 2007, Culcane et
al, 2015).
The receipt is an important part of the voting protocol, as it allows the user to prove their
vote to an authority in case the voter wishes to dispute their vote or prove that they have voted
contrary to what the system has recorded. The receipt also allows the user to find their vote
and view how the system recorded their vote. These receipts vary from system to system, but
typically these receipts are the summary of how the voter voted, which can be presented to the
voter in an encrypted or obfuscated manner. As an example, Votegrity summarizes the vote in
a print out which prompts the voter to pick the top or the bottom layer of the receipt. The
receipt is a laminated piece of paper, which is separated into two layers, which are only
readable when these layers are combined and never on their own. The mutual relationship of
the pixels on the translucent layers is how the vote becomes readable (Chaum, 2004).
Some electronic voting protocols implement a challenge system, which helps a voter to
establish trust in the system. Apollo (Gaweł et al, 2016) is an extension of the Helios protocol,
however, it avoids some security issues that are inherent in Helios by having voter assistants
to verify, lock and audit the vote. The assistants are external to the voting protocol devices that
can interact with the election and can be laptops, tablets, or any other external devices. These
interact with the session by fetching the personalized string, input by the voter during the start
of the session, to fetch the session. The voter that wishes to audit their vote sends the audit
code through the voting booth, which in turn opens the encryption of the ballot by posting the
randomness encrypted with the session key. Each voting assistant checks the bulletin board
and displays the plaintext value of the vote. This procedure may be repeated as many times as
the voter wants (Gaweł et al, 2016).
Mixing is one of the two predominant techniques that are used in electronic voting
protocols and utilizes mix networks (mixnet), a protocol that takes in multiple input messages
from the users and shuffles these messages in random order before passing them to the next
destination (Chau, 1981). Mixnets, in the context of voting, are used to provide a degree of
anonymity to the user by obfuscating where the message came from. For example, Zeus
(Tsoukalas et al, 2013) implements mixing after the election has been closed to break the
linkability between the encrypted ballots and the voters who cast them. This is a multi-round
procedure which depends solely on the number of mixing proxies available to the system.
Each stage of the mixing provides a proof of correct mixing, which can be used to verify that
the mixing server is not corrupt.
The second widely used technique is homomorphic tally. Cohen and Fischer (Cohen and
Fischer, 1985) describe how this can be applied to a voting protocol. Homomorphic tally
involves modifications, usually additions and multiplications, to the ciphertext which are
preserved upon decryption to reveal the operations that have been done on the ciphertext while
recovering the modified decrypted value. Protocols such as Helios 2.0 (Adida et al, 2009),
STAR-Vote (Bell et al, 2013) and several others implement this technique for tallying the
THE FUTURE OF E-VOTING
151
votes due to its simplicity both in application and for verification by the public, though the
efficiency of these protocols, over mixnets, have been different through the papers where these
methods are used.
Protocols such as Zeus (Tsoukalas et al, 2013) and Apollo (Gawel et al, 2016) use the
basis of Helios to build their own voting protocols on, while attempting to tackle some of the
security issues that are inherent to Helios. For instance, Apollo tackles the issues of XSS,
cross-site forgery, clickjacking and clash attacks with the help of the voting assistants. For
example, XSS was possible due to the unchecked URL parameters that meant to obtain the
election URL, but if compromised could have pointed to a proxy with malicious script forced
to execute on the target machine by the attacker. Ultimately, the attacker could encrypt each
choice of the voter correctly, but submit their own ballot instead of the voters when the voter
continued to submit their vote. This attack is impossible to detect server-side, but can be
detected by the voter if the voter checks the WBB later to find their vote. XSS is in the third
place of the top vulnerabilities of web applications as found by OWASP in 2013 (Wichers,
2013) and remains in the same position in OWASPs “Top 10 Application Security Risks” of
2017.
2.2 Blockchain for Voting
The conclusion can be made that an electronic voting system must be secure, while allowing
for as much transparency as possible to be a working E2E verifiable. Blockchains (Nakamoto,
2008) help to achieve this level of security and transparency, while maintaining privacy and
non-malleability of the transactions (Deloitte Nederland Website, 2016; Glass, 2016).
Although different, some elements from the above-mentioned protocols may apply to the
concept of blockchain voting. The notion of WBB, where the encrypted votes can be seen by
the public members, can persist in blockchain in the form like (Blockchain Website, 2017).
Here the blocks of transactions can be observed as well as the height of the blockchain with
any other relevant information. Although blockchain is a promising technology, we have not
found any relevant papers to date that present a protocol for online voting with blockchains.
Examples such as Follow My Vote (Follow My Vote Website, 2017) or TIVI (TIVI Website,
2017) present a seemingly sound voting protocol, however they are presented without any
in-depth specification to verify the security of the protocol.
One other noteworthy blockchain technology that could revolutionize electronic voting is
Ethereum (Wood, 2014). Ethereum differs from Bitcoin (Nakamoto, 2008) as it serves as a
generic platform for creation of custom functionality in the form of smart contracts. The
currency used by Ethereum is ether and gas. However, the main difference is the fact that the
contracts allow for different functionality using the Ethereum Virtual Machine (EVM), while
being enforced by the peer-to-peer, decentralized way, inherent to the core structure of
blockchain. Ethereum possesses two types of accounts, which is another way of specifying
types of users. Human entities use accounts, whereas contracts are accounts which are
operated by code on the EVM. Contracts are the agents that bring about the generic
functionality of Ethereum and allow one to create custom behavior for one’s blockchain
application. These applications include, and are not limited to, automatic payments or creation
of custom currency, which is worthless outside of the context of the contract application
(Wood, 2014; Devcon2 Video, 2016).
IADIS International Journal on Computer Science and Information Systems
152
3. ZCASH OVERVIEW
Zcash is a decentralized blockchain payment scheme, which aims to provide anonymity and
privacy of transactions. One of the biggest differences between Zcash and Bitcoin is the proof-
of-work system, where Zcash relies on zero-knowledge proofs (Hopwood et al, 2016). Zcash
is an implementation of a concept called Zerocash (Ben-Sasson et al, 2014) which describes
similar concepts to Zcash but the architecture behind Zcash is different. We present a brief
overview of the important concepts of Zcash prior to describing the details of our proposed
voting protocol.
3.1 Addresses and Transactions
Zcash supports both anonymous and transparent transactions as it has two types of addresses,
which differs from the Bitcoins single address. These addresses are, namely, z- address and
t-address, where z-address is the address which preserves anonymity in transactions, and
t-address resembles the Bitcoins addresses in structure and allows for transparent transactions.
The transactions between different addresses ensures the conversion of transparent value into a
shielded value and vice versa. The details of shielded values cannot be observed by the public.
The transactions between addresses is illustrated by Figure 1.
Figure 1. Types of Transactions in Zcash (Peterson, 2016)
Private transactions occur when both, the sender and receiver use z-addresses, which
ensures that no entity, outside the entities involved, can view the details and the value of Zcash
(ZEC) that are exchanged in the transaction.
The private, z-addresses are generated with the combination of the keys, of which there are
a total of 4 keys, which allow for spending, viewing, paying and transmission of secret values
between the parties. These keys are namely:
Paying key (): Used as a part to generate payment address.
Transmission key ( ): Used to encrypt and decrypt secret values to be passed
between the parties involved in a transaction.
Spending key ( ): Allows spending of ZEC.
Viewing key ( ): Establishing keys for viewing the private transaction between
involved parties.
THE FUTURE OF E-VOTING
153
The combination of paying key ( ) and transmission key ( ) is what makes up a
z-address.
Part of spending a ZEC involves revealing a nullifier for a ZEC which has a commitment in
a Merkle tree (Nakamoto, 2008). The commitment is placed on such tree in Zcash, whenever a
new ZEC is generated. A nullifier can be considered as a serial number for each ZEC which
prevents double-spending of the same ZEC. The spending procedure involves locating a
commitment on the Merkle tree and ensuring that the nullifier has not yet been revealed, as
once the nullifier is revealed, the ZEC is considered spent. The nullifier set is maintained at
every full node and newly revealed nullifiers are inserted into the set with each transaction. A
full node is simply a device which has the entire Zcash blockchain stored on it and therefore
contains the full nullifier set.
A secret pair of keys is established and known as the ephemeral keys. The ephemeral keys
are established for the transmission of the secret values in private transactions to ensure that
only the sender and the recipient can view the transaction. The possession of the private
ephemeral key () and the recipient’s address is what allows the sender to view the
transaction. At the same time, the receiver uses their viewing key ( ) and the ephemeral
public key () to view the transaction from their end. The ephemeral public key is sent with
the transaction, which is the way that the receiver obtains it. Even if a third party obtained this
key, they do not have the other keys to view the transaction or derive a key to decrypt the
secret values in the transaction.
Part of the transaction, named JoinSplit Transfer in Zcash (Hopwood et al, 2016), is for the
sender to spend their ZEC, which reveals the nullifier for the input ZEC, and generation of the
commitments for the new ZEC which will be passed to the receiver as part of the transaction.
The values used to generate the ZEC are passed to the receiver after being encrypted with a
key established via transmission key (). These values in a transaction are accompanied,
by a zero-knowledge proof to ensure that the transaction is legitimate and follows the rules for
a transaction.
Another important aspect of the JoinSplit Transfer, is the transmission of the secret values
used to generate each ZEC and contain information about it. These secret values must be
passed to the recipient, otherwise the recipient, will not be able to spend the coin in their next
transaction. These values are encrypted using the ephemeral keys, transmission key and secret
keys established as part of the encryption setup. The recipient is then able to decrypt these
values due to the nature of the keys used to encrypt them, being setup in agreement between
the sender and the recipient.
Finally, the JoinSplit Transfer supports both shielded and transparent values in the same
transaction as the transparent value pool in each transaction is dedicated for transparent
transactions as well as to hold the miners reward for processing the transaction.
3.2 Zero-Knowledge Proving System
The key to the private transactions is the zero-knowledge proving system. This is because
there is a need to transfer the secret values between the involved parties without disclosing
these values to each other. To facilitate this transfer, Zcash implements zk-SNARKs
(Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) devised into libsnark
library from the designs of Ben-Sasson (Ben-Sasson, et al, 2014; Ben-Sasson et al, 2013).
IADIS International Journal on Computer Science and Information Systems
154
This construct allows for generation of zero-knowledge proofs given an arbitrary program.
The proofs are generated using several steps which are shown in Figure 2.
For this paper, we will not be discussing these steps in details, rather we provide an
overview of the zk-SNARK functionality for better understanding of its application in Zcash.
The purpose of supplying a proof is to verify the legitimacy of secret values, which are used to
generate a ZEC, exchanged during a transaction. Libsnark allows the conversion of programs
into proofs of knowledge. The program utilizes a port for a GCC compiler to create a circuit
based on monitoring the execution of a program. The compiler creates a circuit from a
program, which is a mathematical model for a logical circuit. The purpose behind the circuit is
to accept a specific value that satisfies its logic, and reject any other input. These circuits are
supplied into the generator function with some secret values, known as toxic waste. The toxic
waste is made up of several values, which if disclosed to the public, may result in people
generating fake proofs for their transactions. These values are therefore deleted after the setup
has been complete and the generator function has generated the keys and other values, which
are used in the transaction verification.
The purpose of the generator function is to generate 2 keys, namely proving key and
verifying key. The proving key is used by the prover to create a proof. The proving function
takes the proving key, the secret value, which the prover is trying to prove the knowledge of,
and the public function for which the secret value is for as parameters. The result is a proof
which is passed to the verifier.
The verifier uses the verifying key, the public function and the proof to determine the
validity of the proof and returns a binary answer of true or false, depending on whether the
verifier is satisfied by the supplied proof (Lundkyist, 2017).
Figure 2. Overview of zk-SNARK Proof Creation (Buterin, 2016)
The generator function is part of a setup procedure and uses toxic waste values as part of
the setup stage. The setup phase for Zcash is done once to establish the proving and
verification keys. If the toxic waste is not deleted and a party was able to obtain these keys,
then the said party would be able to generate fake proofs.
The JoinSplit Transfer also provides some proofs as part of the transfer is to generate new
ZECs. Some of the things that the proof is used to prove are:
The total values of input ZECs and output ZECs matches.
The commitments exist and are valid for the input ZECs.
The nullifier and the commitment have been calculated correctly.
THE FUTURE OF E-VOTING
155
The proofs are not limited to these three items and the total size of the resulting proof is
296-bytes (Hopwood et al, 2016).
4. SYSTEM OVERVIEW
Prior to describing our voting protocol, it is worth mentioning that the underlying Zcash
protocol (Hopwood et al, 2016) has not been changed in any way. The protocol utilizes basic
functions offered by Zcash and creates a platform with the ability to cast votes using Zcash
tokens. The work assumes the following things: assumption of confirmed identity, where the
protocol assumes that the identity of a potential voter can be verified, such as employing
X.509 certificates (Hazlewood, 2011) and Certificate Authorities (CA) to verify those
identities. This is to facilitate legal authorisation of the vote transaction on behalf of the voter.
Our approach to the creation of the voting protocol revolves around certain principles,
which we believe are the minimum number of key things needed in order to impement a
successful voting protocol. We call these principles the cornerstones of voting and they are:
Anonymity, Privacy and Transparency. Anonymity ensures that the voter’s vote cannot be
traced back to the them. Privacy ensures that the transaction of the vote can be completely
private if a voter wishes to do so and transparency opens up the critical steps of the underlying
voting mechanism to the public in order to demonstrate that the votes are not tampered with.
These principles can be seen in Figure 3. We separate out voting protocol into four distinct
steps: registration, notification, voting, and tally/audit.
Figure 3. The Cornerstones of Voting
4.1 Registration
Registration is the first step of the protocol and is required as part of the identity verification
step and for audit purposes, to keep track of which voters have cast a ballot, and is a control
mechanism to disallow unregistered people to participate in the vote. A potential voter who
wishes to participate in an election or a poll is required to visit the registration page, where
IADIS International Journal on Computer Science and Information Systems
156
communication with the server is established transparently. The system needs to authenticate a
potential voter and can do so by following the Challange-Handshake Authentication Protocol
(CHAP) (Simpsom, 1994) and exchange challenge information and solution. The
authentication mechanism can vary, however in this case X.509 certificate was used as an
example.
After successful registration, the voter’s email address or an X.509 certificate containing
their email address is stored in the database used by the voting system. After the voter has
registered, they are redirected to a page where one could obtain a Zcash wallet required for
voting. The overall registration step can be seen in Figure 4.
Figure 4. Voter Registration Process
4.2 Invitation
Invitation step is a small step which initialises the voting process. In this step a poll
administrator inputs poll relevant data, such as the name of the poll, the candidate list and the
duration of the poll. When the administrator finishes, the system traverses the database of
stored email addresses, or X.509 certificates to obtain relevant contact details, to send a
one-time unique link to each of the voters’ email addresses, which redirects the voters to a
unique ballot assigned to them. The server cannot issue invitatioin prior to comencement of
any poll. This is similar to the Zeus protocol (Tsoukalas et al, 2013) where the administrator
too, inputs the details of the poll as well as the list of the registered users.
The issued links time to live (TTL) is only as long as the duration of the poll/election set
by the administrator and expire as soon as the timer runs out. The voter visits the link and is
required to authenitcate themselves in the same way as they have during the registration. This
authentication can run against the database to ensure that the voter has registered prior to
clicking the link. Once the information has been verified, the voter is presented with the
unique ballot on which they can cast their vote. The invitation step can be seen in Figure 5.
THE FUTURE OF E-VOTING
157
Figure 5. Invitation to Participate in Ballot
4.3 Voting
Once the voter has followed the ballot link, they are redirected to the ballot page. The ballot is
a simple interface which contains candidates’ names and a checkbox next to the names. The
top of the ballot contains a field which requires the voter to input their receiving t-address. The
voter generates these addresses to send and receive the tokens provided by the system. To
maintain anonymity, but at the same time adhere to the transparency of the vote, the voter is
required to provide a receiving t-address and is required to send the vote with a z-address. If
the voter does not use z-address for sending their vote, their vote will not be anonymous.
The receiving t-address is provided by the voter on the top of the ballot and can be
changed as many times as required by the voter. This address ensures that the voter receives
the vote token, which is redirected to the candidate wallet in the subsequent step. The voter
uses the z-address to ensure that their vote is anonymous.
When the voter is ready to cast their vote, they must agree to the terms and conditions of
the voting system. That is that the voter authorizes the subsequent transaction to take place
from their account, to return the token granted to them by the system. The terms and
conditions can also include any other relevant data to the election procedures, such as any
legal liabilities in stealing tokens.
Once the authorisation takes place, the vote tokens can be generated by the system faucet
to send to a ZEC pool, or if there are enough ZECs available, issue them straight from the
ZEC pool. The ZEC pool is a system wallet which issues ZECs to the voters once the voter
has authorised the vote. Once the voter has authorised the vote, the system changes the voter’s
status in the database, as well as incrementing the system count of the total votes for the
current election. The number of voters whose status has changed to “voted” can also be
tracked by similar system counters if further integrity checks are required for the system. At
the same time, a token is sent to the receiving address specified by the voter. The number of
issued tokens is tracked by the system and is compared to the total number of votes to ensure
that no extra votes have been added into the tally. Figure 6 outlines the steps taken when the
voter casts their vote.
IADIS International Journal on Computer Science and Information Systems
158
Figure 6. Overview of the Voting Process
4.4 System Variants
The transaction between the candidate and the voter becomes private if the candidate uses
z-address. Inherent to the Zcash protocol, z-addresses break the linkability between the ZECs
and previous transaction. This means that when the candidate empties their wallet into the
ZEC pool, the voter may no longer trace their vote to the ZEC pool. This scheme requires
more trust in the system, however it guarantees the privacy of the system i.e. no one can see
the details and amounts of the transaction sent to the candidate.
Since private transactions require more complicated setup, there are more internal steps
involved in making these transactions. One of the most important pieces of information is the
establishment and sharing of ephemeral keys. These keys allow the voter and the candidate
both to view the transaction, which is exclusive to the two parties. These keys are established
as per key agreement function of Zcash. Internally, the transaction remains the same. This
variant may require the voter to revisit their cast vote to ensure that the vote has not been
tampered with along the way i.e. that it is sent to the candidate of their choice and only 1 ZEC
vote token has been sent.
The second variant of the system involves the candidate’s receiving with their t-addresses.
This is an example of a deshielding transaction and would mean that the candidate’s token
balance can be observed by the public close to real-time depending on how fast the blocks are
pushed to the chain. The linkability of the tokens would also be preserved. Linkability in this
case means that a token can be traced back to the sender to the ZEC pool, where the tally
occurs after an election timer has expired. This can help users determine if their vote has been
counted in the tally.
Regardless of the variant used, the JoinSplit Transfers of vote tokens from voters to
candidates are stored on the blockchain as transactions with the appropriate data for each
JoinSplit Transfer.
THE FUTURE OF E-VOTING
159
4.5 The Tally/Audit
The final stage of the voting protocol is the vote count and the audit which takes place after
the count to review the election process and ensure that the integrity of the election has not
been compromised. The candidate wallets send all the ZEC vote tokens to the ZEC pool which
has ZEC balance of 0 ZEC vote tokens. This requires some trust in the system, however the
assumption is that the candidate wallets and a ZEC pool have 0 ZEC vote tokens in the
beginning and that candidate wallets send all the collected ZEC vote tokens into the coin pool.
The transactions may be more difficult to verify as these are private, and the details are only
available to the voters and the candidates only. However, if the same party who starts an
election holds the ownership of the candidate wallets and may implement verification systems
to check each transaction destined for each candidate.
The candidate wallets send all their acquired ZEC vote tokens to the ZEC pool using
sending t-address on the candidate’s side and a receiving t-address on the side of the ZEC
pool. The system declares the end of the election or a poll as soon as the expiry time has been
met. After that, no votes are accepted into the count and the system, the unique vote links
expire, and the ballot forms do not allow to proceed with the submission of the votes.
At this point the number of total votes cast becomes public as well as the number of tokens
issued for the voters. The total number of transactions may also be displayed with the total
number of voters who participated in the election. It is not in the interest of the candidates to
not empty their wallets upon conclusion of the election, or to send an incorrect number of ZEC
vote tokens as the system equations will not balance and the election will be considered
forfeit. Figure 7 provides an example election with 100 total votes being cast between
candidate X and candidate Y.
Figure 7. Example of Tally and Audit
IADIS International Journal on Computer Science and Information Systems
160
5. SECURITY CONSIDERATIONS
A significant issue with internet voting protocols are compromised voting machines. Since the
target platform of the protocol would be user’s end devices, such as computers and mobile
devices, it is possible for a coercer to influence the outcome of the vote by compromising the
voter’s device as it would be much easier to achieve than compromising the entire electronic
voting scheme. The coercer could infect the voter’s machine and influence the voting software
installed. The voting software will then be influenced by the coercer’s candidate choice. One
of the possible ways that a concerned voter can defend against such an attack is to obtain a
checksum of the voting application. A checksum can simply be a hashing of the voting
software of a specific version which the voter has installed on their device. If the voter’s
device is compromised, then the hash versions will not be the same and the voter can obtain a
new copy of the software.
Since our proposed voting protocol does not make any changes to the underlying Zcash
protocol, some problems, like double voting i.e. using the same granted vote token to vote for
multiple candidates, is inherently absent in the voting protocol. However, since the unique
ballot link is sent to a voter’s email address, the issue of compromised machine can persist
once again. A potential coercer could get access to the voter’s email first and attempt to cast a
vote on their behalf. Notification systems can be in place to send email confirmation when a
vote has been issued by the voter and visually notify the voter of the number of times they
have attempted to vote so far.
A major consideration in dealing with Zcash and the automated script assumption is that
all the operations deal with ZECs, which have a non-negligible value on the market
(CoinGecko Website, 2017). This gives a potential incentive for corrupt voters to attempt to
hijack the vote token upon brief arrival to their wallet. The assumption is that the script can
detect the specific transaction arriving into the wallet and redirecting it to a candidate
immediately. There are several mitigations to avoid ZEC hijacking. First is to deal with the
smallest denominations of ZEC (1 zatoshi) to reduce the incentive to steal a whole ZEC as 1
ZEC is zatoshis (Hopwood et al, 2016). Though the audit calculations for the end of the
election may not fail, a rogue transaction to a wallet, not belonging to a candidate may be
noticed by the public.
The use of 1 zatoshi is an additional factor which helps to reduce the cost of running
elections. Since the administrative authority oversees creating the polls/elections, they need to
provide the ZEC vote tokens to grant to the users. With the current pricing of a ZEC token
being approximately $235 (CoinGecko Website, 2017) and providing 1 zatoshi to each voter,
it is possible to facilitate 300 million voters, at a cost of 3 ZECs. Reinforcing the above point
of hijacking tokens, it will provide even less incentive as each zatoshi will have a price of
0.00000235 of a dollar given the above pricing.
Having mentioned the required balance of values at the end of an election to verify its
integrity, a possible attack could be carried out on the system, where a losing candidate does
not submit all the received votes. This would cause the election to be forfeit as the total
number of ZEC vote tokens does not balance with the total number of votes and ZEC vote
tokens issued. This attack could be detected if the candidates were using t-addresses as all the
receiving transactions would be visible, however it would pose a problem if the candidate used
z-address as no public party, except the administrators of the voting system would know if a
candidate is misbehaving. A possible mitigation for this attack can disregard the total number
THE FUTURE OF E-VOTING
161
of ZEC vote tokens returned to the counting pool, only if this number is less than or exactly
equal to the number of total votes. In case of this occurrence, the voters and the administrators
can be notified by the system that the votes returned did not match the total number of votes
issued.
One potential way to make the system more trustworthy is with the help of more trackers,
like the trackers used to count the total issued tokens and total votes. Similarly, these can be
used to track the number of tokens that each candidate had in their wallet before an election
and the number of tokens which were in the ZEC token pool to further ensure that no
discrepancies occurred during the voting process.
An alternative solution can implement internal system trackers, which count the number of
votes cast for each candidate, and serve the purpose of controlling the amount of ZEC vote
tokens returned by the candidates. A tracker for each candidate increments each time a vote
has been cast for a candidate and the system expects to withdraw this amount of ZEC vote
tokens from the candidate wallet, which would not let a malicious candidate trick the system.
These trackers would function even if the candidates used z-addresses. It is also possible to
make this tracker public, during the tally period, to notify the public what the expected vote
count is.
A question may arise, of what would happen if the system counters have been modified by
an attacker? According to the rules of the system, the integrity of the election will be
considered compromised and the result will be forfeit. The reality of a decentralized system is
that there may be more than one instance of the tracker initialized at a given time, and it may
be required that they all need to agree at the end of an election.
One significant attack on the entire blockchain is called 51% attack (Learn Cryptography
Website, 2013). This is one of the biggest flaws in blockchain technology. This attack allows
an entity with the biggest contribution to block mining to be able to change the contents of the
past blocks on the blockchain due to the sheer computer power available to the entity. Other
activities would include prevention of some transactions from obtaining a required number of
confirmations and preventing people from sending ZEC vote tokens to the candidate
addresses. This attack would be difficult to prevent. On one hand, it is possible to pick out
several trusted verifiers out of the public volunteers and allow them to confirm the transactions
to be included in the blocks. On the other hand, there may be trust issues raised by the
participating voters. One other option is to allow any willing public member to participate in a
verification pool. This would mean that the voter adds their computing power to the pool of
other voter’s machines to verify the transactions, however this pool would need to be
organized by a trusted party whose actions can be verified in case the party is considered
rogue.
6. FUTURE WORK
Having outlined the voting protocol and the basis for its operations, it is important to outline
the direction this protocol can take. The Ethereum protocol (Wood, 2014), has been
established early in the work as a potential candidate to become the platform for our voting
protocol. One of the reasons for this is that Ethereum supports creation of contracts, which are
accounts which are operated by the EVM. These contracts can be used to implement a voting
IADIS International Journal on Computer Science and Information Systems
162
scheme. However, voters’ anonymity and privacy are important pieces of any voting protocol
and are not yet handled by EVM transactions.
Steady advancements in development of the Ethereum platform bring the possibility of
creation of this protocol closer. The future Ethereum aims to make use of zk-SNARKs to add
privacy and anonymity of transactions. The zk-SNARKs are complex to implement efficiently
due to the time taken to generate proofs, which is one of the issues in implementing these
today. However, steps towards adoption of zk-SNARKs have already been taken by Ethereum
(Hudson, 2017).
Our initial idea focused on developing a voting protocol for Irish Electoral System. The
Irish system uses proportional representation – single transferable vote (PR-STV) system. In
PR-STV the votes of the candidates who got the least number of votes, get transferred to the
second candidate of the voter’s choice and so forth until all representatives are selected
(Eustace, 2017). This means that there will be more complex transactions involved and the
system may need to include data in the transactions which is only comprehended by the nodes
which are running the voting system since integrating extra data into the transactions is not
supported by the Zcash protocol or blockchain. Logic is required to be in place to transfer
correct number of votes to other candidates and therefore some state is required to be kept,
which potentially ties this to the Ethereum project.
Alternatively, it is possible to store or combine all ballots together to obtain candidate
ranking. Storing ballots means that if a candidate is out of the election, their votes will be
transferred to the next candidate according to the stored ballot. This process continues until
either the ballot has no more candidate transfer information or, the candidate has been
selected. The combination of ballots leads to the concept of potential transfers. This creates a
vote state for each of the votes on the ballot. Suppose a voter has casted their vote for
candidate A, followed by their second choice of candidate C, followed by candidate B.
Another voter may have cast their vote for candidate B, then A, then C. In this case, the votes
from all the ballots would get summed together initially giving candidate A a vote and
candidate B a vote with potential votes for candidate A totaling to 1, which comes from the
second choice of the second voter. This is the case for candidate C also. In the case that the
candidate B is out of the election, the A candidate would get transferred the potential votes
stored. This system can run these transactions in stages after a candidate either won an election
with excess votes or is out of the election completely.
Finally, steps have been made to integrate Zcash and Ethereum together in projects such as
Zcash over Ethereum (ZoE), however these are still at very early stages. ZoE project attempts
to run Zcash on pre-compiled contracts to prove that a sender knows a commitment on a
Merkle tree, which is part of Zcash proofs in every transaction. The reason that this work is
still in its early stages is that zk-SNARKs take a significant time to generate and equate to
approximately 40-60 seconds for proof generation in each Zcash transaction, therefore a
pre-compiled contract is used. Once this project is more efficient at these calculations it may
be possible for a better integration of zk-SNARKs in other blockchain systems (Bowe, 2016;
Reitwiessner, 2017).
THE FUTURE OF E-VOTING
163
7. CONCLUSION
A standardized electronic voting solution which would be widely adopted has not yet
emerged, and although there are some good candidates, there are inherent security issues
which make these protocols unsuitable for elections. The literature identifies a distinct gap in
the domain which could be filled by a protocol, using a different technology then the previous
protocols. Blockchain offers an inherently more secure platform, and with development of the
recent anonymous transaction scheme, namely Zcash, it is finally possible to tackle the
anonymity issues of blockchain transactions, which would open a possibility for blockchain
voting. Ethereum has offered the smart contract functionality since it first came to pass,
however the much-needed anonymity factor has not been present in the protocol so far. The
rapid growth of the Ethereum protocol, and its integration with Zcash will most likely come
up with the protocol, suitable for wide-spread, cheap voting system. As indicated by the future
work on these protocols, voting on blockchain has received the much-needed push in the right
direction.
The applications for the proposed protocol are not limited to government elections only.
These can be stretched to opinion polls or corporate elections providing a unified platform for
voting regardless of the cost or circumstance. The drive behind a cheaper, unified, electronic
voting system was the basis for the above protocol, which has potential to grow into a real
wide-spread implementation, dealing with assumptions and concerns which limit the current
system.
The standardization or adoption of such protocol would be a step towards public approval
of electronic voting schemes, provided that the said protocol is secure and has been tested and
tried. The release of new protocols, with security issues does not take steps to progress in
public approval and, ultimately, replacement of the paper elections.
A major effort has gone into development of a sound voting system and with the rapid
developments of blockchain technology and its implementations in various fields, one final
push is required to bring a sound electronic solution to one of the humanities basic rights - to
vote.
REFERENCES
Adida, B., 2008, July. Helios: Web-based Open-Audit Voting. In USENIX security symposium, 17,
pp. 335-348).
Adida, B., De Marneffe, O., Pereira, O. and Quisquater, J.J., 2009. Electing a university president using
open-audit voting: Analysis of real-world use of Helios. EVT/WOTE, 9(10).
Bell, S., Benaloh, J., Byrne, M.D., DeBeauvoir, D., Eakin, B., Fisher, G., Kortum, P., McBurnett,
N., Montoya, J., Parker, M. and Pereira, O., 2013. STAR-Vote: A secure, transparent, auditable, and
reliable voting system. USENIX Journal of Election Technology and Systems (JETS), 1(1), p.18-37.
Ben-Saason, E., Chiesa, A., Genkin, D., Kfir, S., Tromer, E., Virza, M., 2014, libsnark: C++ library for
zkSNARK proofs. Available at: https://github.com/zcash/libsnark
Ben-Sasson, E., Chiesa, A., Genkin, D., Tromer, E. and Virza, M., 2013. SNARKs for C: Verifying
program executions succinctly and in zero knowledge. In Advances in Cryptology–CRYPTO 2013
(pp. 90-108). Springer, Berlin, Heidelberg.
Ben-Sasson, E., Chiesa, A., Tromer, E. and Virza, M., 2013. Succinct Non-Interactive Arguments for a
von Neumann Architecture. IACR Cryptology ePrint Archive, 2013, p.879.
IADIS International Journal on Computer Science and Information Systems
164
Ben-Sasson, E., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., Virza, M.,, 2014, Zerocash:
Decentralized anonymous payments from bitcoin, Proc. - IEEE Symp. Secur. Priv., pp. 459474,
2014.
Blockchain Website, 2017, Bitcoin Block Explorer Blockchain, Available at: https://blockchain.info/
Bowe, S., 2016, Zcash - zkSNARKs in Ethereum, Zcash Blog, Available at: https://z.cash/blog/zksnarks-
in-ethereum.html
Bradbury D., 2014 How Block Chain Technology Could Usher in Digital Democracy. Available at:
http://www.coindesk.com/block-chain-technology-digital-democracy/ [Accessed 23 November
2016]
Buterin, V., 2016, Quadratic Arithmetic Programs: from Zero to Hero, Medium, Available at:
https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-
f6d558cea649#c1fkogp41
Carback, R., Chaum, D., Clark, J., Conway, J., Essex, A., Herrnson, P.S., Mayberry, T., Popoveniuc, S.,
Rivest, R.L., Shen, E. and Sherman, A.T., 2010. Scantegrity II municipal election at Takoma Park:
the first E2E binding governmental election with ballot privacy. 19th USENIX Conf. Secur.,
pp. 19-35
Chaum, D., 2004. Secret-ballot receipts: True voter-verifiable elections. IEEE security & privacy, 2(1),
pp.38-47.
Chaum, D.L., 1981. Untraceable electronic mail, return addresses, and digital
pseudonyms. Communications of the ACM, 24(2), pp.84-90.
Cohen, J.D. and Fischer, M.J., 1985. A robust and verifiable cryptographically secure election
scheme (pp. 372-382). Yale University. Department of Computer Science.
CoinGecko Website, 2017, Zcash/Bitcoin (ZEC/EUR) Price Chart, Available at:
https://www.coingecko.com/en/price_charts/zcash/usd
Culnane, C., Ryan, P.Y., Schneider, S. and Teague, V., 2015. vVote: a verifiable voting system. ACM
Transactions on Information and System Security (TISSEC), 18(1), p.3.
Deloitte Nederland. 2016, Blockchain technology: 9 benefits & 7 challenges, Available at:
https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/blockchain-technology-9-benefits-and-7-
challenges.html
Devcon2: Ethereum in 25 Minutes. 2016 Buterin, V., [Online video], YouTube, Ethereum Foundation.
Available at: https://www.youtube.com/watch?v=66SaEDzlmP4
Estehghari, S. and Desmedt, Y., 2010. Exploiting the Client Vulnerabilities in Internet E-voting Systems:
Hacking Helios 2.0 as an Example. EVT/WOTE, 10, pp.1-9.
Eustace, J. 2017, Our Voting System, Available at: http://spunout.ie/news/article/our-voting-
system1?gclid=EAIaIQobChMItPHooamY1wIV573tCh3rjQO3EAAYASAAEgJ5jvD_BwE
Follow My Vote Website. 2017, The Online Voting Platform of The Future - Follow My Vote. Available
at: https://followmyvote.com/
Gaweł, D., Kosarzecki, M., Vora, P.L., Wu, H. and Zagorski, F., 2016, October. Apollo–End-to-End
Verifiable Internet Voting with Recovery from Vote Manipulation. In International Joint Conference
on Electronic Voting (pp. 125-143). Springer, Cham.
Glass, P., 2016 How secure is blockchain?, Available at:
https://www.taylorwessing.com/download/article-how-secure-is-block-chain.html
Hazlewood, L., 2011, What is an X.509 Certificate? Stormpath User Identity API, 2011. Available at:
https://stormpath.com/blog/what-x509-certificate
Heather, J., 2007, July. Implementing STV securely in Prêt à Voter. In Computer Security Foundations
Symposium, 2007. CSF'07. 20th IEEE (pp. 157-169). IEEE.
Hopwood, D., Bowe, S., Hornby, T. and Wilcox, N., 2016. Zcash Protocol Specification. Tech. rep.
Zerocoin Electric Coin Company.
THE FUTURE OF E-VOTING
165
Hudson, J., 2017, EIPs, GitHub Website, Available at: https://github.com/ethereum/EIPs
Learn Cryptography Website, 2013, 51% Attack, Available at:
https://learncryptography.com/cryptocurrency/51-attack
Lundkvist, C., 2017, Introduction to zkSNARKs with Examples, ConsenSys Media, Available at:
https://media.consensys.net/introduction-to-zksnarks-with-examples-3283b554fc3b
Nakamoto, S., 2008. Bitcoin: A peer-to-peer electronic cash system.
Neff, C.A., 2004. Practical high certainty intent verification for encrypted votes.
P. Peterson, 2016, Anatomy of a Zcash Transaction”, Zcash Blog. Available at:
https://z.cash/blog/anatomy-of-zcash.html
Parsovs, A., 2016. Homomorphic Tallying for the Estonian Internet Voting System. IACR Cryptology
ePrint Archive, 2016, p.776.
Reitwiessner, C., 2017, An Update on Integrating Zcash on Ethereum (ZoE), Ethereum Blog, Available
at: https://blog.ethereum.org/2017/01/19/update-integrating-zcash-ethereum/
Ryan, P.Y., Bismark, D., Heather, J., Schneider, S. and Xia, Z., 2009. Prêt à voter: a voter-verifiable
voting system. IEEE transactions on information forensics and security, 4(4), pp.662-673.
Simpson, W., RFC 1994: PPP Challenge Handshake Authentication Protocol (CHAP), Obsoletes
RFC1334 [LS9 2]. Status: DRAFT STANDARD.
Swan M., 2015, Blockchain: Blueprint for a New Economy, O’Reilly Media, Sebastopol. California.
TIVI Website, 2017, TIVI Online Voting, Available at: https://tivi.io/tivi/
Tsoukalas, G., Papadimitriou, K., Louridas, P. and Tsanakas, P., 2013, August. From Helios to Zeus. In
EVT/WOTE. Washington D.C
Wichers, D., 2013. Owasp top-10 2013. OWASP Foundation.
Wichers, D., 2017. Owasp top-10 2017. OWASP Foundation.
Wood, G., 2014. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project
Yellow Paper, 151.
