FASTEN: Fair and Secure Distributed Voting Using Smart Contracts
AA version of this paper will appear in the
IEEE International Conference on Blockchain and Cryptocurrency (IEEE ICBC 2021). This is a full version.
FASTEN: F
AIR AND S ECURE D ISTRIBUTED V OTING U SING S MART C ONTRACTS
Sankarshan Damle and Sujit Gujar
Machine Learning Lab
International Institute of Information Technology (IIITH)Hyderabad, India [email protected]; [email protected]
Moin Hussain Moti
The Hong Kong University of Science and TechnologyHong Kong [email protected]
February 23, 2021 A BSTRACT
Electing democratic representatives via voting has been a common mechanism since the 17 th century.However, these mechanisms raise concerns about fairness, privacy, vote concealment, fair calculationsof tally, and proxies voting on their behalf for the voters. Ballot voting, and in recent times, electronicvoting via electronic voting machines (EVMs) improves fairness by relying on centralized trust.Homomorphic encryption-based voting protocols also assure fairness but cannot scale to large scaleelections such as presidential elections. In this paper, we leverage the blockchain technology ofdistributing trust to propose a smart contract-based protocol, namely, FASTEN. There are manyexisting protocols for voting using smart contracts. We observe that these either are not scalable orleak the vote tally during the voting stage, i.e., do not provide vote concealment. In contrast, weshow that FASTEN preserves voter’s privacy ensures vote concealment, immutability, and avoidsdouble voting. We prove that the probability of privacy breaches is negligibly small. Further, our costanalysis of executing FASTEN over Ethereum is comparable to most of the existing cost of elections. Elections are fundamental to democratic governance. Since direct democracy - a form of government in which politicaldecisions are made directly by the entire body of qualified citizens - is impractical, societies select representatives forgovernance. Consequently, elections have been a common mechanism for modern representative democracy since 17 th century [1]. They make it possible to include every eligible individual in the decision-making process by registering itsvote into the system. A fair election is possible only when the voter can freely vote for its desired preference.One must also ensure an agent’s participation in the voting process is hidden. This can be achieved by eliminating the link between the voter and its vote, i.e., anonymous voting. In order to design such a fair election with anonymousvoting, i.e., fair and secure election (FSE), we first define the following essential properties.1. Voter Anonymity (VA).
A vote cannot be traced back to the voter either during or after the election.2.
Vote Concealment (VC).
The vote’s value should remain hidden from the system (voters, candidate, electioncommission). This in turn ensures that the vote tally remains a mystery to the system until the voting window hasexpired.3.
Vote Immutable (VI).
Once a voter casts its vote, it should be impossible to alter it to any other vote by anyone.4.
Double Voting Inhibition (DVI).
A voter should be allowed to vote only once in a specific election. a r X i v : . [ c s . CR ] F e b PREPRINT - F
EBRUARY
23, 2021
FSE Overview.
Towards FSE, the most traditional voting method is paper ballots . It partially ensures anonymity, voteconcealment, and vote immutability. The major drawback of ballot-based voting is that it involves tiresome manual workin counting the votes. Along with the risk of unintentional and intentional human-error involved, the non-durability ofpaper and lack of a robust mechanism to avoid double voting are some of the other challenges involved with this system.Election through electronic voting machines (EVM)s is a technological upgrade over the paper ballot system. EVMsprovide voter anonymity that does not take voter ID as a parameter. But, it fails at guaranteeing vote immutability.This is because the voter needs to trust the company that provides the EVM software for vote concealment and voteimmutability. They also entrust the company with shipping the EVMs with the correct version of the firmware, andthus, the EVM remains a black box to the voter. Besides, the double voting inhibition problem is still there.Micali et al. [2] propose a protocol for secure auctions that is also applicable for voting. However, the body conductingthe elections, election commission (EC), will know all the votes post the voting stage. To overcome the “centralizedtrust" placed on EC, the authors propose an expensive zero-knowledge proof of the result. Consequently, the protocol isalso not scalable. Adida [3] proposes a most popular scheme
Helios , which relies on the security of one server and isnot viable for nationwide elections. Thus, there is a need to look for a completely different approach to conduct an FSE.
FSE over Blockchain.
With Ethereum [4], we observe that blockchain can not only be used to solve the problem ofdesigning a cryptocurrency but can also be used to implement smart contracts [4]. A smart contract allows blockchainto establish an interactive platform for n parties. Such a contract enforces the outcome of any event through a set ofrules. These rules correspond to a programming language understandable to the execution system. The key concepthere is distributing trust rather than relying on a single party. Thus, we explore ways to leverage such a distributed trustto conduct an FSE.The important steps in the voting procedure for FSE are: (i) voter authentication , i.e., a person claiming to be a votershould be an eligible voter; (ii) vote registration , which preserves the privacy of the voter as well as its vote; (iii) outcome verification that counts the tally of votes in a verifiable manner. Zhao et al. [5] propose a voting protocol basedon Commit-Publish mechanisms that also leverages smart contract. As the authors’ main goal is boardroom voting, itdoes not address step (i). It solves steps (ii) and (iii). To the best of our knowledge, in a plethora of voting schemes overblockchain, except [6], no protocol satisfies all the four desirable properties of a fair election. The challenge with [6] isscalability as it is Zcash-based, which is considerably slower than Bitcoin.
Our Approach.
We propose a novel protocol for FSE, namely, FASTEN:
FAir and Secure disTributEd votiNg . Wepartially rely on EC for authentication, which issues a random but unique token for each voter after authenticating thevoter. The token is unique to the voter and the particular election. If the voter tries to obtain multiple tokens for thesame election - it will receive the same token. Therefore, FASTEN is resistant to
Sybil attacks. This authentication issimilar to several secure applications over blockchain (e.g., [7–10]). In this work, we assume that EC does not storethe link between a voter and its token . Next, the smart contract considers tokens as an eligibility to vote granted byEC. After this, each voter registers its encrypted vote and token to the smart contract. The smart contract holds thehashes of all the tokens that are issued by EC. It computes the hash of the token registered by the voter and checks if itis present in the database. Once the entry is confirmed, the encrypted votes are registered in the voter database. Afterthe vote casting window expires, the smart contract decrypts all the votes and computes the tally.Since our protocol deploys smart contracts based on blockchain, one may also implement it as a DecentralizedApplication (DApp). DApps comprise a friendly UI for any smart contract, thereby allowing layperson to interactwith said contracts. Thus, FASTEN helps improve fairness in elections, i.e., designing FSE and improving voterparticipation.With FASTEN, we show that a straightforward protocol will achieve an FSE. We believe that the simple design of ourprotocol is desirable and will benefit the end-user. This simplicity is in contrast with sophisticated protocols whichdeploy heavy cryptographic and security primitives to achieve FSE. These protocols, especially how they reach thedesired privacy, are challenging to explain to a layperson. These limit their use in general elections where participatingvoters are in millions. We outline some of them next. Such trusted third party authentications also have a close parallel with the Zcash Parameter Generation [11]. These links thuscorrespond to “toxic waste" – to be destroyed. In this work we present FASTEN as an Ethereum-based smart contract. The protocol can also be easily conducted as throughcomputational logic over other distributed platforms like
Hyperledger Fabric [12] or
Quorum [13]. PREPRINT - F
EBRUARY
23, 2021
Paper VA VC VI DVI Scalable [2] (cid:88) × (cid:88) (cid:88) × (No Blockchain)[3] (cid:88) (cid:88) (cid:88) (cid:88) × (No Blockchain)[5, 14, 17] (cid:88) (cid:88) (cid:88) (cid:88) × [15, 18–20] (cid:88) × (cid:88) (cid:88) (cid:88) [6] (cid:88) (cid:88) (cid:88) (cid:88) × FASTEN (cid:88) (cid:88) (cid:88) (cid:88) (cid:88)
Table 1: Comparison of Different secure voting protocols
There have been few attempts before to design a voting protocol based on blockchains but they all use
Commit-Publish mechanisms to conceal the vote tally. A
Commit-Publish mechanism requires voters to submit a deposit beforecommitting to a vote and are refunded the deposit when they publish their vote. Both the Open Vote Network Protocolimplemented by McCorry [14] and the bitcoin based protocol by Zhao [5] use this mechanism. While this mechanismcould be used for boardroom voting, it cannot be used for mass election like general presidential election of nationsbecause most voters would be reluctant to submit the deposit. This is because, in a population of millions voters will notconsider their vote to be of much importance to begin with. In addition, once the voters commit, they have to participatein the protocol again to reveal their commitment. Note that, several nations are struggling to bring voters to votingbooths to cast their vote when they just have to come once. Thus, we believe that it is unrealistic to believe that a voterwill choose to participate twice in the same election. With FASTEN, we require the voters to come on-chain, i.e., onlineon blockchain, only once to register their votes and without any deposit.In other works, FollowMyVote [15] uses trusted authorities to ensure voter anonymity. The voters cast their votes inplain-text therefore risking the concealment of the vote tally. In contrast, voters in FASTEN are required to submitencrypted votes, “cipher-texts", thereby concealing their votes. Our encryption-decryption mechanism ensures theconcealment of the vote tally until the vote casting window expires. Due to space constraints, we present several otherworks through Table 2 to place FASTEN with respect to the existing literature in FSEs. We also refer the interestedreader to [16, Table 1] for a more comprehensive comparison of secure voting protocols over blockchain. We nextpresent the preliminaries required for the design and analysis of FASTEN.
The main stakeholders of any election are the voters, the candidates and the election commission (EC). EC represents thegoverning body of the election. Once an election is announced, interested candidates need to register their candidaturewith EC before a certain deadline which we denote as t ecr . It is EC’s responsibility to ensure fair candidature registration.For the time period between the beginning and end of token distribution, i.e., t btd and t etd , EC issues tokens to thevoters after authenticating them. Actual vote casting begins at time t bvc and ends at t evc . In FASTEN, the voters submittheir encrypted votes over the Ethereum-based smart contract. We show how EC (or any other interested party) canget the vote tally using the smart contract. We refer to the procedural methods of the overall protocol which are onthe smart contract as on-chain methods and the remaining procedures as off-chain methods . Figure 1 illustrates thetemporal aspect of FASTEN.We use an Ethereum-based smart contract for on-chain methods which in turn relies on the blockchain technology.Hence, we first summarize blockchain technology and Ethereum-based smart contracts in the following subsections. A blockchain can serves as an open, append-only distributed ledger that can record transactions between two partiesefficiently, verifiably and in a permanent way. Blockchain security method comprise public-key cryptography. Apublic key (a long, random-looking string of numbers) is an address on the blockchain. Value tokens sent across thenetwork are recorded as belonging to that address. Data stored on the blockchain is generally considered incorruptible.Therefore, blockchains are secure by design. The interested readers are referred to [21] for more details.3
PREPRINT - F
EBRUARY
23, 2021
Apply ForCandi-dature Backout Get Token GetEncryptionKey GetCandidateList Cast Vote GetDecryptionKey Tally Vote C I D P r oo f U n i qu e I D C I D P r oo f t bcr − t ecr V I D P r oo f U n i qu e T ok e n t btd − t etd A E n c r yp ti on K e y A G e t C a nd i d a t e L i s t V T ok e n & E n c r yp t e d V o t e t bvc − t evc A E n c r yp ti on K e y A L i s t o f V o t e s t bvt FASTEN Protocol Timeline
OFF-CHAIN METHODS ON-CHAIN METHODS
Figure 1: Illustration of the protocol timeline in FASTEN. Here, C: Candidate, V: Voter, and A : Other agentTo maintain this ledger, blockchain comes with stack based programming that triggers transactions; and uses ad-hocmessage passing and distributed networking. Its network does not have centralized points of vulnerability that computerhackers can exploit nor any central point of failure. This makes blockchain potentially suitable for the recording ofevents, medical records, and other management activities, such as identity management, transaction processing, anddocumenting provenance [22]. By storing data across its network, the blockchain eliminates the risks that come withdata being held centrally. This leads to smart contracts . In particular, we use Ethereum-based smart contracts. Ethereum is an open blockchain platform that allows anyone to build and use decentralized applications (DApps) thatrun on blockchain technology. Ethereum is not limited to predefined operations, as in the case of Bitcoin, but allowsexecution of user-defined operations written in computer codes/scripts on the blockchain through
Ethereum VirtualMachine (EVM). Thus, Ethereum supports the execution of smart contracts .The concept of smart contracts was introduced in 1994 by Nick Szabo [23]. A smart contract is similar to a legalcontract in adhering to strict rules and consequences, stating the obligations, benefits and penalties which may be due toeither party in various circumstances. In addition to all this, it can take information as an input, process that informationusing the set of rules defined in the contract, and take action accordingly.A smart contract in Ethereum is executed on EVM. For every executed instruction, there is a specified cost, expressedin the number of gas units. Gas is the name for the execution fee that senders of transactions need to pay for everyoperation made on an Ethereum blockchain. Gas and ether are decoupled deliberately since units of gas align withcomputation units having a natural cost, while the price of ether generally fluctuates as a result of market forces. TheEthereum protocol charges a fee per computational step that is executed in a contract or transaction to prevent deliberateattacks and abuse on the Ethereum network [24].We use the Ethereum smart contracts to enforce FASTEN. We now explain important aspect in designing of votingprotocol to improve fairness in elections.
As a smart contract resides on blockchain, we inherent the decentralized feature of blockchain with it in our protocol.In designing a FSE, it is mandatory to verify the eligibility of a voter before allowing it to vote. This verificationprocess requires examining the voter’s real-world identity. Examining the same on-chain risks the privacy/anonymityof the voter. This is because it links the real-world voter identity with the encrypted vote. Therefore, there is a needfor separating voter ID from encrypted vote. For the same purpose, we take help from the respective EC to distributetokens which separates voter’s real ID from vote. The tokens are randomly distributed off-chain (off the blockchain,that is not part of the contract) to voters after verifying their identity and eligibility. Since time is of utmost importancein an election, the voting protocol strictly follows a timeline of events to avoid any liabilities. Every method of thecontract has a time bound out of which the contract reverts the call.4
PREPRINT - F
EBRUARY
23, 2021
Notation Definition t bcr time-stamp for beginning the candidature registration(Candidates can begin registration after this time) t ecr time-stamp for ending the candidature registration(All candidates must register before this time) t btd time-stamp for beginning the token distribution(Voters can collect their tokens after this time) t etd time-stamp for ending the token distribution(All voters must collect their token before this time) t bvc time-stamp for beginning the vote casting(Voters can begin casting their vote after this time) t evc time-stamp for ending the vote casting(All voters must cast their vote before this time) t bvt time-stamp for beginning the vote tally(Anyone can ask for vote tally only after this time)Table 2: Time Constraints in FASTEN Role of Election Commission (EC).
To ensure that only eligible candidate gets to vote, we take help from EC to verifyvoter eligibility. Every data on the smart contract is on blockchain and thus is publicly available. This implies thatthe voter database cannot be made public to preserve voter anonymity. Also verifying voter ID on blockchain andregistering vote through that ID violates voter anonymity. To resolve these, we let EC verify voter ID off-chain anddistribute random tokens to the voters as a grant to vote. Note that every voter must be given only one token. The smartcontract assumes that EC distributes the token truthfully, securely and privately without keeping any trace of voter IDwith the token. The smart contract holds a pre-stored database of hashes of the token issued by the EC. Since the tokenis distributed by verifying the voter eligibility, the smart contract need only check if the token is genuine and not fake.It does so by checking if the hash of the token exist in the token hash database.Also, the voters in FASTEN are not bothered with any commitments through deposits as in previously proposed votingmechanisms based on blockchain. In contrast, they are simply required to get the encryption key and ID, encrypt thevote and send it through the smart contract along with their token. The overhead of submitting the decryption keysrelies with a different set of agents. We refer to such a third party as a
Warden . These agents store the decryption keysafely instead of the voters, the process of which is explained later. Each warden holds a key which corresponds to abatch of vote. These wardens represent a distributed trust system and are incentivized to act honestly in the system.We also assume the candidate registration to be handled by EC and the candidate list to be provided by them in advance.
Role of Smart Contracts.
EVM(s) which are currently used for conducting election systems are black box to the voterbecause the software used inside EVM cannot be inspected by them. This raises concerns regarding code tempering byEVM. Unlike the code in EVM, a smart contract’s code resides on a public distributed ledger, i.e., blockchain. Thisenables anyone to inspect the method’s deployed by a smart contract. Also since smart contract resides on blockchain,every data/transaction that is part of the contract also becomes a part of the blockchain, which ensures the permanenceof the history of the vote done by the voter. Thus, it results in the verifiability of the vote counting.After time t evc , when the decryption key is released public, it can be used to decrypt the encrypted votes stored safelyon blockchain and compare with the result achieved by the smart contract. Since the encryption keys and correspondingdecryption keys have to be different by the design of the protocol, we use an asymmetric cryptography. Any asymmetriccryptographic system will work for our protocol such as ElGamal cryptography system [25]. With these as a backdrop,we now formally present our FSE protocol, FASTEN. In FASTEN, we use Ethereum-based smart contracts to enforce the protocol. The contract maintains strict adherence tothe time constraints. Therefore each method in the contract is bound by a time window outside of which the contractreverts the call made to it. These time-constraints are defined and explained in Table 2.5
PREPRINT - F
EBRUARY
23, 2021
Variables Definition block.timestamp
Current time-stamp candList
List of the registered candidates numKeys
Total number of the encryption keys available idCounter
To allocate the encryption-decryption key pair enKeys
List of all encryption keys provided deKeys
List of decryption keys aggregated by the wardens hashDatabase
Database of the hashes of all the tokens voteBatch
Database to store votes securityAmt
Security amount wardens deposit before registration refundAmt
Array to store amount to be refunded to the wardens reward
Additional reward to the wardens wardens
Mapping from warden address to key id sampleText
Sample file to authenticate key pair(s) tallyDone
Flag to ensure votes are only counted onceTable 3: Variables in FASTENFASTEN also uses some predefined variables and databases, which are fed into the smart contract beforehand. Wedescribe them as follows.
FASTEN: Variables.
Table 3 provides the variables in FASTEN . From Table 3, hashDatabase is basically a mappingfrom hash string to boolean such that T rue value means the hash is present in database. It is pre-populated beforehand.Further, voteBatch is a double array where voteBatch [ i ] represents the array of encryption votes with encryption id i .The list of encrypted votes gets aggregated in the course of the election. These variables are part of the underlyingmethods deployed in FASTEN. We now describe these methods next. In FASTEN, for improved scalability and efficiency, we consider a hybrid model, i.e., some of the underlying methodsare on-chain while others are off-chain. Later, we describe the control flow of the protocol using these methods.
These are the methods that are not part of the smart contract. We formally present them next.•
ApplyForCandidature.
This method allows eligible candidates to register themselves as the candidate forelection. For the implementation, we suggest the use of a biometric scanner for ID authentication. The methodgenerates a unique voting ID for the candidate. It can only be used during ( t bcr , t ecr ) .• Backout.
Registered candidates can use this to backout from the election. The candidates must first authenticatetheir identity using the biometric scanner. The method can also only be used during ( t bcr , t ecr ) .• GetToken.
This method is not part of the smart contract but a facility provided outside the contract to get thetoken privately. This method will distribute a unique token which the voter can use to cast vote. The token willonly be distributed after a succesful ID authentication through biometric. It can be used only in the duration ( t btd , t etd ) . : These set of methods comprise those that are part of the smart contract. We classify them under two subsets: “Generalpublic" methods and “Warder Specific" methods. This categorization is based on whom all can invoke these methods.We now formally present them. General public methods.
These include, For older versions of Solidity, i.e., < . . , block.timestamp corresponds to msg.now . PREPRINT - F
EBRUARY
23, 2021
Method 1:
GetEncryptionKey require( block.timestamp ∈ ( t bvc , t evc ) ) Int i ← idCounter + 1 idCounter = ( idCounter + 1)% numKeys bytes32 ek ← enKeys [ i ] return [ i, ek ] Method 2:
CastVote
Input:
Token t , Int i , bytes32 ev require( block.timestamp ∈ ( t bvc , t evc ) ) bytes32 h ← sha t ) require( hashDatabase [ h ] == true ) hashDatabase [ h ] = f alse voteBatch [ i ] .push ( ev ) Method 3:
VoteTally require( block.timestamp > t bvt ) if tallyDone == f alse then for Int i = 0; i < numKeys ; i + + do for bytes32 ev : voteBatch [ i ] do bytes32 dk = deKeys [ i ] bytes32 dv ← decrypt ( ev ) bytes32 candId = extract ( dv ) candT ally [ candId ]+ = 1 tallyDone = true return candT ally • GetCandidateList.
This method returns the list of all the candidates participating in the election. Thisis simply a getter method. For e.g., a function that is set to “view" in solidity. The method requirese noauthentication and can be invoked during ( t ecr , t bvc ) .• GetEncryptionKey:
This method shares the encryption key with the caller who invokes it. It also requires noauthentication. The caller is provided with an encryption ID and the corresponding encryption key. It can beinvoked only in the duration ( t bvc , t evc ) . We present the pseudo-code in Method 1.• CastVote:
Presented in Method 2, it allows the eligible voters to register their vote. Required parametersare token , encryption id and encrypted vote. The token is validated after which the encrypted vote is storedcorresponding to its encrypted id. This method can be used only in the duration ( t bvc , t evc ) .• GetDecryptionKeys.
Similar to Method 1, this method shares the list of decryption keys with the caller whoinvokes it. The method requires no authentication but can only be invoked after t bvt .• TallyVote:
This decrypts the votes, counts them and returns the result (Method 3). It requires no authentication.Once the votes have been decrypted and counted, it returns the pre-computed result in the subsequent calls.This method can also only be invoked t bvt . Warden Specific Methods.
These include,•
DepositSecurity.
The wardens invoke this method to deposit monetary value as security against their honestbehavior and to confirm their registration. The method is presented in Method 4.•
SubmitEncryptionKey.
As described in Method 5, this method allows the wardens to submit the encryptionkey in the required duration.•
SubmitDecryptionKey.
This method is used by the wardens to timely submit the correct decryption key. Wepresent the method in Method 6.•
WithdrawReward:
From Method 7, wardens can use this method to collect their reward after successfulsubmission of decryption key. This is the only time the voter is required to send a token to the smart contract. PREPRINT - F
EBRUARY
23, 2021
Method 4:
DepositSecurity require( wardens [ msg.sender ] > ) require( block.timestamp < t bvc ) require( msg.value > securityAmt ) ref undAmt [ msg.sender ] = msg.value − securityAmt Method 5:
SubmitEncryptionKey
Input: bytes32 ek uint id = wardens [ msg.sender ] require( id > ) require( block.timestamp < t bvc ) require( ref undAmt [ msg.sender ] > ) enKeys [ id ] = ek Method 6:
SubmitDecryptionKey
Input: bytes32 dk uint id = wardens [ msg.sender ] require( wardens [ msg.sender ] > ) require( block.timestamp ∈ ( t evc , t bvt ) ) require( ref undAmt [ id ] > ) bytes32 ek = enKeys [ id ] require( sampleT ext == decrypt ( encrypt ( sampleT ext, ek ) , dk ) ) deKeys [ id ] = dk refundAmt[msg.sender] += securityAmt + reward Method 7:
WithdrawReward require( wardens [ msg.sender ] > ) require( block.timestamp > t bvt ) uint amt = ref undAmt [ msg.sender ] ref undAmt [ msg.sender ] = 0 if amt >0 then msg.sender.transf er ( amt ) As aforementioned, in FASTEN, we use tokens distributed by EC to register a voter’s vote. We now explain how we usethose tokens to guarantee secure voting.
The tokens are distributed through an off-chain system. Token get pre-generated and stored securely and privately withEC. We assume that tokens will be distributed privately and securely by the respective EC. The voter provides the tokenonly once while sending its encrypted vote. The smart contract keeps the hash of all the tokens in its on-chain database.It calculates the hash of the token provided by the voter and checks if the hash of the token exist in the database. Iffound, it removes the entry of the token from the database and registers the voter’s vote. Now that we have provided the core protocol design, we give a sample walk-through of the protocol. A voter whowishes to use FASTEN, can use it by following Procedure 8.We will now describe the way through which the decryption key is kept secret in FASTEN. We suggest hash functions which are efficient over a smart contract such as sha3 [26]. PREPRINT - F
EBRUARY
23, 2021
Procedure 8:
Voting Procedure() Vote Casting Window Opens token t ← getT oken () Candidate List candList ← GetCandidateList () Let canList be the preferred candidate of Gretel from the list candList Encryption ID, Encryption Key i, ek i ← GetEncryptionKey () Encrypted Vote v ← Decrypt () , encryption done off-chain by the voter CastV ote ( t, v, i ) Vote Casting Window Ends Vote Tallying window opens Vote Count[] vc ← T allyV ote () vc i represents vote count of i th candidate in the canList Decryption Key List dk ← GetDecryptionKeys () where dk i represents decryption key associated with the encryption id i The list of decryption key can be used to get the vote count manually check the same with calculated by thecontract.
As a smart contract cannot store data privately, we take we take assistance from wardens outside the contract to timelysubmit the decryption keys. In FASTEN, wardens are appointed to keep the decryption keys off the chain. They providethe keys to smart contract through a special transaction when the time comes, i.e., during ( t evc , t bvt ) .Consider a set of wardens W . Each warden w i ∈ W has a decryption key dk i and is assigned a batch of votes which canbe decrypted through that key. Trivially, | W | are the total number of batches. Now, let B be the dataset of batches, i.e.,where b i ∈ B is the batch corresponding to w i . Observe that every time GetEncryptionKey() (Method 1) is called, thecontract provides the voter with the encryption id i corresponding to w i and an encryption key ek i . The voter encryptsthe vote using the encryption key and then sends the encrypted vote and “ i " as parameters to CastVote() (Method 2).The contract then assigns the encrypted vote to b i . As a result, after t evc , if we have n votes in total, every batch b i willhold roughly n | W | number of encrypted votes.In FASTEN, we do not take for granted that the wardens will be honest. Towards this, we design our protocol so as tominimize the loss in case any warden turns out to be dishonest. Observe that any dishonest warden can cause trouble intwo ways: aborting its duty and/or leaking the decryption key. We now provide our solution to these two problems. Each warden w i submits a deposit dk i prior to its participation in FASTEN. The warden’s address will be stored inthe smart contract database. As a result, it will get its deposit refunded only if it timely submits the correct decryptionkey. The smart contract will verify the decryption key by trying the encryption-decryption key pair on some r randomstrings. Once the decryption key is verified to be correct, the warden will get the deposit refunded. We also suggest toprovide an additional bonus amount as a reward for honest behavior. We remark that it is practically impossible to prevent any warden w i from leaking its decryption key dk i . In the eventthat a warden w i leaks the decryption key, on average, it will leak the tally of only n | W | votes. Thus, we suggest tochoose the number of wardens | W | so as to minimize this loss to a very minute percentage. For example, having lessthan th fraction of voters with each warden, will ensure that a single dishonest warden cannot leak tally of morethan . of votes. The number of wardens is a protocol parameter and can be increased depending on the budget andrisk tolerance. As aforementioned, an election is said to be fair if it satisfies the four properties: vote anonymity, vote concealment,vote immutability and double voting inhibition. That is, every voter is able to vote discretely and anonymously and thevote tally remains hidden until the end of the election. Further, nobody is able to cast the vote without authentication norcast the vote twice. We now (i) provide the formal definitions; and (ii) prove that FASTEN satisfies all these properties.9
PREPRINT - F
EBRUARY
23, 2021
Definition 1 (Voter Anonymity) . An election protocol is said to satisfy the Voter Anonymity property if probability offinding the vote of any voter is negligibly small as compared to the size of the population.
Claim 1.
FASTEN satisfies voter anonymity with probability of guessing any voters token being at most n l where n isthe number of voters and tokens are l -bit long.Proof. The smart contract takes the token as an attribute from the voter to register their encrypted votes. We demandthe voters to use a new Ethereum address to cast their encrypted vote since the old Ethereum address might have beencompromised by the voter. Since the token is randomly generated and privately distributed off the blockchain, it cannotbe linked back to the voter through the blockchain because Ethereum addresses are randomly generated and have norelation with the identity of the user. The public ledger will only show that a certain encrypted vote has been registeredfor a certain token. It implies that even after the vote is encrypted, it is related to only the token and has no links withthe previous holder of the token. Thus the vote can never be traced back to the voter except possibly random guessing.If token is l -bit long, and size of the voter population is n , the random guessing will not succeed by probability morethan n l . By choosing, l >> log n , we can ensure voter anonymity. Definition 2 (Vote Concealment) . An election protocol is said to satisfy the Vote Concealment Property if no vote’svalue is revealed before the end of the election vote casting period with probability more than k if no more than k wardens are dishonest. Claim 2.
FASTEN satisfies vote concealment property.Proof.
As we have highlighted earlier, the voters will register their encrypted vote to the contract. The encryption keyand the corresponding encryption ID will be provided by the contract itself to the voters. The voter encrypts the votethrough the encryption key off the blockchain on her device and sends it to the smart contract along with the encryptionID and the respective token. Since the vote is encrypted off the chain, the real value of the vote remains hidden until thedecryption key is out. The decryption is made public only after the end of vote casting window, thereby concealing thevote until the voting period ends. Hence the property of Vote Concealment is preserved.
Definition 3 (Vote Immutability) . An election protocol is said to satisfy the Vote Immutability property if no vote’svalue can be altered once it has been casted.
Claim 3.
FASTEN satisfies vote immutability under assumption that majority of the nodes in the network are honest.Proof.
Ethereum blockchain stores all the transactions permanently by default. Once a transaction is part of the publicledger, it cannot be removed or changed unless 51% or more nodes are corrupt. Also, since once the hash of a token ismatched to that of the database on the blockchain, it is immediately removed, thereby no overwriting of the vote ispossible.
Definition 4 (Double Voting Inhibition) . An election protocol is said to satisfy the Double Voting Inhibition property ifprobability that any voter can cast more than one vote in the election is negligible.
Claim 4.
FASTEN satisfies double voting inhibition property.Proof.
The smart contract has an on-chain database containing the pre-calculated hashes of the tokens distributed to thevoters. The voters are required to send their tokens to register their vote. The smart contract calculates the hash of thereceived token and compares it with the ones stored in the database. If a match is found, the token hash is removed fromthe database and the vote is registered. Since the token is immediately removed from the database before registering theencrypted vote, we can safely claim that every token is used only once to register the vote, thus inhibiting double voting.The only possibility for an voter to double vote would be to cast a vote with its valid token as well as guess a randomtoken whose hash matches with that one in database. If hash is of length h -bits, even by birthday-paradox the voterneeds to try h trials to guess a first valid token apart from its own. Typically hash sizes ( h ) are 256 bits. Hence, theprobability of successful double voting is negligible.Thus, we have proved theoretically that FASTEN achieves fairness in election, i.e., FASTEN is a solution for FSE. Nowwe perform cost analysis of FASTEN. 10 PREPRINT - F
EBRUARY
23, 2021
We analyze the cost in terms of ethereum gas, which is constant cost of network resources/utilisation. We use the gasestimation given in ethereum docs and ethereum rate card also given in the docs for the estimation of cost per vote [].We estimate the cost per vote in 2 stages: (i) Voter side cost; and (ii) Warder side cost.
In FASTEN, each voter has to follow a particular sequence of methods in order to cast the vote. From Procedure 8, thevoter follows the given sequence: (i) GetCandidateList, which has its gas requirement as 26 units; (ii) GetEncryptionKey,which consumes 667 gas units; and (iii) CastVote, that consumes 739. In total, the vote casting consumes 1432 Gasunits.Further, TallyVote computes the vote count for each candidate when called for the first time and returns the result. Afterthis, it returns the pre-computed result for subsequent calls. This optimization ensures that there are no redundantcalculations. Therefore, every vote is decrypted and counted once. This ensures that TallyVote is equivalent to countingof a single vote, which we estimate as gas units. The estimation is high as we encrypt votes using -bitElGamal encryption. Thus, the decryption cost is itself high.Fortunately, there is an easy optimization to this as well. We suggest to decrypt the vote on DApp instead of the smartcontract. As smart contracts are mainly used for maintaining persistent states throughout the network and the decryptionwon’t alter the state, the decryption can be done on the DApp. By avoiding the decryption cost, we get an upper boundof gas units cost per vote for the voter side.
In FASTEN, each warden uses the following methods in the order given: (i) DepositSecurity, which requires 23 gasunits; (ii) SubmitEncryptionKey, which requires 629 gas units; (iii) SubmitDecryptionKey, with 600755 gas units; and(iv) WithdrawReward, which requires 21629. That is, each warden consumes gas units in total. The reasonfor such high cost is the encryption and decryption operations done in
SubmitDecryptionKey method to check theauthenticity of the decryption key. But as mentioned during the analysis for voter side’s cost, one can avoid the costof encryption and decryption by computing it on the DApp instead of a smart contract. This also reduces the wardenside cost to an upper bound of gas units. Suppose there exists total of n voters, then every warden holds thedecryption key for n | W | voters, on average. Therefore, cost per vote from warden’s side comes out to be ·| W | n gasunits.For a reasonable choice of n | W | , such as 1000, this cost comes to be ≈ gas units. Adding this to the voter side costcalculated above, we can set the upper bound for the total cost per vote of in FASTEN in terms of Ethereum gas unitsas (when n | W | = 1000 ). Further note that, gas units corresponds to . ETH as 1 gas unit equals · [27]. As at the time of writing of this paper, we have ETH ≈ USD, the overall cost comes out to be . USD per vote.
As shown, the total gas consumption in FASTEN is per vote (when n | W | = 1000 ). The block gas limit at the timeof writing of paper, for Ethereum, is ∗ [28]. Thus, each Ethereum block can hold votes. Further, at the timeof writing this paper, each block takes s to get on the Ethereum Network [29]. This corresponds to a processingcapacity of roughly votes per hour . Inference from Analysis.
A rough estimate of the cost per vote is . USD (when n | W | = 1000 ). This is significantlylower than the amount of money spent in countries all over the world for mass elections. For Example, the per voteelection cost for UK European Parliament Election 2014 is . USD [33]. We remark that this estimate can be significantly improved by deploying a more scalable underlying blockchain consensusprotocol such as [30–32]. PREPRINT - F
EBRUARY
23, 2021
We showed that FASTEN is a solution for FSE through blockchain and smart contracts. It also provides a transparentdecentralized system through which the stakeholders can verify the result. We also argued that our protocol is costefficient compared to the existing election methods. In summary,1. FASTEN does not reveal voter identity at any stage of the process.2. In FASTEN, votes cannot be revealed at any time before the vote casting window expires. Even the vote count isconcealed from everyone until the window expires. Thus, FASTEN ensures that voting is not influenced at any stage.3. FASTEN allows anyone to check the end-to-end voting procedure independently. This is because all the relevantinformation is on a public ledger. As proved, this is achieved without compromising voters’ privacy as every vote iscryptographically secure and cannot be traced back to the voter.4. As we do not assume nor use any constraints on voting population, FASTEN can be used for a large population.5. Our cost analysis shows that FASTEN is cost efficient as compared to exisiting protocols.6. Unlike prior works, in FASTEN voters do not have to commit and return to the protocol to reveal their votes.
Oracles: An alternative to Warden Assistance.
As smart contracts cannot access and fetch data outside the blockchain,in FASTEN, we rely on wardens to provide the decryption keys. Another way to achieve this is through oracles . Anoracle is a third party service designed for smart contracts and can feed data from outside the blockchain to it, asand when required. However, relying on such third party oracles can compromise the distributed trust model of theunderlying blockchain. As a result, in FASTEN, we leverage wardens.In order to use oracles, we need a way to ensure the data provided is genuine and not tempered. Oraclize [34] is onesuch service provider which claims to be provably honest , i.e., which provides unaltered data to smart contracts. Theydo so by accompanying the returned data together with a document - referred as an “authenticity proof" - which can berequested using the oraclize_setProof function provided by the service. The authenticity proofs build upon differenttechnologies such as auditable virtual machines and trusted execution environments (refer [35]).
Liquid Democracy.
The use of transferring voting rights to an informed voter has been referred as liquid democracy [36].Kahng et. al. [36] showed existence of certain delegation mechanisms that can outperform traditional voting in terms ofselecting better candidates. We believe, such mechanisms can be easily implemented through FASTEN. It will need todo a transaction between the voter (willing to transfer voting rights) and the delegate to transfer its token. We leavesecurity analysis of this for a future work.
References [1] Roger Gibbins Heinz Eulau, Paul David Webb et al. Election, 2015.[2] Silvio Micali and Michael O Rabin. Cryptography miracles, secure auctions, matching problem verification.
Communications of the ACM , 57(2):85–93, 2014.[3] Ben Adida. Helios: Web-based open-audit voting. In
USENIX security symposium , volume 17, pages 335–348,2008.[4] Vitalik Buterin. Ethereum: A next-generation smart contract and decentralized application platform.
URLhttps://github. com/ethereum/wiki/wiki/% 5BEnglish% 5D-White-Paper , 2014.[5] Zhichao Zhao and T-H Hubert Chan. How to vote privately using bitcoin. In
International Conference onInformation and Communications Security , pages 82–96. Springer, 2015.[6] Bin Yu, Joseph K Liu, Amin Sakzad, Surya Nepal, Ron Steinfeld, Paul Rimba, and Man Ho Au. Platform-independent secure blockchain-based voting system. In
International Conference on Information Security , pages369–386. Springer, 2018.[7] Yuan Lu, Qiang Tang, and Guiling Wang. Zebralancer: Private and anonymous crowdsourcing system atop openblockchain. In , pages853–865. IEEE, 2018.[8] Huayi Duan, Yifeng Zheng, Yuefeng Du, Anxin Zhou, Cong Wang, and Man Ho Au. Aggregating crowd wisdomvia blockchain: A private, correct, and robust realization. In , pages 1–10. IEEE, 2019.12
PREPRINT - F
EBRUARY
23, 2021[9] Sankarshan Damle, Boi Faltings, and Sujit Gujar. A truthful, privacy-preserving, approximately efficient combina-torial auction for single-minded bidders. In Edith Elkind, Manuela Veloso, Noa Agmon, and Matthew E. Taylor,editors,
Proceedings of the 18th International Conference on Autonomous Agents and MultiAgent Systems, AAMAS’19, Montreal, QC, Canada, May 13-17, 2019 , pages 1916–1918. International Foundation for Autonomous Agentsand Multiagent Systems, 2019.[10] Sankarshan Damle, Boi Faltings, and Sujit Gujar. A practical solution to yao’s millionaires’ problem and itsapplication in designing secure combinatorial auction.
CoRR , abs/1906.06567, 2019.[11] Parameter generation - zcash.[12] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, DavidEnyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, et al. Hyperledger fabric: a distributedoperating system for permissioned blockchains. In
Proceedings of the thirteenth EuroSys conference , pages 1–15,2018.[13] Arati Baliga, I Subhod, Pandurang Kamat, and Siddhartha Chatterjee. Performance evaluation of the quorumblockchain platform. arXiv preprint arXiv:1809.03421 , 2018.[14] Patrick McCorry, Siamak F Shahandashti, and Feng Hao. A smart contract for boardroom voting with maximumvoter privacy.
IACR Cryptology ePrint Archive , 2017:110, 2017.[15] Followmyvote.[16] S. K. Vivek, R. S. Yashank, Y. Prashanth, N. Yashas, and M. Namratha. E-voting systems using blockchain:An exploratory literature survey. In , pages 890–895, 2020.[17] Pavel Tarasov and Hitesh Tewari. Internet voting using zcash.
IACR Cryptology ePrint Archive , 2017:585, 2017.[18] Emanuele Bellini, Paolo Ceravolo, and Ernesto Damiani. Blockchain-based e-vote-as-a-service. In , pages 484–486. IEEE, 2019.[19] Friðrik Þ Hjálmarsson, Gunnlaugur K Hreiðarsson, Mohammad Hamdaqa, and Gísli Hjálmt`ysson. Blockchain-based e-voting system. In , pages983–986. IEEE, 2018.[20] Haibo Yi. Securing e-voting based on blockchain in p2p network.
EURASIP Journal on Wireless Communicationsand Networking , 2019(1):1–9, 2019.[21] Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, and Steven Goldfeder.
Bitcoin and cryp-tocurrency technologies: a comprehensive introduction . Princeton University Press, 2016.[22] Wikipedia contributors. Blockchain — wikipedia, the free encyclopedia, 2017.[23] Nick Szabo. Smart contracts: building blocks for digital markets. , 1996.[24] Ethereum homestead documentation.[25] Taher ElGamal. A public key cryptosystem and a signature scheme based on discrete logarithms.
IEEE transactionson information theory , 31(4):469–472, 1985.[26] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger.
Ethereum Project Yellow Paper ,151, 2014.[27] Ethereum average gas price chart.[28] Evolution of the average gas limit.[29] Average block time of the ethereum network.[30]
Documentation/TechnicalWhitepaper.md , 2020. https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md .[31] Mahnush Movahedi Timo Hanke and Dominic Williams. Dfinity technology overview series consensus system.CoRR abs/1805.04548 (2018), 2018.[32] Sanidhay Arora, Anurag Jain, Sankarshan Damle, and Sujit Gujar. Ashwachain: A fast, scalable and strategy-proofcommittee-based blockchain protocol. In
Workshop on Game Theory in Blockchain at WINE 2020 (GTiB@WINE2020) , 2020.[33] The costs of the 2014 european parliamentary elections, 2016.[34] Oraclize. 13
PREPRINT - F
EBRUARY
23, 2021[35] Oraclize official documentation.[36] Anson Kahng, Simon Mackenzie, and Ariel D Procaccia. Liquid democracy: An algorithmic perspective. In32ndAAAI Conference on Artificial Intelligence