# A Practical Anonymous Voting Scheme Based on Blockchain for Internet of Energy

Authors: Houpeng Hu; Jiaxiang Ou; Bin Qian; Yi Luo; Peilin He; Mi Zhou; Zerui Chen
Journal: Security and Communication Networks
 (2022)

---

## Abstract

E-voting allows us to build a democratic business in most Internet of things (IoT) systems. For example, we may vote to choose a proper energy broker in a smart grid system. In this study, we focus on e-voting services in an Internet of energy (IoE) system, which is a new-style smart grid. A practical e-voting in IoE may focus on the properties of fairness, decentralization, eligibility, anonymity, compatibility, verifiability, and coercion resistance. It is difficult to fulfil all these properties simultaneously. Traditional voting schemes often use a public bulletin board or administrator in the voting process, which makes them become centralized. Services that offer e-voting via blockchain can make the voting schemes decentralized. However, many of them ignore the complexity of organizing the data of the transactions, which should be confirmed by the miners. Moreover, to the best of the authors’ knowledge, no works have tested the performance in the blockchain while considering practical use cases and constraints. Concerning all the challenges, we propose a practical anonymous voting scheme for IoE called IoEPAV. The proposed scheme fulfils all the mentioned design goals simultaneously. We tested IoEPAV both in different test networks of the Ethereum blockchain to give an overall evaluation. The practical evaluation can show that the proposed scheme is easy to be integrated into a real system like IoE. We also gave a comparison analysis with the state-of-the-art blockchain-based e-voting. All the results show that IoEPAV is decentralized, verifiable, anonymous, and highly efficient.


---

## Body

## 1. Introduction

The rapid development of the Internet of things (IoT)[1] promotes the development of various new intelligent network systems, i.e., smart power grid system [2]. Smart grid systems have led to a modern power network called the Internet of energy (IoE), which has drawn great interest from many countries [3]. As a kind of IoT, IoE is reshaping the energy industry into a smart industry with features of data-driven decision-making. However, the intrinsic features of IoE raise a number of challenges, such as autonomy, privacy, and decentralization [4–6]. One of the most common activities/applications in IoE is voting to make a decision.In this study, we focus on the problem of designing a voting scheme fit for an IoE system. For instance, we may vote to choose a proper energy broker in IoE system. Recently, e-voting has become attractive [7] for its convenience in building a democratic activity/business. Voting schemes in an online way called e-voting have been studied by both academic world and industry world [7, 8]. Here, we formally state the design goals, which a deemed secure e-voting scheme must hold [9]. Moreover, we extend the design goals, which particularly are required in IoE [4]. All of them are as follows:(i)
Fairness. Fair voting should assure that no one can obtain the ballot results of others before he/she has submitted his/her ballot. It means the choice of a voter cannot be influenced by those who have voted ahead.(ii)
Decentralization. Any kind of trusted third party (TTP) such as election administrators and (independent) observers should be eliminated from the voting scheme.(iii)
Eligibility. The right of a voter should be checked before he/she begins to vote. To address this, most voting schemes will verify the identities of the voters at the beginning. Moreover, every voter can cast their vote only once.(iv)
Anonymity. The privacy of voters should be protected to make sure that no one can know the owner of a ballot from the voting result at the end.(v)
Compatibility. The voting scheme should be as simple as possible to be integrated into an IoE system.(vi)
Verifiability. Contrasted with the “Anonymity” property, verifiability guarantees that all the stages of the voting can be audited by the voters. For instance, a voter should be able to check whether his/her vote has been tallied or not. Moreover, the validity of each vote should be able to be verified by anyone. It seems to be a contradiction of the “Anonymity” property, and it is difficult for a voting scheme to acquire the two properties at the same time. We will show how to address this in our scheme later.(vii)
Coercion Resistance. To avoid anyone trying to coerce the voters to vote by following their instructions, a voting scheme should be coercion-resistant.Fairness and eligibility are essential properties, which any voting scheme should fulfil. Besides, it is important to handle voting without any kind of trusted third party (TTP) in IoE due to its open and distributed features. This is a challenge for traditional e-voting schemes [10–12]. Most of them assumed that there are administrators or authorities implemented by a Web server to provide a consistent view of the results. As a result, a trusted third party is involved. Unfortunately, with a trusted third party, the protocols will be subjected to the single point of failure and are not available for a trustless environment.Fortunately, blockchain technology offers a novel way to address the challenges of IoE [13]. There are already voting schemes built based on a blockchain network [14–16]. However, new challenges are raised to design a decentralized voting protocol via blockchain in IoE [13, 17, 18]. Firstly, it is difficult to provide verifiability along with anonymity, which seems two contradictory design goals for blockchain. Secondly, the voting scheme as a basic service in IoE should be compatible with the system. Some of the proposals assume that a voter can organize the data structure of a transaction unboundedly and it seems impossible for the existed blockchain networks. We say they are not practical. Thirdly, most works use theoretical analysis without real-world generalizable experiments, and to the best of our knowledge, no works have tested the performance while considering practical use cases and constraints.Briefly, it is hard to find a solution that fulfils all the design goals mentioned above. To address this, our contributions are summarized as follows:(i)
We propose a blockchain-based decentralized anonymous voting scheme for the Internet of energy. To the best of our knowledge, our voting scheme called IoEPAV is the first work to take the key features of the IoE into account. Theoretical analysis is given to show that our proposed scheme fulfils the seven formally stated design goals and approaches to resist all the attacks in the threat models.(ii)
To make the proposed scheme practical, we use smart contracts to automate the voting process of the Internet of energy. With smart contracts, the voting scheme can be easy to integrate into the IoE system. A voter can follow the voting protocol by invoking the interfaces of the smart contracts. Any blockchain system including Ethereum 2.0, which supports smart contracts, is feasible for the proposed scheme, and we do not need to construct a whole new blockchain platform.(iii)
Compared with Yang’s state-of-the-art blockchain-based scheme, our scheme enjoys both decentralization and fewer cryptographic operations; thereafter, we conduct experiments both in the development network and two live testnet of the Ethereum blockchain and the experiment shows that we have implemented a simple, effective, accurate, and low-cost decentralized trusted anonymous voting scheme.The rest of this study is arranged as follows. In Section2, we give the related work of the e-voting service. In Section 3, we introduce the necessary preliminary knowledge. In Section 4, we give our system model and security analysis. In Section 6, we provide an evaluation of the development network and testnet of the Ethereum blockchain. Finally, in Section 7 we draw a brief conclusion.


## 2. Related Work

To address the problem of large-scale elections, Fujioka et al. [12] presented a classic voting protocol in 1992. Their voting scheme is thought to be practical and solves the privacy and fairness problems. Thereafter, Ohkubo et al. [19] tried to decrease the voting round complexity to get a more convenient voting scheme for the voters than that presented by Fujioka. They introduced a kind of distributed talliers in their scheme. As an extension of the voting scheme proposed by Fujioka, a new coercion-resistant voting scheme offered by [20] in 2017 is provided and is an efficient scheme.Since a kind of trusted third party (TTP) such as election administrators and (independent) observers was introduced in these practical voting schemes, solutions using blockchain technology have become a refreshed framework for voters to address the issues of fraud and corruption. In 2018, Srivastava et al. [21] proposed a voting model via blockchain to alleviate known problems in voting systems. Follow My Vote [14] provides a secure online voting platform based on blockchain. Follow My Vote has the capacity to audit the ballot box and watch the real-time voting progress. Another organization Agora [15] proposed a digital voting system using blockchain, where votes will be recorded to various layers, assuring that the voting result could not have been tampered with. Braghin et al. [22] studied various consensus algorithms and cryptographic primitives such as homomorphic encryption and one-time ring signature, which solved the cryptographic problem of security conflicts, thus improving the security of voting system and making voting system more secure in a wider range.To ensure security, privacy, and public verifiability of the whole progress, [16, 23] presented a new voting protocol that does not rely on any TTP. In [16], the authors employ a novel encryption mechanism to encrypt each vote. Proofs are generated for each encrypted vote as well. All the proofs will be stored in a blockchain, and everyone can check the validity of these proofs. They provided a performance and security analysis, which is claimed to show that the voting protocol is feasible for real-life elections. However, the implementation does not include the part interacting with the blockchain, and we cannot see the results in a real system. Table 1 gives an overall comparison of similar systems.Table 1
Property comparison.
ProtocolFairnessDecentralizationEligibilityAnonymityCompatibilityVerifiabilityCoercion resistanceFujioka et al. [12]✓✓✓✓Ohkubo et al. [19]✓✓✓✓Grontas et al. [20]✓✓✓✓✓Follow My Vote [14]✓✓✓✓Yang et al. [16]✓✓✓✓✓✓IoEPAV✓✓✓✓✓✓✓


## 3. Preliminaries

### 3.1. Commitments and Voting

Commitment also called cryptographic commitment [24] is an important cryptographic primitive that has many applications. Here is an example to show the relationship between commitments and votes. Think about a situation that Voter 1 and Voter 2 decide to participate in a voting behavior along with others. In this scenario, the voting institution responsible for counting the votes uses a sealed vote, which generally works as follows: each voter submits a secret sealed vote for the candidate. Once all the votes have been cast, they can be counted. The voting mechanism has good game-theoretic properties, provided that voters do not collude and do not know each other’s votes until the voting close. Therefore, a sealed vote is required.Next, we consider how to do sealed voting when some voters are of outfield and communicate with the voting institution throughout the Internet. Here, a cryptographic commitment helps. To make it simple, we assume that there are two parties in a commitment schemeCommit. Let Alice be one party, who can firstly publish a string c as a commitment for a message m∈M. Then, with the property of cryptographic commitment, Alice can make other party, i.e., Bob, believe that the committed message was m, by opening the commitment. Generally speaking, a cryptographic commitment Commit consists of algorithms C,V that(i)
On inputm∈M, the message to be committed, Algorithm Cm outputs two strings c,o, and we call c the commitment string and o the opening string.(ii)
On inputm∈M and c,o, Algorithm V outputs accept or reject indicating whether the committed message was m.Alice firstly inputs a messagem∈m and calls Algorithm C to calculate c,o. She sends the commitment string c to Bob and keeps the opening string o secret. Later, when Alice wants to open the commitment, she sends Bob m and o. Finally, Bob can verify whether the committed message was m by running Algorithm V.A secure cryptographic commitment schemeCommit is required to satisfy the following two properties:(i)
Binding. Binding requires that a commitment does not disclose any additional information about the message. In particular, assume the adversaryA outputs a 5-tuple c,m1,o1,m2,o2, and we require the advantage that BINDadvA,C:=Prm1≠m2 and Vm1,c,o1=Vm2,c,o2=accept is negligible.(ii)
Hiding. Hiding requires that different messages do not produce the same commitment.We use semantic security definition to formalize this. In particular, two games are performed between an adversaryA and a challenger, denoted as Game 0 and Game 1. Let b=0,1, in the Game b, and the adversary A first outputs m0,m1∈M, inputs a message mb∈M, calls Algorithm C to calculate c,o, and passes c to A. Finally, A outputs a guess b^∈0,1. For b=0,1, Wb is defined as the case, where A outputs 1 in Game b. We require that the advantage that(1)BINDadvA,C:=PrW0−PrW1,is negligible.


### 3.2. Blind Signature

According to the description in [25, 26], a cryptography blind signature is a kind of digital signature where the original message should be blinded (disguised) before being signed. Then, the signer will sign on the blinded message in a way like a conventional digital signature and output a blind signature. Then, the requester can generate a corresponding signature for the original message. In the end, the signature can be verified by everyone in a way like a conventional digital signature. The technique is usually used to provide a kind of privacy protection when the message requester and signer are not the same. For example, blind signatures can be used in an election system.In a general signature scheme illustrated in Figure1, the signer produces a digital signature on known message content. Compared with the general signature scheme, the process of blind signature [27] is as illustrated in Figure 2. The requester performs a blinding shift on the message before sending it to the signer. The signer who then signs on the blinded message will generate a blind signature and send it to the requester.Figure 1
A general signature scheme.Figure 2
Blind signature scheme.A general signature scheme is shown in Figure1, in which a signer can generate a digital signature on a known message. Unlike a signature scheme, the process of blind signature is shown in Figure 2, in which the requester first blinds the message before it is sent to the signer, and then, the signer signs the blind message and sends a blind signature to the requester. With the blind signature, the requester can generate an unblinded signature for the original message.In our voting scheme, we use the blind signature scheme of elliptic curve cryptography (ECC) and adopt the secp256k1 [28] elliptic curve. Elliptic curve domain parameters over Fp are a sextuple: Tp,a,b,G,n,h consisting of an integer p specifying the finite field Fp and two elements a,b∈Fp specifying an elliptic curve EFp defined by the following equation:(2)E:y2≡x3+ax+bmodp.G is a base point on EFp, n is the order of G, h is the cofactor where h=#EFp/n, and ℤn represents the integer not more than n. Suppose that d,P is an asymmetric key pair of the signer, the message is m, and all else is as has been defined.In particular, we consider the blind signature algorithm provided by Zhang et al. [27] as follows:(i)
(1) Letk∈ℤn be an integer randomly selected by the signer, which calculates R=kG. Then, the signer sends R to the requester.(ii)
(2) Firstly, the requester selects two integersγ and δ∈ℤn randomly and computes A=kG+γG+δP=x,y,t=xmodn. It checks whether t equals zero. If so, the requester reselects γ and δ . Then, it computes c=SHA256m‖t and c^=c−δ; here, SHA256 [29] is a cryptography hash function. Finally, the requester sends c^ to the signer as the blinded message.(iii)
(3) The signer generates a blind signatures^=k−c^d using the blinded message and sends to the requester.(iv)
(4) On receivings^, the requester computes s=s^+γ, and along with the above c, the requester gets a signature c,s for the original message m.(v)
(5) Anyone can verify the signaturec,s by checking the following equation:(3)c=SHA256mRxcP+sGmodn.Note that hereRxcP+sGmodn means we get the x resolution values of point cP+sG, and || means we concatenate two strings.


### 3.3. Blockchain

Maintained by many mutual untrusted parties, the leger of a blockchain generally captures the characteristics of decentralization, tamper proof, and traceability. Blockchain technology is an underlying technology of the famous cryptocurrency Bitcoin [30] and has been a prominent development in the past decade. Consequently, many applications are built based on blockchain to acquire the characteristics, so as our proposed voting protocol in this study. The key notations of blockchain technology are as follows:(i)
Ledger. As the name implies, the ledger is used to manage data such as accounts and transaction flow and supports functions such as classified bookkeeping, account reconciliation, and clearing and settlement. In multiparty cooperation, multiple participants hope to jointly maintain and share a timely, correct, and secure distributed ledger to eliminate information asymmetry, improve operational efficiency, and ensure capital and business security. The blockchain is usually regarded as a core technology for building a “distributed shared ledger.” Through the joint of a series of technologies such as chained block data structures, multiparty consensus mechanisms, smart contracts, and world state storage, it can achieve a shared ledger that is consistent, credible, transactionally secure, and difficult to tamper with. The basic contents contained in the ledger include blocks, transactions, accounts, and world states.(ii)
Block. Blocks are data structures constructed in chronological order. The new block will introduce the hash information of the previous block and then use the hash algorithm and the data of this block to generate a unique data fingerprint. The sophisticated data structure design makes the data on chain traceable and verifiable.(iii)
Transaction. A transaction can be regarded as a piece of request data sent to the blockchain system, which can be used to deploy contracts, call contract interfaces, maintain the life cycle of contracts, manage assets, and exchange value. The basic data structure of a transaction includes sender, receiver, and transaction data.(iv)
Consensus Mechanism. The consensus mechanism is a core concept in the blockchain. As a distributed system, the blockchain can be jointly calculated by different nodes, which jointly witness the execution process of transactions and confirm the final calculation results. There is a process of cooperating in the blockchain that it can make mutually untrusted participants to reach an agreement and ensure consistency. Continuous cooperation can be abstracted as a “consensus” process. The algorithms and strategies involved are collectively referred to as a consensus mechanism.(v)
Smart Contract. A smart contract refers to a contract defined in digital form that can automatically execute terms. The digital form means that the contract must be implemented in computer code. As long as the parties reach an agreement, the rights and obligations established by the smart contract will be automatically executed. Thus, the result cannot be denied. To run digital smart contracts, the blockchain system must have compilers and executors that can compile, parse, and execute computer code, collectively referred to as a virtual machine system. After the contract is written, it is compiled with a compiler, and a deployment transaction is sent to deploy the contract on the blockchain system. After the deployment transaction consensus is passed, the system assigns a unique address to the contract and saves the binary code of the contract. After the transaction is called, the virtual machine executor loads the code from the contract storage, executes it, and outputs the execution result.


## 3.1. Commitments and Voting

Commitment also called cryptographic commitment [24] is an important cryptographic primitive that has many applications. Here is an example to show the relationship between commitments and votes. Think about a situation that Voter 1 and Voter 2 decide to participate in a voting behavior along with others. In this scenario, the voting institution responsible for counting the votes uses a sealed vote, which generally works as follows: each voter submits a secret sealed vote for the candidate. Once all the votes have been cast, they can be counted. The voting mechanism has good game-theoretic properties, provided that voters do not collude and do not know each other’s votes until the voting close. Therefore, a sealed vote is required.Next, we consider how to do sealed voting when some voters are of outfield and communicate with the voting institution throughout the Internet. Here, a cryptographic commitment helps. To make it simple, we assume that there are two parties in a commitment schemeCommit. Let Alice be one party, who can firstly publish a string c as a commitment for a message m∈M. Then, with the property of cryptographic commitment, Alice can make other party, i.e., Bob, believe that the committed message was m, by opening the commitment. Generally speaking, a cryptographic commitment Commit consists of algorithms C,V that(i)
On inputm∈M, the message to be committed, Algorithm Cm outputs two strings c,o, and we call c the commitment string and o the opening string.(ii)
On inputm∈M and c,o, Algorithm V outputs accept or reject indicating whether the committed message was m.Alice firstly inputs a messagem∈m and calls Algorithm C to calculate c,o. She sends the commitment string c to Bob and keeps the opening string o secret. Later, when Alice wants to open the commitment, she sends Bob m and o. Finally, Bob can verify whether the committed message was m by running Algorithm V.A secure cryptographic commitment schemeCommit is required to satisfy the following two properties:(i)
Binding. Binding requires that a commitment does not disclose any additional information about the message. In particular, assume the adversaryA outputs a 5-tuple c,m1,o1,m2,o2, and we require the advantage that BINDadvA,C:=Prm1≠m2 and Vm1,c,o1=Vm2,c,o2=accept is negligible.(ii)
Hiding. Hiding requires that different messages do not produce the same commitment.We use semantic security definition to formalize this. In particular, two games are performed between an adversaryA and a challenger, denoted as Game 0 and Game 1. Let b=0,1, in the Game b, and the adversary A first outputs m0,m1∈M, inputs a message mb∈M, calls Algorithm C to calculate c,o, and passes c to A. Finally, A outputs a guess b^∈0,1. For b=0,1, Wb is defined as the case, where A outputs 1 in Game b. We require that the advantage that(1)BINDadvA,C:=PrW0−PrW1,is negligible.


## 3.2. Blind Signature

According to the description in [25, 26], a cryptography blind signature is a kind of digital signature where the original message should be blinded (disguised) before being signed. Then, the signer will sign on the blinded message in a way like a conventional digital signature and output a blind signature. Then, the requester can generate a corresponding signature for the original message. In the end, the signature can be verified by everyone in a way like a conventional digital signature. The technique is usually used to provide a kind of privacy protection when the message requester and signer are not the same. For example, blind signatures can be used in an election system.In a general signature scheme illustrated in Figure1, the signer produces a digital signature on known message content. Compared with the general signature scheme, the process of blind signature [27] is as illustrated in Figure 2. The requester performs a blinding shift on the message before sending it to the signer. The signer who then signs on the blinded message will generate a blind signature and send it to the requester.Figure 1
A general signature scheme.Figure 2
Blind signature scheme.A general signature scheme is shown in Figure1, in which a signer can generate a digital signature on a known message. Unlike a signature scheme, the process of blind signature is shown in Figure 2, in which the requester first blinds the message before it is sent to the signer, and then, the signer signs the blind message and sends a blind signature to the requester. With the blind signature, the requester can generate an unblinded signature for the original message.In our voting scheme, we use the blind signature scheme of elliptic curve cryptography (ECC) and adopt the secp256k1 [28] elliptic curve. Elliptic curve domain parameters over Fp are a sextuple: Tp,a,b,G,n,h consisting of an integer p specifying the finite field Fp and two elements a,b∈Fp specifying an elliptic curve EFp defined by the following equation:(2)E:y2≡x3+ax+bmodp.G is a base point on EFp, n is the order of G, h is the cofactor where h=#EFp/n, and ℤn represents the integer not more than n. Suppose that d,P is an asymmetric key pair of the signer, the message is m, and all else is as has been defined.In particular, we consider the blind signature algorithm provided by Zhang et al. [27] as follows:(i)
(1) Letk∈ℤn be an integer randomly selected by the signer, which calculates R=kG. Then, the signer sends R to the requester.(ii)
(2) Firstly, the requester selects two integersγ and δ∈ℤn randomly and computes A=kG+γG+δP=x,y,t=xmodn. It checks whether t equals zero. If so, the requester reselects γ and δ . Then, it computes c=SHA256m‖t and c^=c−δ; here, SHA256 [29] is a cryptography hash function. Finally, the requester sends c^ to the signer as the blinded message.(iii)
(3) The signer generates a blind signatures^=k−c^d using the blinded message and sends to the requester.(iv)
(4) On receivings^, the requester computes s=s^+γ, and along with the above c, the requester gets a signature c,s for the original message m.(v)
(5) Anyone can verify the signaturec,s by checking the following equation:(3)c=SHA256mRxcP+sGmodn.Note that hereRxcP+sGmodn means we get the x resolution values of point cP+sG, and || means we concatenate two strings.


## 3.3. Blockchain

Maintained by many mutual untrusted parties, the leger of a blockchain generally captures the characteristics of decentralization, tamper proof, and traceability. Blockchain technology is an underlying technology of the famous cryptocurrency Bitcoin [30] and has been a prominent development in the past decade. Consequently, many applications are built based on blockchain to acquire the characteristics, so as our proposed voting protocol in this study. The key notations of blockchain technology are as follows:(i)
Ledger. As the name implies, the ledger is used to manage data such as accounts and transaction flow and supports functions such as classified bookkeeping, account reconciliation, and clearing and settlement. In multiparty cooperation, multiple participants hope to jointly maintain and share a timely, correct, and secure distributed ledger to eliminate information asymmetry, improve operational efficiency, and ensure capital and business security. The blockchain is usually regarded as a core technology for building a “distributed shared ledger.” Through the joint of a series of technologies such as chained block data structures, multiparty consensus mechanisms, smart contracts, and world state storage, it can achieve a shared ledger that is consistent, credible, transactionally secure, and difficult to tamper with. The basic contents contained in the ledger include blocks, transactions, accounts, and world states.(ii)
Block. Blocks are data structures constructed in chronological order. The new block will introduce the hash information of the previous block and then use the hash algorithm and the data of this block to generate a unique data fingerprint. The sophisticated data structure design makes the data on chain traceable and verifiable.(iii)
Transaction. A transaction can be regarded as a piece of request data sent to the blockchain system, which can be used to deploy contracts, call contract interfaces, maintain the life cycle of contracts, manage assets, and exchange value. The basic data structure of a transaction includes sender, receiver, and transaction data.(iv)
Consensus Mechanism. The consensus mechanism is a core concept in the blockchain. As a distributed system, the blockchain can be jointly calculated by different nodes, which jointly witness the execution process of transactions and confirm the final calculation results. There is a process of cooperating in the blockchain that it can make mutually untrusted participants to reach an agreement and ensure consistency. Continuous cooperation can be abstracted as a “consensus” process. The algorithms and strategies involved are collectively referred to as a consensus mechanism.(v)
Smart Contract. A smart contract refers to a contract defined in digital form that can automatically execute terms. The digital form means that the contract must be implemented in computer code. As long as the parties reach an agreement, the rights and obligations established by the smart contract will be automatically executed. Thus, the result cannot be denied. To run digital smart contracts, the blockchain system must have compilers and executors that can compile, parse, and execute computer code, collectively referred to as a virtual machine system. After the contract is written, it is compiled with a compiler, and a deployment transaction is sent to deploy the contract on the blockchain system. After the deployment transaction consensus is passed, the system assigns a unique address to the contract and saves the binary code of the contract. After the transaction is called, the virtual machine executor loads the code from the contract storage, executes it, and outputs the execution result.


## 4. Proposed Protocol

In this subsection, we will describe a practical anonymous voting protocol via blockchain. Our scheme has all the aforementioned properties in Section1.


### 4.1. System Overview

As shown in Figure3, the voting protocol consists of four stages: initialization, voting, opening, and verifying/tally. We adopt the ECC system in our scheme, and the elliptic curve is secp256k1. This curve can be described as T=p,G,n,a,b,h, where a and b are constants, p is the p value of the finite field Fp of secp256k1, G is the base point, n is the order of G, and h is a cofactor. All these parameters are public.Figure 3
Proposed IoEPAV.


#### 4.1.1. Initialization

Anyone in the IoE system can launch voting by the proposed IoEPAV. All voters who want to join the voting should provide their public keys and identification. In the initialization stage, all the public information of the voters will be broadcasted to the blockchain through the smart contract in IoEPAV. We assume that there arenv different voters v1,v2,…,vnv. Each voter vi generates two pairs of ECC keys skvi,pkvi and sk^vi,pk^vi. Let addrvi be the public address of the voter vi in the Ethereum network, and IDvi represents the voter’s identification. Then, the public information for each voter vi is a tuple IDvi,pkvi,pk^vi,addrvi. Everyone can get this information from the blockchain to verify its validity.


#### 4.1.2. Voting

As soon as voting is launched, each votervi can start to submit their ballot. Firstly, a cryptography commitment protocol is invoked Commit=C,V. Here, we use the algorithm C and the algorithm V will be used later in the final stage. C as cvi,ovi←RCmvi is invoked for the ballot message mvi of voter vi.Then, votervi generates a c˜=c^1,c^2,…,c^nv and x˜=x^1,x^2,…,x^nv for different voters v1,v2,…,vnv, where vnv≠vi. Voter vi completes this by a blind commitment algorithm x˜,c˜←BlindXcvi,pknv˜,pknv^˜ in the blind signature protocol.LetHnv be the hash of the tuple addri,IDi,c^nv for different voters v1,v2,…,vnv, where vnv≠vi. Then, voter vi uses the ECDSA signature algorithm snv=Signski,Hnv for other different voters nv and gets a tuple of signatures s˜=s1,s2,…,snv.Then, a group information ofIDi,addri,c˜,s˜ is recorded into the blockchain through the smart contract. Note that x˜ has been saved in secret by voter vi himself in this stage. The detailed design of the algorithm C and BlindX is given in Section 4.2.OnceIDi,addri,c˜,s˜ generated by voter vi is recorded, the other voters can generate a blind signature for it. Firstly, every other voter verifies the validity of the signature snv by the ECDSA verification algorithm Verifysnv,pki. If snv is valid, then every other voter generates a blind signature dnv by a blind signature algorithm dnv←BlindSsk^nv,sknv in the blind signature protocol and sends dnv into the blockchain. Let d˜=d1,d2,…,dnv for different voters v1,v2,…,vnv where vnv≠vi.At the end of this stage, we havec˜,s˜,d˜ for a ballot mvi of voter vi. The detailed design of the algorithm BlindS will be given in Section 4.2.


#### 4.1.3. Opening

In this stage, votervi will open his/her voting commitment. Firstly, he/she gets the d˜ from the blockchain and calculates the corresponding tuple y˜=y1,y2,…,ynv for different voters v1,v2,…,vnv where vnv≠vi. Here, ynv is a signature for the original commitment cvi. Voter vi generates y˜ by calculating (4)ynv=dnv+γ,where γ is a random key saved in BlindX.Givenxnv,cvi,ynv, voter vi can verify the validity of ynv by an algorithm VerifySxnv,cvi,ynv,pknv, where xnv is saved in BlindX. Note that ynv is a signature of the commitment cvi from voter vnv. If the signature ynv is valid, then voter vi sends the open commitment string ovi and xnv to the blockchain. Note that voter vi chooses a random address in the Ethereum network to send this transaction. Anyone cannot find out who has sent this transaction. The detailed design of the algorithm VerifyS will be given in Section 4.2. Finally, we have cvi,ovi,x˜,y˜ for an original ballot mvi of voter vi in the blockchain.


#### 4.1.4. Verifying/Tally

Now, we have a voting list ofcvi,ovi,x˜,y˜ for each voter vi. Everyone can use VerifyS again to verify the voting. Note that we do not have to verify all the y˜ values for a ballot mvi of voter vi. If more than half of y˜ are valid, we think cvi,ovi is valid. Finally, we can use the Vcvi,ovi algorithm in cryptography commitment to open the original ballot mvi and tally the result of the voting.


### 4.2. Algorithm Design

In this subsection, we will describe the design of the algorithms mentioned in A in detail. To make the voting service as simple as possible to be integrated into an IoE system, we assume that anyone who tries to use the voting service can ignore the underlying design of smart contracts of the blockchain. The details are as follows:(i)
Cryptography Commitment Algorithms. To construct a cryptography commitment protocol, we should build a pair of efficient algorithmsC,V. We can do this by using a collision-resistant hash function. As shown in Algorithm 1, the algorithm C generates a 32 byte random string as the open string o in the commitment protocol. The commit string c is the hash of the original ballot m and o. Algorithm 2 is a invert process to verify whether m,o is corresponded to c. The algorithm C is used at the beginning of the “Voting” stage, while the algorithm V is used at the end of the “Verifying/Tally” stage. We will give the security analysis for this commitment protocol in Section 5.(ii)
Blind Algorithms. We divide the blind signature protocol into three algorithms. They areBlindX, BlindS, and VerifyS. As shown in Algorithm 3, BlindX is used for blinding the commit string cvi for the ballot. γ and δ are two random secret keys. G and n are the public parameters in the ECC and the commit string; the input also includes the public keys of each voter. Following the blind signature protocol mentioned in Section 3, BlindX is used to generate the blinded message s˜,c˜. At the end of BlindX, each voter keeps the secret data xj,c^j,γ,δ and sends addrvi,addrnv˜,s˜,c˜ to the blockchain.Then, in Algorithm 4,BlindS is used for the other voters to sign on c^nv submitted by voter vi in Algorithm 3. With the corresponding secret keys s⌢knv,sknv, each signer can generate a blind signature dnv as Line 8 in Algorithm 4. Then, voter vi can easily calculate the explicit signature ynv = dnv + γ for cvi. Finally, we have VerifyS as shown in Algorithm 5 to verify the validity of the signature ynv. Everyone who gets the public key of the signers from the blockchain can calculate the hash. Here, the blind signature protocol mentioned in Section III is divided into Algorithms 3 to 5.Algorithm 1: Generate commitment.
InputmOutput (c,o)(1)
o = crypto.randomBytes(32)(2)
c = SHA256(m  + serialize(o))(3)
return (c, o)Algorithm 2: Open commitment.
Inputm,c,oOutputTrue or False(1)
c^  = SHA256(m  + serialize(o));(2)
ifc≠c^then(3)
returnFalse(4)
else(5)
returnTrue(6)
end ifAlgorithm 3: BlindX.
Inputcvi,pknv^˜,pknv˜(1)
γ = crypto.randomBytes(32);(2)
δ = crypto.randomBytes(32);(3)
forj = 0 to nvdo(4)
Aj =  pk^j + γ ∗ G + pkj ∗ δ(5)
tj = getXpointFromPubkey Ajmod n(6)
xj = SHA256(cvi + tj)(7)
c^j = xj − δ(8)
c˜.pushc^j(9)
Hi = SHA256 IDi+addri+c^j)(10)
sj = secp256k1.ecdsaSign(Hi, ski)(11)
s˜.pushsj(12)
save(xj, c^j, γ, δ)(13)
end for(14)
await Contract.setAnmVote(addrvi, addrnv˜, s˜, c˜);Algorithm 4: BlindS.
Inputsk^nv,sknv(1)
(v,snv, c^nv) = await Contract.getAnmtVote addri,addrnv(2)
ifv≠addrithen(3)
Return(4)
end if(5)
H = SHA256 IDi+addri+c^nv(6)
S = secp256k1.ecdsaVerify(snv, H, pki)(7)
ifS==Truethen(8)
dnv = sk^nv − c^nv ∗ sknv(9)
else(10)
Return(11)
end if(12)
await Contract.signAnmVote(addri, dnv)Algorithm 5: VerifyS.
Inputxnv,cvi,ynv,pknvOutputTrue or False(1)
B = xnv ∗ pknv + ynv ∗ G(2)
bx = getXpointFromPubkey(B)modn(3)
H = SHA256(cvi + bx)(4)
ifH==xnvthen(5)
ReturnTrue(6)
else(7)
ReturnFalse(8)
end if


### 4.3. Smart Contract Design

In this part, we present the design of the smart contract, which provides interfaces to record the voting data into the blockchain. Thus, the smart contract should involve the necessary data structure referring to the voting scheme. Firstly, we need a data structure to record the information binding with the voter. As shown in Table2, “address, PK, PKs, and ID” are the basic public information, while the other three mapping data are corresponding to process data generated in the blind signature protocol. Table 3 is designed for storing the results in the “opening” stage. Besides, there are some other variables such as an “unit” for the number of voters. To be succinct, we do not list all of them.Table 2
Structure of a voter.
Data typeDescriptionaddressvoterstringPKstringPKsstringIDmapping(address⇒  string)simapping(address⇒  string)ci_pimapping(address⇒  string)dsigsTable 3
Structure of an open result.
Data typeDescriptionstringmstringbmstringoimapping(address⇒  string)cimapping(address⇒  string)yisboolisFinishedRecall that there are four stages in the whole voting scheme, namely, initialization, voting, opening, and verifying/tally. Then, the smart contract should afford the necessary interfaces for them to interact with the blockchain. The interfaces can be classified into two types: “Write” for recording information into the blockchain and “Query” for querying information from the blockchain. We have 11 interfaces in our smart contract. Considering the space of the paper, only those critical functions are given in detail. However, it is enough for the readers to understand the whole protocol. In the stage “Initialization,” a kind of “Write” function is used to record the public identity information of a voter. Then, in the stage “Voting,” a “Write” interface named “setAnmVote” is used to record the blind commitment generated in Algorithm3. As shown in Algorithm 6, iV and iS are the accounts in the Ethereum blockchain that represents a voter’s address and a potential signer’s address separately. isi and ici_pi are data generated in “BlindX.” voters is an array corresponding to the data structure in Table 2. The requirement in Line 1 makes sure that only the voter himself can set the data. Once the data have been recorded, no one can reset it including the voter himself.Algorithm 6: setAnmVote.
InputiV,addr˜,s˜,c˜(1)
require(msg.sender = =iV);(2)
fori = 0 to nvdo(3)
iS = addr˜ [i];(4)
isi = s˜ [i];(5)
ici_pi  = c˜ [i];(6)
require(votersiV.si iS) = = 0);(7)
votersiV.si iS = isi;(8)
votersiV.ci_pi iS = ici_pi;(9)
end forAs soon as the data are confirmed by the blockchain, the other voters acting as a signer will try to generate a blind signature for the commitment. The algorithm for a signer to generate a blind signature is described in Algorithm 4. Firstly, a signer will use “getAnmVote” in Algorithm7 to query the commitment data generated for him. Anyone can query the commitment according to the public Ethereum account address. In the end, the signer will submit his blind signature idsig through “signAnmVote” in Algorithm 8. Similarly, the requirement in Line 1 makes sure that only the signer himself can set the corresponding data. Once the signature has been recorded, no one can reset it including the signer himself.Algorithm 7: getAnmVote.
InputiV,iSOutputV,S,isi,ici_pi(1)
return (votersiV.voter, voters iV.si iS, users iV.ci_pi iS);Algorithm 8: signAnmVote.
InputiV,idsig(1)
require(votersiV.voter.isvaild() and users iV.dsigs[msg.sender]).length = = 0);(2)
votersiV.dsigs[msg.sender] =  idsig;The design ideas of the other interfaces are similar to these algorithms given above. When “Write” information to the blockchain, necessary conditions are set. Then, anyone can check the data from the blockchain by the kind of “Query” interface.


## 4.1. System Overview

As shown in Figure3, the voting protocol consists of four stages: initialization, voting, opening, and verifying/tally. We adopt the ECC system in our scheme, and the elliptic curve is secp256k1. This curve can be described as T=p,G,n,a,b,h, where a and b are constants, p is the p value of the finite field Fp of secp256k1, G is the base point, n is the order of G, and h is a cofactor. All these parameters are public.Figure 3
Proposed IoEPAV.


### 4.1.1. Initialization

Anyone in the IoE system can launch voting by the proposed IoEPAV. All voters who want to join the voting should provide their public keys and identification. In the initialization stage, all the public information of the voters will be broadcasted to the blockchain through the smart contract in IoEPAV. We assume that there arenv different voters v1,v2,…,vnv. Each voter vi generates two pairs of ECC keys skvi,pkvi and sk^vi,pk^vi. Let addrvi be the public address of the voter vi in the Ethereum network, and IDvi represents the voter’s identification. Then, the public information for each voter vi is a tuple IDvi,pkvi,pk^vi,addrvi. Everyone can get this information from the blockchain to verify its validity.


### 4.1.2. Voting

As soon as voting is launched, each votervi can start to submit their ballot. Firstly, a cryptography commitment protocol is invoked Commit=C,V. Here, we use the algorithm C and the algorithm V will be used later in the final stage. C as cvi,ovi←RCmvi is invoked for the ballot message mvi of voter vi.Then, votervi generates a c˜=c^1,c^2,…,c^nv and x˜=x^1,x^2,…,x^nv for different voters v1,v2,…,vnv, where vnv≠vi. Voter vi completes this by a blind commitment algorithm x˜,c˜←BlindXcvi,pknv˜,pknv^˜ in the blind signature protocol.LetHnv be the hash of the tuple addri,IDi,c^nv for different voters v1,v2,…,vnv, where vnv≠vi. Then, voter vi uses the ECDSA signature algorithm snv=Signski,Hnv for other different voters nv and gets a tuple of signatures s˜=s1,s2,…,snv.Then, a group information ofIDi,addri,c˜,s˜ is recorded into the blockchain through the smart contract. Note that x˜ has been saved in secret by voter vi himself in this stage. The detailed design of the algorithm C and BlindX is given in Section 4.2.OnceIDi,addri,c˜,s˜ generated by voter vi is recorded, the other voters can generate a blind signature for it. Firstly, every other voter verifies the validity of the signature snv by the ECDSA verification algorithm Verifysnv,pki. If snv is valid, then every other voter generates a blind signature dnv by a blind signature algorithm dnv←BlindSsk^nv,sknv in the blind signature protocol and sends dnv into the blockchain. Let d˜=d1,d2,…,dnv for different voters v1,v2,…,vnv where vnv≠vi.At the end of this stage, we havec˜,s˜,d˜ for a ballot mvi of voter vi. The detailed design of the algorithm BlindS will be given in Section 4.2.


### 4.1.3. Opening

In this stage, votervi will open his/her voting commitment. Firstly, he/she gets the d˜ from the blockchain and calculates the corresponding tuple y˜=y1,y2,…,ynv for different voters v1,v2,…,vnv where vnv≠vi. Here, ynv is a signature for the original commitment cvi. Voter vi generates y˜ by calculating (4)ynv=dnv+γ,where γ is a random key saved in BlindX.Givenxnv,cvi,ynv, voter vi can verify the validity of ynv by an algorithm VerifySxnv,cvi,ynv,pknv, where xnv is saved in BlindX. Note that ynv is a signature of the commitment cvi from voter vnv. If the signature ynv is valid, then voter vi sends the open commitment string ovi and xnv to the blockchain. Note that voter vi chooses a random address in the Ethereum network to send this transaction. Anyone cannot find out who has sent this transaction. The detailed design of the algorithm VerifyS will be given in Section 4.2. Finally, we have cvi,ovi,x˜,y˜ for an original ballot mvi of voter vi in the blockchain.


### 4.1.4. Verifying/Tally

Now, we have a voting list ofcvi,ovi,x˜,y˜ for each voter vi. Everyone can use VerifyS again to verify the voting. Note that we do not have to verify all the y˜ values for a ballot mvi of voter vi. If more than half of y˜ are valid, we think cvi,ovi is valid. Finally, we can use the Vcvi,ovi algorithm in cryptography commitment to open the original ballot mvi and tally the result of the voting.


## 4.1.1. Initialization

Anyone in the IoE system can launch voting by the proposed IoEPAV. All voters who want to join the voting should provide their public keys and identification. In the initialization stage, all the public information of the voters will be broadcasted to the blockchain through the smart contract in IoEPAV. We assume that there arenv different voters v1,v2,…,vnv. Each voter vi generates two pairs of ECC keys skvi,pkvi and sk^vi,pk^vi. Let addrvi be the public address of the voter vi in the Ethereum network, and IDvi represents the voter’s identification. Then, the public information for each voter vi is a tuple IDvi,pkvi,pk^vi,addrvi. Everyone can get this information from the blockchain to verify its validity.


## 4.1.2. Voting

As soon as voting is launched, each votervi can start to submit their ballot. Firstly, a cryptography commitment protocol is invoked Commit=C,V. Here, we use the algorithm C and the algorithm V will be used later in the final stage. C as cvi,ovi←RCmvi is invoked for the ballot message mvi of voter vi.Then, votervi generates a c˜=c^1,c^2,…,c^nv and x˜=x^1,x^2,…,x^nv for different voters v1,v2,…,vnv, where vnv≠vi. Voter vi completes this by a blind commitment algorithm x˜,c˜←BlindXcvi,pknv˜,pknv^˜ in the blind signature protocol.LetHnv be the hash of the tuple addri,IDi,c^nv for different voters v1,v2,…,vnv, where vnv≠vi. Then, voter vi uses the ECDSA signature algorithm snv=Signski,Hnv for other different voters nv and gets a tuple of signatures s˜=s1,s2,…,snv.Then, a group information ofIDi,addri,c˜,s˜ is recorded into the blockchain through the smart contract. Note that x˜ has been saved in secret by voter vi himself in this stage. The detailed design of the algorithm C and BlindX is given in Section 4.2.OnceIDi,addri,c˜,s˜ generated by voter vi is recorded, the other voters can generate a blind signature for it. Firstly, every other voter verifies the validity of the signature snv by the ECDSA verification algorithm Verifysnv,pki. If snv is valid, then every other voter generates a blind signature dnv by a blind signature algorithm dnv←BlindSsk^nv,sknv in the blind signature protocol and sends dnv into the blockchain. Let d˜=d1,d2,…,dnv for different voters v1,v2,…,vnv where vnv≠vi.At the end of this stage, we havec˜,s˜,d˜ for a ballot mvi of voter vi. The detailed design of the algorithm BlindS will be given in Section 4.2.


## 4.1.3. Opening

In this stage, votervi will open his/her voting commitment. Firstly, he/she gets the d˜ from the blockchain and calculates the corresponding tuple y˜=y1,y2,…,ynv for different voters v1,v2,…,vnv where vnv≠vi. Here, ynv is a signature for the original commitment cvi. Voter vi generates y˜ by calculating (4)ynv=dnv+γ,where γ is a random key saved in BlindX.Givenxnv,cvi,ynv, voter vi can verify the validity of ynv by an algorithm VerifySxnv,cvi,ynv,pknv, where xnv is saved in BlindX. Note that ynv is a signature of the commitment cvi from voter vnv. If the signature ynv is valid, then voter vi sends the open commitment string ovi and xnv to the blockchain. Note that voter vi chooses a random address in the Ethereum network to send this transaction. Anyone cannot find out who has sent this transaction. The detailed design of the algorithm VerifyS will be given in Section 4.2. Finally, we have cvi,ovi,x˜,y˜ for an original ballot mvi of voter vi in the blockchain.


## 4.1.4. Verifying/Tally

Now, we have a voting list ofcvi,ovi,x˜,y˜ for each voter vi. Everyone can use VerifyS again to verify the voting. Note that we do not have to verify all the y˜ values for a ballot mvi of voter vi. If more than half of y˜ are valid, we think cvi,ovi is valid. Finally, we can use the Vcvi,ovi algorithm in cryptography commitment to open the original ballot mvi and tally the result of the voting.


## 4.2. Algorithm Design

In this subsection, we will describe the design of the algorithms mentioned in A in detail. To make the voting service as simple as possible to be integrated into an IoE system, we assume that anyone who tries to use the voting service can ignore the underlying design of smart contracts of the blockchain. The details are as follows:(i)
Cryptography Commitment Algorithms. To construct a cryptography commitment protocol, we should build a pair of efficient algorithmsC,V. We can do this by using a collision-resistant hash function. As shown in Algorithm 1, the algorithm C generates a 32 byte random string as the open string o in the commitment protocol. The commit string c is the hash of the original ballot m and o. Algorithm 2 is a invert process to verify whether m,o is corresponded to c. The algorithm C is used at the beginning of the “Voting” stage, while the algorithm V is used at the end of the “Verifying/Tally” stage. We will give the security analysis for this commitment protocol in Section 5.(ii)
Blind Algorithms. We divide the blind signature protocol into three algorithms. They areBlindX, BlindS, and VerifyS. As shown in Algorithm 3, BlindX is used for blinding the commit string cvi for the ballot. γ and δ are two random secret keys. G and n are the public parameters in the ECC and the commit string; the input also includes the public keys of each voter. Following the blind signature protocol mentioned in Section 3, BlindX is used to generate the blinded message s˜,c˜. At the end of BlindX, each voter keeps the secret data xj,c^j,γ,δ and sends addrvi,addrnv˜,s˜,c˜ to the blockchain.Then, in Algorithm 4,BlindS is used for the other voters to sign on c^nv submitted by voter vi in Algorithm 3. With the corresponding secret keys s⌢knv,sknv, each signer can generate a blind signature dnv as Line 8 in Algorithm 4. Then, voter vi can easily calculate the explicit signature ynv = dnv + γ for cvi. Finally, we have VerifyS as shown in Algorithm 5 to verify the validity of the signature ynv. Everyone who gets the public key of the signers from the blockchain can calculate the hash. Here, the blind signature protocol mentioned in Section III is divided into Algorithms 3 to 5.Algorithm 1: Generate commitment.
InputmOutput (c,o)(1)
o = crypto.randomBytes(32)(2)
c = SHA256(m  + serialize(o))(3)
return (c, o)Algorithm 2: Open commitment.
Inputm,c,oOutputTrue or False(1)
c^  = SHA256(m  + serialize(o));(2)
ifc≠c^then(3)
returnFalse(4)
else(5)
returnTrue(6)
end ifAlgorithm 3: BlindX.
Inputcvi,pknv^˜,pknv˜(1)
γ = crypto.randomBytes(32);(2)
δ = crypto.randomBytes(32);(3)
forj = 0 to nvdo(4)
Aj =  pk^j + γ ∗ G + pkj ∗ δ(5)
tj = getXpointFromPubkey Ajmod n(6)
xj = SHA256(cvi + tj)(7)
c^j = xj − δ(8)
c˜.pushc^j(9)
Hi = SHA256 IDi+addri+c^j)(10)
sj = secp256k1.ecdsaSign(Hi, ski)(11)
s˜.pushsj(12)
save(xj, c^j, γ, δ)(13)
end for(14)
await Contract.setAnmVote(addrvi, addrnv˜, s˜, c˜);Algorithm 4: BlindS.
Inputsk^nv,sknv(1)
(v,snv, c^nv) = await Contract.getAnmtVote addri,addrnv(2)
ifv≠addrithen(3)
Return(4)
end if(5)
H = SHA256 IDi+addri+c^nv(6)
S = secp256k1.ecdsaVerify(snv, H, pki)(7)
ifS==Truethen(8)
dnv = sk^nv − c^nv ∗ sknv(9)
else(10)
Return(11)
end if(12)
await Contract.signAnmVote(addri, dnv)Algorithm 5: VerifyS.
Inputxnv,cvi,ynv,pknvOutputTrue or False(1)
B = xnv ∗ pknv + ynv ∗ G(2)
bx = getXpointFromPubkey(B)modn(3)
H = SHA256(cvi + bx)(4)
ifH==xnvthen(5)
ReturnTrue(6)
else(7)
ReturnFalse(8)
end if


## 4.3. Smart Contract Design

In this part, we present the design of the smart contract, which provides interfaces to record the voting data into the blockchain. Thus, the smart contract should involve the necessary data structure referring to the voting scheme. Firstly, we need a data structure to record the information binding with the voter. As shown in Table2, “address, PK, PKs, and ID” are the basic public information, while the other three mapping data are corresponding to process data generated in the blind signature protocol. Table 3 is designed for storing the results in the “opening” stage. Besides, there are some other variables such as an “unit” for the number of voters. To be succinct, we do not list all of them.Table 2
Structure of a voter.
Data typeDescriptionaddressvoterstringPKstringPKsstringIDmapping(address⇒  string)simapping(address⇒  string)ci_pimapping(address⇒  string)dsigsTable 3
Structure of an open result.
Data typeDescriptionstringmstringbmstringoimapping(address⇒  string)cimapping(address⇒  string)yisboolisFinishedRecall that there are four stages in the whole voting scheme, namely, initialization, voting, opening, and verifying/tally. Then, the smart contract should afford the necessary interfaces for them to interact with the blockchain. The interfaces can be classified into two types: “Write” for recording information into the blockchain and “Query” for querying information from the blockchain. We have 11 interfaces in our smart contract. Considering the space of the paper, only those critical functions are given in detail. However, it is enough for the readers to understand the whole protocol. In the stage “Initialization,” a kind of “Write” function is used to record the public identity information of a voter. Then, in the stage “Voting,” a “Write” interface named “setAnmVote” is used to record the blind commitment generated in Algorithm3. As shown in Algorithm 6, iV and iS are the accounts in the Ethereum blockchain that represents a voter’s address and a potential signer’s address separately. isi and ici_pi are data generated in “BlindX.” voters is an array corresponding to the data structure in Table 2. The requirement in Line 1 makes sure that only the voter himself can set the data. Once the data have been recorded, no one can reset it including the voter himself.Algorithm 6: setAnmVote.
InputiV,addr˜,s˜,c˜(1)
require(msg.sender = =iV);(2)
fori = 0 to nvdo(3)
iS = addr˜ [i];(4)
isi = s˜ [i];(5)
ici_pi  = c˜ [i];(6)
require(votersiV.si iS) = = 0);(7)
votersiV.si iS = isi;(8)
votersiV.ci_pi iS = ici_pi;(9)
end forAs soon as the data are confirmed by the blockchain, the other voters acting as a signer will try to generate a blind signature for the commitment. The algorithm for a signer to generate a blind signature is described in Algorithm 4. Firstly, a signer will use “getAnmVote” in Algorithm7 to query the commitment data generated for him. Anyone can query the commitment according to the public Ethereum account address. In the end, the signer will submit his blind signature idsig through “signAnmVote” in Algorithm 8. Similarly, the requirement in Line 1 makes sure that only the signer himself can set the corresponding data. Once the signature has been recorded, no one can reset it including the signer himself.Algorithm 7: getAnmVote.
InputiV,iSOutputV,S,isi,ici_pi(1)
return (votersiV.voter, voters iV.si iS, users iV.ci_pi iS);Algorithm 8: signAnmVote.
InputiV,idsig(1)
require(votersiV.voter.isvaild() and users iV.dsigs[msg.sender]).length = = 0);(2)
votersiV.dsigs[msg.sender] =  idsig;The design ideas of the other interfaces are similar to these algorithms given above. When “Write” information to the blockchain, necessary conditions are set. Then, anyone can check the data from the blockchain by the kind of “Query” interface.


## 5. Security Analysis

In this section, we will discuss why our protocol can resist the potential attacks in the threat models and fulfil all the design goals in Section3.


### 5.1. Threat Models

In our scheme, we suppose a voter is a rational one, which means he/she would not let their right to vote become invalid by doing something obviously break the protocol. For instance, a voter should submit his/her blind signature for other voters’ ballots correctly; otherwise, his/her right to vote will be thought invalid. Here, we present the threat model specially for a voting service.(1)
Voter Model. Although a voter is a rational one, he/she may try to lead the voting result in his/her favour without breaking the rule of the protocol. First, since the voting is anonymous, a voter may attempt to submit a duplicate ballot to increase his/her chance to vote. Second, because each voter will blindly sign on the blinded ballots, it is possible for a voter to attempt to change the original ballot after the corresponding blind ballot has been blindly signed by others. It means any vulnerability of the blind signature protocol will defeat the whole voting scheme. Third, knowing other voters’ public identities, a voter may look for ways to let others’ legal ballots become invalid by forging others’ ballots.(2)
Adversary Model. An adversary can be anyone who is a user of the IoE system. First, an adversary may attempt to affect other voters’ choices through vote buying, voter coercion, and so on. Second, there is a possibility for an adversary to stop an eligible voter from performing the process of the voting protocol. For example, voters can be subjected to DDoS attacks, causing them to malfunction. Third, an adversary may attempt to tamper with the result of the voting.(3)
Blockchain System Model. Attacks against the blockchain system may also cause the failure of the voting scheme, since it is based on the blockchain.


### 5.2. Cryptography Commitment

A cryptographic commitment schemeCommit=C,V is secure when it is both hiding and binding. In our scheme, we constructed the cryptographic commitment using a collision-resistant hash function H (in out construction, we use SHA256).We now prove that the binding commitmentCH satisfies two properties based on the assumption that H is collision-resistant.(i)
Binding Proof. The binding commitmentCH is a binding commitment if H is collision-resistant. This can be shown immediately as follows: if there exists an adversary A that breaks the binding property, it will immediately give a collision for H. More precisely, for some commitment string c, assume A outputs two pairs m1,o1 and m2,o2, where m1≠m2, but Vm1,c,o1=vm2,c,o2 = accept. Thereafter, we have a collision for H that Hh1,o1=c=Hm2,o2. So, we can say that CH is computationally binding since it depends on a computational assumption for solving this collision for H.(ii)
Hiding Proof. We first consider input hiding required that the distributionHm1,o is statistically indistinguishable from the distribution Hm2,o for all m1,m2∈M, where o←rR. In our construction, once H is collision-resistant and if the set R is large enough, it is considered input hiding. For example, R=0,1512 should be sufficient for SHA256. This provides a way to build a secure and practical commitment scheme from SHA256. Then, if H is input hiding, no adversary even an unbounded adversary A can break the security of its derived commitment scheme CH. So, we can say that CH is unconditionally hiding.


### 5.3. Blind Signature

The blind signature protocol we used in our scheme is recalled as follows:(i)
(1) The signernv randomly generates two pair keys sknv,pknv and sk^nv,pk^nv and pknv,pk^nv are public to the requester vi.(ii)
(2) The requester selects two integersγ and δ∈ℤn randomly and computes A=pk^nv+γ∗G+δ∗pknv=xp,yp,t=xpmodn. It checks whether t equals zero. If so, the requester reselects γ and δ. Then, it computes x=SHA256cvi‖t and c^=x−δ, where SHA256 is a hash function with 32 bit words and cvi is the commitment generated by voter vi. Finally, the requester sends c^ to the signer as the blinded message.(iii)
(3) The signer generates a blind signatured=sk^nv−c^∗sknv using the blinded message and sends to the requester.(iv)
(4) On receivingd, the requester computes y=d+γ, and with its above x, the requester gets a signature x,y for the original message cvi.(v)
(5) Anyone can verify the signaturex,y by checking the following equation: x=SHA256cvi‖Rxx∗pknv+yGmodn.Correctness Proof. Firstly, we prove the signaturex,y to be valid as follows:(5)Rxx∗pknv+yGmodn,=Rxx∗pknv+d∗G+γ∗Gmodn,=Rxx∗pknv+sk^nv∗G−c^∗sknv∗G+γ∗Gmodn,=Rxx∗pknv+sk^nv∗G−x−δ∗sknv∗G+γ∗Gmodn,=Rxpk^nv+γ∗G+δ∗pknvmodn,=Rxxp,ypmodn,=t.It follows thatx=SHA256cvi‖Rxx∗pknv+yGmodn, which means that x,y is a valid signature of cvi.Blindness Proof. Secondly, we show the blindness of the protocol. We define viewV for a signer during the process of the protocol. For example, let x,y be the signature of cvi that has been generated in the protocol. Then, view V consists of sknv, pknv=sknv∗G, sk^nv, pk^nv=sk^nv∗G, c^, and d=sk^nv−c^∗sknv. We then show that for any given view V and valid message signature pair cvi,x,y, blinding factors γ and δ exist and are unique. Then, for γ and δ, we have(6)c^=x−δmodn,γ=y−sk^nv+c^∗sknvmodn,x=SHA256cviRxpk^nv+γ∗G+δ∗pknvmodn.Then,Rxpk^nv+γ∗G+δ∗pknvmodn is uniquely determined by x and cvi. To make it succinct, we note sknv^+γ+δ∗sknv=Rx−1cvi°x, which means sk^nv+γ∗G+δ∗sknv is uniquely determined by x and cvi.Then,δ∗sknv=Rx−1cvi°x−sknv^−γmodn=Rx−1cvi°x−sknv^−y+sknv^−c^∗sknvmodn=Rx−1cvi°x−y−c^∗sknvmodn.Finally, we have(7)γ=y−sknv^+c^∗sknvmodn,δ∗sknv=Rx−1cvi°x−y−c^∗sknvmodn.Then,γ and δ can be uniquely determined by x,y,cvi,sk^nv,sknv,c^. All x,y,cvi,sk^nv,sknv,c^ are in the view V.


### 5.4. Security Properties

First, we will show how the protocol fulfils the seven design goals.Fairness. The proposed voting scheme is a fair voting by succeeding the hiding property of the cryptography commitment protocol. Since we have proven the security of the cryptography commitment protocol used in our scheme, no one can obtain the ballot results of others before he/she has submitted his/her ballot.Decentralization. Directly, the protocol is decentralized as it is built without any TTP. We use smart contracts to automate the voting process of the Internet of energy. Eligibility. In the initialization stage, we check all the voters’ identities and public information to make sure the eligibility.Anonymity. The correctness and blindness of the blind signature protocol make sure that no one can know the owner of a ballot from the voting result at the end. Since we have proven the security of the blind signature protocol used in our scheme, the privacy of voters can be protected.Compatibility. As the protocol is realized by smart contract and Web3 [31], it can be integrated into an IoE system easily. Any blockchain system including Ethereum 2.0, which supports smart contracts, is feasible for the proposed scheme and we do not need to construct a whole new blockchain platform.Verifiability. The data generated in each stage of the voting can be checked from the blockchain. Therefore, the voting is verifiable.Coercion Resistance. Even though one tries to compel a voter to vote by his/her instruction, he/she cannot find out whether the coerced voter has done as he/she wishes.


### 5.5. Resistance against the Threat Model

Finally, we will show how the protocol resists the potential attacks in the threat models. (1) Resistance against Voter: first, a voter cannot submit a duplicate ballot because the design of the smart contract will reject a piece of duplicate information. Second, a voter cannot change the original ballot for the security of the blind signature protocol. Third, to forge others’ ballots, a voter should get their secret keys or break the ECC asymmetric cryptography. (2) Resistance against Adversary: first, since the voting is anonymous, an adversary cannot affect other voters’ choices. Second, to stop an eligible voter from voting, an adversary should break the security of the blockchain. The blockchain makes sure that the result of the voting cannot be tampered with.(3) Resistance against Blockchain: because our protocol is designed via the Ethereum blockchain, which is proven secure in practice, and thousands of applications have been built on it. A 51% attack is still hypothetical by a group of miners controlling more than 50% of the network’s mining hash rate or computing power. For voting, if more than 50% of voters collude, it is not necessary to launch voting. Besides, the fully decentralized architecture of blockchains makes them robust against DoS/DDoS attacks.


## 5.1. Threat Models

In our scheme, we suppose a voter is a rational one, which means he/she would not let their right to vote become invalid by doing something obviously break the protocol. For instance, a voter should submit his/her blind signature for other voters’ ballots correctly; otherwise, his/her right to vote will be thought invalid. Here, we present the threat model specially for a voting service.(1)
Voter Model. Although a voter is a rational one, he/she may try to lead the voting result in his/her favour without breaking the rule of the protocol. First, since the voting is anonymous, a voter may attempt to submit a duplicate ballot to increase his/her chance to vote. Second, because each voter will blindly sign on the blinded ballots, it is possible for a voter to attempt to change the original ballot after the corresponding blind ballot has been blindly signed by others. It means any vulnerability of the blind signature protocol will defeat the whole voting scheme. Third, knowing other voters’ public identities, a voter may look for ways to let others’ legal ballots become invalid by forging others’ ballots.(2)
Adversary Model. An adversary can be anyone who is a user of the IoE system. First, an adversary may attempt to affect other voters’ choices through vote buying, voter coercion, and so on. Second, there is a possibility for an adversary to stop an eligible voter from performing the process of the voting protocol. For example, voters can be subjected to DDoS attacks, causing them to malfunction. Third, an adversary may attempt to tamper with the result of the voting.(3)
Blockchain System Model. Attacks against the blockchain system may also cause the failure of the voting scheme, since it is based on the blockchain.


## 5.2. Cryptography Commitment

A cryptographic commitment schemeCommit=C,V is secure when it is both hiding and binding. In our scheme, we constructed the cryptographic commitment using a collision-resistant hash function H (in out construction, we use SHA256).We now prove that the binding commitmentCH satisfies two properties based on the assumption that H is collision-resistant.(i)
Binding Proof. The binding commitmentCH is a binding commitment if H is collision-resistant. This can be shown immediately as follows: if there exists an adversary A that breaks the binding property, it will immediately give a collision for H. More precisely, for some commitment string c, assume A outputs two pairs m1,o1 and m2,o2, where m1≠m2, but Vm1,c,o1=vm2,c,o2 = accept. Thereafter, we have a collision for H that Hh1,o1=c=Hm2,o2. So, we can say that CH is computationally binding since it depends on a computational assumption for solving this collision for H.(ii)
Hiding Proof. We first consider input hiding required that the distributionHm1,o is statistically indistinguishable from the distribution Hm2,o for all m1,m2∈M, where o←rR. In our construction, once H is collision-resistant and if the set R is large enough, it is considered input hiding. For example, R=0,1512 should be sufficient for SHA256. This provides a way to build a secure and practical commitment scheme from SHA256. Then, if H is input hiding, no adversary even an unbounded adversary A can break the security of its derived commitment scheme CH. So, we can say that CH is unconditionally hiding.


## 5.3. Blind Signature

The blind signature protocol we used in our scheme is recalled as follows:(i)
(1) The signernv randomly generates two pair keys sknv,pknv and sk^nv,pk^nv and pknv,pk^nv are public to the requester vi.(ii)
(2) The requester selects two integersγ and δ∈ℤn randomly and computes A=pk^nv+γ∗G+δ∗pknv=xp,yp,t=xpmodn. It checks whether t equals zero. If so, the requester reselects γ and δ. Then, it computes x=SHA256cvi‖t and c^=x−δ, where SHA256 is a hash function with 32 bit words and cvi is the commitment generated by voter vi. Finally, the requester sends c^ to the signer as the blinded message.(iii)
(3) The signer generates a blind signatured=sk^nv−c^∗sknv using the blinded message and sends to the requester.(iv)
(4) On receivingd, the requester computes y=d+γ, and with its above x, the requester gets a signature x,y for the original message cvi.(v)
(5) Anyone can verify the signaturex,y by checking the following equation: x=SHA256cvi‖Rxx∗pknv+yGmodn.Correctness Proof. Firstly, we prove the signaturex,y to be valid as follows:(5)Rxx∗pknv+yGmodn,=Rxx∗pknv+d∗G+γ∗Gmodn,=Rxx∗pknv+sk^nv∗G−c^∗sknv∗G+γ∗Gmodn,=Rxx∗pknv+sk^nv∗G−x−δ∗sknv∗G+γ∗Gmodn,=Rxpk^nv+γ∗G+δ∗pknvmodn,=Rxxp,ypmodn,=t.It follows thatx=SHA256cvi‖Rxx∗pknv+yGmodn, which means that x,y is a valid signature of cvi.Blindness Proof. Secondly, we show the blindness of the protocol. We define viewV for a signer during the process of the protocol. For example, let x,y be the signature of cvi that has been generated in the protocol. Then, view V consists of sknv, pknv=sknv∗G, sk^nv, pk^nv=sk^nv∗G, c^, and d=sk^nv−c^∗sknv. We then show that for any given view V and valid message signature pair cvi,x,y, blinding factors γ and δ exist and are unique. Then, for γ and δ, we have(6)c^=x−δmodn,γ=y−sk^nv+c^∗sknvmodn,x=SHA256cviRxpk^nv+γ∗G+δ∗pknvmodn.Then,Rxpk^nv+γ∗G+δ∗pknvmodn is uniquely determined by x and cvi. To make it succinct, we note sknv^+γ+δ∗sknv=Rx−1cvi°x, which means sk^nv+γ∗G+δ∗sknv is uniquely determined by x and cvi.Then,δ∗sknv=Rx−1cvi°x−sknv^−γmodn=Rx−1cvi°x−sknv^−y+sknv^−c^∗sknvmodn=Rx−1cvi°x−y−c^∗sknvmodn.Finally, we have(7)γ=y−sknv^+c^∗sknvmodn,δ∗sknv=Rx−1cvi°x−y−c^∗sknvmodn.Then,γ and δ can be uniquely determined by x,y,cvi,sk^nv,sknv,c^. All x,y,cvi,sk^nv,sknv,c^ are in the view V.


## 5.4. Security Properties

First, we will show how the protocol fulfils the seven design goals.Fairness. The proposed voting scheme is a fair voting by succeeding the hiding property of the cryptography commitment protocol. Since we have proven the security of the cryptography commitment protocol used in our scheme, no one can obtain the ballot results of others before he/she has submitted his/her ballot.Decentralization. Directly, the protocol is decentralized as it is built without any TTP. We use smart contracts to automate the voting process of the Internet of energy. Eligibility. In the initialization stage, we check all the voters’ identities and public information to make sure the eligibility.Anonymity. The correctness and blindness of the blind signature protocol make sure that no one can know the owner of a ballot from the voting result at the end. Since we have proven the security of the blind signature protocol used in our scheme, the privacy of voters can be protected.Compatibility. As the protocol is realized by smart contract and Web3 [31], it can be integrated into an IoE system easily. Any blockchain system including Ethereum 2.0, which supports smart contracts, is feasible for the proposed scheme and we do not need to construct a whole new blockchain platform.Verifiability. The data generated in each stage of the voting can be checked from the blockchain. Therefore, the voting is verifiable.Coercion Resistance. Even though one tries to compel a voter to vote by his/her instruction, he/she cannot find out whether the coerced voter has done as he/she wishes.


## 5.5. Resistance against the Threat Model

Finally, we will show how the protocol resists the potential attacks in the threat models. (1) Resistance against Voter: first, a voter cannot submit a duplicate ballot because the design of the smart contract will reject a piece of duplicate information. Second, a voter cannot change the original ballot for the security of the blind signature protocol. Third, to forge others’ ballots, a voter should get their secret keys or break the ECC asymmetric cryptography. (2) Resistance against Adversary: first, since the voting is anonymous, an adversary cannot affect other voters’ choices. Second, to stop an eligible voter from voting, an adversary should break the security of the blockchain. The blockchain makes sure that the result of the voting cannot be tampered with.(3) Resistance against Blockchain: because our protocol is designed via the Ethereum blockchain, which is proven secure in practice, and thousands of applications have been built on it. A 51% attack is still hypothetical by a group of miners controlling more than 50% of the network’s mining hash rate or computing power. For voting, if more than 50% of voters collude, it is not necessary to launch voting. Besides, the fully decentralized architecture of blockchains makes them robust against DoS/DDoS attacks.


## 6. Implementation and Performance

### 6.1. Implementation Description

We use a PC with an OS version of Ubuntu 18.04 64x as a user client. The CPU and memory are Intel(R) Core(TM) i7-10510U CPU @ 1.80 GHz 2.30 GHz and 8G separately. We implemented our protocol in two parts, namely, Web3 programs and smart contracts. We write the smart contract in Solidity. We use JavaScript to finish the Web3 programs along with several libraries. “Ethers.js” is an Ethereum library to interact with the Ethereum blockchain. “Crypto.js” is a JavaScript library to realize the cryptography protocol adopted in our voting protocol. The experiment code is available athttps://github.com/researchSec/IoEPAV. As shown in Figure 4, each user plays as a voter and a blind signer simultaneously. They interact with the blockchain network through the Web3 application. Indeed, the Web3 application will invoke the smart contract to read or write voting data on the blockchain network. Note that the users do not need to involve in the mining or consensus progress of the blockchain network. For simplicity, we use multiple Ethereum accounts to represent different voters in the Web3 application to invoke the smart contract. To evaluate the performance in a more reliable and practical manner, we deploy the smart contract on two popular test networks of Ethereum and have strong links to the main network. Besides, we build an Ethereum development with a professional tool called Hardhat. Thus, in the connectivity model, we run our test cases in three blockchain networks separately. They are Hardhat local network, Rinkeby test network, and Ropsten test network.Figure 4
Connectivity model.The Ethereum network that deals with real money is called “mainnet,” and then, other live networks named “testnets” (multiple ones) are also provided by Ethereum. In testnets, the network does not deal with real money but does mimic the real-world scenario well. Ropsten and Rinkeby are the testnets we choose. Ropsten is a proof of work (PoW) testnet. This means it is the best like-for-like representation of Ethereum. Rinkeby is proof of authority (PoA) [32] testnet. In Table 4, we give the state of the two blockchain networks when we performed the experiment. In the testnet Ropsten, the coin is mined following the same scheme as the mainnet. Rinkeby uses PoA consensus schemes, which are a potential direction of Ethereum evolutions.Table 4
State of the blockchain Network.
Test networkConsensusAverage block time (S)Active nodes/minersLatest block numberRinkebyPoW47.184210027471RopstenPoA15.034411869370


### 6.2. Performance in Local Environment

Firstly, we test the key steps in the local development environment to see the performance without considering the latency and throughput according to the network condition. As shown in Table5, the time for each stage of the voting is proportionate to the increased number of voters. The result is quite straightforward to understand since more voters mean more commitments to be generated. However, even if the number of voters is up to 50, the time is not more than 2 seconds. The time for verifying does not exceed one second. Thus, one can launch voting efficiently.Table 5
Average response time.
Number of votersInitialization (MS)Blind messages (MS)Blind signature (MS)Opening (MS)Verifying (MS)5374.0323.43212.0282.43109.4310635.85499.14436.43561.43149.43301314.141298.711234.711129.29228.14502162.282314.432271.141897.43383.86


### 6.3. Performance in Live Networks

The performance of the voting scheme is relative to the network condition of the live networks. To give an overall evaluation of the system, we give the average response time, transaction cost, throughput, and latency for the execution of the smart contract. To make it clear, we give the description of evaluation properties as follows.Average Response Time. This metric indicates the time taken to send a transaction to the blockchain and get a response. Note that when a user gets a response, it does not mean that the sent transaction has been confirmed by the nodes/miners of the blockchain.Transaction Cost. Gas cost is the transaction cost. Gas refers to the fee that is required to successfully execute a contract on the Ethereum blockchain platform. We use the base unit “Gas.”4×10−9 Ether ≈1 Gas.Transaction Acceptance Latency (TAL). Firstly, a signed transaction is created. The user sends the created transaction to an Ethereum network and captures the current time pointTs. When the transaction is confirmed, the user captures the current time Te. This metric indicates the time of t=Te−Ts.Throughput. We consider two metrics, namely, (a) read throughput called QPS (query rate per second) and (2) transaction throughput called TPS (transactions per second). QPS indicates the total number of reading transactions performed within a defined period of time. TPS indicates the ratio of valid transactions that are initiated within a defined period of time.Firstly, we give the response time of each stage in the voting scheme on different test networks. As shown in Figures5–9, the performances are quite stable in all live networks. The response time for each stage of the voting is proportionate to the increased number of voters. The result is quite straightforward to understand since more voters mean more commitments to be generated. The performances in the two test networks are quite similar.Figure 5
Initialization.Figure 6
Blind messages.Figure 7
Blind signature.Figure 8
Opening.Figure 9
Verifying.To evaluate how the network conditions affect the performance of the voting scheme, we give the transaction acceptance latency (TAL) and throughput in Figures10 and 11. The TPS and QPS are quite similar between Rinkeby and Ropsten. This can be an explanation for the result of the response time above. Since the throughput in the mainnet of the Ethereum blockchain is about 85 times the size of that in the test networks, we can infer that the performance of the voting scheme will act more efficiently in the mainnet. Note that the TAL varies significantly with different loads (different numbers of concurrent transactions). In the experiment, we give the number of concurrent transactions according to the number of voters.Figure 10
Throughput.Figure 11
Transaction acceptance latency.In Table6, we also give the average transaction fee for the smart contract deployment and each stage of the voting scheme. As we can see, the gas cost in the two test networks has little difference since the size of the smart contract and transactions are identical.Table 6
Average transaction cost.
Test networkDeployment (Gas)Initialization (Gas)Blind messages (Gas)Blind signature (Gas)Opening (Gas)Rinkeby2,353,838251,023204,76892,811289,189Ropsten2,353,838251,035204,78092,823284,258


### 6.4. Cost Comparison

In Yang’s blockchain-based scheme [16], basic cryptographic operations are also introduced. The difference is we use scalar multiplication on an elliptic curve, while Yang uses exponentiation in a multiplicative group. However, if we only care about computational complexity, it is similar.(i)
In ECC, given an elliptic curve of sizen, the number of double-and-add steps is proportional to Ok for k∗G. Each double/add is a sequence of a constant number of field multiplications, squares, additions, and subtractions. Multiplication and squares are the expensive ones, and using the Karatsuba algorithm as mentioned in [33], they are On1.58. Therefore, the result is Okn1.58.(ii)
In comparison, the computational complexity of a modular exponentiation of formgamodb is similar. Square-and-multiply is Oa. Each square/multiply is Ob1.58. Therefore, the result is Oab1.58.According to Yang’s performance analysis, only the most time-consuming operations are taken into account.t is denoted as the time of one exponentiation calculation such as a gamodb. Correspondingly, we use t to denote the time of one multiplication calculation in ECC such as k∗G. Let tE and tD be the time of encryption and decryption separately. Then, we let tS and tV be the time of executing ECDSA signature and verification, respectively. Approximately, tE=2t, tD=t, tS=t, and tV=t. nv is used to denote the number of voters. In Yang’s scheme, nc is the number of candidates, respectively. Note that we can take over the blind signer to candidates in our protocol. To be succinct for comparison, we let p=nc=nv. The cost of these operations in Yang’s and our scheme for comparison is given in Table 7. As shown in Table 7, our scheme IoEPAV is at a lower cost.Table 7
Count of the cryptographic operations.
ProtocolVotingVerifying/tallyIoEPAV6∗ t ∗ nv2∗ t ∗ nvYang [16](5∗ nv ∗ t + 3 ∗ t) ∗ nv(5∗ nv ∗ t + 5 ∗ t) ∗ nv ∗ nv


## 6.1. Implementation Description

We use a PC with an OS version of Ubuntu 18.04 64x as a user client. The CPU and memory are Intel(R) Core(TM) i7-10510U CPU @ 1.80 GHz 2.30 GHz and 8G separately. We implemented our protocol in two parts, namely, Web3 programs and smart contracts. We write the smart contract in Solidity. We use JavaScript to finish the Web3 programs along with several libraries. “Ethers.js” is an Ethereum library to interact with the Ethereum blockchain. “Crypto.js” is a JavaScript library to realize the cryptography protocol adopted in our voting protocol. The experiment code is available athttps://github.com/researchSec/IoEPAV. As shown in Figure 4, each user plays as a voter and a blind signer simultaneously. They interact with the blockchain network through the Web3 application. Indeed, the Web3 application will invoke the smart contract to read or write voting data on the blockchain network. Note that the users do not need to involve in the mining or consensus progress of the blockchain network. For simplicity, we use multiple Ethereum accounts to represent different voters in the Web3 application to invoke the smart contract. To evaluate the performance in a more reliable and practical manner, we deploy the smart contract on two popular test networks of Ethereum and have strong links to the main network. Besides, we build an Ethereum development with a professional tool called Hardhat. Thus, in the connectivity model, we run our test cases in three blockchain networks separately. They are Hardhat local network, Rinkeby test network, and Ropsten test network.Figure 4
Connectivity model.The Ethereum network that deals with real money is called “mainnet,” and then, other live networks named “testnets” (multiple ones) are also provided by Ethereum. In testnets, the network does not deal with real money but does mimic the real-world scenario well. Ropsten and Rinkeby are the testnets we choose. Ropsten is a proof of work (PoW) testnet. This means it is the best like-for-like representation of Ethereum. Rinkeby is proof of authority (PoA) [32] testnet. In Table 4, we give the state of the two blockchain networks when we performed the experiment. In the testnet Ropsten, the coin is mined following the same scheme as the mainnet. Rinkeby uses PoA consensus schemes, which are a potential direction of Ethereum evolutions.Table 4
State of the blockchain Network.
Test networkConsensusAverage block time (S)Active nodes/minersLatest block numberRinkebyPoW47.184210027471RopstenPoA15.034411869370


## 6.2. Performance in Local Environment

Firstly, we test the key steps in the local development environment to see the performance without considering the latency and throughput according to the network condition. As shown in Table5, the time for each stage of the voting is proportionate to the increased number of voters. The result is quite straightforward to understand since more voters mean more commitments to be generated. However, even if the number of voters is up to 50, the time is not more than 2 seconds. The time for verifying does not exceed one second. Thus, one can launch voting efficiently.Table 5
Average response time.
Number of votersInitialization (MS)Blind messages (MS)Blind signature (MS)Opening (MS)Verifying (MS)5374.0323.43212.0282.43109.4310635.85499.14436.43561.43149.43301314.141298.711234.711129.29228.14502162.282314.432271.141897.43383.86


## 6.3. Performance in Live Networks

The performance of the voting scheme is relative to the network condition of the live networks. To give an overall evaluation of the system, we give the average response time, transaction cost, throughput, and latency for the execution of the smart contract. To make it clear, we give the description of evaluation properties as follows.Average Response Time. This metric indicates the time taken to send a transaction to the blockchain and get a response. Note that when a user gets a response, it does not mean that the sent transaction has been confirmed by the nodes/miners of the blockchain.Transaction Cost. Gas cost is the transaction cost. Gas refers to the fee that is required to successfully execute a contract on the Ethereum blockchain platform. We use the base unit “Gas.”4×10−9 Ether ≈1 Gas.Transaction Acceptance Latency (TAL). Firstly, a signed transaction is created. The user sends the created transaction to an Ethereum network and captures the current time pointTs. When the transaction is confirmed, the user captures the current time Te. This metric indicates the time of t=Te−Ts.Throughput. We consider two metrics, namely, (a) read throughput called QPS (query rate per second) and (2) transaction throughput called TPS (transactions per second). QPS indicates the total number of reading transactions performed within a defined period of time. TPS indicates the ratio of valid transactions that are initiated within a defined period of time.Firstly, we give the response time of each stage in the voting scheme on different test networks. As shown in Figures5–9, the performances are quite stable in all live networks. The response time for each stage of the voting is proportionate to the increased number of voters. The result is quite straightforward to understand since more voters mean more commitments to be generated. The performances in the two test networks are quite similar.Figure 5
Initialization.Figure 6
Blind messages.Figure 7
Blind signature.Figure 8
Opening.Figure 9
Verifying.To evaluate how the network conditions affect the performance of the voting scheme, we give the transaction acceptance latency (TAL) and throughput in Figures10 and 11. The TPS and QPS are quite similar between Rinkeby and Ropsten. This can be an explanation for the result of the response time above. Since the throughput in the mainnet of the Ethereum blockchain is about 85 times the size of that in the test networks, we can infer that the performance of the voting scheme will act more efficiently in the mainnet. Note that the TAL varies significantly with different loads (different numbers of concurrent transactions). In the experiment, we give the number of concurrent transactions according to the number of voters.Figure 10
Throughput.Figure 11
Transaction acceptance latency.In Table6, we also give the average transaction fee for the smart contract deployment and each stage of the voting scheme. As we can see, the gas cost in the two test networks has little difference since the size of the smart contract and transactions are identical.Table 6
Average transaction cost.
Test networkDeployment (Gas)Initialization (Gas)Blind messages (Gas)Blind signature (Gas)Opening (Gas)Rinkeby2,353,838251,023204,76892,811289,189Ropsten2,353,838251,035204,78092,823284,258


## 6.4. Cost Comparison

In Yang’s blockchain-based scheme [16], basic cryptographic operations are also introduced. The difference is we use scalar multiplication on an elliptic curve, while Yang uses exponentiation in a multiplicative group. However, if we only care about computational complexity, it is similar.(i)
In ECC, given an elliptic curve of sizen, the number of double-and-add steps is proportional to Ok for k∗G. Each double/add is a sequence of a constant number of field multiplications, squares, additions, and subtractions. Multiplication and squares are the expensive ones, and using the Karatsuba algorithm as mentioned in [33], they are On1.58. Therefore, the result is Okn1.58.(ii)
In comparison, the computational complexity of a modular exponentiation of formgamodb is similar. Square-and-multiply is Oa. Each square/multiply is Ob1.58. Therefore, the result is Oab1.58.According to Yang’s performance analysis, only the most time-consuming operations are taken into account.t is denoted as the time of one exponentiation calculation such as a gamodb. Correspondingly, we use t to denote the time of one multiplication calculation in ECC such as k∗G. Let tE and tD be the time of encryption and decryption separately. Then, we let tS and tV be the time of executing ECDSA signature and verification, respectively. Approximately, tE=2t, tD=t, tS=t, and tV=t. nv is used to denote the number of voters. In Yang’s scheme, nc is the number of candidates, respectively. Note that we can take over the blind signer to candidates in our protocol. To be succinct for comparison, we let p=nc=nv. The cost of these operations in Yang’s and our scheme for comparison is given in Table 7. As shown in Table 7, our scheme IoEPAV is at a lower cost.Table 7
Count of the cryptographic operations.
ProtocolVotingVerifying/tallyIoEPAV6∗ t ∗ nv2∗ t ∗ nvYang [16](5∗ nv ∗ t + 3 ∗ t) ∗ nv(5∗ nv ∗ t + 5 ∗ t) ∗ nv ∗ nv


## 7. Conclusion and Future Work

We present a novel blockchain-based voting scheme for IoE system. By getting rid of a trusted third party, the proposed scheme can avoid the single point of failure and is available for a trustless environment. In the past proposals, it is difficult to capture all the required features for a voting scheme. To the best of our knowledge, our scheme is the first one to fulfil all the design goals simultaneously. To achieve this, we combine the cryptography commitment and blind signature protocol. We also use smart contracts to automate the voting process of the Internet of energy. With smart contracts, the voting scheme can be easy to integrate into the IoE system. A voter can follow the voting protocol by invoking the interfaces of the smart contracts. Although we do not use any high-performance cryptography library, the performance in a real environment demonstrates the feasibility of our protocol.In the future, we can try to use parallel computation in the voting stage to improve efficiency as well. Another interesting open problem is to create a version of the voting scheme that reduces the number of blind signatures. Making the number of blind signatures irrelative to the number of voters will be a great improvement. This would give a solution that is more efficient with large-scale voters.



---

*Source: 4436824-2022-08-21.xml*