key: cord-0653411-wuebi3bz authors: Onur, Ceyhun; Yurdakul, Arda title: ElectAnon: A Blockchain-Based, Anonymous, Robust and Scalable Ranked-Choice Voting Protocol date: 2022-03-31 journal: nan DOI: nan sha: dca3f3991336118994e16c601072b5a78f976d54 doc_id: 653411 cord_uid: wuebi3bz Remote voting has become more critical in recent years, especially after the Covid-19 outbreak. Blockchain technology and its benefits like decentralization, security, and transparency have encouraged remote voting systems to use blockchains. Analysis of existing solutions reveals that anonymity, robustness, and scalability are common problems in blockchain-based election systems. In this work, we propose ElectAnon, a blockchain-based, ranked-choice election protocol focusing on anonymity, robustness, and scalability. ElectAnon achieves anonymity by enabling voters to cast their votes via zero-knowledge proofs anonymously. Robustness is realized by removing the direct control of the authorities in the voting process by using timed-state machines. Results show that ElectAnon is scalable amongst existing works as it reduces the gas consumption up to 89% compared to previous works. The proposed protocol includes a candidate proposal system and swappable tallying libraries. An extension is also proposed to minimize the trust assumption on election authorities. Our code is available on https://github.com/ceyonur/electanon. The recent COVID-19 pandemic has pushed existing systems and procedures to be implemented remotely. Legacy election systems, which oblige voters to go to a specific place to cast a ballot, have also been impacted by the pandemic. For example, almost half of the votes were cast through mail voting in the US 2020 presidential election [9] . Internet voting, or simply i-voting, has enabled voters to cast their ballots remotely, unlike those legacy voting systems which require voters to show up in a specific place like voting booths. Research shows that internet voting can be a better solution in pandemic periods, as it can give faster results and be more cost-effective when compared to mail voting [20] [19] . The i-voting brings possible advantages like reduced operational costs for elections, time-saving, increased voter participation, and improved transparency in elections. Estonia and Switzerland are two early adopters of i-voting in nationwide government elections [4] . An Estonian governmental agency, Enterprise Estonia (EAS), reported that the i-voting saved approximately 11,000 working days cumulatively in the 2011 Estonian parliamentary election [35] . The same report mentions that the saved costs were roughly equal to €504,000. Blockchain has emerged as a new paradigm to solve concerns like censorship and single point of failure using a decentralized infrastructure. Blockchain technology offers distributed, secure, privacy-preserving, and immutable ledgers. These innovations are found to be very suitable for voting systems [16] . Many existing blockchain-based applications use voting mechanisms, such as decentralized autonomous organizations (DAOs) [11] . We think that just as blockchains can be helpful for voting systems, voting systems can also be beneficial for blockchains. In this work, we analyze and discuss secure election requirements along with state-of-the-art solutions in blockchain-based election systems. Analyzing existing solutions has shown us that anonymity, robustness, and scalability are common problems. They cannot achieve anonymity because election authorities can know voter identities during voting. Robustness is also not assured as most of the protocols are disruptable in the voting process or require additional assistance from authorities to tally votes. Most of the works use complex encryption and decryption schemes to preserve privacy. We find that these complex schemes are inefficient for blockchains and cause high voting transaction costs, making existing systems unscalable. In the light of these analyses, we propose ElectAnon, a blockchain-based ranked-choice election protocol focusing on anonymity, robustness, and scalability. We aim to achieve privacy through anonymity in the proposed protocol using zero-knowledge proofs. This not only brings a novel solution for privacy issues but also increases the scalability by replacing complex encryption schemes with zero-knowledge proof schemes, which are more optimized and efficient for blockchains. ElectAnon minimizes manual transitions between election phases to achieve robustness. ElectAnon aims to reduce voting gas costs to increase scalability. Our main contributions in this work are presented as follows: • We gather known secure election requirements and extend them. Anonymity is derived from existing Privacy requirements. The current definition of Robustness is expanded by adding Autonomy to it. Scalability is also redefined and included in blockchain-based election requirements. • A privacy-preserving, anonymous, blockchain-based voting protocol is proposed. The protocol fulfills the discussed election requirements. • The protocol inherits a scalable ranked-choice voting system to conduct more democratized elections. • A candidate proposal system is included in the protocol to provide an end-to-end decentralized election experience. • A modular and algorithm-agnostic mechanism is used in tallying to switch between different methods easily. Two ranked-choice tallying methods, Borda Count and Tideman, are implemented and analyzed. • The Merkle Forest extension is proposed for adjusting trust assumptions and conducting even more trustless election environments. We used Ethereum Virtual Machine (EVM) [8] based smart contracts and an EVM-based zeroknowledge tool called Semaphore [15] in our implementations. Our work supports other EVMbased blockchain platforms. ElectAnon can be especially beneficial for decentralized autonomous organizations (DAOs) because of its inherently democratic voting protocol and the ability to work with existing EVM-based smart contracts. Performance tests are conducted in the Ethereum and Avalanche local test networks to measure the scalability of the implemented solution. We see that our work can run feasibly up to 100,000 voters. Moreover, we show our work can increase the number of voters indefinitely with increased costs. Test results show that our work reduces the total election gas consumption by 89% compared to existing solutions. The pioneer whitepaper of blockchain technology, Bitcoin, was published in 2008 by an anonymous identity, Satoshi Nakomoto [28] . Bitcoin proposes secure, agreeable and decentralized asset transfers in peer-to-peer networks. Bitcoin brought a groundbreaking approach to asset transfers with modern cryptography techniques. It does not only offer a way to decentralize asset transfers but also reduce transaction costs in comparison to traditional banking. Bitcoin also brings a rewarding system called Proof of Work to incentivize network participants to contribute to network security actively. A fee in every transfer (transaction) is deducted as a reward. Bitcoin has some basic scripting to support features like time-locking transactions and multi-owner transactions. However, this has turned out insufficient to support many application use cases. Vitalik Buterin proposed Ethereum in 2014 to address issues with Bitcoin [8] . Ethereum aims to become a global and decentralized computer that can run many different applications called smart contracts [8] . Ethereum has been a massive success since its release in 2015. Smart contracts are applied in various industries like finance, logistics, insurance, entertainment and art. The article reports that the number of smart contracts deployed on the Ethereum network was almost 1.5 million in 2020 [33] . Today, it remains the second-largest cryptocurrency, just one place behind Bitcoin. Decentralized Autonomous Organization (DAO) is yet another blockchain concept in recent years. DAO can be defined as "an organization that requires no central management" [11] . In DAOs, organizational decisions are made through proposals and elections conducted with smart contracts in the blockchain. Each proposal defines an administrative operation like hiring new employees and managing resources. DAOs distribute tokens to investors as voting power. A recent article shows that the DAO member number peaked at 700,000 in September 2021 [2]. Zero-Knowledge proofs provide a way to prove the existence of the knowledge without revealing the knowledge itself. Use cases include anonymous authorizations, private payments, computation off-loading and electronic voting [32] [26] . Zero-Knowledge Succinct Non-Interactive Argument of Knowledge or simply zk-SNARK brought an efficient zero-knowledge protocol that reduces the number of rounds to verify proofs [32] . zk-SNARK proofs are "succinct" and can be verified in milliseconds, and their proof sizes can be as small as a few hundred bytes long. zk-SNARKs are widely used in blockchains to preserve privacy and off-load heavy computations for scalability. Zcash is a well-known blockchain platform that uses zk-SNARKs [6] . Zcash offers fullprivate blockchain transactions that completely hide sender and receiver addresses and transaction amounts. The success of Zcash has led other blockchain platforms to use zk-SNARKs. Ethereum optimized zk-SNARK operations and reduced their gas costs with the Istanbul upgrade [13] . Aztec [40] and StarkNet [37] are two side networks developed with zk-SNARKs to off-load Ethereum transactions. zk-SNARKs are constructed with complex arithmetic equations called circuits [30] . There are circuit compilers that can abstract these equations and generate circuits using higher-level languages. Circom [1] and Zokrates [44] are two popular zk-SNARK circuit compilers. They support basic software-language concepts like variables, functions, control flows. These languages can declare private input signals which are not revealed in proofs. They can also generate smart contract verifiers to verify proofs on-chain. Typical steps for generating and verifying zk-SNARK proofs are listed as follows: (1) A high-level program (circuit) is designed by writing the logic for the zero-knowledge computation. (2) The circuit is compiled into a set of low-level arithmetic equations. (3) Verification and proving keys are generated with the compiled circuit. (4) Prover executes the compiled circuit with given public and private inputs and generates the witness result. (5) Prover generates the proof with the witness and the proving key. (6) Prover sends the generated proof and public inputs to the verifier. (7) Verifier verifies the proof with the verification key. The Semaphore is a zero-knowledge protocol and set of tools for anonymous signaling [15] . It uses a circuit and a smart contract to prove these three properties: (1) An identity is eligible to broadcast a signal. (2) The signal truly belongs to the identity owner (3) The signal is not broadcasted twice. The Semaphore aims to prove these properties without revealing extractable information about the user identity. As a result, users can broadcast various signals without revealing their actual identities. A valid proof verifies that the user is indeed on the eligible list. Eligible lists are defined with Merkle trees so that identity verification can be efficiently done with Merkle proofs. The Semaphore contains a Circom zk-SNARK circuit, smart contracts, and a Javascript library. Semaphore can be used in many use cases like private transactions, anonymous authentication, mixers, and private voting. We adopted and utilized the Semaphore in our voting protocol. Ranked Choice Voting (RCV) enables voters to sort their candidate preferences and vote with a sorted list, i.e., preference list. Each preference in the list gives a ranked score to the respective candidate. James Anest discusses the depths of RCV and its potential contributions to conduct more "democratic" elections in his work [5] . The author states that RCV can encourage candidates to enter elections without worrying about spoiling votes for other candidates. RCV also encourages voters to participate in elections because it enables voters to express their preferences without worrying about wasting their votes. One of the debates claims that RCV could be too complicated for voters [10] . However, Anest argues that with the advances in computer technology, the RCV can be used in large-scale elections [5] . ElectAnon uses the ranked choice-voting electoral system to provide more democratic setups. Myrvold & Ruskey developed an efficient algorithm to rank & unrank permutation lists [27] . The ranking algorithm takes a permutation list ( ), size of the list ( ), and its inverse ( −1 ); then outputs the corresponding rank integer ( ). Each rank integer represents a permutation list, since there can be at most ! different permutations, the rank integer ( ) can be in the range of between [0... ! − 1]. The unrank algorithm takes , , and an identity permutation ′ and outputs the corresponding permutation list . Both ranking and unranking algorithms have linear ( ( )) arithmetic operation complexity, making them efficient to compute. ElectAnon uses a ranked-choice electoral system. We used the aforementioned rank & unrank algorithms to encode/decode preference lists. Instead of storing the whole list, we were able to compute the rank of each preference list and store the corresponding integer rank in the smart contract. Voters compute ranks of their preference lists off-chain(offline) in the voting phase, so it also off-loads the computation. Our tallying function in the smart contract unranks these rank integers and computes preference lists to obtain results. Some requirements must be satisfied to conduct a secure online election. D.A Gritzalis identified some of these requirements in his work in 2002 [14] . Gritzalis' requirements are still valid even today. Recent work [18] in 2021 mentions a similar set of requirements for secure blockchain-based online elections. We gathered and presented existing definitions of Eligibility, Uniqueness, Privacy, Fairness, Soundness, Universal Verifiability, Individual Verifiability secure election requirements. We also expanded current definitions of Privacy and Robustness. We also introduce Scalability as a secure online election requirement. 2.7.1 Eligibility. Only eligible voters should be able to cast ballots in an election [14] . The eligibility of a voter is generally decided by election owners & authorities. 2.7.7 Privacy and Anonymity. Votes should not be distinguishable in terms of who cast them. It also means that no one should be able to figure out which voter used which ballot [43] . Online voting can be susceptible to linking a digital identity to the actual identity via linkage attacks [25] . This could carry a higher risk if a party, like the election authority, knows the real identities. We expand the Privacy requirement by ensuring that no operation in an election can be linked to actual identities. We call this Anonymity of voters. If the Anonymity is guaranteed, then no parties, even election authorities, can know who interacted with the election protocol during the voting process. 2.7.8 Robustness. This condition ensures the inability of any parties to disrupt an ongoing election [18] . Shirazi et al. expand the Robustness by adding tallying availability on top of voting availability [36] . Voting availability ensures that eligible voters can finish the voting process without disruption. Tallying availability ensures that valid votes can be tallied correctly without any interruption. We think Robustness is crucial for blockchain systems since each transaction requires a transaction fee and cost. If a disruption happens after vote casting, it means that this cost would be for nothing. Most internet-voting protocols typically consist of different phases like Initialization, Voting and Tallying [3] . We extend the Robustness requirement by adding autonomy, which ensures that there can be no halting/freezing between phase changes. 2.7.9 Self-Tallying. Everyone should be able to calculate the election result and come up with the same result as others [42] . This ensures there is no need for authorities or any specific actors to calculate the election result. Everyone, even non-participants, should be able to learn the election result without depending on other parties. 2.7.10 Scalability. We define Scalability as the maximum number of voters and candidate counts in an election. Most blockchain platforms have a fixed capacity of transaction and block size. It means that the Scalability in those systems is more evident and can be easily measurable. We have iterated over some most qualified works mentioned in Trends in blockchain-based electronic voting systems [31] . We evaluated these works in the following aspects: Eligibility, Uniqueness, Privacy, Anonymity, Fairness, Soundness, Universal Verifiability, Individual Verifiability, Robustness and Scalability. Table 1 categorizes and summarizes this evaluation. We have identified Anonymity, Robustness and Scalability are three common problems in the prior works. Anonymity was not considered thoroughly in the related works. Prior studies try to accomplish Privacy by keeping votes encrypted and secret. In the previous works, election authorities hold the information of voters' real identities and their public keys and blockchain addresses. This is needed to form a list of eligible voters properly so that Eligibility can be reassured. Most blockchain addresses are pseudo-anonym by design [23] . As a result, blockchain addresses can be traced to link the user with their chain activities. However, when voters act in an election (vote, commit, register, etc.), election authorities can know which address uses which function. Election authorities may form and enhance a link between the voter identity/blockchain address and the vote usage pattern. In blockchain-based voting systems, it can expose a link between voter identities and different blockchain activities. These blockchain activities can include transactions, token balances, and ownerships. If Anonymity is not guaranteed, then election authorities can link actual identities to these blockchain activities. This link can be further enhanced and break Anonymity if the same list of eligible voters is used many times. We think studies like Yang et al. [41] , McCorry et al. [24] , Priscore [42] suffer from this issue; since they need to repeat their elections in case of abandoned votes. The Robustness also could not be adequately achieved in prior works. Works like Yang et al. [41] and Chaintegrity [43] depend on third-party actors to decrypt ballots in tallying. This violates Robustness, as third-party actors can disrupt the election by providing invalid credentials or not providing credentials at all. Some other works like McCorry et al. [24] and PriScore [42] use shared secret-key encryption to encrypt votes and distribute these shared keys to registered voters. The scheme requires a sufficient number of keys to be revealed for decryption. It means that if voters abandon their votes and do not reveal their shared keys, the remaining votes cannot be decrypted. McCorry et al. [24] try to solve this by incentive mechanisms of depositing and refunding assets. However, if the political advantages of the election exceed economic incentives, voters can still disrupt the election by abandoning their votes. PriScore [42] tries to solve this with additional cryptographic operations; however, it fails to apply it for more than one abandoned vote. Every blockchain transaction costs additional fees. So a large-scale election setup can be very costly, especially the cases like nationwide elections. As a result, Robustness becomes a very crucial requirement in blockchain-based voting. In our work, we tried to minimize the risk of disruption during voting and eliminated the possibility of election repetition. Scalability is another aspect that could not be adequately achieved in prior works. We think that this is because most of the previous works try to preserve privacy with complex encryption/decryption schemes like homomorphic encryption, ElGamal encryption, and shared key encryptions. Gas consumption is a solid indicator of scalability since transactions have a maximum consumable gas limit in Ethereum. Works like McCorry et al. [24] , Panja et al. [29] and Priscore [42] use Ethereum as the blockchain platform and provide their gas consumptions. We tried to evaluate their work in today's Ethereum gas limit standards. We found that these works either hit a maximum gas limit with a relatively small voter set, or consume too much gas, making them practically impossible. We tried to minimize the voter-side gas consumption in our work so that it can be practically possible to conduct a large-scale election with Ethereum. ElectAnon is a self-tallying, privacy-preserving election protocol implemented with EVM smart contracts and the Semaphore [15] zero-knowledge tool. The protocol aims to support all of the requirements mentioned in the Section 2.7. The protocol utilizes a ranked-choice electoral system. There are three system actors: Election Authority, Proposers and Voters. The protocol flows in a timeline of six phases: Setup, Register, Proposal, Commit, Reveal, and Completed. Different actors take different actions in each phase. An overview of our protocol flow and the timeline is presented in Figure 1 . • Election Authority ( ) is responsible for system setup and initialization. decides on system parameters and initializes the election by deploying the smart contract to the blockchain. is also responsible for registering eligible proposers and voters to the system. role can be distributed to multiple parties. In this work, we used a single for the sake of simplicity. ElectAnon protocol implements a timed-transition state machine for each phase. Each state has a timed-transition guard with a lifetime/deadline for these states. If any state-specific transaction (function call) is received after this lifetime, the transaction is rejected, and no changes occur in the blockchain. For example, if the proposal lifetime is selected as 30 blocks, any call to the Proposal state-specific function is rejected after 30 blocks. In addition to lifetimes, there are also conditional transitions in functions to safely change the state to the next one. 4.2.1 Setup State. Election Authority ( ) initializes election parameters and the protocol at this state. decides on the election question, an arbitrary string representing various question topics. For example, "who should be the president" in a presidential election and "which platform should be used" in organizational decisions. prepares the Semaphore zero-knowledge circuit (Circ) in this state. The circuit defines a static tree-level parameter inside the circuit code. The tree-level specifies the maximum depth of the Merkle tree. The parameter also indicates the maximum voter count since voters are registered through Merkle trees. The maximum voter count equals the Merkle tree leaf count, which is 2 tree-level . can alter the tree-level parameter in the circuit to change the maximum voter count. The Semaphore circuit and smart contract use 20 levels by default. It means that a maximum 2 20 = 1.048.576 number of voters can fit into the Merkle tree. must also announce the zero-knowledge verification (VerifyK) and the proving keys (ProveK); so that voters can verify the circuit and generate zero-knowledge proofs. These keys are generated with the given circuit as shown in the equation 1. can store these keys and the circuit in a place where every voter can access, preferably a decentralized storage like The InterPlanetary File System (IPFS) [7] . The storage address ( ) can be put in the smart contract so that voters can fetch keys to generate their proofs. generates the verifier smart contract (VerifierSC) with the verifier key (VerifyK). The verifier smart contract is embedded in the main smart contract (MainSC) so that these two can be combined and deployed as a single smart contract ( ). decides on the election parameters to conduct a custom election. These parameters are tree-level, maximum candidate count, proposal lifetime, commit lifetime, and reveal lifetime. The tree-level should be the same as the one in the circuit . The maximum candidate count indicates the maximum number of proposals that can be registered as candidates. Each lifetime ( ) parameter defines the lifespan of the related state in terms of block number. For example, proposal lifetime indicates the lifespan of the proposal state. can deploy the smart contract ( ) with these parameters. This phase is completed when the contract is deployed. Figure 2 shows the sequence diagram for this state. Voters generate their identity ( ) and identity commitment ( ) with the identity generation function ( ). The function takes a random seed and generates the which contains following components: a private key and public key pair ( , ), a nullifier ( ) and a trapdoor (Trap i ). The identity commitment is constructed by hashing , and . Voters send their to to be registered as an eligible voter for the election through a secure channel. Voters never send the actual identity , but a hash of the which is . The identity must be kept secret by the voter. The Equation 2 shows and generation. generates a Merkle-tree root from all collected identity commitments, then submits along with the list of collected s to the smart contract. The smart contract has a function, addVoters, for Merkle tree registration. The function takes the list and the corresponding . Due to the gas limit of Ethereum, list size has a limit. In our experiments, we found this limit is approximately 30.000 s in a single addVoters call. can split list into smaller batches (like 30.000 per call) and issue them with multiple calls to the smart contract. s must be added to the smart contract in the same order as they are used when constructing the Merkle-tree root. This must be maintained correctly by the so that voters can safely reconstruct the same Merkle tree. can change the state machine to the next state, when it confirms the register state is successfully done. Figure 3 shows the sequence diagram for this state. The smart contract removes proposers from the eligible list after proposing to ensure they can only submit once. The smart contract publishes a ProposedEvent, which contains the assigned candidate ID ( ) and the proposal string. Figure 4 shows the sequence diagram for this state. In addition to lifetime, the state changes when all registered proposers successfully propose or the total proposal count reaches the maximum candidate count. can choose to register more than the maximum candidate count proposers in the Register state to increase the chance of having enough proposals for the election. Voters cast their ballots in the Commit state. Each voter investigates the candidate list and decides its preference list. The candidate list can be fetched from the blockchain by filtering ProposedEvent events. ElectAnon uses a ranked-choice electoral system. In this system, voters need to prepare their preferences as a sorted list, from the most preferred to the least preferred. Voters need to prepare a list that contains every registered candidate. Each of these preference lists is a permutation of [1, 2, 3, ..., ], where is the candidate count. ElectAnon uses an encoding algorithm to rank & unrank each specific preference list [27] . As explained in the Section 2.6, this algorithm efficiently maps a given permutation list to a single rankID integer. Instead of storing the whole list, we store a single voteID (rankID) in the contract. After finalizing their decisions, voters can get the rank of their preference list with the ranking algorithm, which results in voteID ( ). ElectAnon uses vote hashes ( s) to hide the plaintext s to preserve Fairness. Voters can hash their with a secret key VSk to safely mask their . This provides a way to generate indistinguishable vote hashes VH from a plaintext . Each voter locally stores their and for later use. They should keep and as a secret to preserve their privacy. Voters generate Merkle trees to obtain their Merkle proofs to prove their eligibility to vote. Merkle tree leaves ( s) can be fetched from blockchain by filtering VotersAddedEvent event logs. Voters also obtain the Merkle tree-level from the smart contract. With all of these, each voter can generate the Merkle tree and the Merkle proof with their own . The equation 4 shows how to generate the Merkle proof. ( Upon completing the steps above, each voter can start generating the witness and the zeroknowledge proof ( ) with the Semaphore circuit ( ). Voters can fetch the circuit ( ) and the proving key ( ) from the IPFS with the provided in the smart contract. The circuit expects the following inputs: the vote hash ( ), the identity commitment ( ), the Merkle proof , the external nullifier ( ), and the signature ( ). The is the same as the contract address and accessible from the smart contract. is obtained by signing the with the private key . The circuit outputs the witness, which contains a verification for the Merkle root and the nullifier hash . A detailed explanation about and is given at the end of this section. Voters can use this witness result and the to generate their proofs . The commitVote function in the smart contract expects three inputs from voters. These inputs are , and . The verifier smart contract (VerifSC) expects 2 additional inputs to verify . These inputs are and the Merkle tree root . is defined as the contracts deployed blockchain address. is the registered Merkle root in the Register state. The smart contract then verifies the given proof to ensure the proof is intact with given inputs. As a result, the contract rejects or accepts the proof. If the proof is accepted, nullifier hash ( ) is marked as used to prevent the double-voting. The smart contract stores the vote hash VH in a mapping keyed with voters' blockchain addresses for later use. Figure 5 shows the sequence diagram for this state. The Commit state ends with two conditions. The first one is the timed transition which changes the state after commitLifetime. The smart contract will reject any transaction (function call) made after this time. The other one checks if every voter has committed already. The Semaphore Proof. It is worth mentioning how the Semaphore proof is constructed and works in our voting protocol. In general, the proof ensures these three properties: (1) The voter identity is in the eligible voter list. (2) The same identity is not used to cast a vote hash twice. (3) The vote hash is indeed generated by the identity which created the proof. The circuit guarantees the first property with Merkle trees and Merkle proofs. Voters form their Merkle proof ( ) and use it as a private input in the circuit. The circuit also takes each subcomponent of as private inputs. These subcomponents are , and . The circuit re-generates the by hashing , and as in Equation 2. The circuit continues with generating the Merkle root by the generated along with given private input. The circuit puts the resulting Merkle tree root into the proof . The smart contract verifies and checks whether the root in the proof is verifiable with the registered root . As a result, the verifier verifies that voters indeed generated the correct Merkle tree root with their and . With this, ElectAnon verifies that the voter is eligible since the is indeed a member of the eligible voter Merkle tree. The circuit ensures the second property with a nullifier hash ( ). As told before, the circuit takes subcomponents as private inputs. One of these subcomponents is identity nullifier ( ), which is a random integer. The circuit hashes following inputs to obtain : identity nullifier ( ), external nullifier ( ), Merkle proof ( ). The circuit puts into the proof . In the verification, the smart contract takes from the voter as input and verifies that it matches the one in the . Additionally, the smart contract marks and stores this as used and invalidates any future calls with the same . This prevents double voting with the same . The zeroknowledge proof ensures that is constructed correctly with components of , , . So reforging a new would require a change in these components. is provided by the smart contract itself to the verifier, so the voter has no direct control over it. If the voter provides an invalid in the proof generation, the verifier will not validate the proof. and is a part of , so reforging would result in a completely different ′ . This would invalidate the proof as this new ′ would not be in the eligible list. Voters sign their vote hashes (VH ) with their private key . The circuit takes the voter public key and the signature as private inputs. Then, it checks the signature with the given public key . This completes the last property since it can verify that the voter indeed generates . In the Reveal state, voters can reveal their vote hashes VH with the revealVote function. The contract stores VH in the Commit state within a map of addresses to vote hashes. It means voters need to reveal their commitments with the same blockchain address they used in the Commit state. Each voter provides inputs of voteID (VID ) and the vote secret key VSk to the smart contract. The smart contract checks if the hash of these two inputs (VH ′ ) is equal to the one that was stored (VH ) in the previous state. If they're not equal, the smart contract rejects the transaction. If hash holds, the smart contract deletes the stored VH in the contract to guarantee that it is not revealed twice. The contract passes the , the candidate count ( ), and the storage mapping Tally Storage ( ) to the tally library. is required to keep revealed votes in the storage so that tally libraries can use revealed votes. The tally library defines a tally function that tallies revealed results. The library can change the , which means that each revealed is counted accordingly and put into the contract storage through . The tally function may differ for each tallying algorithm and implementation. Figure 6 shows the sequence diagram for this state. The state is changed if the timed-transition revealLifetime exceeds or all committed votes are successfully revealed. Voters must reveal their votes within this lifetime; otherwise, they cannot be counted. Everyone can call the electionResult function to get the election result in this state. This function is a view function, meaning that calling it will not create state-changing transactions in the blockchain and requires no transaction fees. The smart contract uses a tallying library to calculate the results. The tallying library uses the populated tallying storage and calculates the election result. The election result shows the candidate ID ( ) of the winner. Note that the smart contract publishes ProposedEvent for each proposal in the previous Proposal state. The actual proposal string can be fetched by filtering these ProposedEvent with the winner to find the winner proposal. Figure 7 shows the sequence diagram for this state. . The calculateResult function is used in the Completed state and announces the winner ID by interpreting the given tallying storage . These two functions can be customized for each tallying algorithm. The Borda Count was devised by Jean Charles de Borda in 1781 [12] . In the basic form, each ballot holds a sorted list of candidates. Each of these candidates is assigned a score based on their orders in the list. At the end of the election, each of these scores for the candidateID is summed together. As a result, the candidate with the maximum total score wins the election. We implement Borda Count tallying algorithm as a tallying library. The tally function takes voteID ( ) and then unranks it into the related preference list. The preference list represents a sorted list of candidates. The function scores each of sorted candidates in a decreasing scores of [ , − 1, − 2, ..., 1] , where is the candidate count, i.e preference list size. These scores are added to the tally storage in a map of candidateIDs to their respective cumulative score. calculateResult function of this library compares each cumulative score of candidates and then returns the candidateID with the maximum score. We used this library as the main tallying library in our experiments. The Tideman Method [39] , also known as Ranked pairs, is a tallying method devised by T. N. Tideman in 1987 [39] . The method collects the ranked preferences and compares each candidate in a pairwise fashion. These pairwise comparisons are sorted by their winner's vote dominance against the loser. The algorithm starts locking the winners against losers in this sorted order by constructing a directed graph. The one that is not locked by another candidate, the vertex with an in-degree of 0, becomes the winner. If any cycle occurs in the locking, that pair is ignored. The method guarantees both the Majority and Condorcet rules. T. N. Tideman states that Borda is not the Condorcet method, unlike the Tideman method. The Tideman also guarantees the Majority Rule by ensuring that the election winner is selected as the majority's first choice. Unlike Tideman, Borda does not guarantee the Majority Rule [17] . We implement the Tideman Method as a tallying library to support both Majority Rule and Condorcet criterion. The tally function increments how many times voteID ( ) is used and then stores it in the tally storage . It means that the tally function tracks the count of s in their encoded (ranked) forms in the election. The calculateResult function unranks s into preference lists and follows the Tideman algorithm to calculate the winner. ElectAnon uses Merkle trees to prove eligibility of voter identity commitments efficiently. On the other hand, the original Semaphore smart contract calculates the Merkle tree on the smart contract (on-chain). Calculating the Merkle tree on-chain provides a safe way to keep the Merkle tree root intact with the registered leaves. This calculation has a very high gas consumption since it requires multiple hash operations per tree level. So, we eliminated it by off-loading this calculation to the election authority. The Election Authority calculates the Merkle tree root off-chain then sends it to the smart contract along with Merkle tree leaves (identity commitments). This introduces a trust assumption in authority to honestly calculate this Merkle tree. We propose the Merkle Forest solution to reduce the trust assumption on election authority. In this solution, each Merkle tree root is calculated with a zero-knowledge circuit and verified on the chain. The circuit takes a fixed-size leaf-list as a private input. Then it forms a Merkle tree from these leaves and generates the Merkle root. It also hashes all elements in the given list input with the Keccak-256 hash function to obtain the hash output. The proof outputs both the Merkle tree root and the hash output. The smart contract takes the leaf-list, the Merkle tree root, and the zero-knowledge proof as inputs. The smart contract computes the Keccak-256 hash of the given leaf-list and verifies the given zero-knowledge proof with the given Merkle tree root and the calculated hash of the leaf-list. In this way, the smart contract can ensure that the given Merkle tree root is indeed calculated with the given leaf-list. After a successful verification, the root is registered to the ElectAnon smart contract with a tree index. A new tree must be constructed and registered to the smart contract to register more voters. This is because zk-SNARK circuits do not support dynamic-size arrays. For instance, if the fixed tree size in the circuit is set to 256, each tree can hold at most 256 voters. In order to register 2560 for the election, these 2560 voters must be split into ten trees. Smart contract stores tree roots within a mapping[treeIndex] => treeRoot structure. The smart contract publishes an event when a tree is registered. The event contains treeIndex, treeRoot, and leaves so that voters can track which tree they're registered. In the Commit state, each voter must specify their tree index; so that the smart contract can fetch the Merkle root of that particular tree and verify the Semaphore proof of the voter. Note that ElectAnon already has a zero-knowledge proof construction from the Semaphore circuit. This Merkle Forest approach adds another zero-knowledge circuit and verifier to the ElectAnon to verify that Merkle tree constructions are done faithfully. With this method, the smart contract can verify that each Merkle tree root input is correctly constructed from the given Merkle tree leaves. We have realized that the Keccak-256 hash function is inefficient for zero-knowledge proofs. However, it is an efficient hash function for EVM-based smart contracts. The keccak-256 hash function is only required when leaf inputs are private. If we can remove this necessity by making the leaf list a public input, we can also remove the Keccak-256 hash function from the circuit. With that, the verifier smart contract can take the complete leaf-list as the input and verify the remaining Merkle tree construction proof with this list input. We also implemented a circuit that can take public inputs of tree leaves and requires no Keccak-256 hash function in this work. We wanted to compare these two different versions. We used Zokrates [44] as the main zk-SNARK toolbox in our implementations. We conducted experiments for both of these Merkle Forest implementations (with and without Keccak-256) in the Section 8.3. In this section, we analyze ElectAnon with aspects defined in the Election requirement section. At the Register state, each voter generates an identity commitment and submits it to the election authority ( ). decides voters' eligibility and forms a Merkle tree ( ) with these eligible s. registers the Merkle tree root ( ) and the identity commitment list ( s) to the smart contract. At the Commit state, voters create proofs to prove that they own a valid identity commitment , and they can generate the correct Merkle tree root with their Merkle proofs . The smart contract verifies this proof with the registered . At the end of this verification, the protocol verifies that the is indeed in the eligible voter set. The smart contract rejects transactions without valid proof; thus ElectAnon ensures Eligibility. The Semaphore's double-signaling prevention ensures Uniqueness [15] . Voter identity includes a random-secret nullifier . Each voter generates the zero-knowledge proof with private inputs of their nullifier and an external nullifier . The smart contract verifies that is correctly generated by the voter with the . The smart contract also stores this and invalidates any call with the same . Each of these s are unique to their . So in order to reforge a valid , one must regenerate a new . However, if this is not registered in the eligible set, the proof will still fail due to the Eligibility proof. So each voter can only vote once with their valid ; thus ElectAnon achieves Uniqueness. Privacy is ensured by preserving the anonymity of voter identities. We assume voters send their identity commitments ( ) to Election Authority ( ) in a secure, private channel. The protocol aims to keep identities and their commitments secret when voters cast their votes. If one of them is revealed in the voting time, then can distinguish voters and learn about their votes. In the Commit state, voters generate zero-knowledge proofs without revealing their identity commitments or . The zero-knowledge proof proves that the vote is indeed generated by the voter. Voters generate their zero-knowledge proofs in their local offline environments. The zero-knowledge circuit takes voter identity as a private input and generates the proof . The zero-knowledge compiler ensures that the given private input of is not revealed in the . The smart contract takes as input but does not require or . As a result, no identity or their commitment counterpart is revealed. Voters still interact with the smart contract through their blockchain addresses. We assume they use a new and fresh blockchain address when they first interact with the smart contract in Commit state. Any reuse of these addresses in other blockchain applications can compromise their anonymity. Voters also need to keep their and secret. If these assumptions hold, then even the cannot deduct any information about voter identities. ElectAnon ensures Anonymity since no one can distinguish any voter operation and link them to actual voter identities. This satisfies Privacy since no one can link a vote to the real voter identity. ElectAnon voting phase consists of two consecutive states, Commit and Reveal. Voters commit the hash of the vote ( ) without revealing the actual vote ID ( ) in the Commit state. This is done by hashing the with a random vote key (VSk ). These VSk and the must be kept secret until the end of the Commit state to guarantee the Fairness is preserved. In the Reveal state, voters provide their plaintext along with as their inputs to the smart contract. The smart contract verifies that committed hashes can be reconstructed with these inputs. Then these revealed votes are stored in the smart contract to be tallied. This ensures that commitments do not reveal any information about actual votes, and they're not modifiable once they're committed. ElectAnon guarantees that no-intermediate results are obtainable in the Commit state, and committed votes are not alterable. Thus, ElectAnon satisfies the Fairness requirement. ElectAnon encodes ranked-choice lists into single integer vote IDs ( ). Each of these s represents a permutation of candidate IDs. For a list of size , there can be at most ! permutations. It means that s can be in range of [0, ! − 1]. This is easily detectable in the Reveal state as s are revealed in this state. ElectAnon checks the revealed and rejects the transaction if it is not in the valid range. ElectAnon achieves Soundness by securing that invalid votes cannot be revealed and tallied. ElectAnon uses blockchain technology. Blockchain technology ensures that every transaction is transparent and verifiable by the whole network. ElectonAnon is a self-tallying protocol so that everyone can calculate results independently. With these two aspects, ElectAnon achieves Universal Verifiability. Voters can verify that their committed vote hashes ( s) are successfully cast in the ballot by verifying blockchain transaction inputs. They can also ensure that their revealed votes are tallied correctly by verifying that transactions contain their plaintext ( ) inputs. Thus ElectAnon achieves Individual Verifiability. ElectAnon includes a timed-transition state machine in the smart contract to ensure autonomy so election protocol can change states without interruption. The Register is the only state that the protocol requires a manual transition from the election authority ( ). There is no voter-smart contract interaction required before the Commit state. Even if disrupts the protocol, it will not affect any votes or voters. ElectAnon ensures voters' activities do not affect each other. In the Reveal state, voters reveal their votes. If a voter abandons a committed vote, others will not be affected by it, and the election can safely continue to tally. ElectAnon guarantees that a started election will not be disrupted by any means. As a result, ElectAnon achieves voting availability. Moreover, ElectAnon is a self-tallying protocol. It means that everyone can tally the result without requiring any external assistance. By that, ElectAnon also satisfies the tallying availability. ElectAnon ensures Robustness by combining voting availability, tallying availability, and autonomy. We deployed ElectAnon to a local Ethereum network by using the Hardhat [22] tool. Hardhat provides local ethereum networks, gas consumption reports, and a wallet pre-filled with accounts. We used Solidity version 0.8.7 and the latest Ethereum fork London. We used a MacBook Pro with an 8-core 3.2GHz Apple M1 chip and 16 GB Ram, running on macOS BigSur (Version 11) to conduct our tests. We measured gas consumption of functions that voters use in the election protocol. Figure 8 shows measured gas consumptions for commitVote, revealVote, and calculateResult. We run them in 2 different setups. In the first one, we fixed the voterCount to 10 and increased the candidate count linearly. In the second setup, we used a fixed candidate count of 10 and increased voter counts exponentially. We found that commitVote has a (1) gas complexity. The function consumes approximately 315.000 gas per transaction. Since the function verifies the zero-knowledge proofs, it consumes relatively more gas than other functions. We've seen that the function revealVote is only affected by the candidate count. The consumption function is approximately: * 8000 + 39000 and thus linear with ( ). Votes are counted in revealVote function, and voteIDs ( s) are unranked with the Ranking/Unranking permutation algorithm [27] . The algorithm takes a linear time to unrank the rankID to a permutation list. As expected, it causes a linear gas consumption with respect to candidate count . We found that voter count does not affect n revealVote. There is a down-slope in between voterCount=10 and 100. This is because there is an additional map initialization cost when revealVote is called for the first time. Hardhat gas-reporter takes an average gas consumption if the same function is used more than once. Eventually, the average value becomes closer to the maximum when there are few voters and becomes closer to the minimum when there are more voters. The calculateResult function is not affected by the voter count, but it has linear complexity with the candidate count ( ). This is because the Borda Count tally library partially tallies the results in the revealVote function. The calculateResult function iterates over each candidate ID in the tally storage and finds the candidate with the maximum score, then reports it. As a result, the function cost increases linearly with respect to candidate count. The smart contract deployment takes a total of 3,458,406 gas. The deployment is done only once by the election authority. Figure 9 shows gas consumptions for addVoters, addProposers, propose, toProposalState, which are mainly used by the election authority and proposers. The gas consumption of addProposers is proportional to the candidate (proposal) count. The cost function of addProposers is 50180 + (23586 * ) which is ( ). The measured gas consumptions of propose Merkle trees must be generated by both election authority and voters. We analyzed functions of generating Merkle tree (genTree) and Merkle proof (genMerkleProof ) with increased voter count. Figure 10 shows these results. We found that the tree can be constructed within 42 minutes for 100,000 voters. Merkle proof generation takes only 6 seconds for 100,000 voters. Merkle tree and proof generation have a linear relation with the voter count. The generated Merkle proof file size is 165,5 megabytes for 100,000 voters. The file contains all Merkle proofs for every individual leaf. It means voters can grab the file and find their related Merkle proofs without generating the tree. We also analyzed the Semaphore circuit setup times, file sizes, and the witness & proof generation times. Results can be found in the table 2. Results show that compiling the circuit and generating keys take almost 15 minutes and 250-megabyte file size. This is reasonably feasible since it is a one-time setup only. Each voter uses genID and genIDCommit functions to generate identity and commitments. In the table, it can be seen that these functions take sub-second times. Voters use genWitness and genProof to generate their zero-knowledge proofs. They take around 10 secs to generate a proof with the Semaphore circuit. We conducted tests for our Tideman algorithm. The algorithm heavily uses graphs, matrixes, and sorting algorithms which are very costly for smart contracts. We reduced storage costs by using the rank & unranking permutation algorithm. We see that the Tideman library is capable of running with 250 voters and 10 candidates. The calculateResult function hits the 30 million gas limit with more than 250 voters and thus cannot be used for more than 250 voters. The function is a view function that does not consume actual transaction fees. This makes it a viable option for small-scale elections. We show the Tideman algorithm gas consumption results for 250 voters and 10 candidates in the table 3. We compared the ElectAnon with similar works like McCorry et al. [24] and PriScore [42] . McCorry et al. [24] conducted their gas consumption tests with 40 voters. PriScore [42] also shows gas costs for each of their different functions. We computed their total gas costs for 40 voters and 10 candidates. We also run our tests with 40 voters and 10 candidates setup. A comparison table can be found in Table 4 . We found that ElectAnon offers an 83% and 89% decrease in total election gas costs compared to McCorry et al. [24] and Priscore [42] , respectively. At the time of writing this work, the gas price in Ethereum is equivalent to nearly 100 gwei, and one ETH price is approximately $4,500. A gwei equals to 10 9 ETH, so a gwei roughly equals to $4, 500/10 9 = $0.0000045. It means that, a single gas costs 100 * $0.0000045 = $0.00045. In our work, voters total gas cost is 417,996 which makes $0.00045 * 417, 996 = $188.09. We considered running the ElectAnon in another Ethereum Virtual-Machine compatible network, Avalanche. Avalanche implements a novel consensus mechanism with proof-of-stake Sybil protection [34] . It offers a faster finalization time with fairly low gas fees when compared to Ethereum. The Avalanche gas price changes between 25-150 nAVAX (equivalent to gwei) [21] . The current price of Avalanche is $85 on average. If we take the gas price as nearly 100 nAVAX, then our voting transactions costs 100/10 9 * $85 * 417, 996 = $3.55. We run an election with 10 voters and 10 candidates in Avalanche local network. We found that ElectAnon is compatible with the Avalanche network, and it costs the same gas as the Ethereum network. However, since gas prices and the AVAX price are much lower than the Ethereum main network, it significantly reduces the election cost. In our tests, we found that the voter functions, i.e. commitVote, revealVote, calculateResult, are not affected by the increased voter count. It means that voters do not pay for extra gas in case of a large-scale election. The cost of election authority increases with both candidate count for addProposers and voter count for addVoters. We assume that the election authority has enough resources to conduct the election. A possible bottleneck of ElectAnon could be adding voters to the eligible list. It costs almost a total of 10,000,000 gas for 10,000 voter registration. 10,000,000 gas, i.e 10,000 voters, almost costs $5000 in Ethereum. It means that a single leaf insertion costs approximately 5000/10, 000 = $0.5. This is a fair cost for small to medium scale elections, i.e. up to 10,000 voters. The gas cost increases linearly. A large-scale election with 1,000,000 voters would cost approximately $500.000. Even though our work offers the best gas consumption amongst others like McCorry et al. [24] and Priscore [42] , $500.000 is still too much. The total USD cost can be decreased using the Avalanche network, which has a significantly lower gas price. The same total cost to register 1,000,000 voters can be decreased to almost 100/10 9 * $85 * 10, 000, 000 * 100 = $8500 in the Avalanche. We also run tests for the Merkle forest Extension with various fixed tree sizes. Each size represents the total leaf size, and thus the maximum voter count can fit into one tree. We show results for two different implementations in Table 5 . One of the implementations uses the Keccak-256 hash function; the other one uses public input lists. Implementation with the Keccak-256 hash function consumes less gas. It is because the smart contract takes a single hash input. Whereas in the other implementation without Keccak-256, all leaves are passed to the verifier to be verified. Giving a complete list instead of a single hash increases the gas consumption with respect to increased voter count. We see that the implementation without the Keccak-256 hash function produces fewer circuit constraints. As a result, generation times and file sizes are much lower. We think that the circuit with Keccak-256 is more feasible for a smart contract approach since it consumes almost one-quarter of gas compared to the one without Keccak-256. Inserting a 256-sized tree with the Keccak-256 circuit consumes 482,409 gas, whereas the implementation without Merkle forest extensions consumes 276,929 for 200 voter registration. It's possible to generate a 256-size tree circuit and insert multiple trees to the smart contract, thus increasing the total voter count with several rounds. We think the Merkle forest extension can be a feasible option for small-scale elections. In this work, we proposed a blockchain-based, anonymous ranked-choice voting protocol. Our work, ElectAnon, ensures anonymity with zero-knowledge proofs. We used a zero-knowledge gadget, Semaphore [15] , which provides anonymous membership proofs with the efficient zk-SNARK technique. Our protocol also provides efficient mechanisms for ranked-choice voting. We used an effective algorithm [27] to encode and decode our ranked-choice lists with integers. ElectAnon is designed to be robust and uninterruptible in the voting phase. We implemented the protocol in Ethereum smart contracts to ensure decentralization and robustness. We also defined some of the most critical election requirements and provided a deep-down analysis of prior works. We also discussed and analyzed alternative extensions like Merkle Forest and the Tideman method for our protocol. We have run experiments and shown the results. We also compared our work with prior works. Our protocol not only assures critical election requirements but also scales to be used in large-scale elections. Overall, we show that ElectAnon can especially be beneficial for governance applications like decentralized autonomous organizations (DAOs). Our current voting scheme expects voters to decide their preferences for all candidates. In other words, each preference list must contain all possible candidates. This can be a burden for elections with many candidates, as voters have to evaluate all candidates and form a list of all candidates sorted by their preferences. It can be avoided by specifying a smaller preference list size. For example, suppose there are 50 candidates, the election can require voters to decide on a smaller number like 10 or 5 candidates as their preference lists. So voters can evaluate a smaller candidate subset instead of the whole set. Authors of the Ranking and unranking permutations in linear time [27] mention a possible extension to accomplish -permutations of an -set. As future work, we aim to implement this approach for our preference list encoding to reduce the required list size, and thus usability can be increased. Trustless Trust -DAOs, the Future of Governance Security of Internet Voting Schemes: A Survey. SSRN Scholarly Paper ID 3459657 Internet Voting in Comparative Perspective: The Case of Estonia Ranked choice voting Zerocash: Decentralized Anonymous Payments from Bitcoin IPFS -Content Addressed, Versioned, P2P File System A next-generation smart contract and decentralized application platform Mail-in voting became much more common in 2020 primaries as COVID-19 spread Self-Reported Understanding of Ranked-Choice Voting An Overview of Decentralized Autonomous Organizations on the Blockchain The original Borda count and partial voting Ethereum Foundation Principles and requirements for a secure e-voting system Blockchain-Based E-Voting System Contemporary Mathematics: Contemporary Mathematics at Nebraska Blockchain for Electronic Voting System-Review and Open Research Challenges New development: Running elections during a pandemic Debate: safeguarding democracy during pandemics. Social distancing, postal, or internet voting-the good, the bad or the ugly? Ava Labs. 2021. Transaction Fees Ethereum development environment for professionals by Nomic Labs De-anonymizing Ethereum blockchain smart contracts through code attribution A Smart Contract for Boardroom Voting with Maximum Voter Privacy Theoretical Results on De-Anonymization via Linkage Attacks A Survey on Zero Knowledge Range Proofs and Applications Ranking and unranking permutations in linear time Bitcoin: A peer-to-peer electronic cash system A Smart Contract System for Decentralized Borda Count Voting Non-Interactive Zero-Knowledge for Blockchain: A Survey Trends in blockchain-based electronic voting systems Maksym Petkus. 2019. Why and How zk-SNARK Works Smart-Corpus: an Organized Repository of Ethereum Smart Contracts Source Code and Metrics Snowflake to avalanche: A novel metastable consensus protocol family for cryptocurrencies Estonian Internet voting SCOOP4C Robust electronic voting: Introducing robustness in Civitas StarkNet Alpha 2 Solidity Programming Language Independence of Clones as a Criterion for Voting Rules Blockchain voting: Publicly verifiable online voting protocol without trusted tallying authorities PriScore: Blockchain-Based Self-Tallying Election System Supporting Score Voting Chaintegrity: blockchain-enabled large-scale e-voting system with robustness and universal verifiability This research was partially supported by Boğaziçi University Scientific Research Projects (BAP) No: 17A01P7.