ArticlePDF Available



Abstract and Figures

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.
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
Pavel Tarasov and Hitesh Tewari
School of Computer Science and Statistics, Trinity College Dublin, University of Dublin, Ireland
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.
Blockchain, E-Voting, Zcash, zk-SNARK
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.
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.
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
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
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
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
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 combination of paying key ( ) and transmission key ( ) is what makes up a
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
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 proofs are not limited to these three items and the total size of the resulting proof is
296-bytes (Hopwood et al, 2016).
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
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
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.
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
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.
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
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
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
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
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
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).
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
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
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
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:
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 CryptologyCRYPTO 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
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,
Blockchain Website, 2017, Bitcoin Block Explorer Blockchain, Available at:
Bowe, S., 2016, Zcash - zkSNARKs in Ethereum, Zcash Blog, Available at:
Bradbury D., 2014 How Block Chain Technology Could Usher in Digital Democracy. Available at: [Accessed 23 November
Buterin, V., 2016, Quadratic Arithmetic Programs: from Zero to Hero, Medium, Available at:
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),
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:
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:
Devcon2: Ethereum in 25 Minutes. 2016 Buterin, V., [Online video], YouTube, Ethereum Foundation.
Available at:
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:
Follow My Vote Website. 2017, The Online Voting Platform of The Future - Follow My Vote. Available
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:
Hazlewood, L., 2011, What is an X.509 Certificate? Stormpath User Identity API, 2011. Available at:
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.
Hudson, J., 2017, EIPs, GitHub Website, Available at:
Learn Cryptography Website, 2013, 51% Attack, Available at:
Lundkvist, C., 2017, Introduction to zkSNARKs with Examples, ConsenSys Media, Available at:
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:
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
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:
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.
... This makes the election a very important event in our modern democracy. The problem with the existing ballot system is that it can be easily manipulated by power hungry organizations [2]. Democratic countries have been experiencing dictatorial regimes which have introduced widespread terror among their people. ...
... The election of 1946 in Romania was heavily rigged. The communists took over Romania and abolished the multi-party system to gain complete control of the country [2]. Furthermore, Opposition parties in Nigeria still believe 2019 general elections were massively rigged in farvour of the ruling party APC. ...
... Estonia was the first in the world to adopt an electronic voting system for its national elections [1]. Soon after, electronic voting was adopted by Switzerland for its general elections [2], and by Norway for its council election [3]. For an electronic voting system to compete with the traditional ballot system, it has to support the same criteria the traditional system supports, such as security and anonymity. ...
Full-text available
Blockchain is a distributed ledger technology that allows digital assets to be transacted in a peer-to-peer decentralized network. Those transactions are verified and registered by every node of the network, thus creating a transparent and immutable sequence of registered events whose veracity is provided by a consensus protocol. E-voting system is an electronic way of casting and counting votes. It is an efficient and cost effective way for conducting a voting process in real time. However, globally, concerns on security networking and privacy of communication for e-voting have evolved. Securing e-voting is very urgent and has becoming a popular topic in the area of communications and networking. In Nigeria, citizens have complained over the integrity of national electoral umpire simply because Nigeria is still using traditional voting system. Integrity is put to test on every of our election result especially by the opposition parties. Electronic voting systems are one example of a use case that can be improved by the block-chain technology. We therefore, try to apply block-chain technology to our electoral process in order to improve the security of e-voting in Nigeria. This paper proposed block-chain based electronic voting in order to have safe, free, fair, and transparent elections in Nigeria. Finally, we recommend this system to be absorbed by Independent National Electoral Commission for reliable, effective and efficient electoral system.
... The registration method, the type of implemented framework, and whether it is a conceptual or implemented framework are outlined in Table 5. Most of the proposed systems that address the anonymity concern follow either a theoretical approach [48], [53], [56], [64], or with an implemented system [31]. Tarasov This article has been accepted for publication in IEEE Access. ...
... This is the author's version which has not been fully edited and content may change prior to final publication. Quantum blockchain [53] Quantum computation [53] Auditablity Internal Permissioned blockchain [61] Vote calculation algorithm [61] Crypto [47] Cryptography [47] Integrity Internal Ethereum [34] ✓ Three-phase system [34] Not mentioned [57] Blind signature [57] Permissioned blockchain [61] External Bitcoin [46] Bitcoin [46] Not mentioned [58] Smart contracts & ATAM [58] Not Mentioned Ethereum [35] ✓ Not mentioned [60] Simple random sample [60] Privacy Internal Blockchain biometrics [43] IoT based system [43] Ethereum [13], [38], [48], [49], [51] Un-linkable signatures (Ring Signature) [51] Not mentioned [57] Blind signature [57] Quantum blockchain [54] Quantum-assisted blockchain [54] External Bitcoin [45] Private blockchain [45] Ethereum [31], [36] ✓ Two-phase verification [ Security Internal Not mentioned [57], [60] Simple random sample [60] Blockchain biometrics (fingerprint) [44] Biometrics (fingerprint) [44] Ethereum [13], [48], [50], [51] Biometrics [13], [48] Quantum blockchain [54] Quantum-assisted blockchain [54] ZCash [64] Cryptography [64] External Not mentioned [45], [55], [56], [58], [59] Improved JP Cruz & Y Kaji algorithm [45] Ethereum [31], [36]- [38] ✓ Encrypted voter ID & name & vote count [37] Not mentioned ...
... This is the author's version which has not been fully edited and content may change prior to final publication. Quantum blockchain [53] Quantum computation [53] Auditablity Internal Permissioned blockchain [61] Vote calculation algorithm [61] Crypto [47] Cryptography [47] Integrity Internal Ethereum [34] ✓ Three-phase system [34] Not mentioned [57] Blind signature [57] Permissioned blockchain [61] External Bitcoin [46] Bitcoin [46] Not mentioned [58] Smart contracts & ATAM [58] Not Mentioned Ethereum [35] ✓ Not mentioned [60] Simple random sample [60] Privacy Internal Blockchain biometrics [43] IoT based system [43] Ethereum [13], [38], [48], [49], [51] Un-linkable signatures (Ring Signature) [51] Not mentioned [57] Blind signature [57] Quantum blockchain [54] Quantum-assisted blockchain [54] External Bitcoin [45] Private blockchain [45] Ethereum [31], [36] ✓ Two-phase verification [ Security Internal Not mentioned [57], [60] Simple random sample [60] Blockchain biometrics (fingerprint) [44] Biometrics (fingerprint) [44] Ethereum [13], [48], [50], [51] Biometrics [13], [48] Quantum blockchain [54] Quantum-assisted blockchain [54] ZCash [64] Cryptography [64] External Not mentioned [45], [55], [56], [58], [59] Improved JP Cruz & Y Kaji algorithm [45] Ethereum [31], [36]- [38] ✓ Encrypted voter ID & name & vote count [37] Not mentioned ...
Full-text available
The utilization of electronic voting systems for the election of public offices is becoming widespread globally. This trend can be attributed to the benefits provided by these systems, including remote voting capabilities and accelerated vote counting. Furthermore, electronic voting systems offer improved privacy and enhanced protection against voting bias. Blockchain technology enhances the robustness of the voting process through its immutable vote storage mechanism, thereby reducing the threat of vote tampering and safeguarding the legitimacy of elections. This technology has been adopted by countries such as Germany, Russia, Estonia, and Switzerland for use in their e-voting systems. This study provides a comprehensive overview of the blockchain-based e-voting systems currently being implemented by various countries and companies and proposed for academic research. Additionally, this study analyzes the challenges faced by blockchain e-voting systems and identifies areas for future research to enhance the trustworthiness of such systems.
... Here are some of the authors using Bitcoin in their research, such as [7,24,128,128,149,150,156,164]. [138,166,174,175,179] In the services sector, with 29 articles, Ethereum is the first most popular Blockchain system, as below [123,181]. Ethereum is a decentralized platform that is open-source and can be accessed anywhere globally (Ethereum Foundation, 2014). It operates on both a public and a private Blockchain architecture. ...
... Research Article Examination of evaluation criteria [175,184] Scalability testing (nodes, transactions per second, response time) [182,185] Performance tests (blocks per hour, blocks per day, transaction latency, transaction throughput) [123,176] Security test/analysis (vulnerability towards specific types of attacks) [125,181] Cost evaluation [127,171] Performance tests are a type of method test in which the authors verify the performance of their solution in the real world. It involves load testing and monitoring the time it takes to complete various election processes, such as voter registration, setup, and ballot casting and tallying. ...
... This equation, which is based on public-key cryptography, is beneficial due to its efficiency (PKC). ECC is used to produce keys, resulting in far more minor keys than the typical key generated by digital signature [129,181]. Some studies claim that ECDSA is more efficient than RSA when signing and decrypting, but that it is slower when verifying signatures and encrypting data. ...
Full-text available
Electronic voting systems must find solutions to various issues with authentication, data privacy and integrity, transparency, and verifiability. On the other hand, Blockchain technology offers an innovative solution to many of these problems. The scalability of Blockchain has arisen as a fundamental barrier to realizing the promise of this technology, especially in electronic voting. This study seeks to highlight the solutions regarding scalable Blockchain-based electronic voting systems and the issues linked with them while also attempting to foresee future developments. A systematic literature review (SLR) was used to complete the task, leading to the selection of 76 articles in the English language from 01.01.2017 to 31.03.2022 from the famous databases. This SLR was conducted to identify well-known proposals, their implementations, verification methods, various cryptographic solutions in previous research to evaluate cost and time. It also identifies performance parameters, the primary advantages and obstacles presented by different systems, and the most common approaches for Blockchain scalability. In addition, it outlines several possible research avenues for developing a scalable electronic voting system based on Blockchain technology. This research helps future research before proposing or developing any solutions to keep in mind all the voting requirements, merits, and demerits of the proposed solutions and provides further guidelines for scalable voting solutions.
... Many conventional offline services, such as voting, mail, and payments, are migrating online due to the rapid development of the Internet and information technologies [1]. Evoting is an area of research which is attracting significant attention. ...
... Input: voter id Output: V ID v ,invalid() 1 Access v = f alse; 2 candidates = candidates; 3 if (voter id ∈ candidates) then 4 Access v = true; 5 Token v = (timestamp, expDate, Access v ); Time and gas cost: In order to determine the number of units of gas required by PVPBC to perform voter registration, we measured the gas required to deploy the smart contract as part of voter registration for 10 contracts. We repeated each experiment 30 times for each contract, and report the average time in seconds and cost for each contract. ...
Full-text available
Privacy and verifiability are crucial security requirements in e-voting systems and combining them is considered to be a challenge given that they seem to be contradictory. On one hand, privacy means that cast votes cannot be traced to the corresponding voters. On the other hand, linkability of voters and their votes is a requirement of verifiability which has the consequence that} a voter is able to check their vote in the election result. These two contradictory features can be addressed by adopting privacy-preserving cryptographic primitives, which at the same time as achieving privacy, achieve verifiability. Many end-to-end schemes that support verifiability and privacy have the need for some voter action. This makes ballot casting more complex for voters. We propose the PVPBC voting system, which is an e-voting system that preserves privacy and verifiability without affecting voter usability. The PVPBC voting system uses an effective and distributed method of authorization, which is based on revocable anonymity, by making use of a permissioned distributed ledger and smart contract. In addition, the underlying PVPBC voting system satisfies election verifiability using the Selene voting scheme. The Selene protocol is a verifiable e-voting protocol. It publishes votes in plaintext accompanied by tracking numbers. This enables voters to confirm that their votes have been captured correctly by the system. Numerical experiments support the claim that PVPBC scales well as a function of the number of voters and candidates. In particular, PVPBC's authorization time increases linearly as a function of the population size. The average latency associated with accessing the system also increases linearly with the voter population size. The latency incurred when a valid authentication transaction is created and sent on the DLT network is 6.275 ms. Empirical results suggest that the cost in GBP for casting and storing an encrypted ballot alongside a tracker commitment is a linear function of the number of candidates, which is an attractive aspect of PVPBC.
... A distributed blockchain voting system does not assume a trusted authority to validate the results and the integrity of the voting is enforced by the voters themselves (Moura and Gomes, 2017). Riemann and Grumbach (2017) have highlighted the need for a distributed voting protocol using a cryptographic algorithm that could limit the power of authorities in online voting protocols (Tarasov and Tewari, 2017). So far, only few distributed online voting protocols have been proposed and even less are fully distributed (Noizat, 2015;Kubjas, 2017). ...
... Land Administration Metadata Searching: 35 Screening: 8 Kaczorowska, 2019; Vos et al., 2017;Bhatia et al., 2019;Müller and Seifert, 2018;Stefanovic et al., 2018;Lemieux, 2017;Leible et al, 2019;Kombe et al, 2017 e-voting Metadata Searching: 35 Screening: 11 Riemann and Grumbach, 2017;Shaheen et al., 2017;Noizat, 2015;Moura and Gomes, 2017;Kubjas, 2017;Schulz and Schafer, 2017;Boucher, 2016;Johnson et al., 2017;Nair et al., 2015;Hsiao et al., 2017;Tarasov and Tewari, 2017 Smart cities use different technologies and infrastructure transparency for public administration by using blockchain that acts as a tool for decentralized and distributed applications (Dapps). The smart city blockchain governance relates to a collective infrastructure that supports multiple blockchain platforms, Hyperledger fabric, and Multichain for permissioned Dapps running on smart contracts. ...
Full-text available
A smart city is a relatively new socio-technical notion related to sustainable and intelligent urban life. During the past decade, numerous smart city initiatives have been implemented around the world as a test bench for a sustainable economy. However, as big data grows in smart economies, there is a great concern about security along with a sense of trustiness for the controlling authorities of these data depositories. Blockchain is a sharing economy technology that reshapes the smart cities' terrain having immune records, public consensus, and security mechanisms that decentralize control to all citizens and government organizations. This work provides a systematic literature review of blockchain-based applications across the governance of smart cities. The paper discusses and organizes use cases from seventy-nine selected papers into smart city governance using a component-based analysis to classify the use of blockchain smart city platforms and distributed applications in smart governance.
... Blockchain technology possesses numerous benefits which include its transparency, integrity, and betterplaced security over other available systems. Its potential to effectively record and compute election results with a lesser probability of any third party tampering or interfering with the process has drastically increased its demand for the electioneering process [26]. There are basic concepts within blockchain technology that are significant for voting systems and are discussed below. ...
Full-text available
Multiple reported and proved cases of fraud and manipulation have caused electoral results to be questioned and sometimes openly rejected, undermining democracy in Nigeria. The study suggests blockchain technology to address electoral issues in Nigeria because of the technology's transparency, end-to-end verifiability, auditability, privacy, anonymity, immutability, and provenance which make it a promising voting system alternative. The study proposed a blockchain-backed voting system architecture that employs its unique methods to validate voters and allows them to vote easily, protecting their privacy and lowering election security threats. The study also analyses blockchain technology's use in electoral processes using PESTLE analysis and highlighted it challenges. The report argues blockchain-powered e-voting will improve elections and democracy in Nigeria.
... However, governments are hesitant towards these approaches because of security concerns and people's lower technological awareness. However, a safe electronic voting system maintains transparency and security to the necessary level and reduces these expenditures, while also boosting the legitimacy of election outcomes (Tarasov and Tewari, 2017). ...
Conference Paper
Full-text available
Voting is a process of group decision-making or opinion-gathering that can be utilized to resolve any ideological disagreements. Voting on paper is still the most popular method. However, this traditional method of collecting votes is quite expensive and employs paper ballots. As a solution to this, a very secure and transparent solution is a necessity, which should also ensure the privacy of the participants. An e-voting system can be taken into consideration as a remedy to the problems that the traditional voting system currently has, and one of the technologies that is most suited for use in highly secure situations like this is blockchain. A hashing technique serves to strengthen the security of a blockchain, which is a decentralized system. Peer-to-Peer networks and a decentralized timestamping server make it difficult to manipulate or alter the data in this system. In this paper, we are presenting a safe voting system that was created using blockchain technology that allows voters to select one candidate from an existing group for major elections (e.g.: presidencies) and general elections. In this system, we used the Ethereum network, Ganache blockchain and the Solidity programming language to create and test an example e-voting application as a smart contract for the Ethereum network. The records of ballots and votes will eventually be stored on the Ethereum blockchain. Voting requests are handled by the consensus of all Ethereum nodes and can be made by users straight from their Ethereum wallets. This agreement offers an open environment for electronic voting. With the help of this system, voting may be done more securely and affordably online.
... On the other hand, the village head supporting group will maintain a strategic position and control natural Page | 158 resources beneficial to many people. The disunity of society can occur in the absence of secrecy and independence of the organizers of the village head election (Tarasov & Tewari, 2017). ...
Full-text available
This article describes the intervention of the Sleman local government in village administration, especially in implementing the e-voting village head election. The argument of the Sleman local government is that the e-voting device for the election of the village head is smart, fast, and accurate. The author rejects this argument, because of the involvement of 59 state civil servants as the main technical team. The involvement of ASN in the election of e-voting village heads indicates that the independence of the organizers is lost. The involvement of ASN in the election of lurah has violated Law No. 16/2014, article 32. This research method uses an exploratory qualitative approach combined with governmentality. Primary data collection was done through interviews and observations. Secondary data was collected through mapping journals and books. After the data is collected, validation checks are carried out with the principle of triangulation. Data analysis was carried out by combining theory and field data. The results of the study indicate that there are non-independent ASNs that can create a pseudo-legitimacy for the results of the lurah election.
The blockchain methodology utilizes cryptographic hashes to establish end-to-end demonstration to facilitate security for votes. The aim of the project is to establish a successful voting methodology with the help of blockchain mechanism. With this mechanism, every vote is reserved as a new block and gets updated in the database. The system assures that voting system maintains the one person, one-vote (democracy) principle. This is accomplished by matching the voter's unique face biometric at the start of each voting attempt to avoid double voting. In this, we have created an online voting system through blockchain methodology which is used to solve the issues that are faced by the pre-developed methodology. For each unique vote, different enactment is done. Miners will reject a vote if it is suspected as being malicious. Blockchain mechanism used here makes the vote trustworthy and reliable, and it will also aid to raise the number of voters besides it enhances trust toward the government. In this project, we apply the hash function using SHA—256 algorithms for secure password hashing. It is necessary to have unique hash for every vote that is being recorded by cryptographic hash by which each vote can be verified distinctly. This characteristic facilitates the general voting process’s verifiability. In addition to this, the vote that is being counted is more secure and not an individual including the operator knows about the details of the vote that is being recorded.KeywordsVotingFace biometricBlockchainPollingResult prediction
This book concentrates on the sustainable applications of the Blockchain Technology across multiple latest computational knowledge domains. It covers the feasible and practical collaboration of Blockchain Technology with latest Sustainable Smart Computing Technologies. It will target the vast applications of Blockchain in the field of Internet of Things, Artificial Intelligence, and Cybersecurity. The book effectively provides satisfactory information about the essentials of Blockchain and IoT to a typical pursuer alongside encouraging an examination researcher to distinguish some modern issue regions that rise up out of the intermingling of the two advancements. Besides, the creators talk about pertinent application zones, for example, smart city, e-social insurance, and so forth along the course of the book. • Covers the recent advancements in Blockchain technology • Discusses the applications of Blockchain technology for real life problems • Address the challenges related to implementation of Blockchain technology • Includes case studies • Includes the latest trends and area of research in Blockchain Technology This book is primarily aimed at graduates, researchers and professions working in the field of blockchain technology.
Full-text available
An argument system for NP is a proof system that allows efficient verification of NP statements, given proofs produced by an untrusted yet computationally-bounded prover. Such a system is non-interactive and publicly-verifiable if, after a trusted party publishes a proving key and a verification key, anyone can use the proving key to generate non-interactive proofs for adaptively-chosen NP statements, and proofs can be verified by anyone by using the verification key. We present an implementation of a publicly-verifiable non-interactive argument system for NP. The system, moreover, is a zero-knowledge proof-of-knowledge. It directly proves correct executions of programs on TinyRAM, a nondeterministic random-access machine tailored for efficient verification. Given a program P and time bound T, the system allows for proving correct execution of P, on any input x, for up to T steps, after a one-time setup requiring \(\tilde{O}(|P| \cdot T)\) cryptographic operations. An honest prover requires \(\tilde{O}(|P| \cdot T)\) cryptographic operations to generate such a proof, while proof verification can be performed with only O(|x|) cryptographic operations. This system can be used to prove the correct execution of C programs, using our TinyRAM port of the GCC compiler. This yields a zero-knowledge Succinct Non-interactive ARgument of Knowledge (zk-SNARK) for program executions, in the preprocessing model — a powerful solution for delegating NP computations, with several features not achieved by previously-implemented primitives. Our approach builds on recent theoretical progress in the area. We present efficiency improvements and implementations of two main ingredients: 1 Given a C program, we produce a circuit whose satisfiability encodes the correctness of execution of the program. Leveraging nondeterminism, the generated circuit’s size is merely quasilinear in the size of the computation. In particular, we efficiently handle arbitrary and data-dependent loops, control flow, and memory accesses. This is in contrast with existing “circuit generators”, which in the general case produce circuits of quadratic size. 2 Given a linear PCP for verifying satisfiability of circuits, we produce a corresponding SNARK. We construct such a linear PCP (which, moreover, is zero-knowledge and very efficient) by building and improving on recent work on quadratic arithmetic programs.
Full-text available
The Pr\^et \`a Voter cryptographic voting system was designed to be flexible and to offer voters a familiar and easy voting experience. In this paper we present a case study of our efforts to adapt Pr\^et \`a Voter to the idiosyncrasies of elections in the Australian state of Victoria. This technical report includes general background, user experience and details of the cryptographic protocols and human processes. We explain the problems, present solutions, then analyse their security properties and explain how they tie in to other design decisions. We hope this will be an interesting case study on the application of end-to-end verifiable voting protocols to real elections. This is the 10th February 2014 version of "Draft Technical Report for VEC vVote System". We now place this version on the record, following the external review of the VEC vVote system. The team involved in developing the vVote design described in this report were: Craig Burton, Chris Culnane, James Heather, Rui Joaquim, Peter Y. A. Ryan, Steve Schneider and Vanessa Teague.
Full-text available
STAR-Vote is a collaboration between a number of academics and the Travis County (Austin), Texas elections office, which currently uses a DRE voting system and previously used an optical scan voting system. STAR-Vote represents a rare opportunity for a variety of sophisticated technologies, such as end-to-end cryptography and risk limiting audits, to be designed into a new voting system, from scratch, with a variety of real world constraints, such as election-day vote centers that must support thousands of ballot styles and run all day in the event of a power failure. This paper describes the current design of STAR-Vote which is now largely settled and whose development will soon begin.
Full-text available
In March 2009, the Université catholique de Louvain elected its President using a custom deployment of the Helios web-based open-audit voting system. Out of 25,000 potential voters, 5000 registered, and almost 4000 voted in each round of the election. The precision of the voting system turned out to be crucial: in the first round, the leader came short of winning the election by only 2 votes. In this work, we document the new version of Helios used in this election, the specifics of the UCL deployment, and the lessons learned in this deployment. We offer suggestions on running future open-audit elections. We note at least one interesting conclusion: while it is often assumed that open-audit voting will lead to more complaints and potentially a denial-of-service attack on the auditing process, we found that, instead, complaints are likely to be more easily handled in open-audit elections because evidence and counter-evidence can be presented.
Conference Paper
We present security vulnerabilities in the remote voting system Helios. We propose Apollo, a modified version of Helios, which addresses these vulnerabilities and could improve the feasibility of internet voting. In particular, we note that Apollo does not possess Helios’ major known vulnerability, where a dishonest voting terminal can change the vote after it obtains the voter’s credential. With Apollo-lite, votes not authorized by the voter are detected by the public and prevented from being included in the tally. The full version of Apollo enables a voter to prove that her vote was changed. We also describe a very simple protocol for the voter to interact with any devices she employs to check on the voting system, to enable frequent and easy auditing of encryptions and checking of the bulletin board.
Helios is a web-based open-audit voting system de-signed using state of the art web technologies and ad-vanced cryptographic techniques to provide integrity of ballots and voter secrecy in an insecure Internet envi-ronment. In this paper, we demonstrate a simple at-tack against Helios 2.0 that takes advantage of the fact that every candidate in Helios can provide a URL refer-ring to his/her candidacy statement. A malicious can-didate, who wishes to win a Helios-managed election, uploads a specially crafted PDF file containing a candi-dacy statement to his/her website. The attack is then trig-gered against each voter who is using a vulnerable ma-chine. The security of the machine is undermined, e.g., when the voter visits the attacker's webpage. In essence, we exploit Adobe Acrobat/Reader's vulnerabilities to in-stall a malicious browser extension on the voters' ma-chines. Such an extension provides an opportunity for an attacker which may fool the voter (using Social Engi-neering) into accepting a hacked ballot. Due to our attack Helios 2.0 was upgraded to Helios 3.0. We discuss gen-eralizations and the impact of the latest upgrade of Helios on security. We also discuss defences against this attack, generalizations and the impact of the latest upgrade of Helios on security.
We construct a universally verifiable, cryptographic vote casting protocol that enables each voter to determine with high certainty via a receipt that her choices (intended votes) have been accurately represented in the input to a public tally. However, since the receipt, in isolation, can represent a choice for any candidate with equal probability, it does not enable vote buying or coercion. The key to making this possible is that the totality of information that the voter uses to convince herself of encrypted ballot integrity includes temporal information that is only available at the time the ballot is cast. We assume that, as with conventional voting systems, the act of casting takes place in a private environment – i.e. the "poll booth." Under this assumption then, the scheme, in conjunction with a universally verifiable tabulation protocol, provides an end-to-end verifiable, secret vote receipt based election protocol that is coercion free. Intrinsically, the protocol is unconditionally secure, although for the sake of usability, the commitment of data is likely to be implemented via a secure one-way hash. The security of such an implementation would then depend on the one-way property of the hash function employed. The scheme requires no more computation or data processing from the voter than is performed by a bank customer at a typical ATM. Thus, it is very practical.
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.