Future Generation Computer Systems 105 (2020) 13–26

Contents lists available at ScienceDirect

Future Generation Computer Systems

journal homepage: www.elsevier.com/locate/fgcs

Investigating performance constraints for blockchain based secure

e-voting system
∗
Kashif Mehboob Khan a , Junaid Arshad b , , Muhammad Mubashir Khan c
a
Department of Software Engineering, NED University of Engineering & Technology Karachi, Pakistan
b
School of Computing and Engineering, University of West London, UK
c
Department of Computer Science & IT, NED University of Engineering & Technology Karachi, Pakistan

article info a b s t r a c t

Article history: Voting is one of the fundamental pillars of modern democracy. Continuous efforts have been made
Received 21 April 2019 to strengthen the processes and methods involved to achieve verifiable, transparent voting systems.
Received in revised form 2 September 2019 In recent years, blockchain has been increasingly used to address multi-dimensional challenges across
Accepted 2 November 2019
widespread application domains including healthcare, finance and e-voting. However, achieving an
Available online 9 November 2019
efficient solution via use of blockchain requires consideration of a range of factors such as block
Keywords: generation rate, transaction speed, and block size which have a profound role in determining the
Blockchain overall performance of the solution. Current research into this aspect of blockchain is focused on
E-Government Bitcoin with the objective to achieve comparable performance as of existing online payment systems
Blockchain scalability such as VISA. However, there exists a gap in literature with respect to investigating performance
E-voting
constraints for wider application domains. In this paper, we present our efforts to address this gap
Electronic voting
by presenting a detailed study into performance and scalability constraints for an e-voting system.
Performance constraints
Specifically, we conducted rigorous experimentation with permissioned and permissionless blockchain
settings across different scenarios with respect to voting population, block size, block generation rate
and transaction speed. The experiments highlighted interesting observations with respect to the impact
of these parameters on the overall efficiency and scalability of the e-voting model including trade-offs
between different parameters as well as security and performance.
© 2019 Elsevier B.V. All rights reserved.

1. Introduction Blockchain has attracted significant attention with prominent

applications across finance [2], healthcare [3] and supply chain
Voting is one of the fundamental characteristics of human management systems [4]. A Blockchain resembles a data structure
democracy with continuous efforts made throughout human his- which maintains and shares all the transactions being executed
tory to improve the processes, mechanisms and methods involved through its genesis. It is primarily a distributed decentralized
to conduct voting in a verifiable, transparent and accessible man- database that maintains a complete list of constantly germinating
ner. The advent of Information and Communication Technologies and growing data records secured from unauthorized manip-
(ICT), has brought renewed emphasis on using ICT to facilitate ulation, tampering and revision. Blockchain allows every user
voting processes primarily to enable transparency and acces- to connect to the network, send new transactions to it, verify
sibility. Since its first use as punched-card ballots in 1960’s, transactions and create new blocks [5–7]. Each block is assigned a
e-voting systems have achieved remarkable progress via the in- cryptographic hash (which may also be treated as a fingerprint of
ternet technologies [1] with a range of terminologies used such as the block) that remains valid as long as the data in the block is not
e-voting (using a machine in a polling station), digital voting (use altered. If any changes are made in the block, the cryptographic
of electronic devices such as voting machines) and i-voting (using hash would change immediately indicating a change in the data
web browser to cast vote). The focus of our research is on using which may be due to a malicious activity. Therefore, due to its
advancements in ICT via electronic machines in polling stations strong foundations in cryptography, blockchain has been increas-
as part of a public vote (commonly called General Election in the ingly used to mitigate against unauthorized transactions across
UK) with the view of investigating challenges in this respect and various domains [7–9].
potential solutions to address them. Electronic voting (e-voting) is one of the emerging applications
of blockchain whereby researchers aim to leverage benefits such
∗ Corresponding author. as integrity, anonymity and non-repudiation which are critical
E-mail address: [email protected] (J. Arshad). for a voting application. Use of blockchain to facilitate e-voting

https://doi.org/10.1016/j.future.2019.11.005
0167-739X/© 2019 Elsevier B.V. All rights reserved.
14 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26

applications has received significant attention recently with ef- level of difficulty to mine a block, the block-size and average
forts such as [10–13] leveraging blockchain technology to achieve block creation time. These experiments reveal significant trade-
secure and verifiable voting. Specifically, blockchain enables cre- off between transaction block size, block generation rate, and
ating a pool of voters by generating unique physical addresses transaction processing speed. Furthermore, scenarios with per-
which can be used to represent the voter population and the missioned blockchain aim to simulate e-voting environments
candidates. A single voting token may be issued to every voter with large number of voters such as public voting systems. The
corresponding to their unique address thereby representing a experimentation involves evaluation of the system with respect
unique voter. Similarly, some addresses are reserved to identify to the volume of transactions as well as the number of remote
candidates which may then be used to transfer voting token from client voting machines operating from different network locations
voter’s addresses. The voting transaction generated by the voter to observe impact of such constraints on the overall performance
contains the transfer of voting token to his desired candidate as of a blockchain based system.
a receiver’s address. This transaction becomes part of the main We present the findings from our investigation in this pa-
blockchain when confirmed into a block by one of the designated per with the aim to aid research community to understand the
miners. The connected node to the seed node then takes part in caveats with respect to achieving scalable blockchain based solu-
the data synchronization process to update the public ledger of tions as well as expanding new horizons in this respect. Conse-
blockchain along with its local copy. This process enables achiev- quently, through our investigation, we are able to provide a rig-
ing strong non-repudiation for the e-voting application as the orous assessment of the capability of the underlying blockchain
record of the transaction becomes immutable due to consensus fabric and identify potential trade-offs required to achieve desired
protocol acknowledged by all miners. level of performance. Specifically, the paper makes the following
Whilst existing research has focused on leveraging benefits of contributions:
blockchain such as those highlighted above, efforts with respect
to in-depth investigation into challenges surrounding scalability • A thorough investigation is performed aimed at identifying
of blockchain based solutions are primarily limited to cryptocur- and highlighting significance of parameters such as block
rencies such as Bitcoin. For instance, [14] is one of leading efforts size, block generation rate and transaction processing speed
to investigate scalability constraints of Bitcoin where authors in- to achieve scalable solutions using blockchain technology.
vestigated practical limitations in achieving performance level ex- • Rigorous experimentation is conducted which aims to iden-
pected with respect to attributes including time required to mine tify and highlight performance constraints for both per-
a transaction into the block of the longest blockchain, processing missioned and permissionless blockchain settings which can
rate for number of transactions, time required to download and potentially aid researchers in wide range of application do-
run a full copy of blockchain from scratch in order to participate mains.
in the process of transaction validation, costs incurred due to pur- • A novel blockchain based e-voting system is presented
chasing, maintaining and working of resources (such as electricity which investigates the capabilities of blockchain technology
utilization). The motivation for this and other similar research is to achieve e-voting for permissioned and permissionless
the comparison with mainstream online payment system such voting models.
as VISA. Specifically, VISA can process up to 2000 transactions
per second whereas Bitcoin system is limited to 7 transactions Rest of the paper is organized as follows: Section 2 presents
per second primarily due to limits on block generation rate and a background for e-voting systems providing important context
transaction processing speed [15–17]. to cutting edge research within this domain. Section 3 presents
However, wider applications of blockchain mentioned earlier a summary of existing work with respect to scalability research
use platforms such as Ethereum [18] and Multichain [19] that are within blockchain identifying the gap addressed by this research.
fundamentally different from Bitcoin with respect to factors such Section 4 presents an overview of the proposed e-voting system
as block generation rate, consensus algorithm, transaction process followed by details of implementation and experimentation in
rate and block size. These parameters have profound role in de- Section 5 which also includes details of different scenarios and
termining scalability of a blockchain based solution. Furthermore, an analysis of results observed. Section 6 concludes the paper.
the throughput of a blockchain based system not only depends
upon factors such as the capacity of infrastructure such as hashing 2. Electronic voting
power and memory but also on the type of transactions used
within an application. Additionally, in scenarios such as e-voting Electronic voting has been an area of research focus for many
in public domain, large number of transactions are expected to years by using computing machines and equipment to cast votes
be recorded in blockchain concurrently. Therefore, if the rate of and produce high quality and precise results in accordance with
incoming transactions to the unconfirmed pool of transactions the sentiments of the participating voters. Various attempts have
does not match to rate of confirmation of transactions to the been adopted in practice to support election process through the
blocks by the miners, it can result in significant performance use of ICT. One of the first uses of technology involved casting
overhead as well as delays in transaction confirmation time. Con- vote on paper which were scanned and tallied at every polling cell
sequently, an in-depth investigation is required to identify and on a central server [6,20,21]. Direct Recording Electronic (DRE)
assess challenges with respect to scalability for wider application voting systems were adopted later and have attracted significant
domains such as the one considered in this paper. success in encouraging voters to use this technology. In the case
In view of the above challenges, we conducted a thorough in- of DRE, voters begin their journey by going to their polling place
vestigation into the challenges surrounding scalability of and get their token to vote where they utilize their token at
blockchain based applications in general and blockchain based the voting terminal to vote for their preferred candidate. When
e-voting applications in particular. Our investigation includes ex- the candidate selection procedure is completed, DRE systems
perimentation with a blockchain test-bed hosting an e-voting ap- present the final selection to the voter before ballot casting is
plication focusing on variety of scenarios across permissioned and completed [22].
permissionless blockchain settings. Permissionless setting simu- More recently, Hao et al. [21] proposed a two round protocol
lates environments with smaller number of users adopting a that computes the tally in two rounds without using a private
public blockchain with experimentation varying with respect to channel or a trusted third party. The protocol is efficient in
 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26 15

terms of computation and bandwidth consumption but is nei- to conduct blockchain-based e-voting in New South Wales [27,28]
ther robust nor fair in certain conditions [22]. Dalia et al. [22] and Estonia [31]. The challenges encountered by these voting
proposed a protocol to improve the robustness and fairness of models within the context of implementation with blockchain
the two round protocol. Shahandashti et al. [23] proposed E2E are essentially different primarily due to their inherent charac-
verifiable voting system named DRE-ip (DRE-i with enhanced teristics such as voting population, voting methods and logistic
privacy), that overcomes limitations of DRE-i [24] i.e. instead of considerations. For instance, performance scaling to a large pop-
pre-computing ciphertexts, DRE-ip encrypts the vote on the fly ulation is not a significant concern in boardroom voting where
during voting process. DRE-ip achieves E2E verifiability without typical population is less than 20 voters [32], however this is
TAs, but at the same time provides a significantly stronger privacy a significant challenge for public voting model as the system
guarantee than DRE-i. In [25], end-to-end verifiability is achieved is expected to take into account large number of voters with
through the Mixnet protocol [26] that recovers the plaintext concurrent processing. The volume of voting population at the
ballot in an unlinkable manner by randomizing the ciphertext blockchain layer is significant as it has consequences on fac-
through a chain of mix servers. These approaches perform well tors such as number and characteristics of miners, number and
for end-to-end verifiability without compromising k0the privacy characteristics of validators and mining process.
of voters.
An e-voting system may be broadly classified into two types 3. Related works
facilitating; (i) remote user interaction and (ii) voting station
engagement. With respect to existing work related to investigating per-
Remote user interaction: This model facilitates a voter to vote formance and scalability of blockchain, most of the efforts are
from any remote location utilizing a pre-verified identity such focused at cryptocurrency applications of blockchain such as Bit-
as a card or login credentials. Consequently, a person can vote coin. A primary reason for this is the comparison with existing
from their home using their smartphone or computer to register online payment systems such as VISA which have the capability
to vote using a software or a web application. This voting model to process 2000 transactions per second whereas a Bitcoin system
relies on cutting edge technological advancements to provide can only process 7 transactions per second. A fundamental cause
secure and easy method to use alternative to traditional voting of Bitcoin’s comparatively low performance is due to the block
system thereby helping to reduce human errors. Furthermore, generation rate (currently limited to 10 min) and transaction
voters can be provided a feedback that their vote is counted processing speed. Therefore, existing efforts have emphasized
thereby improving the trust of the voter as well as verifiability enhancing transaction speed of Bitcoin to improve its overall
and non-repudiation. A number of initiatives in this regard have scalability thereby facilitating its wider adoption.
been adopted indicating challenges with respect to security and One of the leading works in this respect is presented by Cro-
correctness of the vote such as those identified by [27,28]. man et al. [14] where authors investigated practical limitations
Voting station engagement: This e-voting model includes sce- in achieving desired performance level with respect to attributes
narios where a voter can vote through a polling station where such as time required to mine a transaction into the block of the
electronic voting systems such as DRE are deployed to facilitate longest blockchain, processing rate for number of transactions,
the voting process. Typically, such machines are connected to the time required to download and run a full copy of blockchain from
Internet to aid the overall voting process. A major advantage of scratch in order to participate in the process of transaction valida-
DRE machines is the significant reduction in the cost as it avoids tion, costs incurred due to purchasing, maintaining and working
using ballot papers. A number of initiatives have been adopted of resources (such as electricity utilization). The investigation in-
by different governments across the world to implement such e- cluded taking into account the performance metrics such as block
voting model such as Estonian i-vote system [29] and Norwegian size, transaction processing speed and block generation rate for
i-voting [30]. However a number of security challenges were Bitcoin. In order to assess the practical limitations, experimenta-
identified to achieve transparent and verifiable execution of these tion with varying settings with respect to transaction processing
systems such as those highlighted in [31]. speed were conducted monitoring effective throughput of the
More recently, distributed ledger technologies such as Bitcoin network. The work presented also acknowledges impact
blockchain have been used to achieve e-voting systems primarily of a scalable blockchain on its security i.e. improving scalabil-
due to their advantages in terms of end-to-end verifiability. ity of blockchain can contribute towards limiting opportunities
With properties such as anonymity, privacy protection and non- for forking, transaction malleability attack, and double spending
repudiation, blockchain is a very attractive alternative to contem- thereby improving overall security of the network.
porary e-voting systems and has been used both for boardroom A fundamental concept within Bitcoin network is the reward
voting as well as public voting (focus of this paper). Within this for miners for correctly mining transactions leading to scenarios
context, McCorry et al. [32] proposed one of the early efforts where greedy miners can affect the overall transaction process-
for implementation of decentralized and self-tallying internet ing within the network by prioritizing transactions with higher
voting protocol over Ethereum blockchain using openvote [24] transaction fee. In this context, Karame et al. [35] and Zheng
e-voting approach as their baseline. Khan et al. in [33] proposed et al. [17] presented efforts to study the behaviour of mining
a more recent secure digital voting system using blockchain with nodes where greedy nodes can skew the mining process towards
Prêt à Voter [34] as the underlying voting approach. Blockchain centralization by attempting to utilize their computing power
enhances the level of transparency as compared to traditional to gain financial rewards. Specifically, [35] also highlighted in-
electronic voting system, primarily due to its decentralized na- teresting relationship between scalability and security through
ture. It bears the tendency to preclude many conventional ways network propagation delays. Due to such delays and utilizing
of fraud which are very common in the manual or traditional Bitcoin network bandwidth, an attacker can cause disruption to
electronic voting system. Furthermore, it is computationally in- the blockchain by attempting to stop new blocks to the victim.
feasible to change any of the blocks, due to the highly complex Block size is another important factor in determining the
formal problem solving required thereby significantly reducing transaction speed within a blockchain network. The block size
the risk of vote manipulation. within Bitcoin blockchain is currently fixed to 1 MB with max-
Although blockchain introduces a range of benefits to e-voting imum 7 transactions allowed per second with an average one
domain, a number of challenges remain as observed in attempts hour required to confirm a transaction. In order to increase the
16 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26

Fig. 1. A blockchain based e-voting architecture.

transaction speed, one approach can be to increase the size of of scalability including Bitcoin-NG [39] and Practical BFT (PBFT)
the block as proposed by Segregated Witness [36]. However as and Sharding transactions.
identified by Zheng et al. [17], if block size is high, it is very likely Among other efforts, Kim et al. [40] define scalability as a
that the generation of new blocks will be very slow potentially function of three dimensional parameters; the transaction pro-
leading to forking. This challenge is also highlighted by Zheng cessing speed, the associated fee, and the volume for repository
et al. in [16] proposing that if the size of the block is increased to of the chain in case of a cryptocurrency application. In particular,
gather more transactions in the block, this may lead the network authors have categorized solutions to improve scalability into
towards centralization as the number of participants with capa- classes i.e. on-chain, off-chain and side-chain. On-chain solu-
bilities to store such volume of data will be less. Consequently, tions include efforts such as Big Block which increases the block
authors highlight the non-trivial challenge to achieve a trade- size as adopted by Bitcoin Unlimited to attain the maximum
off between transactions processing rate and network latency transmission limit reducing cost of the transmission. Although,
thereby achieving scalability without compromising security of a block can contain more transactions however it can increase
the blockchain. propagation delay due to high volume of block size which causes
Furthermore, Xu et al. [15] proposed the implementation of forking. Other on-chain methods discussed include Merkelized
GHOST and Pair-wise ledgers such as R3’s Corda24 however there Abstract Syntax Tree (MAST) [41], recommended in Bitcoin’s BIP-
are significant concerns in their adoption such as availability of 114 and Segregated Witness (SegWit) [36]. Off-Chain approaches
data due to the absence of globally replicated database. In this discussed include Lightning network where a channel is estab-
respect, authors proposed increasing the number of nodes to run lished between two addresses for exchange of transaction that
full copy of decentralized and trust-less blockchain network in uses multi-sign address to create stake for both sender and re-
Bitcoin application to achieve security. ceiver. Channel creation is an on-chain activity and requires a
With respect to on-chain solutions to improve scalability of transaction fee at main blockchain while exchange of transaction
blockchain, Vukoli et al. [37] and Bano et al. [38] presented is off-chain and is not maintained at main blockchain so there
a study into the feasibility of available solutions. Specifically, is neither a transaction fee nor a noticeable waiting time. Side-
Vukoli et al. [37] presented a comparison between two different Chain is another technique for addressing scalability issue where
approaches to achieve consensus among nodes i.e. Proof of Work exchange occurs across blockchain so that different functionali-
(PoW) and Byzantine Fault Tolerance (BFT) replication target- ties across blockchains may be brought together to the blockchain
ing their scalability constraints. Focusing on Bitcoin blockchain, in focus. For instance, using one blockchain based cryptocurrency
authors highlighted block creation rate and block size as key into another blockchain based cryptocurrency to use its features.
parameters to improve scalability of bitcoin. An interesting ob- Using this approach, a Bitcoin can make use of smart contracts
servation from this effort is that PoW based blockchains are more on Ethereum blockchain whereby transactions are valid through
scalable in terms of number of nodes by compromising per- such contracts.
formance unlike BFT based blockchains, however BFT performs Although most of the research into scalability of blockchain
better for smaller number of nodes. Although the effort identifies is focused on Bitcoin, Mattias et al. [42] present an effort fo-
new horizons, it requires discussion on how varying block sizes cused on the applications of blockchain technology in the areas
and block creation rate may reveal strengths and weaknesses other than cryptocurrency. The authors compare performance of
of blockchain in general or with respect to an application in a blockchain network through the spectrum of security vulner-
particular. Furthermore, Bano et al. [38] focused on the design abilities, the impact of scalability and how these are related to
based techniques of blockchain proposed to address the challenge decentralized nature of blockchain.
 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26 17

Fig. 2. High-level illustration of the voting process.

The research presented in this paper is focused on the chal- reject a transaction preventing it to become part of the blockchain
lenge of investigating performance constraints with respect to ledger. In the core polling day activity, the voters, using the voting
scalability of a blockchain. Within our research our focus is on machine (located at the polling station), may cast their vote.
wider application domains with a special use case of e-voting The voting status (whether a vote has been cast successfully or
and therefore not limited to cryptocurrencies such as Bitcoin. not) remains unconfirmed until a miner from the mining group
The research is aided by rigorous experimentation to highlight confirms it and updates the ledger of main blockchain. In this
observations which are important in achieving a scalable solution. way, an immutable collection of voting records start to deposit
In order to observe the constraints of scalability, we performed and link in the form of chains of block through their hashes which
experiments and evaluation with respect to number of attributes may easily be used for counting and tracking of votes.
of blockchain scalability including block size, block generation Our proposed e-voting system is successfully deployed as an e-
rate, the impact of Proof of Work and non-Proof of Work based voting application using Multichain as the blockchain fabric. The
blockchains (public versus private blockchains), on-chain and off- proposed e-voting system achieves the objective of maintaining
chain data storage and fetching of the processed data over the secrecy of voting population, verifying voter entitlement and
network involving network constraints. Our study included large confidentiality of the vote while facilitating user in the process
number of transactions submitted parallel from multiple clients of casting vote. The overall voting process is illustrated in Fig. 2.
aiming to explore relationship between the capacity of the block The voting process starts with the registration of voters as
to accommodate number of transactions and the rate at which unique hashes. In terms of blockchain, these are addresses on
transactions are processed. blockchain that will be used by these voters to transfer their votes
to the candidates. Each voter address is assigned a voter token
4. A blockchain based e-voting system which represents a vote in the system with a voter address only
allocated one token to avoid duplicate voting. Since the domain
We have developed a blockchain based e-voting system for of our research application is voting, the asset here refers to
a vote. Therefore, after creating votes as assets on our private
public voting which is also presented at its initial stage in [33]
blockchain, these voting assets are then allocated to an address
and illustrated in Fig. 1. In this paper, we present an overview
which will act as an authority to transfer the right of vote (by
of our model including interactions between different entities
performing a transaction of moving voting asset) to the eligible
involved to provide context to the experimentation and analysis.
candidates. Using these voter addresses, a list of registered voters
We use our e-voting system as an example scenario to identify
is generated which is used to segregate voters into different
and analyse scalability considerations within a blockchain based
polling stations. Therefore, each polling station will have its own
system.
list of voters (list of valid blockchain addresses) which will be
As presented in Fig. 1, the electoral process requires certain
used by client voting machines at each polling station. In this
tasks to be carried out before the voting can be conducted includ- way, as with the current public voting systems in modern world
ing offline generation of voter addresses, generation of candidate democracies, only a voter registered to vote at a specific polling
addresses, entitling the voters and candidates to participate in station will be able to cast their voter using these client voting
the election process (as per their specified roles) at designated machines at the polling station.
locations. These addresses are then used to cast vote from voters Furthermore, similar to the contemporary public voting sys-
to candidate. The offline activities also involve generation of tems, vote casting activity will be carried out in parallel across
voter list and its distribution to individual voting machines which all designated polling stations simulating scenarios where polling
may specifically be designated for casting votes by the voters stations will have designated e-voting machines to facilitate vot-
to their desired candidates. As with the real-life voting systems, ers. In terms of blockchain, the operation of vote casting is
the proposed permissioned environment only allows participants achieved through a blockchain transaction whereby the voter
with valid rights such as voter, candidates or miners. For instance, token is transferred from a valid voter address to a valid can-
for a voter, rights are granted to receive a voting token from didate address. In order to achieve verifiability, a vote can is
vote issuing authority which is consequently sent to their desired not successfully cast unless it is confirmed by one of miners
candidate. Similarly, a candidate should be allowed to receive the and acknowledged by all the miners (consensus) to maintain an
voting tokens to their address from voters’ addresses. auditable and tampered proof list of voting records. Furthermore,
The status of the voting process relies upon a pool of trusted when all the voters are able to cast their votes, the records from
miners which are responsible for either accepting a voting trans- blockchain can be tallied to produce the result of the vote count
action by adding it to their newly created block or can simply against each candidate.
18 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26

Fig. 3. Blockchain node specification for permissionless setting.

Fig. 4. Initial parameter values for permissionless setting.

5. Implementation and experimentation keep waiting in the pool of unconfirmed transactions which can
ultimately overflow the volume of memory pool of node. This
In order to evaluate our voting model with respect to both situation may cause the blockchain to either respond slowly or
permissionless and permissioned access of blockchain network, become non-responsive. Similarly, in a situation where the blocks
an experimental setup was established as a test bench. The setup are being generated very quickly, it may affect the blockchain sig-
consisted of miners, full blockchain node containing list of candi- nificantly by mining empty blocks without any transactions. This
dates and voters, and a client for submitting voting transactions phenomena is very common in private blockchain and therefore
to the blockchain node. The blockchain was implemented using an important challenge to be addressed.
an open source blockchain platform Multichain using its Alpha Furthermore, different settings were experimented with re-
4 version released in August, 2018. We selected this platform spect to varying values for block size, block creation rate to
as it includes new features for handling streams of data which identify and highlight significant trade-offs between block size,
we plan to use along with voting transactions in the future. The block generation rate and total number of voting transactions
machines for creating blockchain node and client zone were run- per second. Finally, in each of these scenarios, transactions were
ning Windows 10 operating systems with Intel Core i7-7500 CPU carried out to transfer a vote from a voter’s addresses to the
processors. This set up was extended for permissioned blockchain candidate addresses. Based on the output data of these scenarios,
by introducing an additional connected full node to the master response of the blockchain was recorded and analysed in the form
blockchain seed node and introducing number of Java based of graphs analysing transaction mining time and waiting time of
remote clients to the blockchain network facilitating submitting a transaction in the pool.
votes in large numbers from various clients. These Java based
remote clients are capable of communicating to the blockchain 5.1. Experiments with permissionless setting
node by accessing Multichain’s Application Programming Inter-
face (API) through JSON based Remote Procedure Call (RPC) client Our first setup involved a permissionless blockchain setting
to submit their voting transactions into the blockchain after being where all participants had the role of a voter and miner. For this
verified by the miners. setting, we created a population of 10 voters with their wallet
The objective of investigation presented in this paper is to addresses which represents a voting scenario with small number
understand the impact of blockchain engine and its associated of voters such as boardroom. The experiments for this setting
attributes on e-voting architecture presented in the previous have been carried out on setup explained in Fig. 3. Within this
section with the view to identify bottlenecks to achieve optimum setup, we conducted experiments with varying configuration for
performance level. In order to achieve this objective, a thorough blockchain including parameters such as block size, block gener-
investigation was conducted by implementing three different ation rate and the difficulty of the Proof of Work. Once the chain
scenarios each corresponding to different voting model settings was created, it initialized the blockchain with immutable param-
based on the number of voters, candidates and the type of client eters as detailed in Fig. 4 which also presents the blockchain
(local vs. remote) involved. The first two scenarios were imple- configuration for two scenarios for permissionless setting.
mented using a permissionless blockchain with a population of Our aim is to investigate the impact of parameters such as
10 voters where all participants had the privilege to mine the transactions processing per second, transaction size, maximum
votes into the blockchain. However, third scenario was imple- and average number of transactions which can be processed, and
mented as a permissioned blockchain with designated nodes as average block size on key performance indicators. These parame-
miners and validators. This scenario represents a public voting ters are critical in identifying constraints of blockchain process
model where designated bodies are responsible for conducting execution with respect to scalability and consequently on the
fair voting process. application running on blockchain. If the block generation rate is
Although the experimentation includes both permissioned and not compatible with the overall system’s desired output, serious
permissionless blockchain settings, the parameters monitored performance degradation can be experienced. For instance, if
through these experiments were: maximum number of voting block generation rate is too high, there may exist a situation
transactions a block can contain, average number of voting trans- in which too many transactions are kept waiting in the pool of
actions a block currently can host, voting transaction size, max- unconfirmed transactions leading to overflow of the volume of
imum transaction processing speed, and the current operational memory pool of node. This situation may cause the blockchain
transaction processing speed of the system. For instance, if the to either respond slowly or even become unresponsive at all.
blockchain generation rate is not compatible with the overall sys- Similarly, in a situation where the block generation rate is very
tem’s desired output it may lead to serious performance degra- small, blocks are being generated very quickly, which may affect
dation. For instance, if block generation rate is too high, there the blockchain by engaging the blockchain into mining empty
may exist a situation where significant number of transactions block even without having a transaction. Through our experience,
K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26 19

Fig. 5. Voter, candidate and transaction hashes for initial experiments.

Fig. 6. A transaction from voter to candidate.

Fig. 7. Sample voting transaction details for scenario A.

Fig. 8. Final candidate votes in their wallet for scenario A.

20 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26

affect behaviour of this scenario in blockchain. According to the

official documentation of Multichain blockchain, there is no fixed
barrier in limiting the capacity of the pool but nodes may have
constraints in picking up transactions from other nodes. Another
thing to ponder here is about the dependent transactions such
as multiple transactions from the same node address which are
dependent on each other. In this case, there is a possibility that
the subsequent dependent transactions start to arrive earlier than
its previous transaction on which it depends. Consequently, in
this case, the earlier arrived transactions cannot be confirmed
until its previous transaction gets into the block delaying the
transaction.
Fig. 9. Sample voting transaction details for scenario B.
Fig. 12.B represents the arrival of voting transactions at differ-
ent timestamps into the node’s wallet. These transactions were
picked up by the miners to begin the race of mining those
this phenomena is commonly witnessed in private blockchain. transactions first. Therefore the transaction processing depends
Therefore, an optimum level is required to be set to keep a primarily upon the Proof of Work which is performed by the
matching condition of equilibrium between the rate of incoming miner while keeping the average block generation rate constant.
transactions and the rate at which the transactions are mined into An observation from Fig. 12.B is that it is not necessarily impor-
the new blocks. tant that the transactions which arrive earlier to the pool, take
Scenario A: For the first scenario within permissionless shorter time to add to the block even though when the difficulty
blockchain setting, the time interval for adding new blocks to is kept constant among all the transactions.
blockchain was set at 15 s i.e. at a regular interval of 15 s, un- In order to evaluate the throughput of the system, transaction
confirmed transactions will be processed, packed and appended processing speed can be one of the vital factors to consider. In this
to the existing chain of blocks in the form of a new block. In case context, Fig. 12.C demonstrates time consumed by each voting
of this experiment, the miner has been configured to compute transaction in the experiment. Since we have set our target block
on average 216 transactions to add its block. Additionally, the time to 15 s, this means that each block will be generated at
block size is set to 1 MB for this experiment. In order to make an interval of 15 s. This interval is an average time of block
the blockchain up and running, there were a total of 60 blocks at generation which means that if a block is mined much earlier
the start of the blockchain. A sample set of voter, candidate and than the target block time then the rest of the block will be
transaction hashes for this experiment are presented in Fig. 5. mined at a rate to restore the average rate of block generation.
Scenario B: Following on from the initial experiments pre- The difference in transaction delays is due to the time taken by
sented in scenario A, we conducted further experiments using the Proof of Work. The difficulty level has been kept constant
larger block size, increased block generation rate and the required throughout all the experiments so that it may not affect our
amount of bits in Proof of Work was extended to 32 bits. This dataset and we can build a direct relationship between number
implies that on average the miner required 232 hashes to mine of transaction and its processing time to check the scalability of
a block. These variations in the values of the parameters signifi- the system. The total amount of time taken by a transaction to be
cantly affected the overall behaviour of the system. Fig. 4 shows published publicly also depends upon its arrival time (in case of
the parameter values for the experimentation for scenario B. our Multichain platform). For instance, in our experiment where
Let the arrival time of a transaction Tx to be submitted to maximum target block time is 15 s, a transaction arrives into a
unconfirmed pool is represented as Tau, the time taken by node wallet and a block is about to be published within 3 or 4 s to keep
for adding the transaction to its local wallet is represented as the average time of 15 s, the transaction (if it does not depend
Tnw, total time taken for confirmation of transaction from un- upon any unconfirmed transaction) will most likely be published
confirmed pool to enter into blockchain is Tctn and the block in the main blockchain within those 3 or 4 s, provided the block
size is represented by Bs. In this respect, Fig. 7 presents sample size does not exceed the maximum size limit. The situation may
voting transaction details for scenario A whereas Fig. 8 presents be different if the same transaction arrives just moments after the
final candidate votes for scenario A. Similarly, Fig. 9 presents latest block was added.
sample voting transaction details and Fig. 10 presents the final Scenario B: As is evident from Fig. 13.A, the transactions move
candidate votes for scenario B respectively. Furthermore, Fig. 6 instantly to node’s wallet upon arrival. An interesting observation
shows the blockchain output for a transaction from voter to here is that even if the transactions are issued with delay (as
candidate i.e. simulating casting of a vote whereas Fig. 15 shows it is the case of transaction number), it has no impact on the
blockchain output for specification of a block containing a trans- time it takes to move the transaction into wallet. Furthermore,
action. Finally, typical voting asset within the proposed system is in Fig. 13.B, it can be observed that the transactions are being
presented in Fig. 11. confirmed to the same block due to increased block generation
rate which were issued subsequently and also were independent
5.1.1. Analysis and discussion for permissionless setting of each other.
Scenario A: Fig. 12. A shows that new transactions are arriving In order to understand the overall outcomes, we consider
at different timestamps but are added immediately to the node’s Fig. 13.B in the context of Fig. 13.C. The above graph shows
wallet upon arrival. Therefore, as evident from this figure, there is that the transactions arriving late to system are unexpectedly
no delay in the transition of its journey from pool to blockchain. being mined earlier than the previous transaction even though
In order to study this behaviour in the context of throughput and these transactions do not depend upon each other. We believe
blockchain performance (transaction processing speed, maximum primary reason for this occurrence is that the new transactions
number of transactions per block etc.), it may be considered are arriving at a time when there is some time left for the block
that the transaction movement from pool to node’s wallet is to add. Another interesting point here to note is that not only the
not a major factor of consideration for the initial experiments. block can contain more transactions but also that in this setting
However, there are some other (although indirect) factors such the work required by the miner is increased significantly due to
as pool size and number of dependent transactions which may Proof of Work been increased to 32 bits.
 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26 21

Fig. 10. Final candidate votes in their wallet for scenario B.

Fig. 11. Sample voting asset within blockchain.

Fig. 12. (A) Time to add unconfirmed transactions from pool to local wallet, (B) Time taken by miners to confirm transactions into the block (C) Transaction mining
time.

Fig. 13. (A) Time to add unconfirmed transactions from pool to local wallet, (B) Time taken by miners to confirm transactions into the block (C) Transaction mining
time.

Fig. 14. (A) Bd−max = 1 MB, Max.4k transactions/block, (B) Bd−max = 10 MB, Max.40k transactions/block, (C) Bd−max = 100 MB, Max.400k transactions/block, (D)
Bd−max = 1000 MB, Max.4000k transactions/block.
22 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26

Fig. 15. Specification of block containing transaction.

Fig. 16. System specification for e-voting architecture.

Fig. 17. Blockchain setup for experimentation.

5.1.2. Scalability analysis for permissionless setting Therefore, Tn = 266.6 transactions per second.
In order to assess the scalability of the proposed e-voting Through the above calculation, we conclude that the proposed
system, we first use mathematical formulation to evaluate the voting model is capable of supporting transaction speed of up
ability of the proposed system to scale. We represent size of to sixteen thousand voting transactions per minute which is
a voting transaction to be represented by Ts , block generation
envisioned to enable the system to perform effectively for small
rate by Bt , maximum amount of data which can be held by
and medium sized voting environments. However, as identified
the block B(d−max) , and average block size by B(d−av g) . In order
to calculate the maximum number of transactions that can be in the earlier experiment, this represents capacity of the block
accommodated by a block in our system T(s−max) per block and the and the actual number of transactions processed may also vary
average number of transaction T(s−av g) per block, we use standard depending upon the block generation rate.
metrics defined by Multichain platform. Therefore the size of the Similar to above, for scenario B, transaction size is 250B
transaction Ts may be obtained by taking arithmetic sum of all whereas maximum block size B(d−max) is increased to 1 GB to
the hexadecimal characters and dividing the sum by 2 [43]. For assess the impact of larger block size on the transaction pro-
scenario A, the transaction size is 250B and with the maximum cessing speed. Although the larger block size has the capacity
block size set to 1 MB, it can support up to 4000 transactions in a
to accommodate up to 4 000 000 transactions for each block
block. However, an interesting observation is that with average
block size as 516B, the system currently contains an average however our experimentation has revealed the average block size
number of two transactions per block indicating that the block B(d−av g) to be 5468B. Interestingly, this represents a 10-times
size is not used to its full capacity. We believe the reason behind increase compared to the average block size for scenario A and
small number of transactions per block is twofold; (i) due to the therefore indicates a directly proportional relationship between
small (10) voter population of the current system, and (ii) due the maximum block size and average block size. Furthermore,
to the short block generation rate i.e. 15 s. Therefore the setup Bt has been set to 60 s and number of required bits for Proof
is not able to fully utilize the capacity of a block resulting in of Work has been set to 32 bits increasing the difficulty level.
smaller blocks. The above result can also be confirmed from the
However, average transactions per block in this case are recorded
blockchain output in Fig. 15. However, as indicated above, the
to be 21 which is again a 10-times increase on the scenario A.
system has ability to scale to a significantly larger population.
The second parameter we are interested in is the transaction Analysing the values of T(s−max/block) and T(s−av g /block) , it can be
processing speed of our voting system. Let us assume the number seen that by increasing the block size the number of transactions
of transactions per second to be represented by Tn . Mathemati- that can be handled by a block has increased however increasing
cally, Tn can be written as the block generation rate and difficulty level of Proof of Work
did not have significant adverse impact. We present graphical
Tn = B(d−max) /Ts /Bt (1)
analysis of this relationship in Fig. 14. Therefore, we conclude
Substituting the values for block size, transaction size and that block generation rate and block size affect the rate at which
block generation rate, we get; transactions arrive to pool and the rate at which these transaction
Tn = 1000000/250/15 are confirmed to the block.
 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26 23

5.2. Experimentation with permissioned setting

For this phase of experimentation, the setup consisted of min-

ers, full blockchain node containing list of candidates and voters,
and a client for submitting voting transactions to the blockchain
node. These machines for creating blockchain node and client
zone are running Windows 10 operating systems over intel Core
i7-7500 CPU processors. Additionally, we introduced a full node
connected to the master blockchain seed node and a number
of Java based remote clients to the blockchain network to fa-
cilitate large number of voters on various clients. The setup is
summarized in Fig. 16.
The permissioned blockchain was created with 100,000 voters
and designated nodes as miners and observers to simulate a
conventional public voting environment. The parameters mon-
itored through these experiments were; maximum number of
voting transactions a block can contain, average number of voting
transactions a block can host, voting transaction size, maximum
transaction processing speed, and the operational transaction
processing speed of the system.
Furthermore, the blockchain setting for these experiments is Fig. 18. Experimentation specification for permissioned blockchain.
non-Proof of Work and instead uses mining diversity and mining
turnover parameters provided by Multichain platform to achieve
consensus. Specifically, mining diversity defines the proportion
of mining power which is necessary to run blockchain properly. 5.2.1. Scalability analysis for permissioned setting
For these experiments, mining diversity is set to 0.3. Therefore Our experimentation with permissioned blockchain involved
the minimum number of miners required to run the blockchain three different settings varying based on the number of concur-
successfully will be obtained by multiplying the value of mining rent clients involved i.e. one, two and seven concurrent clients
diversity to the number of miners and then round the output to to conduct voting transactions. We present analysis of the results
the closest integer. In our case, this value is found to be value is 3 obtained below.
as the total number of miners which are involved in running the Experiments with one client: Fig. 19 demonstrates peak per-
public voting model is 10 as it is shown in Fig. 16. This implies formance in terms of transaction processing speed when nine
that at least three out of ten miners will have to actively par- thousand voting transactions were cast from one client to the
ticipate in the process of adding a new block to the transaction. blockchain master node. At this stage, the system was operat-
Additionally, mining turnover sets up the scheduling of miners ing at a frequency of 23.01 transactions per second i.e. in this
to get their turns in rotation using a round robin scheme. The case, a single voting transaction took 0.043 s to be mined. In
value of mining turnover lies between 0 and 1 with a value of 1 order to understand its implications with respect to scalability
implying that every miner will be looking to add a block to the of blockchain, block size and its generation rate have a profound
blockchain which may create forks and potentially unnecessary role. For instance, if a transaction arrives shortly before a block is
computational tasks. Similarly if the value is set to 0, then a about to mine, it is likely that it will be mined to the block which
default round robin scheduling algorithm will be followed. For is about to be added to the longest blockchain. Similarly, if the
the current experimentation settings, the value has been set to 0.5 transaction arrives after the latest block has been added to the
to achieve a balance between these two extremes. Consequently, main blockchain, this transaction will have to wait until a miner
Proof of Work is not required by the miners to get their turn and mines it to the next block after the average block generation time
add the proposed block into the blockchain. (fifteen seconds in this case). The impact of block generation rate
Within this setup, voter rights are granted to receive a single can increase when the transactions are constructed and com-
voting token from vote issuing authority and send this voting mitted from multiple remote concurrent clients with network
token to their desired candidate. Similarly, a candidate should latency also a factor. However, the general trend shown in Fig. 19
be allowed to receive the voting tokens to their address which is that the proposed e-voting system shows no limitations with
are expected to be received from voters’ addresses. The process respect to scalability in this case. Even in the worst case, when
in this setup relies upon a pool of trusted miners responsible to transaction speed is 12.71 transactions per second, the e-voting
either accepting a voting transaction by adding it to their newly system looks to be in a very stable state and hence shows strength
created block or reject a transaction restricting it to become a part with respect to scalability. Another important observation is that
of the ledger. this experimentation was conducted using a non-Proof of Work
The experimentation was divided into three different cases based permissioned blockchain where we have a pool of trusted
based on varying number of concurrent clients. Specifically, we and designated miners. Therefore the system suits real mode of
evaluated our e-voting system with one, two and seven con- transaction validation in this context and it does not introduce
current clients where these clients were located on a remote disadvantage of over utilization of electric and computational
machine thereby taking into account network bandwidth and power.
delay. As with the real-life public voting system, the proposed Experiments with two concurrent clients: The second set
system is implemented as a permissioned and controlled envi- of experiments involved two concurrent voting clients with one
ronment so that only designated nodes are able to construct and local client and the other interacting with the e-voting application
commit voting transactions simulating the role of a polling station remotely through a programmable interface. Since the additional
in real-life systems. Figs. 17 and 18. A present specifications remote client is concurrently running on the network, the net-
of blockchain master node used for these experiments whereas work latency has a considerable impact as can be observed from
Fig. 18.B presents a sample voting asset within the proposed the graph in Fig. 20 which represents the average transaction
e-voting system. execution time. Both clients started with the same number of
24 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26

world scenario where overall 222,000 transactions were sent

from seven different voting clients running concurrently across
different remote locations. This scenario introduced a number of
factors including network latency, block generation rate, block
size, increased workload on blockchain master and connected
node that caused variation in response time.
As is evident from Fig. 21, a fluctuation can be observed in
the processing speed of voting transactions. Furthermore, as in
the previous scenarios, this speed is calculated by considering
maximum execution time which is taken by an individual client.
The execution time of individual client to process same number
of transactions is presented in Fig. 21.A. Here, due to network
latency and bulk transaction load on blockchain node, there may
Fig. 19. Tx processing speed vs. number of Tx for one client. arrive a situation where bulk transactions which are generated
by seven different clients may increase memory pool size of
blockchain node in such a way that the incoming flux of transac-
voters and their voting transactions were being processed by tion does not synchronize effectively with the transaction mining
process resulting in a mismatch between these two processes.
the blockchain node with almost same frequency. Later on, due
Therefore, execution time of some clients is greater than the
to potential network latency, transactions started to arrive late
others. However, the system demonstrates to be scalable as the
from the remote client. In this case, empty blocks are mined by
average time taken by an individual transaction is around 0.10 s
the blockchain (Multichain and many other private blockchain
which should be healthy for a voting process to carry on.
platforms use this mechanism to keep the blockchain live while
Summarizing the evaluation we have conducted with permis-
operating at a pre-set block generation rate). This happens in
sioned blockchain, we have observed that with the increase in
case if no transaction is being sent from any client (we did number of concurrent clients, the workload for the blockchain
not observe this to be the case for our experiments). Another master node increases which may result in delays in transactions
interesting possibility can be that the mining nodes picked up committed to the blockchain. Fig. 22 shows a comparison of sys-
transactions which were coming from the first block, in that tem’s throughput in terms of number of transactions which are
case the transaction hashes for first client transactions should processed by an individual client when conducted for case 1, 2,
be present more in the block which caused delay for processing and 3. Comparing case 1 with 2 and 3 in Fig. 22, it can be inferred
transactions of the remote client. By examining the data at the that executing multiple clients in parallel over the network has
blockchain, it was obvious that the miner at that moment picked a noticeable impact on the performance of blockchain. We have
up mostly the transaction from first client while the second client also observed the trade-off represented by block generation rate
transactions were supposed to gather at the pool of unconfirmed and block size and their significance to achieve a scalable solution.
transactions. Furthermore, an interesting observation is the delay caused due
Experiments with seven concurrent clients: The third setting to network connectivity. For instance, analysing the case where
attempts to execute a public voting model simulating a real six thousand voting transactions were executed from a client, the

Fig. 20. Experimentation with two clients: (A) Avg. Tx processing speed, (B) Tx processing time.

Fig. 21. Experimentation with seven remote clients: (A) Avg. Tx processing speed, (B) Tx processing time.
 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26 25

[7] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, 2009,

Cryptography Mailing list at https://metzdowd.com.
[8] D. Kraft, Difficulty control for blockchain-based consensus systems,
Peer-to-Peer Netw. Appl. 9 (2015).
[9] Bonneau Joseph, Felten Edward, Miller Andrew, A. Narayanan, S. Gold,
Bitcoin and Cryptocurrency Technologies, Princeton, 2015.
[10] D. Khoury, E. Kfoury, A. Kassem, H. Harb, Decentralized voting platform
based on ethereum blockchain, 2018, pp. 1–6.
[11] N. Kshetri, J. Voas, Blockchain-enabled e-voting, IEEE Softw. 35 (2018)
95–99.
[12] X. Sun, Q. Wang, P. Kulicki, M. Sopek, A simple voting protocol on quantum
blockchain, Internat. J. Theoret. Phys. (2018).
[13] B. Shahzad, J. Crowcroft, Trustworthy electronic voting using adjusted
blockchain technology, IEEE Access 7 (2019) 24477–24488.
[14] K. Croman, C. Decker, I. Eyal, A.E. Gencer, A. Juels, A. Kosba, A. Miller,
Fig. 22. Comparative summary of Tx speed for case 1, 2 and 3. P. Saxena, E. Shi, E. Gün Sirer, D. Song, R. Wattenhofer, On scaling
decentralized blockchains, in: J. Clark, S. Meiklejohn, P.Y. Ryan, D. Wallach,
M. Brenner, K. Rohloff (Eds.), Financial Cryptography and Data Security,
Springer Berlin Heidelberg, Berlin, Heidelberg, 2016, pp. 106–125.
transaction processing speed is almost similar in case 2 and 3 [15] X. Xu, I. Weber, M. Staples, L. Zhu, J. Bosch, L. Bass, C. Pautasso, P. Rimba,
however when the same number of transactions are executed in A taxonomy of blockchain-based systems for architecture design, in: 2017
IEEE International Conference on Software Architecture (ICSA), 2017, pp.
case 1, the transactions processing speed is almost double which 243–252.
we believe is due to the absence of network delay. [16] Z. Zheng, S. Xie, H. Dai, X. Chen, H. Wang, An overview of blockchain
technology: Architecture, consensus, and future trends, in: 2017 IEEE
6. Conclusion International Congress on Big Data (BigData Congress), 2017, pp. 557–564.
[17] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, H. Wang, Blockchain challenges and
opportunities: A survey, Int. J. Web Grid Serv. 14 (2018) 352.
Blockchain is a disruptive technology and has attracted sig- [18] E. Project. Blockchain app platform. [Online]. Available: https://www.
nificant attention with prominent applications across diverse ap- ethereum.org/.
plication domains including supply chain management, gaming, [19] Multichain. Open platform for blockchain applications. [Online]. Available:
www.multichain.com.
healthcare, real estate and finance. Electronic or e-voting is one of [20] Rockwell, Bitcongress – process for block voting and law, 2019.
the emerging applications of blockchain where researchers have [21] F. Hao, P.Y.A. Ryan, P. Zielinski, Anonymous voting by two-round public
proposed to leverage blockchain capabilities to achieve integrity, discussion, IET Inf. Secur. 4 (2) (2010) 62–67.
anonymity and non-repudiation which are critical for a voting [22] K. Dalia, R.P.Y.A. Ben, H. Feng, A fair and robust voting system by broadcast,
in: 5th International Conference on E-voting, 2012.
application. Current research into scalability and performance of
[23] S. Shahandashti, F. Hao, Dre-ip: A verifiable e-voting scheme without
blockchain is focused on Bitcoin with the objective to achieve tallying authorities, vol. 9879, 2016, pp. 223–240.
comparable performance as of existing online payment systems [24] D. Chaum, A. Essex, R. Carback, J. Clark, S. Popoveniuc, A. Sherman, P. Vora,
such as VISA. However, there exists a gap in literature with Scantegrity: End-to-end voter-verifiable optical- scan voting, IEEE Secur.
respect to investigating performance constraints for wider ap- Priv. 6 (3) (2008) 40–46.
[25] D. Chaum, Secret-ballot receipts: True voter-verifiable elections, IEEE Secur.
plication domains. In this paper, we have presented our efforts Priv. 2 (1) (2004) 38–47.
to address this gap by conducting an in-depth investigation of [26] D. Chaum, Untraceable electronic mail, return addresses, and digital
parameters which have a profound role in achieving scalable pseudonyms, Commun. ACM 24 (1981).
solutions using blockchain. Specifically, we investigate the role [27] R. Goré, V. Teague, Submission to Parliament of Victoria Electoral Matters
Committee Inquiry Into Electronic Voting, Tech. Rep., 2016, https://bit.ly/
of block generation rate, block size, transaction processing rate
2IpUSmP.
and transaction size with respect to scalability of blockchain [28] R. Pearce, Nsw’s evoting system under fire, 2016.
based solution. Our experimentation results highlight a trade-off [29] E. M. of Foreign Affairs, Estonian internet voting system, 2019.
between these parameters and identify avenues to explore for [30] H. Baldersheim, J. Saglie, Internet voting in norway 2011: Democratic
and organisational experiences, in: The 4th International Conference on
further research.
Democracy as Idea and Practice, 2013.
[31] A. Barnes, C. Brake, T. Perry, Digital voting with the use of blockchain
Declaration of competing interest technology, 2016, the Economist Competition on Blockchain based e-
voting. [Online]. Available: https://www.economist.com/sites/default/files/
The authors declare that they have no known competing finan- plymouth.pdf.
[32] P. McCorry, S. Shahandashti, F. Hao, A smart contract for boardroom voting
cial interests or personal relationships that could have appeared with maximum voter privacy, 2017, pp. 357–375.
to influence the work reported in this paper. [33] K.M. Khan, J. Arshad, M.M. Khan, Secure digital voting system based on
blockchain technology, Int. J. Electron. Gov. Res. 14 (1) (2018) 53–62,
References http://dx.doi.org/10.4018/IJEGR.2018010103, [Online]. Available.
[34] P. Ryan, Pret a voter with paillier encryption, Math. Comput. Modelling
48 (9) (2008) 1646–1662, mathematical Modeling of Voting Systems
[1] J. Gobel, H. Keeler, A. Krzesinski, P. Taylor, Bitcoin blockchaindynamics:
and Elections: Theory and Applications. [Online]. Available: http://tiny.cc/
The selfish-mine strategy in the presence of propagation delay, Perform.
4eac5y.
Eval. 104 (2016) 23–41, [Online]. Available: https://bit.ly/2IuarKL. [35] G. Karame, On the security and scalability of bitcoin’s blockchain, in: The
[2] P. Treleaven, R. Gendal Brown, D. Yang, Blockchain technology in finance, 2016 ACM SIGSAC Conference, 2016, pp. 1861–1862.
Computer 50 (9) (2017) 14–17. [36] SegWit, 2019. [Online]. Available: https://segwit.org/.
[3] M. Mettler, Blockchain technology in healthcare: The revolution starts [37] M. Vukolić, The quest for scalable blockchain fabric: Proof-of-work vs. bft
here, in: 2016 IEEE 18th International Conference on E-health Networking, replication, in: J. Camenisch, D. Kesdoğan (Eds.), Open Problems in Network
Applications and Services (Healthcom), 2016, pp. 1–3. Security, Springer International Publishing, Cham, 2016, pp. 112–125.
[4] F. Tian, An agri-food supply chain traceability system for china based on [38] M.A.-B. Shehar Bano, G. Danezis, The road to scalable blockchain designs,
rfid amp; blockchain technology, in: 2016 13th International Conference Login 42 (4) (2017) 31–42.
on Service Systems and Service Management (ICSSSM), 2016, pp. 1–6. [39] I. Eyal, A.E. Gencer, E.G. Sirer, R.V. Renesse, Bitcoin-ng: A scalable
[5] M. Rosenfeld, Analysis of hashrate-based double spending, 2014, CoRR, vol. blockchain protocol, in: 13th USENIX Symposium on Networked Systems
abs/1402.2009, [Online]. Available: http://arxiv.org/abs/1402.2009. Design and Implementation (NSDI 16), USENIX Association, Santa Clara, CA,
[6] Jha Praharsh, Jaiswal Shravan, M. Kadam, Double spending prevention in 2016, pp. 45–59, [Online]. Available: https://www.usenix.org/conference/
bitcoins network, Int. J. Comput. Eng. Appl. (2015). nsdi16/technical-sessions/presentation/eyal.
26 K.M. Khan, J. Arshad and M.M. Khan / Future Generation Computer Systems 105 (2020) 13–26

[40] S. Kim, Y. Kwon, S. Cho, A survey of scalability solutions on blockchain, Junaid Arshad is a Senior Lecturer at the University
2018, pp. 1204–1207. of West London. Junaid achieved his PhD from the
[41] J. Rubin, M. Naik, Merkelized abstract syntax trees, 2014. University of Leeds, UK where he investigated the chal-
[42] M. Scherer, Performance and Scalability of Blockchain Networks and Smart lenge of effective intrusion severity analysis for clouds.
Contracts (Master’s thesis), Umee University, Department of Computing Junaid’s research areas involve distributed computing,
Science, 2017. high performance computing such as grid and cloud
[43] M.C.T. Size, 2019. [Online]. Available: https://www.multichain.com/qa/ computing, service oriented computing and Internet
6551/how-to-calculate-transaction-size. of Things emphasizing security challenges including
intrusion detection and response, trust establishment
and management, and security event classification.

Kashif Mehboob Khan graduated in Computer En- Muhammad Mubashir Khan is an Associate Professor
gineering from Sir Syed University of Engineering & in the Department of Computer Science and Infor-
Technology in 2005–2006 followed by Master in C.S. & mation Technology at NED University of Engineering
I.T. from N.E.D University of Engineering & Technology and Technology, Karachi Pakistan. He received his PhD
in 2009. He is currently a PhD student in information degree in Computing from University of Leeds, UK
security at the N.E.D. University, Pakistan. in 2011. He did postdoctoral research in Quantum
Information Group University of Leeds, UK in 2015–
16. His current research interests include Network
and Information Security, Cybersecurity and Quantum
Cryptography.