Development of a Distributed Blockchain eVoting System
Ishaku Liti Awalu Park Hung Kook
Computer Science Department Computer Science Department
Sangmyung University Seoul Sangmyung University Seoul
South Korea South Korea
+82 102 8624557 +82 109 1541509
engrliti@yahoo.com parkh@smu.ac.kr
ABSTRACT
Over the years, elections at different levels are the subject of
many disputes, consolidation and reaffirmation of confidence in
different leaders. These elections range from either boardroom
elections, local elections to national elections. Correspondingly,
electioneering as an institutional process has transformed with
both technological advancements as well political sophistication.
Blockchain as a nascent technology has ushered in a range of
opportunities in different sectors such as finance, real estate,
supply chain management, medical records, elections etc. In this
paper, we leveraged on some of the key characteristics of
Blockchain technology in form of immutability, auditability,
confidentiality, transparency, decentralization etc to develop a
Blockchain eVoting network system that can be utilized for
geographically dispersed elections. Key users of the system or
actors were isolated and their interactions with the system
identified using Use Case Methodology. The system actors are the
voters, miners that consists of Universities and public libraries,
central authority, candidates and the voters. The different stages
of an election process such as pre-election, registration of both
candidates and voters, voting/balloting, tallying and auditing were
equally enumerated. The interactions of the actors with the system
were equally captured, analyzed and used to develop the
conceptual system. The proposed system is made up of a
multichain Blockchain network, an arbitration server, distributed
database, an interactive, multi-device graphic user interface GUI,
and an application server. To engender anonymity, a combination
of Digital Signature and Secure Hash Algorithm SHA was
proposed, also Proof of Work PoW was the proposed consensus
algorithm. The identified stages of the election were evaluated
against the requirements of an eVoting system. The proposed
system was found to satisfy the requirements of an eVoting
system such as transparency, privacy, scalability, receipt freeness,
security, integrity, accuracy, auditable etc.
CCS Concepts
• General and reference➝Cross-computing tools and
techniques➝Design
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. Copyrights
for components of this work owned by others than ACM must be
honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee.
Request permissions from Permissions@acm.org.
ICEME 2019, July 15–17, 2019, Beijing, China.
© 2019 Association for Computing Machinery.
ACM ISBN 978-1-4503-7219-0/19/07…$15.00.
DOI: https://doi.org/10.1145/3345035.3345080
207
Joa San Lim
Computer Science Department
Sangmyung University Seoul
South Korea
+82 103 2342035
jslim@smu.ac.kr
Keywords
Blockchain, eVoting, Multichain, Elections.
1. INTRODUCTION
Modes and methods of monitoring citizens‘ opinions and
decisions are often conveyed in form of elections or referendums
conducted through democratically accepted voting processes.
Groups of individuals (which range from a small group up to
national sizes) employ voting as a method to indicate the group‘s
formal decision-making process either to select an individual into
a leadership position or to accept or reject a political position or
proposition. In other circumstances, it is used as a process of
reinforcing or affirming a leadership or proposition. The history of
contemporary formal elections can be traced as far back as the
17th century [1]. Its emergence is mainly attributed to the
adoption of representative government systems in the western
countries and its corresponding evolution has witness significant
transformations in terms` 244 of the processes and methods,
legislations, technology etc. These transformations are often
geared towards engendering inclusiveness and acceptability by
stimulating trust in the public. This is often translated in form of
reform acts to increase certain social factors such as, inclusiveness
e.g adults suffrage [2], women suffrage [3], universal suffrage [4]
or to expand the size of electorate, e.g 1832 reform act in Britain.
Some reforms were directed towards changing the voting system
that translates into collective decisions e.g plurality systems [5],
majority systems [6], proportional representation systems [7],
hybrid systems etc. These are often expressed in ‗first-pass-post‘,
‗winner-takes-all‘, ‘alternate-votes‘ etc. Another area that has
witness significant transformation is the balloting method.
Historically, balloting started from the use of broken pieces of
pottery in ancient Greece, palm leaves in India, to modern day
paper system of balloting and more recently the use of electronic
devices. The variety of electronic devices used in balloting
includes, optical scan devices, punch card devices, mechanical
machine devices, direct recording systems, public network direct
recording machines etc. Most times equipped to ballot marking
devices are transmitting devices or tallies that act as central
tabulators.
Ingrained in every voting process are the sociological factors that
affect voters‘ trusts, response, turnout and ultimately the
legitimacy of the process [8]. Added to these are the idiosyncratic
factors such as social groupings, of the voters, habitats, cultural
beliefs, personalities, occupations, educational level, income level,
gender etc [9]. Other influencing factors are, level of elections,
type of voting system to be used, agenda of the election,
ideological polarity between contesting entities, frequency of
election etc. other semi intangible factors include partisan de-
alignment and cognitive mobilization [10]. Unfortunately, over
the years, election processes have been marred with several
anomalies e.g electorate manipulation, voter and agent
intimidation, vote buying, turnout buying, ballot tempering, proxy
voter misuse etc [11]. Majority of the transformations and novel
advances in the voting system have been geared towards reducing
electoral fraud, increasing inclusiveness, improving security,
engendering privacy etc. With technology promising to
adequately address these myriad of issues, many countries or
organizations have adopted electronic voting systems either in full
or in part.
Again, these eVoting systems have proven to be vulnerable to so
many challenges such as security and conventional voting
vulnerabilities. More recently, the introduction of the blockchain
technology and its successful implementation in the Bitcoin
technology has encouraged indepth research into its application in
numerous areas like government, AI, IoT etc[12]. Blockchain‘s
inherent characteristics of security, immutability, auditability,
transparency has prompted research in harnessing its potentials in
voting systems [13], [14]. A few startup companies have
developed blockchain eVoting systems e.g Agora, FollowMyVote
etc. In addition, there has been recent attempts in national election
in Estonia and at a micro scale in countries like South Korea and
Sierra Leone. Nevertheless, most implementations are for small
elections and in most circumstances, it is for boardroom elections.
Consequently, we propose a concept for the implementation of
blockchain eVoting system for national elections using a
decentralized architecture that consists of a group of decentralized
university and government libraries as trusted miners. Our
proposed technological arhitecture utilizes a series of server-client
models that supports online decentralized, remote elements with a
multichain blockchain as the backbone. The rest of the paper
consists of background and introduction to eVoting and
blockchain technology, part three is the Use Case Methodology of
the system, discussion on the several components and
implementation of the system. Part four is the limitation and
further research, while part five and six are the conclusion and
references used respectively.
2. INTRODUCTION TO eVOTING
SYSTEMS
There has been significant debate over the origin of eVoting
systems as well as the actions behind its adoption [15], however,
recorded historical archives included the U.S patent 90,646 by
Thomas A. Edisson in 1869 for patent of an election ‗Recorder‘,
that was billed to be used by the US congress election [16].
eVoting refers to the use of computers and all the technological
elements of a computerized system to conduct and cast votes in an
election, survey, referendum or polls. eVoting systems permits
users(voters) to utilize an electronic ballot system to transmit
votes cast to election authorities for collation. This is often
conducted over an internet network. The electronic voting or
eVoting aggregates a set of technologies that ultimately tries to
address the challenges often faced while utilizing the conventional
manual election process. These issues range from security,
convenience, efficiency, cost etc[17]. These eVoting systems
present certain opportunities that tend to foster ties in form of
increased democratic homogeneity between stakeholders such as
voters, electorates, politicians, civil societies etc [18][19][20].
The choice of an eVoting system is dependent on several factors
such as the type of election, i.e political or nonpolitical,
constitutional provisions of the country or as guided by some rules
and regulations. Others are scale of the elections, spread,
geographical disparity etc. Above is necessary because, the
208
processes require different security and technological
considerations. This is especially important in terms of physical
security as well as equipment, software and hardware security. In
addition to security considerations, the choice of electronic
equipment and system design is dependent on the following
factors.
Authenticity •Integrity •Accuracy •Privacy •Security • Democracy
• Mobility • Convenience • Practical • In-coercion • Verifiability •
Transparency •Uniqueness •Scalability • Reliability •Efficiency
•Receipt freeness.
2.1 Design Considerations of the eVoting
System
The design considerations require that, the system should be
designed in such a way that, only eligible voters can have the
ability to cast their votes. Also, the system should be designed in
such a way that, the votes cannot be altered after they have been
cast i.e immutability. Additionally, the system should be designed
to have the ability to identify and accurately count all valid votes.
Furthermore, the system should be designed to have the ability of
allowing a voter cast his vote anonymously i.e votes cannot be
traced back to a specific voter. The system should provide the
adequate security that will prevent tampering or changing of any
vote cast. Finally, the system should be designed to have the
ability to accommodate all eligible voters and the capability to
prevent any voter from casting multiple votes. Factors like
mobility and convenience are mainly attributed to distributed or
geographically dispersed elections, hence eVoting systems are
required to be location neutral. This requirement gives eVoting
systems especially online elections great advantages against the
conventionally available voting systems.
2.2 Overview of Blockchain Technology
A blockchain can simply be viewed as a ledger system that stores
its transactions in blocks, where the blocks of these transactions
form a chain. The first major implementation of blockchain was in
2009 by [21]. Due to its unique key characteristics such as
persistency, auditability, decentralization and anonymity, it has
experienced tremendous successes in several application areas
such as finance, healthcare, IoT, public services, reputation
systems, security services, etc[22]. Its robust security features
implements several, proven secure technologies like
cryptographic hash function, consensus algorithms, digital
signatures etc. Its decentralized feature eliminates a central
management authority thereby reducing 3 cost of deployment and
improving its efficiency. Since its most popular implementation in
finance in form of cryptocurrency as BitCoin, a plethora of
different, yet similar implementations have emerged, e.g LiteCoin,
Ethereum, Ripple etc. Blockchain technology is predicted to be
potentially, the most disruptive technology yet of the century [23].
Already, there are evident technological disruptions due to smart
contracts [24] and in IoT systems [25].
2.3 Blockchain Features
2.3.1 Persistency
The persistency feature of the blockchain is due to its temper-
resistant property, mainly because each recorded transaction in a
blockchain network must be confirmed. In addition, it will be
difficult to temper with the contents of a block in a blockchain
because all the transactions in a broadcasted block must be
validated by the nodes in the blockchain network [26].
2.3.2 Auditability
The blockchain is auditable because a timestamp is used to record
all validated transactions, hence the nodes in the network can be
used to verify validated transactions by tracing it to the previous
record. The auditability feature of a blockchain makes the data in
the blockchain transparent. Due to this feature, all transactions can
be traced by conducting iterative search on the blocks [27].
2.3.3 Anonymity
The blockchain network provides anonymity to users because the
users use generated addresses in conducting transactions and other
interactions in a blockchain network as opposed to personal
details. Therefore, a user can use multiple address just to remain
anonymous and prevent identity exposure [28].
2.3.4 Decentralization
As earlier highlighted, the blockchain is a decentralized network
that uses a peer-to-peer transaction network, hence it does not
require a central server to coordinate and administer the
transactions. This feature, reduces the performance and cost of
implementing blockchains both in terms of operational costs as
well as setup cost [29].
Figure 1. Block architecture.
Figure 2. Blockchain architecture.
2.4 Schemes of Blockchain
[30], Categorized the blockchain taxonomy into three different
classes; public, private and consortium blockchain. In Public
blockchain systems, each node has read permission as such
transactions are visible to all the nodes in the network. Similarly,
209
all nodes in the public blockchain are part of the consensus
determination protocol and any interested user can join the
consensus process. This feature, on the other hand impinge on the
efficiency of public blockchains due to high latency and an
attendant transaction throughput. As opposed to the much touted
feature of blockchain systems being decentralized, private
blockchain systems are centralized as such all or part of the
parameters are controlled by a central administering authority.
Only certified nodes are permissioned to be part of the consensus
process. Additionally, due to the centralization of the consensus
determination, the private blockchain systems are more efficient.
With respect to read permission, the administrating authority
holds full rights to permit reading of transactions in both
consortium and private blockchain systems. In consortium
blockchain systems, not all the nodes partake in the consensus
determination. Due to the limited number of the nodes permitted
to join the consortium blockchain system, they are more efficient
as it will take little time to reach consensus. Also, due to
centralization of both consortium and private blockchain systems,
Immutability, another advantage feature of blockchain systems
can be tempered with.
2.5 Blockchain Architecture
Every blockchain has a set of validation rules, therefore, the block
version shows the validation rules the block conforms to. The
hash is a 256-bit reference to the previous block. This helps in
traceability. The timestamp shows the time of the transaction and
the nBits shows the hash target value, while the nonce is directly
related to the calculated value of the hash. Fig 1 and F. 2 shows
the main structures of a block and the blockchain respectively.
2.6 Consensus Algorithm
Consensus algorithms are protocols employed by blockchain to
ensure all ledgers in the nodes in the blockchain network are
persistently consistent. The Byzantine General Problem is used to
maintain this consistency in the blockchain‘s decentralized
networks and trustless environment [31]. Common consensus
algorithms deployed by blockchain networks are;
1) Proof of work (PoW)
a) HashCash
i) Double iterated SHA256(SHA-3)
ii) Scrypt (internal cash-, Scrypt-n, scrypt-jane)
iii) Blake-256
iv) HEFTY1
v) CryptoNight
b) Momentum birthday collision
c) cuckoo cycle
2) Proof of X
a) Proof of Stake (PoS)
b) Proof of Burn
3) Proof of Activity (PoA)
4) Practical Byzantine Fault Tolerance (PBFT)
5) Delegated Proof of Stake (DPoS)
6) Distributed Byzantine Fault Tolerance
2.6.1 Proof of work
As the algorithm deployed by bitcoin and ethreum, it is the most
popular of the consensus algorithms. The strength of proof of
work lies in its cryptographically secure hash function that
requires a complex computational process as a form of
authentication. The scheme of proof of work considers a
consensus by obtaining a calculated hash value by miners‘ nodes,
that is equal or less than a constantly adjusted set hash value. This
process involves calculation, authentication and validation of the
hash value. The calculation involves variation of the nuances
value to obtained the desired set value or a figure less than the set
value, then all the nodes in the blockchain as the case may be with
respect to structure of deployment, must authenticate the value.
Thereafter, to mitigate fraud, the transaction in the mined block
will be validated. The proof of work, is incentivized, e.g
provisioning of Bitcoins as the case of Bitcoins [21]. Other
incentives protocols as proposed by some researchers include
Proof of Burn, Primecoin [32]. The authentication process, takes
the longest blockchain as the authentic chain. Since the network is
decentralized, forks and orphaning of chains in the blockchain is
possible, due to the phenomenon called branching. In blockchain,
generation of new blocks is regulated e.g 10 mins and 17s for
bitcoin and ethereum respectively [33].
2.6.2 Proof of stake
The proof of stake scheme involves demanding miners to proof
ownership of some form of stake e.g currency as opposed to
finding some nonce in the proof of work scheme. The stake in the
proof of stake is one area that is currently undergoing intense
research e.g age of coin in peercoin, proof of capacity in burtscoin.
This is evident with the myriad of proposals as well as
deployments in the stakes in the proof of stake e.g peercoin,
blackcoin, ethreum‘s casper etc [32]. [34]. Proof of stake schemes
were devised to be more energy efficient, therefore the absence of
computing power demand exposes the system to certain security
risks and vulnerabilities. Proof of stake security strategy is based
on the philosophy that assumes, miners with more stakes in the
network are less likely to attack the network. However, those with
more stakes are likely to dominate the network, thereby
engendering an unfair system [35].
2.6.3 Proof of activity
Proof of activity as proposed by [36], leverages upon the
advantages of booth proof of work and proof of stake. The proof
of activity validation scheme requires a certain number of miners
to collectively sign the block. The number of signing miners is
created in such a way that, major stakeholders do not retain the
sole rights of block creation.
2.6.4 Delegated proof of stake
The delegated proof of stake DPoS is a variant of proof stake and
currently deployed in bitshares [36], the delegated proof of stake
uses representative nodes for the validation of new blocks, thereby
making the validation process more efficient. This scheme ensures
some form of democracy in the validation process, as inefficient
or untrusted nodes can easily be replaced by new ones. Also, like
other schemes, the turnaround time for block creation as well as
the size of the block can be continuously altered.
2.6.5 Practical byzantine fault tolerance
The practical byzantine fault tolerant PBFT scheme is as deployed
by Hyperledger fabric [37]. The PBFT uses a voting system in a
three round voting phases to process new blocks. The phases are,
pre-prepared, prepared and commit. The scheme requires
transactions to be sanction by a primary node. The primary node
is determined by set guidelines and transitioning from one phase
to another often requires a 2/3 majority vote. In a similar manner,
Tendermint [38] uses a three phase voting system as given by pre-
vote, pre-commit and commit with a proposer as opposed to a
primary node in the PBFT. However, just like the PBFT, the
proposer must be known to the nodes in the network as it has the
responsibility of broadcasting of new blocks to the network. Other
protocols that deploy the byzantine agreement scheme are the
Antshares [39]. Just like the delegated proof of stake that relies on
210
delegated nodes, the stellar consensus protocol SCP [40], also
follows the byzantine agreement scheme. Currently there is
significant research into consensus algorithms with emergent
consensus algorithms e.g Greedy Heaviest Observed Sub-tree
GHOST, peer-to-peer blockchain, PeerCensus etc.
Considering the variability based on the divergent advantages as
well as shortcomings of these consensus algorithms, [41]
conducted a comparative study on the consensus algorithms based
on three criteria, i.e tolerated power of adversary, node identity
management and energy efficiency. the study noted that, while
PoW relies on computing power for tolerated power of adversary,
PoS uses stake, DPoS uses no of validators and tendermint utilizes
byzantine voting power. Also, the study added that, PoS, and
DPOS are partially energy efficient, while PBFT and tendermint
are energy efficient whereas PoW has a lot of energy overhead.
3. SYSTEM DEVELOPMENT
3.1 Blockchain Voting Use Case Methodology
The concept of use cases as created by [42] has evolved to its
recent definition that describes it as sequences of actions
performed by a system that can be observed by an actor [43]. As
common with use case methodology in systems development, our
proposed system is made up of the following elements.
3.1.1 Actors
This takes stock of all the key players otherwise known as actors
in the system. The actors can be either within or outside the
boundaries of the system and their interactions with the system or
with other actors. In our proposed system, the actors are;
• Trusted Central Authority
• Trusted Miners
• Candidates to be elected
• Voter
3.1.2 Use case packages
This is the contextual hierarchical representation of the system. Its
main purpose is to enhance readability, especially in mega
projects where the use cases can be grouped by subjects. In our
proposed system we opted for a very simplistic view of the system.
3.1.3 Use case diagrams
These diagrams give a pictorial or graphical view of the system. It
gives the relationships between the actors and use cases as well as
the interrelationships between the different use cases. In our case,
the use case diagrams are represented in the figures Fig 3 and Fig
4 for the Pre-Election and Voting respectively. There are other
elements that are contained in the use case methodology such as
use case views, use case texts etc. due to the adoption of the
simplistic view of our system we limit our use case methodology
elements to use case model diagrams as well as the interactions
with the identified actors.
Figure 3. Pre-election use case
 3.2.2 The application server
The application server or app server provides a model for a
comprehensive service layer. These applications servers execute
programs scripts and routines that provide access to server
applications or server side logic. This application server will be
used for several functions in the proposed system, viz
1) Manage all the applications like access to the authentication,
arbitration server and the blockchain
2) Creation of a dynamically generated user Interface in browser
for the user to interact with the system

Figure 4. Election use case 3) Act as a remote GUI

3.2 The Proposed System Specifically, the application server deploys a web gateway
The proposed system implements a client-server architecture with application that manages the different clients HTTP requests to
the following parts. the applications services. Usually the web gateway utilizes a file
transfer network manager to manage HTTP protocol clients. An
• A user interface (Graphic User Interface) added advantage of the web gateway is that it keeps a log of all of
• Arbitration Server file uploads and file transfers that pass through the web gate. The
• Application Server (This includes the authentication server) architecture uses a web agent just like the IBM MQMFT (MQ
• Authentication Server Managed File Transfer) web Agent, which is installed in the
• Remote Database application server. Once a stakeholder (voter, candidate, trusted
• Private Blockchain agent) generates a request, the web gateway application sets up a
pervasive connection to the logger database and return the status
The activities of the system are; of the stakeholder to the client. The web agent is responsible for
• Voter registration receiving the registration and voting requests from voters,
• Voting candidates and authenticating agencies. The scripts which can be
• Tallying developed in either PHP, Java etc reside in a temporary storage
• Dispute resolution area, which are then transferred to the managed file transfer
network. Depending on the request use case, this is then
3.2.1 The user interface transferred to the arbitration server that routes the request to either
The user interface is to provide the voter, candidates as well as the the blockchain or the authentication server. In our proposed
central national authority with the graphic user interface GUI to system, for added security, the application server retains a logger
interact with the system. Since, the proposed system is designed to database which is isolated from the central voter database. the
use different types of devices (e.g mobile, standalone and Application Server, houses the authentication server as such, it is
dedicated systems) to interact with the election systems, there is a not separately shown in Fig. 6
need for the GUI to be dynamic and cross platform independent.
3.2.3 Arbitration server
Considering the system will be remotely deployed and multiple
devices with different platforms will be utilized in the
electioneering process, therefore, there is a dire need to provide
certain efficiencies such as load balancing, code compatibility,
connection management, scalability and failure recovery, as such,
an arbitration server will be utilized. The arbitration server will be
responsible for checking the clients platforms, codes and
requirements and then connecting it to the appropriate application
server that is compatible with the clients requirements. This is
especially essential because these applications are dealing with a
common datastore. Consequently, the arbitration servers are the
initial access points with which the clients will interact with. In
our proposed system, the arbitration server will connect to the
datastore and have an internal server lookup table that all
registered servers will be recorded and the table will continuously
be updated dynamically. Additionally, the arbitration server
lookup table will contain a list of the server unique server ID, host
address, standardized codes and port number.

3.2.4 Authentication server

As indicated earlier, the authentication server is hosted as an
application on the application server, hence it is not indicated on
Figure 5. Functions. the the election diagram in Fig 6. Most secure web based
applications require users to be authenticated, this is essentially
important due to increased security concerns [44] in a dynamic

211
content environment. Majority of web application servers support
user authentication, which restricts access to certain web pages or
the entire websites e.g ecommerce or subscription websites.
Currently, common authentication schemes utilize a basic or
digest authentication scheme, which uses username and password
scheme or user-agent-sever challenge respectively. Our proposed
system will use a distributed authentication service model, this
again is against the backdrop of memory requirements and load
balancing. The proposed system will utilize a dispatcher-based
authentication in which an associated protected string is used to
specify the realms and schemes for the different categories of
stakeholders. This is especially important as it will logically
separate the stakeholders within the system. This system will
minimize the potential performance issues. For example, some
authentication servers deploy an in memory model, which some
vendors such as CORBA use a virtual object to abstract the usage
and increase performance.

3.3 The Voting Process

3.3.1 Pre-Election
Registration: Generally, this is the first encounter of all the
stakeholders with system, hence there is need for all to be
adequately registered and captured within their roles. The
different categories of identified stakeholders that need to register
with the system are thus;
• The trusted central national authority
• Trusted miners
• The candidates to be elected
• The voter
3.3.2 The trusted central national authority
The trusted national authority is the main administrator of the
system and will be given such privileges. These privileges include
the registration of all the other stakeholders as well as
management of the system in functions such as tallying and
authentication of voters. However, since the blockchain operates
in a decentralized peer-to-peer network, it is expected that it is
going to be micro self-administering. The central authority only
sets rules such as commit time, block size, consensus algorithm,
verification and audit of trusted miners and candidates
respectively.
3.3.3 The trusted miners
These are the miners that will be responsible for approving blocks
as well as broadcasting approved blocks within the network. In
our proposed system, the Trusted Miners consists of a network of
state owned Libraries and natinal universities computing
resources. The trusted central authority will be a miner in the
peer-to-peer network, this is essential for the trusted central
authority to monitor the activities of the blockchain
Figure 6. The election system.
3.3.4 Pre-Election: The candidates to be elected
The registration credentials of the candidates to be elected will be
hard coded on the system by the trusted central authority. To
engender transparency, the system provides an interface where the
candidates to be elected can view and monitor the voting on the
blockchain as it progresses. On the flip side, this provision has the
potential of triggering the candidates to work towards influencing
the votes for or against a particular candidate. However, this is a
trade-off between confidentiality of the voting process and
transparency. Our proposed system‘s bias is tilted towards
transparency because one of the key offerings of blockchain
technology is to provide transparent, immutable transaction.
3.3.5 Pre-Election: Voter registration
This procedure is the initial stage and the first interaction that the
voter is expected to have with the proposed voting system. The
voter is expected to register his biometrics (finger prints). Once a
voter is registered with the system that is using his biometrics,
national identity number, date of birth, name and location, the
voter will be issued a unique ID number. All the information will
be recorded on the central database. Then Unique ID and the
biometric information will be encrypted and stored separately.
Since it is a national election, there is a need to limit the voters to
only citizens of the country, as such, the registered voter database
will be compared with the national citizens database, so that aliens
can be automatically eliminated from the voter database.
Additionally, it is recommended that, the database be updated
from time to time in order to eliminate dead people. A critical
function of the above, is to avoid impersonation and multiple
voting. In our proposed system, the voter registers remotely using
the GUI provided on any of the devices i.e mobile, computers,
voter kiosks etc. As earlier stated, the GUI will be cross platform
i.e it is adaptable to legacy machines, general computers as well
as other hand held devices such as mobile smart phones.

3.4 Voting
3.4.1 Voting: Voter authentication
In our proposed system, since this enables the voter to vote
remotely using any device of convenience, the voter must be

212
authenticated before voting. The voter will supply his biometrics,
in this case finger prints as well as the unique ID issued to the
voter at the point of registration. This information is encrypted
and transmitted to the database and checked against the stored
encrypted information in the database. The encryption is
necessary since untrusted networks and systems are used in the
system. Additionally the authentication processes is routed
throughout the arbitration server that coordinate with the
authentication server to check the database and authenticate the
voter.
3.4.2 Voting: Balloting
After authenticating, the voter‘s status on the GUI will change to a
valid voter, thereafter the arbitration server will request for the
voting page from the application server. Each voter is allocated
digital assets in form of digital currency that will be spent on
electable candidates of his choice. The vote is depicted as an
actual spend or transaction between the voter and the candidates
on the blockchain. Once the voter expends his digital asset (vote)
on a candidate, the session is closed. A another unique number is
issued to the voter to depict a successful transaction (vote). This
unique number is generated from the hash of the combination of
initial voter unique ID, name, name of candidate voted for and the
header number of the previous voter. This will help the central
trusted authority in tracing anomalies or audits. Since, the unique
ID is based on a hash value it cannot be traced by third parties,
thereby granting partial confidentiality of the vote, which is a
critical requirement of a voting system. The trust on the element
of confidentiality is hinged on the trust of the trusted central
national authority. In our system, multiple votes is not possible, as
such aspects like double spend can be curtailed by coding in form
of smart contracts that allow only one fixed spend per candidate
for every voter.
3.5 Tallying
This stage aggregates the total votes cast for each candidate in
order to declare the winner of the election. Since blockchain
provides a transparent system where everyone can see the votes
cast as the trusted miners verify and add consensus blocks to the
blockchain network, we utilize trusted miners that will not reveal
the pattern of the votes during the voting process except to the
permissioned trusted miners. Again, the confidentially of this is
equally hinged on the trust on the trusted miners. The system is
configured to generate a report of votes cast after the election is
completed. This is necessary as there is a specific time set for the
voting process to be completed. Once that time is reached the
system is configured to automatically generate the aggregate
report of the total votes per candidate and the winner.
3.6 Auditing
As initially highlighted, there are so many parties working
independently in the proposed system, therefore, it is important
that a designed set of rules are followed to achieve success of the
blockchain Voting system. These rules will be used in conflict
resolution or when anomalies arise from the system. A clear
advantage of blockchain technology is its auditability in addition
to other features such as reliability, data integrity and anonymity.
The unique ID issued to the voter after successfully casting his
vote can be used to confirm the vote as well as audit the vote since
the unique ID is linked to the hash of the previous vote cast.
3.7 The Blockchain
In our proposal, the blockchain is made up of trusted nodes of
miners which in our case is a distributed network of
213
nationally/state owned universities and government-public
libraries. Each of the members of the network of trusted miners
hold independent copies of the voting database. Also, each of
these trusted miners/nodes is assigned a public key/addresses as
administered by the central trusted national authority, however,
the corresponding private keys are only known by the individual
miners/nodes. The network is created in such a way that, each of
the miners/nodes can generate an independent transaction,
however, in order to ascertain the origin of the transaction, the
generating node/miner must digitally signed using the originators
private key. The distributed peer-to-peer network is used for block
propagation, block confirmation and block timestamping. in our
proposed system, we utilize a multichain blockchain
3.7.1 The multichain blockchain
The multichain blockchain is a private-permissioned, off the
shelve, blockchain, it has a simple to use API and currently
supports linux, Mac and windows servers. Multichain blockchain
was created to from the Bitcoin core and was designed to address
some of the limitations of bitcoin such as, limited capacity,
transaction cost, irrelevant data, mining risks, poor privacy and
openness [45], [46], [47]. The multichain blockchain adopts user
permissions in an integrated manner to address openness and
privacy issues associated with the mining of bitcoin core. The
scheme utilized include the following
• Introduction of controls by limiting transactions to only those
that are permitted
• Eliminating proof of work mining requirements
• Other issues that relate to scalability are addressed by setting
controls to limit parameters such as. Block size and permissible
transactions.
• Limiting the view of transactions within the blocks to only a
select few participants.
3.7.2 Transactions/Votes
From our scheme, the transactions are in form of votes and as
mentioned earlier, these votes are sent in encrypted forms to the
arbitration server that sends it to the blockchain. The identity of
the voter and the security of the vote is managed using public key
cryptography. Private keys are generated randomly but are
mathematically related to the public key/address and the vote. The
vote in form of funds transfer can only be accessed by signing it
with the private key.
3.7.3 The blocks
With each candidate having a blockchain on the core of the
multichain, the creation of the blocks is conducted through an
extended handshake process by two nodes/miners in the
multichain blockchain. The process is as below
• Using a permitted list, the intending connecting nodes present
their public address
• Each of the intending connecting nodes crosscheck the presented
public addresses against its copy of the permitted list
• A challenge message is exchanged between the nodes
• The messages are signed using the corresponding private keys
• A peer-to-peer connection is established, on the other hand, if
the corresponding signed messages are wrong, the process of
handshake is aborted.
From above, an advantage of the multichain blockchain is that, the
network can be controlled by selecting which member can reserve
the rights to either send or receive transactions. Additionally, the
network can also permit public view of the vote but restrict the
nodes that can conduct the blockchain transactions [48]. Since our
proposed system is distributed, several distributed aggregation
centers will be utilized but only a selected trusted few will be
permitted nodes.
3.7.4 The mining
For ease of administration, these selected trusted nodes will have
special metadata privileges for revoke/grant of transactions. In
multichain, these privileges are often reserved for the miner of the
genesis block and are often accompanied with administrative
responsibilities to manage nodes with common address outputs.
Any changes must be approved or voted by a minimum number of
administrators in the multichain blockchain, hence, this acts as
backstop security against fork blockchains taking over the system.
Privileges are contained in the transactions metadata so as to
ensure a fast and efficient propagation within the blockchain
network. The mining procedure is as below
• Transactions in the blocks are ordered according to the
permissioned changes
• Then the total number of miners is generated after the
application of the permissioned changes
• The spacing is calculated by the multiplication of the number of
miners in above to the mining diversity.
• The block is then either approved or considered invalid by
evaluating (spacing-1). if the value of (spacing-1) is not 11 equal
to the previous block generated by the generating miner it is
considered invalid.
In most circumstances, multichain blockchains implement the
round-robing schedule, which is a process that schedules the
generation of blocks in a rotational basis. Hence in our proposed
system, a round-robin effect will be implemented so that, the
permitted miners will generate blocks in a scheduled manner.
Also, another advantage of using a multichain blockchain is that,
the mining diversity will be adjusted to cater for the capacity of
the miners. In our prosed system, the mining diversity is set to
0.75, which as suggested by [48] is the efficient and safe mining
diversity value. Unfortunately, despite 1 being the desired value, it
is avoided because, it can result into blockchain freeze due to the
occasional inactivity of some of the miners.
3.7.5 Consensus algorithm
Even though, multichain blockchain initial deployments support
the proof of work consensus algorithm, nonetheless, the default
transaction fees in a mutlichain blockchain is set to zero.
Therefore, in our proposed Voting system, the there is no
compensation or reward for mining since the computational cost
negligible as well as the proposed miners are all public
organizations. This is because, they are all geared towards
ensuring the smooth functioning of the electoral process.
3.7.6 Deployment scenario
We proposed a centralized currency settlement deployment as
presented in the [48]), as opposed to the consumer facing reward
scheme, bond issuance and peer-to-peer. This is because, the
deployment utilizes a central authority that acts as a custodian and
administrator of the blockchain. It manages the mining and miners
by distributing the different functions in order to ensure
robustness as well as minimize redundancy in the multichain
214
blockchain. Much as this deployment would accept a zero value
of mining diversity since the miners are trusted, but to ensure
strict compliance we still maintain the value of 0.75. The central
authority, grants the permissions for the trusted miners to connect
and form a network. Additionally, the central authority tokenizes
the votes which act as the transactions that will be mined by the
trusted miners. In a transparent peer-to-peer network, the trusted
central national authority, is responsible for settling the votes
transactions. A major advantage of this deployment scenario is
that, it leverages on the propagation efficiency of a dense peer-to-
peer networked system that is fault tolerant. Finally, a critical
advantage is that, the multichain can be coded to provide a
feedback messaging that will alert a voter of successful
transaction (vote). However, to ensure confidentially and
safeguard the receipt freeness requirement of the Voting systems,
we propose coding the message to simply indicate success of the
transaction(vote) without any reference to the candidate voted for
or identity of the voter.
4. LIMITATION AND FURTHER
RESEARCH
The proposed system assumed full trust in the central trusted
authority and the trusted miners, this clearly goes against
decentralize characteristics of a blockchain and its self-
administration characteristics. Therefore, further research should
endeavor to develop a self-administrating system that does not
need to be managed by a central authority. Additionally, the paper
is a conceptual proposition, as such, there is a need to implement
or run-through the concept. However, most blockchain networks
are live and at the moment, it is not feasible to run-through the
system or even evaluate the system. Furthermore, there are no
evaluation parameters for blockchain voting systems, further
research is recommended into developing the parameters of
evaluating an blockchain voting system. This will aid in the
standardization of blockchain voting systems.
Captions should be Times New Roman 9-point bold. They should
be numbered (e.g., ―Table 1‖ or ―Figure 2‖), please note that the
word for Table and Figure are spelled out. Figure‘s captions
should be centered beneath the image or picture, and Table
captions should be centered above the table body.
5. CONCLUSION
The In this paper, we proposed a blockchain Voting system using
Use Case Methodology. The identified actors are the Trusted
Central Authority that coordinates and administers the election.
There are also, the candidates that present themselves up for an
election. Other actors are the voters that vote for the individual
candidates and the group of individual minerstrusted. The voting
system itself is made up of a dynamic multi-platform Graphic
User Interface, an arbitration server, authentication, application
server, database and a blockchain of trusted miners. The trusted
central authority is responsible for the registration of both the
candidates as well as the voters. The candidates present their
credentials to be accredited by the Trusted Central Authority. On
the other hand, the voter is registered using his biometrics, name
and date of birth, which is then encrypted, hashed, and used to
generate a unique ID that is issued as the Voter ID to the voter.
On Election Day, the voter is authenticed by the system using a
combination of the systems arbitration and application servers,
against the issued Unique ID and his biometrics. After
authentication, the voter casts his vote using the provided GUI
interface. The vote is registered as a spend transaction on the
blockchain and sent to the Trusted Miners that verify and add the
block using the proof of Work Consensus. The trusted central
authority being part of the trusted miners tallies the final results at
the end of the election and present it to the public. Since all the
trusted miners have copies of the results, they can be verified
using any of the Trusted Miners. Discrepancies can be traced and
resolved since all transactions are linked to one another. The
proposed system leverages on the characteristics of blockchain
technology which include, immutability, verifiability, persistency,
transparency etc..
6. REFERENCES
[1] E. Posada-Carbo, ´Elections before democracy: the History
of Elections in Europe and Latin America. Springer, 2016.
[2] D. H. Close, ―The collapse of resistance to democracy:
conservatives, adult suffrage, and second chamber reform,
1911–1928,‖ The Historical Journal, vol. 20, no. 4, pp. 893–
918, 1977.
[3] C. C. Catt and N. R. Shuler, Woman Suffrage and Politics:
The Inner Story of the Suffrage Movement. C. Scribner‘s
Sons, 1923.
[4] F. I. Michelman, ―Universal resident suffrage: A liberal
defense,‖ U. Pa. L. Rev., vol. 130, p. 1581, 1981.
[5] D. L. Horowitz, ―Comparing democratic systems,‖ Journal of
Democracy, vol. 1, no. 4, pp. 73–79, 1990.
[6] A. Blais and R. K. Carty, ―The impact of electoral formulae
on the creation of majority governments,‖ Electoral Studies,
vol. 6, no. 3, pp. 209–218, 1987.
[7] A. Blais, ―The debate over electoral systems,‖ International
Political Science Review, vol. 12, no. 3, pp. 239–260, 1991.
12
[8] H. Rong, ―Farmers‘ petition and erosion of political trust in
government [j],‖ Sociological Studies, vol. 3, pp. 39–55,
2007.
[9] D. R. Kinder, G. S. Adams, and P. W. Gronke, ―Economics
and politics in the 1984 american presidential election,‖
American Journal of Political Science, pp. 491–515, 1989.
[10] C. A. Schriesheim, ―Job satisfaction, attitudes toward unions,
and voting in a union representation election.‖ Journal of
Applied Psychology, vol. 63, no. 5, p. 548, 1978.
[11] V. Bogdanor and D. Butler, Democracy and elections:
electoral systems and their political consequences. CUP
Archive, 1983.
[12] A. Kaushik, A. Choudhary, C. Ektare, D. Thomas, and S.
Akram, ―Blockchain—literature survey,‖ in 2017 2nd IEEE
International Conference on Recent Trends in Electronics,
Information & Communication Technology (RTEICT). IEEE,
2017, pp. 2145–2148.
[13] E. C. Ferrer, ―The blockchain: a new framework for robotic
swarm systems,‖ in Proceedings of the Future Technologies
Conference. Springer, 2018, pp. 1037–1058.
[14] M. Atzori, ―Blockchain technology and decentralized
governance: Is the state still necessary?‖ Available at SSRN
2709713, 2015.
[15] M. Volkamer, Evaluation of electronic voting: requirements
and evaluation procedures to support responsible election
authorities. Springer Science & Business Media, 2009, vol.
30.
215
[16] L. H. Toledo-Pereyra, ―Lessons from thomas alva edison–
the greatest american inventor–to surgical investigators,‖
Journal of Investigative Surgery, vol. 16, no. 4, pp. 185–188,
2003.
[17] O. Kulyk and M. Volkamer, ―Efficiency comparison of
various approaches in e-voting protocols,‖ in International
Conference on Financial Cryptography and Data Security.
Springer, 2016, pp. 209–223.
[18] T. L. Becker, T. D. Becker, and C. D. Slaton, The future of
teledemocracy. Greenwood Publishing Group, 2000.
[19] T. Blair and J. Cunningham, ―Modernising government.
presented to parliament by the prime minister and the
minister for the cabinet office by command of her majesty,‖
Retrieved Genuary, vol. 17, p. 2016, 1999.
[20] T. L. Becker, T. D. Becker, and C. D. Slaton, The future of
teledemocracy. Greenwood Publishing Group, 2000.
[21] S. Nakamoto et al., ―Bitcoin: A peer-to-peer electronic cash
system,‖ 2008.
[22] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang,
―Blockchain challenges and opportunities: a survey,‖
International Journal of Web and Grid Services, vol. 14, no.
4, pp. 352–375, 2018.
[23] K. Schwab, The fourth industrial revolution. Currency, 2017.
[24] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou,
―Hawk: The blockchain model of cryptography and privacy-
preserving smart contracts,‖ in 2016 IEEE symposium on
security and privacy (SP). IEEE, 2016, pp. 839–858.
[25] Y. Zhang and J. Wen, ―An iot electric business model based
on the protocol of bitcoin,‖ in 2015 18th International
Conference on Intelligence in Next Generation Networks.
IEEE, 2015, pp. 184–191.
[26] G. Zyskind, O. Nathan et al., ―Decentralizing privacy: Using
blockchain to protect personal data,‖ in 2015 IEEE Security
and Privacy Workshops. IEEE, 2015, pp. 180–184.
[27] G. Fridgen, S. Radszuwill, N. Urbach, and L. Utz, ―Cross-
organizational workflow management using blockchain
technology-towards applicability, auditability, and
automation,‖ 2018.
[28] M. Moser, ―Anonymity of bitcoin transactions,‖ 2013.
[29] M. Atzori, ―Blockchain technology and decentralized
governance: Is the state still necessary?‖ Available at SSRN
2709713, 2015.
[30] V. Buterin et al., ―A next-generation smart contract and
decentralized application platform,‖ white paper, 2014.
[31] G.-T. Nguyen and K. Kim, ―A survey about consensus
algorithms used in blockchain.‖ Journal of Information
processing systems, vol. 14, no. 1, 2018.
[32] S. King, ―Primecoin: Cryptocurrency with prime number
proof-ofwork,‖ July 7th, 2013.
[33] M. Swan, ―Blockchain temporality: smart contract time
specifiability with blocktime,‖ in International symposium
on rules and rule markup languages for the semantic web.
Springer, 2016, pp. 184–196.
[34] V. Zamfir, ―Introducing casper ―the friendly ghost‖,‖
Ethereum Blog URL: https://blog. ethereum.
org/2015/08/01/introducing-casperfriendly-ghost, 2015.
[35] A. Chepurnoy, ―Interactive proof-of-stake,‖ arXiv preprint
arXiv:1601.00275, 2016.
[36] F. Schuh and D. Larimer, ―Bitshares 2.0: General overview,‖
accessed June-2017. [Online]. Available: http://docs.
bitshares. org/ downloads/bitshares-general. pdf, 2017.
[37] C. Cachin, ―Architecture of the hyperledger blockchain
fabric,‖ in Workshop on distributed cryptocurrencies and
consensus ledgers, vol. 310, 2016.
[38] J. Kwon, ―Tendermint: Consensus without mining,‖
Retrieved May, vol. 18, p. 2017, 2014.
[39] Z. Erik, ―Antshares and the blockchain,‖ URl:
https://cryptorating.eu/whitepapers/NEO/antshares.pdf, 2016.
[40] D. Mazieres, ―The stellar consensus protocol: A federated
model for internet-level consensus,‖ Stellar Development
Foundation, 2015.
[41] M. Vukolic, ―The quest for scalable blockchain fabric: Proof-
of-work vs. ´ bft replication,‖ in International workshop on
open problems in network security. Springer, 2015, pp. 112–
125.
[42] N. Jacobson, D. Butterill, and P. Goering, ―Development of a
framework for knowledge translation: understanding user
context,‖ Journal of health services research & policy, vol. 8,
no. 2, pp. 94–99, 2003.
216
[43] G. Booch, I. Jacobson, and J. Rumbaugh, ―The unified
modeling language reference manual,‖ 1999.
[44] R. Pang and J. Stabile, ―Method and apparatus for
implementing an extensible authentication mechanism in a
web application server,‖ 2002, uS Patent 6,446,204.
[45] K. N. Khaqqi, J. J. Sikorski, K. Hadinoto, and M. Kraft,
―Incorporating seller/buyer reputation-based system in
blockchain-enabled emission trading application,‖ Applied
Energy, vol. 209, pp. 8–19, 2018.
[46] M. Samaniego and R. Deters, ―Internet of smart things-iost:
using blockchain and clips to make things autonomous,‖ in
2017 IEEE international conference on cognitive computing
(ICCC). IEEE, 2017, pp. 9–16.
[47] L. Castaldo and V. Cinque, ―Blockchain-based logging for
the crossborder exchange of ehealth data in europe,‖ in
International ISCIS Security Workshop. Springer, 2018, pp.
46–56.
[48] G. Greenspan, ―Multichain private blockchain-white paper,‖
URl: http://www. multichain. com/download/MultiChain-
White-Paper. pdf, 2015.Yu, Y. T. and Lau, M. F. 2006. A
comparison of MC/DC, MUMCUT and several other
coverage criteria for logical decisions. J. Syst. Softw. 79, 5
(May. 2006), 577-590. DOI=
http://dx.doi.org/10.1016/j.jss.2005.05.030.