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

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. )e 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.)e 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.


Introduction
e 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 datadriven decision-making. However, the intrinsic features of IoE raise a number of challenges, such as autonomy, privacy, and decentralization [4][5][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. e 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. e 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.
e 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 coercionresistant.
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. is is a challenge for traditional e-voting schemes [10][11][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].
ere are already voting schemes built based on a blockchain network [14][15][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. irdly, 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. eoretical 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 blockchainbased 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. e rest of this study is arranged as follows. In Section 2, 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.

Related Work
To address the problem of large-scale elections, Fujioka et al. [12] presented a classic voting protocol in 1992. eir voting scheme is thought to be practical and solves the privacy and fairness problems. ereafter, 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. ey 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. ey 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.

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.
ink 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. e 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. erefore, 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 scheme Commit. Let Alice be one party, who can firstly publish a string c as a commitment for a message m ∈ M. en, 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  We use semantic security definition to formalize this. In particular, two games are performed between an adversary A and a challenger, denoted as Game 0 and Game 1. Let b � 0, 1, in the Game b, and the adversary A first outputs m 0 , m 1 ∈ M, inputs a message m b ∈ 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, W b is defined as the case, where A outputs 1 in Game b. We require that the advantage that is negligible.

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. en, the signer will sign on the blinded message in a way like a conventional digital signature and output a blind signature. en, 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. e 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 Figure 1, 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. e requester performs a blinding shift on the message before sending it to the signer. e signer who then signs on the blinded message will generate a blind signature and send it to the requester.
A general signature scheme is shown in Figure 1, 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.

Security and Communication Networks
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 F p are a sextuple: T(p, a, b, G, n, h) consisting of an integer p specifying the finite field F p and two elements a, b ∈ F p specifying an elliptic curve E(F p ) defined by the following equation: G is a base point on E(F p ), n is the order of G, h is the cofactor where h � #E(F p )/n, and Z 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) Let k ∈ Z n be an integer randomly selected by the signer, which calculates R � kG. en, the signer sends R to the requester. (ii) (2) Firstly, the requester selects two integers c and δ ∈ Z n randomly and computes A � kG+ cG + δP � (x, y), t � xmodn. It checks whether t equals zero. If so, the requester reselects c and δ . en, it computes c � SHA256(m‖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) e signer generates a blind signature s � k − cd using the blinded message and sends to the requester. (iv) (4) On receiving s, the requester computes s � s + c, and along with the above c, the requester gets a signature c, s for the original message m. (v) (5) Anyone can verify the signature (c, s) by checking the following equation: Note that here R x (cP + sG)modn means we get the x resolution values of point cP + sG, and || means we concatenate two strings.

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.
e 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. e blockchain is usually regarded as a core technology for building a "distributed shared ledger." rough 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. e basic contents contained in the ledger include blocks, transactions, accounts, and world states. (ii) Block. Blocks are data structures constructed in chronological order. e 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. e 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. e basic data structure of a transaction includes sender, receiver, and transaction data. (iv) Consensus Mechanism. e 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  [12] ✓ ✓ ✓ ✓ Ohkubo et al. [19] ✓ ✓ ✓ ✓ Grontas et al. [20] ✓ ✓ ✓ ✓ ✓ Follow My Vote [14] ✓ ✓ ✓ ✓ Yang et al. [16] ✓

Requester Signer
Message m Digital Signature S (m) calculation results. ere 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. e 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. e 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.
us, 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.

Proposed Protocol
In this subsection, we will describe a practical anonymous voting protocol via blockchain. Our scheme has all the aforementioned properties in Section 1. Figure 3, 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. is 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 F(p) of secp256k1, G is the base point, n is the order of G, and h is a cofactor. All these parameters are public.

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 are Let addr v i be the public address of the voter v i in the Ethereum network, and ID v i represents the voter's identification. en, the public information for each voter v i is a tuple . Everyone can get this information from the blockchain to verify its validity.

Voting.
As soon as voting is launched, each voter v i 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 Voter v i completes this by a blind commitment algorithm (x, c) ← BlindX(c v i , pk n v , pk n v ) in the blind signature protocol.
Let H n v be the hash of the tuple (addr i , en, a group information of (ID i , addr i , c, s) is recorded into the blockchain through the smart contract. Note that x has been saved in secret by voter v i himself in this stage. e detailed design of the algorithm C and BlindX is given in Section 4.2.
Once (ID i , addr i , c, s) generated by voter v i is recorded, the other voters can generate a blind signature for it. Firstly, every other voter verifies the validity of the signature s n v by the ECDSA verification algorithm Verify(s n v , pk i ). If s n v is valid, then every other voter generates a blind signature d n v by a blind signature algorithm d n v ←BlindS(sk n v , sk n v ) in the blind signature protocol and sends d n v into the blockchain. Let d � (d 1 , d 2 , . . . , d n At the end of this stage, we have (c, s, d) for a ballot m v i of voter v i . e detailed design of the algorithm BlindS will be given in Section 4.2.
Here, y n v is a signature for the original commitment c v i . Voter v i generates y by calculating where c is a random key saved in BlindX.
Given (x n v , c v i , y n v ), voter v i can verify the validity of y n v by an algorithm VerifyS(x n v , c v i , y n v , pk n v ), where x n v is saved in BlindX. Note that y n v is a signature of the commitment c v i from voter v n v . If the signature y n v is valid, then voter v i sends the open commitment string o v i and x n v to the blockchain. Note that voter v i chooses a random address in the Ethereum network to send this transaction. Anyone cannot find out who has sent this transaction. e detailed design of the algorithm VerifyS will be given in

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. e details are as follows: (i) Cryptography Commitment Algorithms. To construct a cryptography commitment protocol, we should build a pair of efficient algorithms (C, 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. e 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. e 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. ey are BlindX, BlindS, and VerifyS. As shown in Algorithm 3, BlindX is used for blinding the commit string c v i for the ballot. c 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 (x j , c j , c, δ) and sends (addr v i , addr n v , s, c) to the blockchain.  Security and Communication Networks Algorithm 5 to verify the validity of the signature y n v . 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.

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. us, 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 Table 2, "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.
Recall that there are four stages in the whole voting scheme, namely, initialization, voting, opening, and verifying/tally. en, the smart contract should afford the necessary interfaces for them to interact with the blockchain. e 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. en, in the stage "Voting," a "Write" interface named "setAnmVote" is used to record the blind commitment generated in Algorithm 3. 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. e 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.
As 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. e algorithm for a signer to generate a blind signature is described in Algorithm 4. Firstly, a signer will use "getAnmVote" in Algorithm 7 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. e design ideas of the other interfaces are similar to these algorithms given above. When "Write" information to the blockchain, necessary conditions are set. en, anyone can check the data from the blockchain by the kind of "Query" interface.

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 Section 3.

reat 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.

Security and Communication Networks 7
(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. ird, 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. ird, 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.

Cryptography Commitment.
A cryptographic commitment scheme Commit � (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).   . is provides a way to build a secure and practical commitment scheme from SHA256. en, if H is input hiding, no adversary even an unbounded adversary A can break the security of its derived commitment scheme C H . So, we can say that C H is unconditionally hiding.

Blind Signature.
e blind signature protocol we used in our scheme is recalled as follows: (i) (1) e signer n v randomly generates two pair keys (sk n v , pk n v ) and (sk n v , pk n v ) and pk n v , pk n v are public to the requester v i . (ii) (2) e requester selects two integers c and δ ∈ Z n randomly and computes A � pk n v + c * G + δ * p k n v � (xp, yp), t � xpmodn. It checks whether t equals zero. If so, the requester reselects c and δ. en, it computes x � SHA256(c v i ‖t) and c � x − δ, where SHA256 is a hash function with 32 bit words and c v i is the commitment generated by voter v i . Finally, the requester sends c to the signer as the blinded message. (iii) (3) e signer generates a blind signature d � sk n v − c * sk n v using the blinded message and sends to the requester. (iv) (4) On receiving d, the requester computes y � d + c, and with its above x, the requester gets a signature x, y for the original message c v i . (v) (5) Anyone can verify the signature (x, y) by checking the following equation: Correctness Proof. Firstly, we prove the signature (x, y) to be valid as follows: � R x pk n v + c * G + δ * pk n v modn, modn), which means that (x, y) is a valid signature of c v i . Blindness Proof. Secondly, we show the blindness of the protocol. We define view V for a signer during the process of the protocol. For example, let (x, y) be the signature of c v i that has been generated in the protocol. en, view V consists of sk n v , pk n v � sk n v * G, sk n v , pk n v � sk n v * G, c, and d � sk n v − c * sk n v . We then show that for any given view V and valid message signature pair (c v i , (x, y)), blinding factors c and δ exist and are unique. en, for c and δ, we have

Security and Communication Networks
en, R x (pk n v + c * G + δ * pk n v )modn is uniquely determined by x and c v i . To make it succinct, we note Finally, we have en, c and δ can be uniquely determined by (x, y, c v i , sk n v , sk n v , c). All (x, y, c v i , sk n v , sk n v , c) are in the view V.

Security Properties.
First, we will show how the protocol fulfils the seven design goals.
Fairness. e 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. e 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. e data generated in each stage of the voting can be checked from the blockchain. erefore, 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.

Resistance against the reat 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.
ird, 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. e 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.

Implementation and Performance
6.1. Implementation Description. We use a PC with an OS version of Ubuntu 18.04 64x as a user client. e 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. e experiment code is available at https://github. com/researchSec/IoEPAV. As shown in Figure 4, each user plays as a voter and a blind signer simultaneously. ey 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. us, in the connectivity model, we run our test cases in three blockchain networks separately. ey are Hardhat local network, Rinkeby test network, and Ropsten test network.
e 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. is 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.

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 Table 5, the time for each stage of the voting is proportionate to the increased number of voters. e 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. e time for verifying does not exceed one second. us, one can launch voting efficiently.

Performance in Live Networks.
e 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. is 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. e user sends the created transaction to an Ethereum network and captures the current time point T s . When the transaction is confirmed, the user captures the current time T e . is metric indicates the time of t � T e − T s . roughput. 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 Figures 5-9, the performances are quite stable in all live networks. e response time for each stage of the voting is proportionate to the increased number of voters. e result is quite straightforward to understand since more voters mean more commitments to be generated. e performances in the two test networks are quite similar.
To evaluate how the network conditions affect the performance of the voting scheme, we give the transaction acceptance latency (TAL) and throughput in Figures 10 and  11. e TPS and QPS are quite similar between Rinkeby and Ropsten. is 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.
In Table 6, 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.

Cost
Comparison. In Yang's blockchain-based scheme [16], basic cryptographic operations are also introduced. e 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 size n, the number of double-and-add steps is proportional to O(k) 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 O(n 1.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 g a modb. Correspondingly, we use t to denote the time of one multiplication calculation in ECC such as k * G. Let t E and t D be the time of encryption and decryption separately. en, we let t S and t V be the time of executing ECDSA signature and verification, respectively. Approximately, t E � 2t, t D � t, t S � t, and t V � t. n v is used to denote the number of voters. In Yang's scheme, n c 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 � n c � n v . e 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.

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   Protocol Voting Verifying/tally IoEPAV 6 * t * n v 2 * t * n v Yang [16] (5 * n v * t + 3 * t) * n v (5 * n v * t + 5 * t) * n v * n v 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. is would give a solution that is more efficient with large-scale voters.

Data Availability
No data were used to support this study.

Conflicts of Interest
e authors declare that they have no conflicts of interest.