Online Voting Scheme Using IBM Cloud-Based Hyperledger Fabric with Privacy-Preservation

Abstract

The current traditional paper ballot voting schemes suffer from several limitations such as processing delays due to counting paper ballots, lack of transparency, and manipulation of the ballots. To solve these limitations, an electronic voting (e-voting) scheme has received massive interest from both governments and academia. In e-voting, individuals can cast their vote online using their smartphones without the need to wait in long lines. Additionally, handicapped voters who face limited wheelchair access in many polling centers could now participate in elections hassle-free. The existing e-voting schemes suffer from several limitations as they are either centralized, based on public blockchains, or utilize local private blockchains. This results in privacy issues (using public blockchains) or large financial costs (using local/private blockchains) due to the amount of computing power and technical knowledge needed to host blockchains locally. To address the aforementioned limitations, in this paper, we propose an online voting scheme using IBM cloud-based Hyperledger Fabric. Our scheme allows voters to cast their encrypted votes in a secure manner. Then any participant can obtain the ballot results in a decentralized and transparent manner, without sacrificing the privacy of individual voters. We implement the proposed scheme using IBM cloud-based Hyperledger Fabric. The experimental results identify the performance characteristics of our scheme and demonstrate that it is feasible to run an election consisting of thousands of participants using cloud-based Fabric.

1. Introduction

The democratic election process is a critical component of governance for systems ranging from small local governments and corporations to major national and international organizations. Democracies rely on the election process to give an equal voice to each of their members or citizens; however, traditional election schemes consisting of paper ballots are flawed in several ways. Firstly, traditional paper ballot elections require voters to visit physical polling centers. Many of these polling locations are not designed to ensure fair and equal access to all. For example, long lines and limited wheelchair access discourage voters from participating [1]. Secondly, traditional paper ballot elections do not scale well for large voter populations so it can take days or weeks for election results to be processed. Thirdly, traditional ballot elections are difficult to audit for manipulation. Traditional elections typically rely on third parties to perform poll-watching or conduct surveys (i.e., exit polling) to identify inconsistencies and increase public trust of the election results. However, these methods fail to produce perfect traceability of elections and can themselves be corrupted [2]. The difficulty of maintaining trust and accountability in elections increases for large elections where thousands of individuals are relied upon and can act maliciously or make consequential mistakes. As a result the chances of lost or falsified ballots increases [3].

To solve these issues, governments, academic researchers, and private companies have proposed moving to an electronic voting (e-voting) scheme [4]. E-voting is a voting process in which voters can submit their votes using computers or even smart phones without the need of traditional paper ballots [4]. E-voting aims to solve the aforementioned issues by allowing anyone including people who struggle with mobility due to age or disability to vote safely and conveniently from their homes. In addition, e-voting schemes can save time tallying votes [5]. Moreover, an e-voting scheme can provide more secure and accountable elections by introducing logging schemes as a countermeasure to prevent fraudulent behavior and vote manipulations. Unlike paper ballots, e-voting can allow for the automated generation of immutable audit trails that can be leveraged to validate election integrity.

While e-voting schemes have the potential to solve issues associated with traditional paper ballot elections, the majority of the current e-voting schemes rely on a central third party to run the election [6,7,8]. This makes them vulnerable to single-point-of-failure attacks as well as privacy concerns of submitted votes by both internal and external attackers [9,10,11]. They are vulnerable to distributed denial of service (DDoS) and Sybil attacks launched by malicious users and external attackers. To address the limitations of centralized e-voting schemes, many researchers have proposed using the blockchain to host an e-voting scheme [12,13,14,15,16,17,18]. The blockchain technology, at its core, contains a ledger, or transaction history, that follows an append-only scheme. Due to the immutable structure of the ledger, the use of a blockchain would naturally deter vote tampering and manipulation. This is because previous votes written to the ledger cannot be overwritten or changed. A set-in-stone timeline is created as the election takes place, recording every encrypted vote and action taken on the blockchain.

However, the majority of existing implemented blockchain-based voting schemes are based on public blockchains, which could result in privacy issues as the votes are easily available to the public if additional measures such as vote encryption are not implemented [16]. In [5,17], the Ethereum blockchain is used, which posts votes publicly, providing no election privacy. While [17] utilizes encryption of votes to protect voter privacy, [5] provides no such safeguard. This transparency sacrifices privacy to allow for an easily auditable scheme. In [19], homomorphic encryption is used to protect the ballots. The organizer can verify the ballot when tallying the votes without obtaining any details about the content of the ballot. However, the scheme suffers from high computation and communication overheads due to the time and computational power required to aggregate homomorphic encrypted ballots and to decrypt the large ciphertexts that were produced by the scheme.

In this paper, we propose an electronic voting scheme using IBM Cloud-based Hyperledger Fabric. We opt to develop our e-voting scheme using the Hyperledger Fabric blockchain for two main benefits. Firstly, Hyperledger Fabric is a private blockchain, meaning only identified nodes can participate in the network, and these known participants can access the data stored on each block. Secondly, using IBM cloud-based Hyperledger Fabric removes the burden needed to set up and run a private local blockchain. Self-hosting a private blockchain requires thousands of dollars worth of hardware and a great wealth of technical knowledge to set up and maintain [20]. Our developed scheme is unique, as most existing works depend on using public or locally-hosted blockchains to run an e-voting scheme. Moreover, ours is not a costly solution, as elections only run on a scheduled basis, e.g., once a year or once every four years [12,13,15,21,22,23]. Our proposed e-voting scheme allows small businesses and governments alike to run an election in a decentralized, transparent, and secure manner.

We developed a custom smart contract with four custom attributes to drive all of the functionality required to host an election. The smart contract handles the creation of the election, registering of voters, casting of votes, and tallying of votes. In our voting scheme, the blind signature cryptoscheme is leveraged so that voters can obtain anonymous voting tokens so they can cast their votes to the blockchain while maintaining the privacy of their real identity, which is not shared with the network. To evaluate our proposed scheme, we have used Hyperledger Caliper to measure and evaluate the performance in terms of throughput, latency, and error rate. The  results indicate that the use of the IBM Cloud to remotely host a blockchain-based e-voting scheme is feasible and scalable to elections involving 10,000 voters.

The rest of this paper is organized as follows. In Section 2, we perform a literature review and discuss related works. Next, in Section 3, we present the considered scheme model followed by the design goals of our proposed scheme. Section 4 gives an overview of the preliminaries used in our paper. Section 5 discusses the considered blockchain design and our developed smart contract. In Section 6, we present the performance evaluations of our proposed scheme. An analysis of the proposed scheme is given in Section 7. Finally, we give concluding remarks in Section 8.

2. Related Work

In this section, the literature review is provided for e-voting schemes.

Table 1. A summary comparison between our scheme and existing e-voting schemes. Note: √ shows a functionality a realized feature; ◯ shows a (partially) realized function by relying on a central trust × is an unrealized feature. (Author’s own processing).

	Architecture	Election Privacy	Identity Privacy	Easy for Voters to Audit Results	Implemented Performance Evaluation	Affordable
Current Paper Ballot scheme 1	Centralized	×	◯	×	√	×
Hanifatunnisa et. al. [5]	Hybrid	×	◯	×	√	×
Liu and Wang: [12]	Blockchain	×	√	√	×	×
Hjálmarsson et al. [13]	Blockchain (public)	×	×	√	×	×
Seifelnasr et al. [17]	Blockchain (public)	×	√	√	√	×
Our scheme	Blockchain (private)	√	√	√	√	√

¹ https://www.blablacar.com/.

provides a comparison between our scheme and existing e-voting schemes.

E-Voting In Industry. In [24], Specter et al. analyze the first blockchain-based e-voting scheme used by a state in its general elections, Voatz. The app used in this scheme was found to contain severe security flaws such as requirements of weak passwords, easily bypassed anti-virus, and an API that can take full control of a user’s device. In addition, voter’s choices could be deduced via a side-channel attack.

Score Voting. In [25], Yang et al. present a distributed scored voting scheme that uses a novel dual zero-knowledge proof to preserve privacy. Each component of the crypto scheme is performance tested locally using Charm, then the scheme is benchmarked locally on the Ethereum blockchain to determine average costs. Unlike our scheme, all scheme testing was conducted locally.

Self-Tallying. In [26], Lin et al. present a complete self-tallying e-voting protocol based on [27]. Minimal performance testing was conducted. The authors present the average time for proving and verifying a single vote, but no testing of scale is shown. In [28], Li et al., propose a modification of [27,29] to deliver a scheme model of self-tallying voting schemes based on blockchain in decentralized IoT. The scheme is performance tested, but scalability is capped to only 12 voters. In [30], Li et al. propose and implement a traceable self-tallying e-voting protocol using a homomorphic time-lock puzzle to provide self-tallying. However, both on-chain and off-chain performance testing was limited to less than 10 voters, showing minimal scale for the scheme.

Blockchain Based E-Voting schemes. In [21], Onur et al. propose a blockchain-based, ranked-choice election protocol on the public Ethereum blockchain. While performance testing was only implemented locally using Hardhat, virtualized scalability was demonstrated up to 10,000 voters. Result verification through Merkle Tree generation was demonstrated up to 100,000 voters, but no election scheme functions were tested at this scale. In [31], Han et al. propose and implement a blockchain-based self-tallying voting scheme with software updates in decentralized IoT. The authors tested the voting scheme using a Raspberry Pi device to simulate an IoT device, but did not test the update integration. In addition, the testing only included up to 100 voters. In [32], Mukherjee et al. present a framework to be used for blockchain-based elections, but no implementation beyond broad software architecture concepts is discussed. Since no implementation is shown, there are also no performance metrics for the proposal.

On-Chain Voting schemes. E-voting schemes that utilize the blockchain for the conduction of the voting process require more resources, but allow for a more open, transparent voting process. In [12,13,15,22,23], the election process logic exists entirely on-chain. In [13,22], no encryption is used to protect voter identities. In addition, the Rinkeby Network, a private but widely used blockchain, is used which poses privacy concerns. While Koç et al. conducted performance testing on their scheme, they failed to show any scalability beyond four voters. In [12,13,15,23], no performance testing or scalability is shown. Without performance testing, it is impossible to conclude if the proposed system is a feasible solution at any scale. In [15], some votes have the chance of going uncounted if they are cast at the same time. Ref.  [13] relies on multiple nodes representing each voting district, which establishes a significantly high cost to scale. Ref. [12] allows the viewing of vote totals before casting a ballot, which could lead to voter manipulation and sway.

Blockchain as Vote Storage. To combat the high resource cost of utilizing blockchain as a voting solution, some proposed schemes simply leverage a blockchain as a database to store votes, but these solutions rely on traditional ballot casting, which can lead to vote manipulation as well as other forms of voter fraud. Refs. [5] utilize blockchain to store votes or vote counts, but still rely on traditional polling centers for ballot casting. Refs. [5] rely on traditional paper ballots at polling centers. In addition, no individual votes are stored on the blockchain, only vote totals from each polling center, allowing for fraud and vote manipulation on the local level at polling centers. Ref. [5] only verifies polling locations, and not individual voters. This passes the reliance of voter verification to unreliable traditional methods.

The main advantages to our approach compared to the previous proposals are as follows:

• Our scheme hosts all aspects of the election on the blockchain, allowing for an entirely remote election to take place. This aspect allows for remote voters to still have their voice heard. Since our scheme aims to address the requirement for secure online voting beyond national presidential elections, a fully remote voting system is necessary. This is particularly relevant as numerous companies that wish to conduct internal elections or employee surveys have implemented a ’work-from-home’ policy for their employees. Without the need for a polling center, geographically distributed voters who would otherwise be unable to attend an election can have their voices heard.
• Our scheme utilizes the IBM Cloud infrastructure to host the latest version of the Hyperledger Fabric blockchain. By hosting the private blockchain in the cloud, managing and hosting elections requires less physical hardware and resources. In addition, the IBM cloud provides a scalable “pay as you go” platform, allowing elections of any size to be hosted by our scheme.
• Our scheme has been implemented and tested, allowing for the collection of performance metrics. This implementation proves that the conceptual ideas proposed for our blockchain e-voting scheme are able to be put into action. These performance metrics showed us that our scheme, when hosted on the IBM Cloud with minimum required cost, is easily scalable up to 10,000 voters. In addition, these performance metrics reflect expected results from [33].

3. Scheme Model

In this section we first describe the considered scheme model, followed by the threat model, and finally the design goals that we established.

3.1. Scheme Model

As depicted in Figure 1, the considered network model has the following entities.

• Blockchain Network. The private Hyperledger Fabric blockchain hosted on IBM’s cloud infrastructure. The Hyperledger Fabric requires the use of a minimum of three peers: an endorser peer, which utilizes the smart contract to write new transactions; an orderer, which verifies the new transaction and writes it to a new block on the blockchain; and the committer, which checks the validity of all transactions on the blockchain and writes valid transactions to the ledger. Our blockchain network utilizes a voter peer, which utilizes our developed smart contract to write our transactions (any action taken within the election), and an orderer, which verifies and writes each transaction. Each of these peers act also as the committers for our network. In a production environment, additional peers can be added to act solely as committers, funds permitting. In accordance with [34], our organization and orderer have separate Certificate Authorities (CA). Hyperledger Fabric utilizes certificate authorities to identify each peer and define each functionality. If additional peers are added solely as committers, a third CA is required; however, all additional committer-only peers can share the third CA.
• Voters. The voter is an entity that can cast votes to the ballot. Note that voters do not maintain a whole copy of the ledger; but they can run the scheme using lightweight nodes, which lets them communicate with the network, read from the blockchain and submit transactions [35]. In our scheme, we implemented a preferential voting scheme; so, when casting a vote, the voters rank three candidates to receive vote payouts. The candidate selected first receives three votes, the second receives two votes, and the third one vote.
• Organizer. This is the organization hosting the election, such as small businesses, states and governments, etc. Specifically, the organizer is represented by a person in the IT department who has the technical skills to set up a blockchain environment on the IBM Cloud Platform. The organizer’s main duty is to initiate the election, e.g., defining the candidates’ names and configuring the blockchain on the IBM Cloud by defining the nodes necessary to be used to carry out the election, creating the channels between the nodes, and uploading/initializing the packaged smart contract.

3.2. Threat Model

Since attacks may come from both internal and external attackers, this work is following the blockchain threat model given in [36], where the blockchain is trusted for immutability and availability but not designed to maintain privacy. Therefore, we assume that both the organizer and the blockchain are honest-but-curious, meaning they correctly run the voting scheme but also aim to infer voters’ sensitive information. Therefore, the blockchain shall not know any information about the voters’ votes other than the election results, i.e., the total number of votes per candidate.

We consider threats that may come from some of the blockchain validators/miners who could misbehave with the aggregated data. In other words, blockchain validators may try to modify the votes of legitimate voters’ votes (i.e., double counting votes twice) before aggregating the total votes by double counting votes to give a candidate more votes than their actual vote count.

Finally, existing works depend on voters’ anonymity to protect voter’s privacy; however, internal attackers can link voters’ pseudonyms to their real identities by snooping their messages generated from their IP addresses.

3.3. Design Goals

Based on the considered threat assumptions and to ensure security and privacy against internal and external attackers, our design goals for our scheme are laid out as follows:

• The proposed e-voting scheme should neither rely on a central entity to run the election nor require certain infrastructure to set up a private blockchain network. Central entities are vulnerable to a single-point-of-failure or attack. Our goal is to develop and implement the scheme using an open source blockchain platform and cloud-based infrastructure to avoid hardware costs required to host a private blockchain.
• The proposed scheme should protect voters’ privacy by ensuring the following: (i) Only authenticated voters should be able to cast their votes to the ballot while protecting their real identities from being revealed or tracked. (ii) Since anonymity alone is not sufficient to ensure voters’ privacy against internal attackers who can link voters’ pseudonyms to their real identities by knowing their IP addresses, the proposed scheme should withstand such eavesdropping attacks by making it difficult to determine the exact selection of a specific voter.
• The scheme should also resist any fraud or manipulation attacks that would give preference to specific candidates over others. For example, blockchain nodes or internal attackers may try to replay legitimate voters’ votes or recorded transactions on the blockchain to give a candidate more votes than their actual vote count. In other words, authenticated voters can cast their encrypted votes, and the blockchain nodes can only compute the number of votes per candidate correctly.

Finally, one primary goal of this work is to evaluate the efficacy of developing the blockchain-based e-voting scheme on top of IBM cloud-based infrastructure in terms of throughput and scalability.

4. Preliminary Background

4.1. Blind Elliptic Curve DSA Signatures

In this cryptoscheme, a user checks if a signature on a message M is valid from the signer while hiding M from the signer. In our voting scheme, the blind signature cryptoscheme in [37] is leveraged so that voters can obtain anonymous voting tokens so they can cast their votes to the blockchain while keeping their real identity private. The aforementioned cryptoscheme is used because it is efficient in terms of computations with shorter signatures and it contains the following steps:

• All parties are assumed to use an elliptic curve of order n with generator G. P = d·G is the signers’ public key, where $d\in {\mathbb{Z}}_n^{*}$ is the private key.
• The signer first selects a random element $k\in {\mathbb{Z}}_n^{*}$ and then he/she sends $R=k$·G to the requester.
• Then, the requester selects the following random elements $\gamma ,\delta \in {\mathbb{Z}}_n^{*}$ to compute A = R + $\gamma$·G + $\delta$·P. Let x be the x-coordinate of point A, and $t=xmodn$. The requester then computes $c=H\left(M\right|\left|t\right)modn$ and sends $c^{\prime }=(c-\delta )modn$ to the signer. $H(·)$ is a cryptographically secure hash function, and $H:{\left\{\right\}}^{*}\stackrel{}{\to }{Z}_n^{*}$.
• The signer then computes $s^{\prime }=(k-c^{\prime }·$d$)modn$ and sends the result back to the requester.
• The requester then computes $s=(s^{\prime }+\gamma )modn$ and the signature of M is stored as $(s,c)$. Finally, to validate the signature, the verifier calculates A  = c·P + s·G. Then, $t=xmodn$ is computed, where x is the x-coordinate of point A. The verifier verifies if $c\stackrel{?}{=}H\left(M\right|\left|t\right)modn$.

4.2. Verifiable Aggregator Oblivious Encryption

Aggregator oblivious encryption cryptoscheme enables the computation of aggregated data M of n users’ individual data in a privacy-preserving way by an untrusted aggregator. The main idea is that a user i encrypts a message $m_i$ and sends the ciphertext $c_i$ to the aggregator. Then, the aggregator computes the sum $M={\sum }_{i=1}^n{m}_i$ from ${\left\{c_i\right\}}_{i\in [1,n]}$. On the other hand, verifiable aggregator oblivious encryption [38] ensures the correctness of the aggregated data. In this cryptoscheme, the user i computes a tag ${\sigma }_i$ in addition to $ci$, and the aggregator generates a publicly verifiable proof $\sigma$ from ${\left\{{\sigma }_i\right\}}_{i\in [1,n]}$ that proves the correctness of M. Note that ensuring the correctness of the aggregated data is very critical in a voting scheme to ensure a fair ballot, and the results of the ballot reflect the voters selections. In our scheme, we employ verifiable aggregator oblivious encryption to make sure that blockchain nodes cannot manipulate the ballot results by, for example, counting multiple votes for the same voter. The verifiable aggregator oblivious encryption consists of the following algorithms:

• $\mathit{Setup}\left(1^{\lambda }\right)\to \mathrm{param},s{k}_A$: Given a security parameter $\lambda$ as an input, this algorithm generates public parameters $PP$ and a secret key of aggregator $s{k}_A$, a set of user secret keys ${\left\{{\mathrm{sk}}_i\right\}}_{i=1}^n$, and the aggregate verification key $v_k$.
• $\mathit{Enc}(param,t,x_i)\to c_i,{\sigma }_i$: Given $param$, t, a value $x_i$, and $s{k}_i$, this algorithm produces a ciphertext $c_i$ and a tag ${\sigma }_i$.
• $\mathit{AggrDec}(param,{\left\{\left(c_i,{\sigma }_i\right)\right\}}_{i=1}^n,s{k}_A)\to Xt={\sum }_{i=1}^n{x}_{i,t}modM$: This algorithm is considered the aggregation and decryption algorithm and it uses the $param$, t, the ciphertexts and tags ${\left\{\left(c_i,{\sigma }_i\right)\right\}}_{i=1}^n,{\sigma }_t$ and $s{k}_A$, to produce ${\left\{\left(c_i,{\sigma }_i\right)\right\}}_{i=1}^n$, and the proof ${\sigma }_t$ where M is some fixed integer contained in $param$.
• $\mathit{VerifySum}\left(\right)\to$: This verification algorithm is applied to the aggregation algorithm and it takes $param$, t, $v{k}_t$, and $\left(X_t,{\sigma }_t\right)$ as input, and outputs 1 or 0.

5. Proposed Solution

This section details our proposed cloud hosted blockchain e-voting scheme, and demonstrates how our scheme meets all our design goals. We will explain our proposed anonymous credential scheme, our blockchain choice and setup, our developed smart contract functionality, and how these work together to accomplish all of our design goals.

5.1. Initialization

In this phase the organizer runs the $\mathit{Setup}$ algorithm explained in Section 4.2 to compute public parameter $PP$ and a secret key of aggregator $s{k}_A$ used by the blockchain validators, a set of user secret keys ${\left\{{\mathrm{sk}}_i\right\}}_{i=1}^n$, and the aggregate verification key $v_k$, as follows. The organizer chooses $\left(p,e,g_1,g_2,{\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T\right)$ where ${\mathbb{G}}_1,{\mathbb{G}}_2$ and ${\mathbb{G}}_T$ are groups of $\lambda$-bit prime order $p=M,g_1\in {\mathbb{G}}_1$ and $g_2\in {\mathbb{G}}_2$ are generators, and $e:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_T$ is a bilinear map.

Let $H_i:\mathbb{Z}\to {\mathbb{G}}_1$$(i=1,2,3,4,5)$ be hash functions, then choose $\gamma ,s_1,\dots ,s_n,t_0\stackrel{\$}{\in }{\mathbb{Z}}_p$, set $s_0=-{\sum }_{i=1}^n{s}_i,h=g_1^{\gamma }$, and $Z=e\left(h,g_2\right)$. Finally, the $\mathit{Setup}$ algorithm Outputs $PP$ as $PP=\left(\left(p,e,g_1,g_2,{\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T\right),Z,H_1,H_2,H_3,H_4,H_5\right)$, $\mathrm{s}{\mathrm{k}}_A=\left(s_0,t_0\right)$, ${\mathrm{sk}}_i=\left(s_i,t_0,h\right)$, and $\mathrm{vk}=\varnothing$.

5.2. Obtaining Anonymous Credentials

Privacy is critical in an e-voting scheme. The scheme shall allow only authenticated voters to cast their votes while protecting their real identities from being tracked by the blockchain nodes, organizers, and other potential eavesdroppers. To address this issue, voters need to obtain untraceable tokens from the organizers. The process of acquiring the tokens is as follows.

The voter chooses random element $\left\{s\right\}\in {\mathbb{Z}}_n^{*}$ and then computes the token public keys $\left\{TP\right\}$, where $TP$ = $s·G$. Then, the voter and the organizer execute the blind signature protocol, discussed in Section 4, so that the voter can acquire a valid signature $si{g}_O\left(TP\right)$ for the token coin $TP$ without revealing $TP$ to the organizer. The process is as follows:

Step 1:

A voter $v_i$ initializes the communication by sending a message $ms{g}_1$, as follows:

$$ms{g}_1=I{D}_{v_i}\parallel Si{g}_{v_i}\left(I{D}_{v_i}\right)$$

where $I{D}_{v_i}$ is the voter’s real identity, such as his/her registered email address account, and $Si{g}_v\left(I{D}_{v_i}\right)$ is the signature on the whole message using the voter’s private key.

Step 2:

The organizer chooses a secret element $k\in {\mathbb{Z}}_n^{*}$ and computes $R=k·G$ and he/she sends $ms{g}_2$ back to the voter

$$ms{g}_2=R\parallel Si{g}_O\left(R\right)$$

where $Si{g}_O\left(R\right)$ is the organizer’s signature on the message.

Step 3:

The voter computes A = R + $\gamma$·G + $\delta$·P, where $\gamma ,\delta \in {\mathbb{Z}}_n^{*}$ are random elements and computes $t=xmodn$, where x is the x-coordinate of point A. The voter computes $c^{\prime }=(c-\delta )modn$, where $c=H\left(TP\right|\left|t\right)modn$. The voter sends $ms{g}_3$ that includes $c^{\prime }$ as well as the voter’s signature $Si{g}_{v_i}\left(c^{\prime }\right)$ to the organizer:

$$ms{g}_3=c^{\prime }\parallel Si{g}_{v_i}\left(c^{\prime }\right)$$

Step 4:

The organizer computes $s^{\prime }=(k-c^{\prime }·d)modn$ where d is the organizers’ secret key and they reply back with $ms{g}_4$, where,

$$ms{g}_4=s^{\prime }\parallel Si{g}_O\left(s^{\prime }\right)$$

Finally, the voter uses $ms{g}_4$ to compute $s=(s^{\prime }+\gamma )modn$ and stores the signature on $T{P}_{v_i}$ ($Si{g}_O\left(T{P}_{v_i}\right)$) as $(s,c)$. The organizer is oblivious to the voters’ tokens, i.e., public keys. Note that, although this phase require the voters to use his/her real identity to obtain anonymous voting tokens, and due to the use of the blind signatures, the organizer would not be able to link a specific voting token $\left(si{g}_O\left(T{P}_{v_i}\right)\right)$ to the voter $v_i$ when the token is used in the voting process.

5.3. Submitting Anonymous and Encrypted Votes

Each voter encrypts his/her vote using the $\mathit{Enc}$ algorithm, discussed in Section 4.2, using $PP,t,x_i,s{k}_i,PP$ as an input, as follows. The voting ballot is shown in Figure 2. Each ballot $B_{v_i}$ is divided into elements, where each element corresponds to one candidate and each voter selects the candidates by putting 1 in the element corresponding to this candidate. For instance, if the message size is 1000 bits and the number of candidates is five, the message is then divided into five elements, each of them a size of 200 bits. A voter $v_i$ chooses $d_{v_i}\stackrel{\$}{⟵}{\mathbb{Z}}_p$ and then computes ${\mathrm{vk}}_{v_i}:=g_1^{d_{v_i}}$, and computes

$$C_{B_{v_i}}=g_1^{B_{v_i}}{H}_1{\left(\tau \right)}^{s_i}{H}_2{\left(\tau \right)}^{t_i}$$

and

$${\sigma }_i=h^{B_{v_i}}{H}_3{\left(\tau \right)}^{s_i}{H}_4{\left(\tau \right)}^{t_i}{H}_5{\left(\tau \right)}^{v_i}$$

The smart contract handles all of the necessary election logic and the smart contract voting scheme is summarized in Algorithm 1. To then cast a vote, the voters need to use the anonymous tokens described in Section 5.2 to be able to vote for their specific candidates, as follows. The voter uses the private key that corresponds to the token $T{P}_{v_i}$ to sign and broadcast the following message to the blockchain:

$$ms{g}_5=\left(C_{B_{v_i}},{\sigma }_i,v{k}_i,si{g}_O\left(T{P}_{v_i}\right),\sigma \left(v_i\right)\right),$$

where $\sigma \left(v_i\right)$ is the signature on the whole message. Then, the blockchain should first verify if the voter is authenticated by checking the organizer’s signature on the $T{P}_{v_i}$ ($si{g}_O\left(TP\right)$), as follows. The blockchain first computes A  = c·P + s·G. Then, it computes $t=xmodn$, where x is the x-coordinate of point A. The verifier checks if $c\stackrel{?}{=}H(ms{g}_5\left|\right|t)modn$. If the verification succeeds, then the blockchain continues to execute the smart contract Algorithm 1. In the example, the vote will only be written as a valid transaction if the voter has not cast a ballot already, the current time lies within the election start and end times, and the voter has their anonymous tokens described in Section 5.2. This logic solely utilizes the smart contract and data stored on the ledger, eliminating the need for external centralized databases during the election process.

Algorithm 1 Pseudocode for voterContract (Author’s own processing)

5.4. Obtaining Election Results

This phase starts once the blockchain receives n total votes. The blockchain should run the following algorithm $\mathit{AggrDec}$, discussed before in Section 3, as follows.

The $\mathit{AggrDec}$ uses (param, $\left.t,{\left\{\left(c_{i,t},{\sigma }_{i,t},{\mathrm{vk}}_{i,t}\right)\right\}}_{i=1}^n,{\mathrm{sk}}_A\right):$ Parse ${\mathrm{sk}}_A=\left(s_0,t_0\right).$ Compute

$$V_t=H_1{\left(t\right)}^{s_0}{H}_2{\left(t\right)}^{t_0}\prod _{i=1}^n{c}_{i,t}=g_1^{X_t}$$

where $X_t={\sum }_{i=1}^n{x}_{i,t}$, and the discrete logarithm $V_t$ with respect to basis $g_1$ is solved. Then, the algorithm computes

$${\sigma }_t=H_3{\left(t\right)}^{s_0}{H}_4{\left(t\right)}^{t_0}\prod _{i=1}^n{\sigma }_{i,t}\mathrm{and}{\mathrm{vk}}_t=\prod _{i=1}^n{\mathrm{vk}}_{i,t}$$

Output $\left(X_t,{\sigma }_t\right.$, vk $\left.{}_t\right)$.

Finally, the blockchain broadcasts the results of the ballot as well as the tags for verification. The organizer and the voters can check the correctness results by running the $\mathit{VerifySum}$, as follows.

First, the verifier, i.e., the organizer/voters uses the param, $\left.t,X_t,{\sigma }_t,v{k}_t\right)$ to check if

$$\frac{e\left({\sigma }_t,g_2\right)}{e\left(H_5\left(t\right),v{k}_t\right)}=Z^{X_t}$$

holds. If so, this means the ballot was computed correctly by the blockchain.

5.5. Blockchain Design and Methodology

As explained earlier, the voter needs to obtain anonymous tokens from the organizer using blind signatures, then the voters can cast anonymous and encrypted votes to the smart contract. Finally, blockchain nodes aggregate all the votes that have been cast to obtain the result of the election in a privacy-preserving manner.

In our proposed scheme, voters, as seen in Figure 3, interact with the endorser peer through a web application. Their input prompts the endorser peer to utilize the smart contract to write and execute a new transaction. This transaction is simulated by the endorser peer and forwarded to the orderer to verify the transaction. When the orderer verifies the transaction, it writes a new block to be distributed to each peer in the network. Once the transaction has been written as a new block, the network committers, which consist of every peer on the network (including the endorser), verify the integrity of the transaction. If verified, the new block is added to the channel’s ledger.

Throughout this whole process, Certificate Authority (CA) nodes are used to identify each peer and orderer. In addition, each CA creates and validates each transaction. For example, in our scheme, the Voter CA is used by the Voter Peer to sign, or endorse, the transaction during its creation. Again, after the transaction has been committed to the ledger, the Voter CA is used to verify all endorsements on the transaction to validate it before writing the transaction to the Voter Peer’s copy of the blockchain ledger. In the proposed model, we only include a single voter peer. However, this can be expanded upon to further distribute the endorsement process with additional peers, thus requiring additional signatures, or endorsements, before committing the transaction.

6. Performance Analysis

The performance of our proposed scheme is evaluated in this section. The experiment setup is explained, followed by key metrics used to evaluate the scheme and, finally, the results of these experiments are given.

6.1. Experiment Setup and Methodology

Hyperledger Fabric Platform. To implement our proposed scheme, we leveraged the IBM Cloud infrastructure to host the required hardware. According to the Hyperledger Documentation, this private blockchain is “an open source enterprise-grade permissioned distributed ledger technology (DLT) platform” [20]. This means that a level of trust is required within the network, removing anonymity between nodes, but ensuring only authorized nodes are added to the blockchain. The permissioned nature of the Hyperledger Fabric sets it up as a great tool for companies to utilize internally, without the fear of outside manipulation. In addition, Hyperledger Fabric is a cryptocurrency free blockchain, eliminating some major risk and attack incentives. In order to host our private blockchain network, we first deployed a free Kubernetes cluster consisting of 2 vCPUs with a total of 4 GB of RAM using the IBM Kubernetes Service [39]. On this cluster, we linked an instance of the IBM Blockchain Platform service. This established the environment in which we set up our private Hyperledger Fabric blockchain. Utilizing Fabric version 2, we have established an Endorser peer, a single orderer, and two committer peers. These nodes all share a common channel, on which we instantiated our developed smart contract. Hyperledger is built to be highly configurable through its modular design and use of smart contracts. Hyperledger’s smart contracts, or chaincode as they refer to it, drive the functionality of the blockchain. The chaincode acts as the logic for the blockchain, meaning this is the fundamental aspect of our proposed solution. While many blockchains require their smart contracts to be written in domain-specific languages, Hyperledger allows smart contracts to be written in general-purpose programming languages like Java, Go, and Node.js. Our developed smart contract is written in Go. In addition, Hyperledger Fabric introduces a new architecture for transactions in which transactions are executed before they are ordered, dramatically reducing the time necessary per transaction. The new execute-order-validate approach first executes a transaction, checking its correctness. Then, an orderer submits the transaction to the rest of the blockchain via a consensus protocol. Finally, a validator validates the transaction. This three-step process allows for multiple peers to execute their transactions before they are committed to the ledger, allowing for theoretically more transactions per second with less cpu usage than other blockchains [40]. Our smart contract defines four objects: an election, a ballot, a voter, and a votable Item. These four objects not only store the data necessary to host an election, but also interact with each other to form the base of our election functionality. Our contract class extends the Hyperledger Fabric base Contract class, allowing for easy import and initialization onto the endorser peer. Our contract class utilizes our four custom attributes to allow users to register to vote, cast votes, and query the election results. To instantiate the smart contract, we utilized the IBM Blockchain web console to propose our chaincode. Then, once each node in the channel signed the proposal, our developed smart contract took effect.

Hyperledger Caliper Setup. We leveraged Hyperledger Caliper version 2.0 to stress test and collect performance metrics on our scheme. Caliper is a blockchain benchmark framework that implements custom-defined use cases to produce performance reports. As seen in Figure 4, Caliper utilizes workers to generate and serve transactions to a blockchain network. These workers can be configured to serve transactions representing the different functions defined by our developed smart contract; getBallot, castVote, and getResults. In addition, the workers can serve these transactions at varying rates. the number of transactions to be served must also be set. To run these tests, we used an Ubuntu 20.04 DigitalOcean droplet with 1 GB memory and 1 shared vCPU as the test harness to remotely connect to our IBM Cloud-based Hyperledger Fabric instance.

6.2. Performance Metrics and Benchmarks

Performance Metrics. We ran each test experiment independently, utilizing Caliper’s workload modules to construct and send transactions. Three performance metrics of our implemented scheme were then recorded and analyzed to determine its applicability and scalability:

• Transaction Throughput. This metric is used to show the rate at which valid transactions are committed by our blockchain network, measured in transactions per second (tps). As emphasized by the Performance and Scalability Working Group (PSWG) in [41], this metric determines the rate at which transactions are committed across the entire blockchain network, not just at a single node. This helps to provide more accurate details of the experiment as, for a transaction to be functional across the network, it must be reflected by every node. A high tps value indicates that the widespread implementation of our proposed scheme is viable, enabling a large-scale participation of voters in the election. Conversely, a low tps would increase the time required for a significant number of voters to participate in the election.
• Transaction Latency. This metric, computed as transaction confirmation time at network threshold less the submit time of the transaction, demonstrates the time taken for a transaction to be usable across the network. Measuring transaction latency across all nodes of the network ensures a more realistic timing evaluation that reflects the true latency experienced by all users, rather than just the voter.
• Error Rate. This is the rate at which submitted transactions are rejected or dropped. The error rate is computed as the number of failed transactions divided by the number of sent transactions. This metric gives an accurate way to determine the maximum operational stress our scheme can handle without fault. Note that while error rate approaches zero in ideal conditions, we assume that ideal conditions are impracticable at large scales due to the distributed architecture of Hyperledger Fabric.

Use Cases and benchmarks. Based on the aforementioned metrics, three different experiments are used to evaluate and analyze the efficacy of the proposed scheme. These use cases are shown in

Table 2. Parameters for Performance Evaluation (Author’s own processing).

	Send Rate for GetBallot (tps)	Send Rate for CastVote (tps)	Number of Transactions
Experiment I: Transaction send rates and its impact on scheme throughput and latency	50, 100, 150, 200, 250, 300	5, 25, 50, 75, 100	1000
Experiment II: Varying numbers of transactions impact on scheme throughput and latency	50, 100, 150, 200, 250, 300	5, 25, 50, 75, 100	1000, 2000, 10,000, 20,000
Experiment III: Transaction send rates impact on error rate	50, 100, 150, 200, 250, 300	5, 25, 50, 75, 100	1000, 2000, 10,000, 20,000

and they are described in detail as follows:

• Experiment I shows varying transaction rates’ impact on our scheme’s throughput and latency to show the scheme’s ability to process transactions when receiving varying amounts of transactions. This simulates the impact of multiple voters using the scheme concurrently.
• Experiment II analyzes the varying of total transactions’ impact on the throughput and latency at differing transaction send rates to show the scheme’s scalability. This demonstrates the scheme’s ability to handle elections involving differing scales of total voters.
• Experiment III shows the error rate due to varying total transactions and transaction send rates.

For each of the use cases, we tested the main functions of our scheme’s functions, namely GetBallot and CastVote. The GetBallot function reads the ledger and returns the ballot associated with a specific voter. The CastVote function generates a new ballot for the voter to use in the election and writes the ballot to our blockchain with the voter’s choices.

6.3. Results and Discussion

In this section, the results of our performance testing are given and analyzed.

6.3.1. Experiment I

Figure 5 shows the average throughput and latency for GetBallot and CastVote functions at varying transaction send rates. The results indicate that as transactions are sent at higher rates, the scheme reaches a peak throughput, at which point latency begins to rise and the throughput is unable to match further increases to the send rate. This maximum throughput also is dependant on the transaction type: around 200 tps for GetBallot, a read function, and around 75 tps for CastVote, a write function. As seen in Figure 5 the average latency does not rise until the send rate eclipses the scheme’s peak throughput. These results are generalized as follows:

• A large number of voters, 200 per second, can concurrently fetch ballots without significant delay.
• Fewer voters, 75 per second, can concurrently cast votes without significant delay.
• The type of transaction will affect scheme performance.

6.3.2. Experiment II

Figures shown in Figure 6 illustrate the average throughput and latency for GetBallot and CastVote functions for varying total numbers of transactions. The results indicate that there is no significant impact on total number of transactions, as long as the send rate remains below the scheme’s peak throughput. As send rates increase beyond the peak throughput, the impact of the number of transactions increases. As seen in Figure 6a,b, an increase to the transaction send rate before reaching the peak throughput of approximately 200 tps for GetBallot does not result in different throughput or latency between different volumes of total transactions. After the peak throughput is surpassed differences in performance emerge depending on the total transaction volume. There is not a clear relationship between transaction count and how throughput degrades after the send rate surpasses optimal throughput. For GetBallot, we observed that the throughput at high send rates was generally better for a total of 1000 tx than 20,000 tx, but this was not the case for CastVote. This could result from inconsistencies that arise in performance when max throughput is exceeded. For average latency, the impact of transaction count is more clear. As seen in Figure 6c,d, there is an increase in latency as the transaction count increased for CastVote. This is also seen in Figure 6a,b for GetBallot, with the exception of the observed latency at 20,000 total transactions, which is lower than the latency at 10,000 tx. These results are generalized as follows:

• When the transaction send rate is lower than the peak throughput, increasing the number of transactions has no impact on throughput or latency.
• After the peak throughput is surpassed, increasing the number of transactions decreases the throughput and increases the average latency.

6.3.3. Experiment III

Figure 7 shows the measured error rate for the GetBallot and CastVote functions at varying transaction send rates and transaction totals. The results indicate that the number of transactions and transaction send rate impact the error rate in conjunction. For a total number of transactions below 10,000, neither tested function ever dropped or rejected a transaction for every send rate tested. At 10,000 transactions submitted, the error rate for the GetBallot function rose minimally when the send rate passed the scheme’s peak throughput measured in Experiment I. For 10,000 total transactions, the error rate for the CastVote function rose quickly once the send rate passed the scheme’s peak throughput measured in Experiment I. The results are generalized as follows:

• Errors are unlikely to occur when transactions are submitted to the scheme at/or below its peak throughput.
• Error rate follows the same trend as latency, rising only when the transaction send rates eclipse the scheme’s peak throughput.
• Error rate increases when large numbers of transactions are being processed (i.e., 10,000).

We have concluded that our scheme is scalable up to 10,000 voters as long as user interaction is capped on a transaction per second basis. For usages such as fetching election results, if user interaction is capped to 200 transactions per second, users will experience little to no latency with our scheme, and no queries are likely to be dropped. For casting votes, if user interaction is capped to 75 transactions per second, users will experience minimal latency, and no votes are likely to be lost. These results also prove the feasibility of using the IBM Cloud to host our Hyperledger Fabric blockchain. As discussed in [33], Hyperledger Fabric itself is scalable, but now we can conclude that hosting Hyperledger Fabric on the IBM Cloud is also scalable, even when constrained by operating cost. As noted previously in this paper, we leveraged the free tier Kubernetes service on the IBM Cloud. This gave us minimal operating capacity, and with a larger budget, more scalability could be expected. To determine the exact scalability of a higher-tier service, however, further performance testing would be required.

7. Security and Privacy Analysis

In this section, security and privacy concerns are discussed, and how the proposed scheme is mitigating them.

Proposition 1.

The proposed scheme protects the privacy of voters.

Proof. 

A voter can interact with the blockchain with a one-request-only blockchain address obtained using blind signatures. The votes’ privacy is protected by encrypting them using the Verifiable Aggregator Oblivious Encryption. Only the voter who submitted his/her vote can know the exact vote and no one including the blockchain nodes can get access to the private information of the voters. □

Proposition 2.

Our scheme ensures election fairness.

Proof. 

This is because the votes are encrypted and no one can access the votes that have been cast. Only the election results can be obtained by using the $\mathit{AggrDec}$, as explained in detail in Section 5.4. Because the votes are in an encrypted format, only the tally of the election can be obtained to protect the individual votes of the voters. □

Proposition 3.

The proposed scheme is secure against single-point-of-failure attacks.

Proof. 

This is due to the underlying blockchain that is used to run the scheme. Our proposed e-voting scheme allows small businesses and governments alike to run an election in a transparent, decentralized, and secure manner. □

8. Conclusions

This paper proposed and implemented a decentralized e-voting scheme that offers a robust and accessible alternative to traditional paper ballots. Our scheme provides a scalable and flexible solution to secure online voting. By using the private Hyperledger Fabric blockchain hosted on the IBM cloud, we presented a secure and private scheme that can be implemented with little technical knowledge at a reasonable cost to users. In our scheme, no one can link a vote to a specific voter because the voters interact using random generated addresses with the blockchain. This blockchain address is a one-time pseudonym generated by the voters, and it cannot reveal the voters’ real identity. Analysis and performance evaluations were taken to prove the feasibility of our scheme. Our testing identified the throughput and election size limitations of our hardware, the impact of throughput and transaction count on latency and error rates, as well as the differing performance characteristics of read and write operations on the network. The results show that even when using minimal resources in the cloud, it is feasible to run an election with thousands of participants with concurrent vote transactions.

In the future, we will consider a bigger scale of elections by simulating a bigger number of transactions at higher transaction rates with increasing the number of blockchain validators. Moreover, we will expand this work to consider score voting. Score-based score voting is a special type of election that enable voters to assign a score to each candidate. Each voter gives each candidate a score within a predetermined range, such as 0 to 5. Then, the sum of the scores is added for each candidate. However, this will require extra computation and communication overheads to perform the aggregation of all scores, thus an efficient aggregation technique suitable for score voting will be further developed.