ROCHESTER INSTITUTE OF TECHNOLOGY

INDEPENDENT STUDY

Blockchain and Ranked Choice Voting

Author:Eric DUDLEY

Supervisor:Prof. Alan KAMINSKY

A paper submitted in fulfillment of the requirementsfor an independent study.

in

Computer ScienceB. Thomas Golisano College of Computing & Information Sciences

April 22, 2019

i

“Trust, but verify.”

Russian Proverb

ii

ROCHESTER INSTITUTE OF TECHNOLOGY

AbstractProf. Alan KAMINSKY

B. Thomas Golisano College of Computing & Information Sciences

Bachelor’s Computer Science

Blockchain and Ranked Choice Voting

by Eric DUDLEY

Voting in elections has been a keystone of democracy for millenia, as the votingpopulation increases and technology advances, electoral systems have to scale also.Blockchain technology has the potential to bring voting to a new level of accessibil-ity and transparency. With cryptocurrencies being the latest trend for investors andfinance enthusiasts, many new blockchain systems have been created. With thesesystems, malicious users have found methods to attack blockchains and “doublespend”. Startups such as Agora and Polys have attempted to develop blockchainsystems that mitigate the risks of running an electronic voting system while also in-troducing the benefits of using a blockchain. This writeup examines the current stateof blockchain technology, blockchain security, electoral systems, existing electronicvoting systems, and proposes a blockchain based electronic voting system calledBlock Vote.

iii

Contents

Abstract ii

Contents iii

Concepts vi

1 Independent Study Proposal 11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Learning Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Planned Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3.1 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Blockchain 32.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 An Overview of Blockchain Technology: Architecture, Consensus, and

Future Trends (Zheng et al., 2017) . . . . . . . . . . . . . . . . . . . . . . 32.2.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Immutable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Auditable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Anonymous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Decentralized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.3 Consensus Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 5Which chain is the right one? (Haon, 2018) . . . . . . . . . . . . 5Hard and Soft Forks (Acheson, 2018) . . . . . . . . . . . . . . . . 6Proof of Work (Tar, 2018) . . . . . . . . . . . . . . . . . . . . . . 6Practical Byzantine Fault Tolerance (Curran, 2018) . . . . . . . . 7Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Voting 83.1 Voting Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Important Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Transparency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.2 Single Choice Electoral Systems(King, 2000) . . . . . . . . . . . 9Plurality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

iv

Majority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Proportional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.3 Ranked Choice Electoral Systems(“Ranked Voting” 2019) . . . . 10Instant-runoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Single transferable vote . . . . . . . . . . . . . . . . . . . . . . . 11Borda count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Blockchain Security 134.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 Types of Blockchain Systems(Joshi, Han, and Wang, 2018) . . . 13Public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Private . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Consortium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Voting Application . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.1 Peer-to-peer Network Attacks(Zaghloul, 2018) . . . . . . . . . . 14

Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Sybil Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Eclipse Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.2 Blockchain Attacks(“Blockchain Attack Vectors” 2018) . . . . . 17Selfish Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Double Spending . . . . . . . . . . . . . . . . . . . . . . . . . . . 1751% Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Fake Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Blockchain Voting 205.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2 Existing Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Bitcoin Based Voting Bao, Wang, and Shi, 2018 . . . . . . . . . . 20Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Ballot Casting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.1 Polys (“Polys – Online Voting System” 2019) . . . . . . . . . . . 21Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Ballot Casting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.2 Agora Vote (“Agora Vote” 2019) . . . . . . . . . . . . . . . . . . 22Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.3 Block Vote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.3.2 Election Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Election Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Small Election Voting Process . . . . . . . . . . . . . . . . . . . . 25Large Election Voting Process . . . . . . . . . . . . . . . . . . . . 25Election Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3.3 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Privileged Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

v

Auditor Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3.4 Ballot Casting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

BitCoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Ballot Counting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 Block Vote POC 306.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.1.1 Missing Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.1.2 Block Vote Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.1.3 User-Facing Application . . . . . . . . . . . . . . . . . . . . . . . 30

Network Visualization . . . . . . . . . . . . . . . . . . . . . . . . 31Election Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Ballot Casting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Election Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 32

7 Conclusion 33

A Usage 34A.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

A.1.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . 34A.1.2 Getting the Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.1.3 Installing Dependencies . . . . . . . . . . . . . . . . . . . . . . . 34

Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A.1.4 Running the Code . . . . . . . . . . . . . . . . . . . . . . . . . . 35Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A.1.5 Code Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

B Work Log 37

vi

Concepts

NISTNational Institute of Standards and Technology, U.S. Department of Com-merce organization responsible for setting government standards for cryp-tographic algorithms.

SHA Secure Hash Algorithm, algorithm chosen by NIST for secure hashing.ECDSA Elliptic Curve Digital Signature Algorithm, digital signature algorithm cho-

sen by NIST for secure digital signing.POW Proof Of Work, a blockchain consensus strategy used by many public

blockchains.BFT Byzantine Fault Tolerance, a requirement of any blockchain consensus al-

gorithm, practical implementations of it can be used as cheaper alternativesto POW.

Bitcoin A popular cryptocurrency that has disrupted the finance industry.AES Advanced Encryption Standard, algorithm chosen by NIST for secure en-

cryption.

1

Chapter 1

Independent Study Proposal

1.1 Introduction

As a student entering my last semester at RIT, I would like to take this opportunityto study an emerging piece of technology, blockchain. I think that voting is an ob-vious application for this technology that could be adopted by private and publicentities to increase security, accuracy, and transparency. The goal of this indepen-dent study is to gain a working knowledge of various types of blockchains, knownattacks against blockchains, and how blockchains can be applied in the realm of vot-ing. I believe this would help further my knowledge of computer security followingmy success in Intro to Cryptography.

1.2 Learning Outcomes

Through the study of blockchain technologies I hope to increase my knowledge andexperience with multiple facets of computer science. I aim to increase my knowledgeof cryptography and the various hashing/encryption algorithms that are used inblockchains. Likewise, I hope to strengthen my understanding of networking byanalyzing the infrastructure and networks that are required by a blockchain basedsystem. Learning both cryptography and networking technology together, I willhave the opportunity to further my knowledge of computer security, learning thestrengths and weaknesses blockchains have in regards to privacy, resiliency, andaccuracy.

1.3 Planned Work

This independent study will include two main intervals of work, research and imple-mentation. The research section will take place over the first 9 weeks of the semester,delving into blockchain technology, attacks on blockchains, and blockchain-basedvoting systems. The implementation section will take place over 5 weeks, focusingon developing a prototype, Floating Ballot, a ranked choice voting system based onblockchain technology. The final week of the semester will be spent revising thisdocument and finalizing the prototype. Throughout the entire semester, a weeklymeeting will be scheduled with Prof. Alan KAMINSKY to sync on the status of thework and to have time for questions and guidance.

Chapter 1. Independent Study Proposal 2

1.3.1 Schedule

Week 1 Research BlockchainWeek 2 ↓Week 3 ↓Week 4 Research Blockchain AttacksWeek 5 ↓Week 6 ↓Week 7 Research Blockchain VotingWeek 8 ↓Week 9 ↓Week 10 Implement BlockchainWeek 11 ↓Week 12 ↓Week 13 ↓Week 14 Implement InterfaceWeek 15 Final RevisionHours/Week 9Total Hours 135

1.4 Deliverables

• Report (this document)

– A recount of the research performed.

– A design for a ranked-choice voting system based on blockchain technol-ogy.

– A commentary on the pros and cons of such a system.

• Prototype

– An implementation or adaptation of a blockchain for ranked-choice vot-ing.

– An implementation or description of the infrastructure required for thesystem.

– An implementation of an interface for testing/using the system.

1.5 Evaluation

Evaluation will be based on research results discussed during weekly progress meet-ings, deliverable software, and final report, as follows:

11% Blockchain research results11% Blockchain attacks research results11% Blockchain voting research results33% Deliverable software34% Final report

3

Chapter 2

Blockchain

2.1 Introduction

This chapter contains a review of the results obtained from researching blockchaintechnology, architecture, and applications. Sections are broken down by researchpaper.

2.2 An Overview of Blockchain Technology: Architecture,Consensus, and Future Trends (Zheng et al., 2017)

This research paper provides a well-formed overview of the current state of blockchaintechnology. Without going into too much depth, this paper covers the current ap-plications of blockchain and their issues, the most popular blockchain architectures,and the various consensus algorithms that are used in different situations.

2.2.1 Characteristics

Immutable

A blockchain should be resistant to changes once a verified transaction has beenadded. If an attacker attempts to modify one or many transactions that have alreadybeen added, other users of the blockchain should be able to immediately detect andresolve this discrepancy.

Auditable

A blockchain retains all previous transactions that have occurred; therefore, if newtransactions are invalid, they can be rejected. In the context of Bitcoin, even if a trans-action is cryptographically valid, it might be invalid because a user does not haveenough Bitcoin to fulfill the amount of the transaction. In this case, all the transac-tions previously associated with the sender’s wallet must be audited to ensure thatthe transaction is valid. Likewise, if an interested user wanted to look back at a se-ries of transactions to ensure they were recorded correctly, they simply have to findthe transactions in the blockchains and check the integrity of the transactions andblocks.

Chapter 2. Blockchain 4

Anonymous

A transaction should not be directly traceable back to the identity of the sender.While it is possible to track and analyze the activity of a particular public key, be-cause the public key is a randomly generated bit string, there is no way to asso-ciate that with an actual individual. This becomes a more difficult problem whenpublic/private key pairs are generated and distributed by a central party instead ofbeing generated by each individual.

Decentralized

All transactions should not have to go through the same server to be verified everytime. Instead, transactions can be sent to any node in the blockchain network, andthe node will verify and communicate the transaction to every other node. In thisway, multiple entities can create nodes so that no one entity has to be completelytrustworthy. This is important when multiple parties are interested in the correctnessof transactions but no party completely trusts any other, so all nodes have an equalsay in what is corrrect.

2.2.2 Architecture

Block

The first component of a blockchain is the block itself. A block is composed of aheader and body. The header contains information about the block within the con-text of the chain, such as the version, timestamp, nonce, and parent block hash. Theparent block hash is what makes a blockchain a chain, it contains the hash value ofthe previous block, so if the previous block is tampered with, it can be detected inthe header of the next block and be invalidated. The other part of the block is thebody, this contains the data of the block such as transactions or ballots.

Transaction

For the sake of simplicity, components of a block will be referred to as transactions. Atransaction will contain different data depending on the application. In a cryptocur-rency, a transaction would contain a receiver, sender, and amount. In the contextof electronic voting, a transaction might contain the candidate(s) being voted for.Each transaction must be verified to ensure its authenticity and integrity, to do this,asymmetric cryptography is used.

Signature

In order for a transaction to be authentic and valid, it must be digitally signed bythe private key associated with the public key that the transaction claims to be ini-tiated by. In the context of Bitcoin, the public key is essentially the address of thesender’s wallet. A common signing algorithm to use is ECSDA or Elliptic CurveDigital Signature Algorithm. Multiple curves can be used with this algorithm tomake the digital signature more or less secure while trading off the computationaldemand of the algorithm.

When a signed transaction is received by a blockchain node, the transaction isverified by using the public(verifying) key, since the only way to generate a correctsignature given the transaction data is by using the private(signing) key; the authen-ticity of the transaction can be securely determined by this process.

Chapter 2. Blockchain 5

2.2.3 Consensus Algorithms

A blockchain distributed over many nodes has no central source of truth; therefore, asystem to reach consensus much be used. Reaching consensus simply means that allnodes on the network agree to the same state of the blockchain to be the truth. Thisproblem is related to the Byzantine Generals problem, where multiple unreliablegenerals have to all agree to attack or not attack a city at the same time. In the caseof blockchains, all nodes have to agree on what transactions have been recordedin what order so that a malicious node does not affect the trustworthiness of theblockchain network as a whole.

Which chain is the right one? (Haon, 2018)

The first and most simple problem that can be solved is the situation where there aretwo versions of the same blockchain going around a network. Node A has a chainof length n, and Node B sends node A a block from a chain of length n; however, thethe last 4 blocks are different than Node A’s current chain. This problem is knownas the chain-split problem and is illustrated in Figure 2.1. This situation can occurwhen two nodes generate and broadcast a new block based on the current version ofthe blockchain at the same time, since these two blocks are both valid but different,the chain biforcates. When multiple possible versions of a blockchain are floatingaround, which one should be accepted? This is an important problem to solve be-cause in order for a distributed set of nodes to effectively represent the state of theblockchain, they must always reach consensus on a single version of the chain.

FIGURE 2.1: An example of a chain-split or fork in a blockchain.Source: HackerNoon (Ray, 2017)

In order to solve this problem, each node must maintain every version of thechain that is currently present in the network. In this case there are two versions.Whenever a new block is received by a node, the node will verify the block and ap-pend it to the version of the chain that it belongs to, if this makes one version longerthan another, then the longer chain becomes the correct or active chain. Any blocksthat were present in the shorter chain after the split become orphaned blocks. Sincethe orphaned blocks are still valid and conforming to the rules of the blockchain, thetransactions on them must still be added to the blockchain, so any transactions thatwere in an orphaned block and are not already on the active version of the blockchainare moved back into the pool of unconfirmed transactions. In short, if there is di-vergent versions of the blockchain, wait till one version becomes longer and then

Chapter 2. Blockchain 6

treat that version as correct. The concept of longer is discussed further in section2.2.3. This solution is simple enough, but there are other ways that a blockchain candiverge amongst the network of nodes, hard and soft forks.

Hard and Soft Forks (Acheson, 2018)

A soft/hard fork in a blockchain is caused by software changes in the nodes. Themore extreme of the two types of forks is the hard fork; in this fork, a change is madeto the blockchain software such that updated nodes reject blocks from the old nodes,and old nodes reject blocks from the updated nodes. In essence a hard fork has thepotential to produce two independent blockchain networks both running differentversions of the node software. An example of a hard fork can be seen with Bitcoinand Bitcoin Cash. A change was made to the Bitcoin software that created a hardfork, the new indendent blockchain continued to be used totally separate from theoriginal Bitcoin chain creating a new cryptocurrency, Bitcoin Cash. A soft fork isless destructive to a blockchain network; in this case, blocks from updated nodesare accepted by old nodes but blocks from old nodes are not accepted by updatednodes. With this change, old nodes are still working based off of the same chainthat updated nodes are, but any blocks generated by an old node will be rejected byupdated nodes. This will not create a pair of independent chains, instead this willsimply prompt old nodes to update software so that they can continue to generatenew blocks and contribute to the chain. A soft fork has happened multiple times invarious popular blockchains including Bitcoin and Ethereum without causing anyserious issues in the operation of the network.

Proof of Work (Tar, 2018)

Proof of work(POW) is the consensus strategy used by Bitcoin. This strategy focusesaround the idea that if it takes a lot of time and computational power to perform ac-tions on the blockchain, then the blockchain becomes resistant to Denial-of-Serviceattacks and malicoius changes to the chain. Once a chain grows sufficiently long, itbecomes impractical to modify older transactions. To demonstrate POW, presumetheir is a blockchain that has no POW requirement; there is a very long chain anda malicious node tries to submit a new version of the chain with one of the trans-actions in one of the earliest blocks changed. This new version of the chain wouldimmediately be rejected by all other nodes because the hash of the maliciously mod-ified block would have changed, and therefore the next blocks "previous block hash’reference would no longer match. To fix this issue, the malicious user simply it-erates through all the blocks after the maliciously modified block and updates the"previous block hash" in each block to match the new values. While this requires re-computing the hash values for many blocks, it can be done in a reasonable amount oftime. Now, all the nodes will verify that the chain is valid and accept the maliciousversion. POW can be used to make these types of attacks more difficult, especially inthe case where malicious nodes continuously spam the network with valid but incor-rect versions of the blockchain. In this example, a new constraint could be put on theblockchain in order to be valid, all block hashes must have the n lowest order bitsas zeroes. Since a secure hashing algorithm such as SHA256 produces completelyrandom bits for any given plaintext, the only way to ensure a hash has n zero bits inthe lowest order positions is to change a nonce and recompute a hash value until thehash value happens to conform to the constraint. With a large enough n, computinga valid hash could take a long time. With respect to this example of the malicious

Chapter 2. Blockchain 7

block change; if the malicious node tries to modify an early block and recompute thenew "previous block hash" references for all following blocks, they will be faced withan intractable number of hash computations, such that the modification is virtuallyimpossible.

Practical Byzantine Fault Tolerance (Curran, 2018)

Algorithms that exhibit Byzantine fault tolerance are able to reach a consensus amongall honest nodes as long two-thirds of them are honest at any given time. Manysuch algorithms are not feasible to use in real-time systems due to their synchronousnature and inefficient designs, despite their proofs of correctness. However, somebyzantine fault tolerant consensus algorithms have been designed to be practical forlarge scale applications, such as blockchain consensus. The basic idea behind mostof these algorithms follows a similar form. When a node submits a block to the net-work, a node is selected to be the “leader” for confirming this block. The leadersends out a broadcast to the network asking for confirmations of the block’s correct-ness, once the leader receives a minimum number of replies, the block is consideredto be confirmed by the whole network. The leader selection process can follow var-ious protocols; however, no single node will be more likely to be selected than anyother; likewise, if the selected leader is outed as dishonest by the rest of the network,the next possible leader will be selected instead. This consensus algorithm is greatbecause it does not require miners to continuously compute hashes of blocks, wast-ing hours of compute resources. Instead, blocks are confirmed by the nodes in theblockchain network electing a leader, communicating with each other, and agreeingupon the truth a block at a time. The main drawback of the practical BFT consensusalgorithm is that it requires a lot of secure communication, making it hard to scalefor large networks.

Conclusion

This chapter introduces many different concepts- blockchains, blocks, transactions,digital signatures, hashing, consensus and so on. In order to further study the appli-cation of blockchain to electronic voting, a strong understanding of these underlyingconcepts is important. This chapter only covers the basic architecture of a blockchainsystem; however, the security/privacy aspects of blockchain are very important, es-pecially for running elections. The security/privacy concerns of blockchain will beaddressed in the security chapter.

8

Chapter 3

Voting

3.1 Voting Systems

Voting in public and private organizations is central to the success of any organiza-tion. In order for a group of people to act together, they have to sensibly agree ondecisions that are made. As such, certain factors are important to ensure that peoplehave easy access and trust in a voting system.

3.1.1 Important Factors

Correctness

A voting system has to be as correct as possible. If a voting system fails to countballots correctly or misinterprets ballots, then the voters lose faith in the system,and the whole organization falls apart. Likewise, if the method to vote is unclear orunfair, then the intended ballot of a voter may be different than the ballot that wascast by them. For example, in a state that leans left, the ballot design can includeall the left candidates at the top of the page and the right candidates at the bottom.This would persuade voters to cast polarized ballots, only voting for left candidates,or only voting for right candidates. Another factor of a voting system that affectscorrectness is ballot design; voters can be confused by a poorly designed ballot thatmakes it unclear how to vote for a particular candidate.

Accessibility

In order for a voting system to effectively gather ballots from the entire population ofvoters, it must be accessible to as many people as possible. This includes the abilityfor voters to vote in person, vote remotely, and for the voting methods to be usableby people with any level of disability. In addition to people with disabilities, voterswho are not familiar with technology should not have to learn a difficult new tech-nology to cast a ballot. If the backing infrastructure of a voting system is updated,the details of the internal operations should not affect the voters.

Transparency

This factor of a voting system is important in building trust with the voters. Thephrase "trust, but verify" comes to mind. Trust that the election authorities are run-ning the election correctly, but make sure the ability to audit and verify is availableto voters. Current day voting systems, especially at the government level, have littleto no transparency. It is impossible for an individual voter to verify that their ballothas been counted; likewise, it is difficult/impossible for the voters to verify that all

Chapter 3. Voting 9

the ballots accepted by the election authority are legitimate and accounted for. Thisone of the main factors where a blockchain based system could make great changes.

Security

In most systems, security is one of the most important factors to its success. If a sys-tem can be modified by any malicious actor, then trust in the system is lost, and thewhole system loses purpose. Moreover, a voting system must be extremely secure,not allowing any malicious actors to change the outcome of an election. In someways security can be traded for transparency. Assuming the election authority istotally trustworthy, a centralized system can cut-off malicious actors and isolate theprocessing of the election from the rest of the world; this situation has a high level ofsecurity but no transparency. Swaying the other way, a decentralized system hostedon the Internet exposes the voting system to malicious actors that now have muchmore information about the election system and can more easily find weaknesses.The goal is to design a system that has sufficient security while being as transparentas possible.

3.1.2 Single Choice Electoral Systems(King, 2000)

In a single choice electoral system, voters must select a single candidate from thecandidates listed on their ballot. Each of the following electoral systems changes theway that these ballots are interpreted.

Plurality

In a plurality system, the candidate with the most ballots wins. For example, if thereare 2 candidates and 100 ballots, the candidate with 51 or more votes will win. Onedrawback of this system is the ability for candidates with few votes to win. Considerthe situation where there are 99 candidates and 100 ballots. If the first 98 candidateseach get one ballot, and the 99th candidate receives the 2 remaining ballots, thenthe 99th candidate will win the election, despite only getting 2% of the votes. Whilethis can seems like a poor system, it has a great benefit; ignoring ties, someone willalways win. This reduces the time and money spent having to run multiple electionsfor a single seat.

Majority

A majority system requires that a candidate receives a majority of the votes. A ma-jority is defined as more than half. In the previous example with 2 candidates and100 ballots, the majority system will have the same result, naming the candidate re-ceiving 51 or more ballots as the winner. However, in the second example where 98candidates receive 1 ballot and the last candidate receives 2, no winner is named,because no candidate achieved more than half(50) of the votes. This brings about atradeoff of a majority system; while the winner of election must be favored by mostvoters, there may not be a winner. In this case, the election must be run again; how-ever, in order to prevent the same exact result, often the candidate(s) with the leastvotes are allowed to run. This process is repeated until a candidate receives a major-ity. In the worst case, the process must be repeated until there are only 2 candidatesremaining.

Chapter 3. Voting 10

Proportional

A proportional system only pertains to elections that have multiple winners andballots are cast for pools of candidates, not individuals. For example, if there are100 seats available and 4 competing parties(pools of candidates), the number ofseats awarded to each pool is proportional to the percentage of ballots the partyreceived. If a party receives 30% of the vote in this example, 30 candidates fromthe party will receive a seat. This system closely translates voter sentiment to actualresults, no party wins completely, instead, exactly what is voted for is awarded toeach party. This system requires a second level of election, how are the individualschosen within the candidate pools? This can be done through multiple mechanisms,random choice, a second election, a second internal election. For the purpose of thispaper, only single candidate elections will be considered to simplify the problemand better address the properties of blockchain with respect to voting.

3.1.3 Ranked Choice Electoral Systems(“Ranked Voting” 2019)

In a ranked choice electoral system, voters may select one or many candidates fromthe candidates listen on their ballot. If a voter selects multiple candidates then theymust order them in terms of favor.

Instant-runoff

FIGURE 3.1: A state diagram for an instant-runoff electoral system.Source: Oakland Voting District (“Instant Runoff Voting” 2019)

In an instant runoff system, ballots contain a list of candidates in order of prefer-ence. Some elections will require voters to order every available candidate, whileother will allow voters to only include one candidate. Most elections will requirevoters to order a fixed number of candidates. An instant-runoff election occurs overmultiple rounds and ends once a candidate has the majority of first-choice votes. Around starts by counting first-choice votes of all ballots; if a candidate has a majority,then the election ends and that candidate wins. Otherwise, all of the ballots whose

Chapter 3. Voting 11

first-choice was the candidate with the least first-choice votes are reallocated basedon their second-choice. In other words, if 10 ballots listed Bob as their first choice,but every other candidate got 11 or more first choice votes, then all 10 ballots whovoted for Bob are given to whoever was listed after Bob on each ballot. Followingthis reallocation, another round is executed until a candidate has a majority. Thisresolution process will always end in a winner because eventually only two candi-dates will remain. Instant-runoff is essentially a single-choice majority system, butinstead of running multiple elections with less and less candidates, multiple roundsare run using ballots from a single election.

Single transferable vote

A single transferable vote system is a more general version of instant-runoff that canbe applied to elections with multiple winners. Instead of a single winner having toachieve a majority of first-choice votes; a candidate has to achieve a quota of votes.Once a candidate achieves a quota, they are elected, and any ballots the candidatereceived above the quota are reallocated to the second-choice. This repeats until therequired number of candidates have been elected.

Borda count

FIGURE 3.2: An example of a Borda count election. Source: Slide Player(Ross, 2016)

A Borda count election is simpler to understand than an instant-runoff system. Inthis type of system, every rank is assigned a score, for example, 10 points for 1st, 5points for 2nd, and 2 points for 3rd. A candidate’s score is the sum of all the pointsearned from each ballot they are ranked on. Once the total scores are calculated forall candidates , the candidate with the greatest score wins.

3.2 Comparison

There is no objectively optimal electoral system; however, depending on the goalsand requirements of an election, electoral systems will have different tradeoffs. Forexample, with single-choice voting, candidates that are popular are more likely togain votes because voters who might rather vote for a less popular candidate don’twant their vote to be wasted, so instead they vote for a more popular candidate.

Chapter 3. Voting 12

In ranked-choice voting, a greater pool of candidates have a chance of winning, be-cause voters will vote for their preferred candidate first and potentially list the morepopular candidate second or third. If a more polarizing election is desired, thensingle-choice voting is a better choice; however, if a middling election is desired,then ranked-choice voting will likely give more priority to candidates in the mid-dle. This is because a polarizing candidate is more likely to get time in the newsand become more well known; therefore, earning more single-choice votes, but in aranked-choice system, candidates are less incentivized to be so polarizing.

Within ranked-choice electoral systems, there are also tradeoffs. Using Bordacount, the candidate who receives the most points wins; therefore, instead of thewinner having achieved some absolute election requirement, they simply receivedmore points than their competitors. Meanwhile, in an instant-runoff system, thewinning requirement is independent of the performance of other candidates, once amajority is reached, a winner is selected.

In this paper, ranked-choice voting will be considered for the application ofblockchain technology. Ballots will be collected in a format that can be interpretedby any of the ranked-choice electoral systems. The proof-of-concept will implementsome of these electoral systems.

13

Chapter 4

Blockchain Security

4.1 Introduction

While blockchain is an exciting new way to store data, for many domains, especiallythose pertaining to government operations, look at it wearily. The weariness stemsmostly from the lack of a track record and the idea that most blockchains are de-centralized on the Internet. This chapter is dedicated to analyzing the strengths andweaknesses of blockchain security.

4.1.1 Types of Blockchain Systems(Joshi, Han, and Wang, 2018)

Public

A public blockchain is the most popular form of blockchain where anyone with anInternet connection can access and contribute. Cryptocurrencies are the most wellknown application of a public blockchain. In these applications, any user can gen-erate a public/private keypair and begin sending and receiving currency. While apublic blockchain has several benefits, complete transparency to the public and de-centralization of authority, there are some downsides that make it a hard sell forcertain applications. With a public blockchain, any actor can start up a node andjoin the blockchain network; therefore, anyone with sufficient resources can start anoverwhelming number of nodes and take over the network. This lack of control overthe members of the network can be a major security risk for certain applications.

Private

Private blockchains are less well known, despite the fact that they are much morelikely to see widespread use by large corporations and governments. This type ofblockchain is characterized by access to the network being restricted to only a cen-tralized authority. For example, a defense company might use a blockchain to handleits internal asset management, and no actors who are not working for the defensecompany have access to the blockchain or are even aware of its existence. The pri-vate blockchain lacks the benefit of being decentralized, but it allows for domainsthat require a higher level of control and trust to benefit from blockchain as a securerecord-keeping mechanism.

Consortium

A consortium blockchain is a mix between a public and private blockchain. Thisis another viable solution for corporation and government domains that require ahigh level of trust but would like to share control with multiple entities. An exam-ple of such a situation would be if a state election is being run, and every county

Chapter 4. Blockchain Security 14

in the state would like to run a node on the network, and public third-parties haveread-only access. This situation requires many individual entities to have differentlevel of access to the blockchain. A blockchain such as this benefits from the con-trol of private blockchains while still allowing multiple entities to interact with theblockchain, increasing transparency.

Voting Application

With respect to the domain of voting, a public blockchain is likely out of the question.While a public blockchain can be used for something like a cryptocurrency, wherethere is no authority that needs to control anything about the currency, a voting sys-tem requires an central authority. In order for an election to be successfuly run, therehas to be an election authority that defines who the candidates are, who the votersare, and ensures that ballots are delivered to the correct voters. A private blockchaincould be used for an election system, where a private network is used to store theballots, and similar voting booth infrastructure can be used to cast ballots. However,this design loses the transparency and audability that are such important aspectsof blockchain technology. The last possibility is a consortium blockchain. This is alikely choice for an election because it has the control of a private blockchain butallows for transparency and auditibility by allowing the public to track and verifythe execution and results of the election.

4.2 Attacks

4.2.1 Peer-to-peer Network Attacks(Zaghloul, 2018)

Denial of Service

Denial of service (DoS) attacks are a well known attack that are most effective onsingle node systems. If a website has a single web server; an attacker can generate anendless series of requests that keep the server busy, preventing real website visitersfrom being served. There are multiple ways to mitigate the risk of a DoS attack atthe server level or at the network level; however, a DoS attack on a peer-to-peernetwork, such as in use by a blockchain network has different characteristics.

FIGURE 4.1: A visualization of a DoS attack used to overwhelm atarget web server. Source: Research Gate (Suryateja, 2018)

Chapter 4. Blockchain Security 15

In a peer-to-peer network, no single node or network is responsible for servingclients. Therefore, a classic DoS attack on a single target node will fail to take downthe network. If a single node is taken down, any other nodes that try to requestsomething from the attacked node will not be able to communicate with it, but allthe other nodes in the network are unaffected and can continue to interact with eachother. Another attack vector could be assaulting all of the nodes in a peer-to-peernetwork simultaneously; however, this is not practical once the size of the networkgrows too large. Likewise, nodes can enter and leave a peer-to-peer network at anytime, so if some nodes are taken down, they can be replaced quickly. These proper-ties make a DoS much more complex and less effective on peer-to-peer networks.

FIGURE 4.2: A visualization of a peer-to-peer network containing sixnodes. Source: Wikipedia (“Peer-to-peer” 2019)

Blockchain networks are susceptible to another type of DoS attack specific toblockchains. In a blockchain network, attackers can flood the network with manytransactions, forcing the miners and consensus process to process these transactionsinstead of legitimate transactions. Despite the fact that normal DoS is difficult to ap-ply to a large peer-to-peer network, this specific type of DoS can be effective becausetransactions/blocks are broadcast throughout the entire network using a gossip pro-tocol. However,t his type of attack is mitigated by controlling the fees associatedwith executing a transaction. It is common with cryptocurrencies to charge a smallfee for every transaction; this fee is paid to the miner who mines the block contain-ing the transaction. By sufficiently increasing the cost of these fees, attackers can notpractically afford to flood the network.

Chapter 4. Blockchain Security 16

Sybil Attack

A sybil attack is a type of attack that is specific to peer-to-peer networks. The attackerin this attack creates multiple dishonest nodes that join the network and disrupt nor-mal operation of the network. For example, an attacker can setup 100 nodes and joina network; to other honest nodes on the network, the new 100 nodes all seem to beunique; however, they are all controlled by one attacker. Once several nodes havejoined the network, they can work together to spread false data into the network orswallow transactions without broadcasting them. This type of attack is impossible tocompletely mitigate; however, blockchain networks have come up with mechanismsto make a sybil attack aiming to broadcast false information, impractical. This typeof mitigation will be seen often with blockchains; the attack is not made impossible,just too expensive to pull off.

FIGURE 4.3: A visualization of a sybil attack where an attacker hascreated several dishonest nodes that are connected to some honest

nodes. Source: Coin Central (Garner, 2019)

A common method to prevent sybil attacks aiming to broadcast false informationis to leverage Proof of Work(POW). POW was referenced early in the paper withreference to a consensus algorithm; in this context, POW makes a sybil attack toodifficult to scale. In order to attack a blockchain network that uses POW, blocks mustbe generated that satisfies the rules of the network, this requires lots of compute toachieve. A sybil attack’s success is predicated on the ability for a single attacker to beable to take on multiple unique identities in the network. With a POW blockchain, aattacker is limited in the number of dishonest nodes they can create by the computepower that they can afford. With a sufficiently difficult POW requirement and largeenough network, an attacker would be unable to acquire enough compute power tostage an attack.

Eclipse Attack

An eclipse attack is closely related to its name. An attacker introduces nodes to apeer-to-peer network and targets a node, attempting to cut it off from other honestnodes. The result is somewhat like a proxy, the dishonest nodes receive all outgoingmessages from the target node and are the source of every incoming message to thetarget node. This attack is only effective at targeting single nodes, unlike a sybilattack which targets the network as a whole. Once a target node has been isolated,the dishonest nodes can force it into storing a false version of the blockchain.

Chapter 4. Blockchain Security 17

FIGURE 4.4: A visualization of an eclipse attack where an attacker hascut-off a target node from honest nodes with dishonest nodes. Source:

Medium (Zaghloul, 2018)

An eclipse attack is achieved by continuosly feeding a target node the addressesof dishonest nodes until most of the peers of the target are dishonest. Once the noderestarts and tries to reconnect to its previously known peers, all of the peers willlikely be dishonest. This attack can be mitigated by adjusting the way that a noderemembers and stores its previous peers.

4.2.2 Blockchain Attacks(“Blockchain Attack Vectors” 2018)

While the previous section presented some attacks unique to peer-to-peer networks,this section will show some attacks that are unique to blockchain networks.

Selfish Mining

While selfish mining does not break the rules of a blockchain network or involvegenerating false information, it is a harmful mining strategy. In a normal POWblockchain network, a miner mines a block based on the most recent block in theestablished chain and broadcasts the mined block as soon as it is mined. Any otherminers who were mining the same transactions now have to start mining anotherblock based on the new end of the chain. A more extreme version of this is whena miner mines a block but does not broadcast it, and the miner continues to minethe next block on its own private fork of the the blockchain. Once the miner canobserve that its private fork is longer, and will overwrite, the publically acceptedversion of the chain, then the miner will release all of the new blocks in its chain atonce. In this situation, the other miners in the network wasted compute resources onseveral blocks before having the blocks replaced by the selfish miner who secretlymined a longer version of the chain. This mining strategy ultimately hurts otherminers while providing a small benefit to the selfish miner, and currently very fewblockchain networks provide the facilities to prevent a selfish miner. The rest of theattacks in this section are against the rules of the blockchain system and actuallyproduce false information.

Double Spending

Double spending is the backbone of blockchain specific attacks. The basic idea ofdouble spending is to submit a transaction to the blockchain, prove that it is valid

Chapter 4. Blockchain Security 18

and confirmed in the chain to a portion of the network, receive some product or ben-efit from this transaction, and then invalidate the transaction with a new one so thatit appears to have never happened. In the world of cryptocurrencies, this equates tosending some amount of currency to a wallet, receiving the product that was beingpaid for, and then paying that transaction back to the original wallet so that it can beused again. This attack is difficult to pull off but can be highly profitable.

51% Attack

A 51% attack is a type of sybil attack that allows for double spending. This typeof attack requires that an attacker has access to more than half of a blockchain net-works compute power. This means that the attacker’s sybil nodes, together, havecomplete control over the mining of new blocks; as a result, it becomes easy to dou-ble spend. The attacker can execute transactions on the honest nodes of the networkto interact with genuine users of the network. After a transaction has been fulfilled,the attacker can use the might of their sybil nodes to rewrite the chain such thatthe transactions involved are undone. This is a powerful attack because it allowsthe attacker to completely control how the blockchain is formed; however, it is onlypractical with smaller blockchain networks. For example, several smaller cryptocur-rencies have suffered a 51% attack, but the larger cryptocurrencies such as BitCoinhave not because the total compute power of their networks are simply too large.

Fake Transactions

This type of attack is simple, an attacker creates a transaction from a user(key) ofthe blockchain without being that user. An obvious use of this attack would be foran attacker to send themselves cryptocurrency from other user’s wallets, essentiallydigital theft. Thankfully this attack is mitigated by virtually all implementations ofblockchain by public key cryptography. In order for a transaction to be created, auser must have access to or have created a public/private key pair. The user is iden-tified by their public key, and the user must digitally sign the transaction with theprivate key. The signature of a transaction can be verified by the public key. Thismeans that a transaction can only be created user who has access to both the publicand private key. While an attacker has access to the public key, they do not have ac-cess to the private key; moreover, given that a secure algorithm is used, it is imprac-tical for a private key to be recovered from a public key. Without any additional in-frastructure, this public-private key pair algorithm prevents false transactions frombeing created. This leads to a general realization about attacks on blockchains. Thesecurity risk of most blockchain attacks is in how transactions are written to thechain, not the validity of transactions themselves.

4.2.3 Conclusion

This chapter reviews the types of attacks that are effective on blockchains. The typesof attacks are split into two main categories, peer-to-peer and blockchain. Peer-to-peer network attacks are general attacks that can maliciously affect any peer-to-peersystem. Blockchain specific attacks exploit features of blockchain consensus algo-rithms. For the purpose of a voting system, many of the security risks of a blockchainsystem can be avoided be using a private or consortium system where only certainnodes are allowed to interact with the network in certain ways. Likewise, a vot-ing blockchain is less susceptible to the risk of “double spending” because elections

Chapter 4. Blockchain Security 19

have beginnings and endings. The premise of double spending is that the blockchainreflects some transaction has been confirmed so a user provides a service or prod-uct, and then the attacker overwrites the transaction so that it seems to never havehappened, having already received the service/product. In an election, the produc-t/service (counting up the ballots) only occurs once the election has ended; therefore,any further changes to the chain after the counting of the ballots does not affect theoutcome of the election.

20

Chapter 5

Blockchain Voting

5.1 Introduction

This chapter reviews existing blockchain voting systems and provides a constructionfor a blockchain voting system called “Block Vote”. This system is an extension ofthe proof-of-concept implementation produceded alongside this writeup.

5.2 Existing Systems

With the latest hype around blockchain technology, several individuals/companieshave attempted to create electronic voting systems based on various blockchain tech-nologies. Some examples of these individuals are discussed in this section.

Bitcoin Based Voting Bao, Wang, and Shi, 2018

This paper from arXiv describes an electronic voting system based on Bitcoin, claim-ing to preserve privacy, decentralization, and practicality.

Architecture

This system is built using only the Bitcoin network; however, in order for the sys-tem to work, it must make some assumptions. One, there are no fees for executingtransactions, two, the number of voters is not too large, and three, all voters are ableto acquire a certain amount of Bitcoin to vote with. In the construction of this sys-tem, there are a set number of voters, candidates, and minimum amount of Bitcoin(threshold) for a candidate to win the election.

Ballot Casting

In order for a voter to cast a ballot using this system, they must have a Bitcoin walletwith a certain amount of Bitcoin in it. From here they submit their ballot by send-ing proportional amounts of their Bitcoin to the candidate addresses they want tovote for. These Bitcoin transactions are commitments to vote and are made anony-mous via a distributed shuffling mechanism. As the election is running, there aretwo ways for it to terminate. Either a candidate wallet obtains enough Bitcoin towin and will submit a win transaction to the network, winning the election. Other-wise, if no candidate has received enough Bitcoin to create a win transaction beforethe end time of the election, then all voters are refunded their Bitcoin. Various de-tails involving the use of a decentralized threshold signature and Bitcoin script hashaddresses which allows for these vote commitment transactions to be created andverified by all voters securely.

Chapter 5. Blockchain Voting 21

Conclusion

While creating a voting system using Bitcoin is novel idea, there are several issuesto point out. First of all, the system would not be economically feasible to run on theactual Bitcoin network, transaction fees and network performance would preventany large elections from being run. As such, these elections would have to run on anisolated Bitcoin network operated by the election authority; however, this rendersbenefits of using an existing blockchain network less glamorous. Without the highimmutability and reliability brought by the sheer size and longevity of the Bitcoinnetwork, it makes little sense to use Bitcoin technology when a custom blockchaincould be used that uses compute resources more efficiently. Additionally, the sys-tem put forward in this system is susceptible to a Sybil attack, where one maliciousactor could easily pretend to be multiple voters and cast multiple ballots by gener-ating multiple Bitcoin wallets to vote from. The system in this paper is secure andefficiently uses the methods provided by Bitcoin to run an election anonymously;however, the context of the system is too theoretical and likely would not be practi-cal for any real-life election.

5.2.1 Polys (“Polys – Online Voting System” 2019)

Polys is an online blockchain-based voting system that aims to replace offline elec-tions with a transparent, anonymous, and secure system.

Architecture

Polys is built on top of Ethereum and uses features such as Ethereum’s PoW algo-rithm Ethash and smart contracts.

Ballot Casting

When ballots are cast to the blockchain, they are signed and encrypted by the voter,this secret ballot is then mined onto the chain. As a result, all ballots on the blockchainare encrypted, but the encryption algorithm used has a property known as homo-morphism. This means that the multiplication of two encrypted messages is equalto the encryption of the two original messages multiplied. As a result, with somecareful planning, the election results can be counted without ever having to decryptindividual ballots. Once all the ballots are counted into a single encrypted result, anadapted version of Shank’s algorithm can be used to decrypt the final result.

This usage of encyption allows for complete anonymity of each ballot such thatno third party can point out who cast what vote, but the overall result can still becomputed.

Conclusion

While Polys introduces new algorithms such as the encryption scheme describedabove, they also use a proven blockchain Ethereum. This can be a better decisionthan writing a new blockchain from scratch. First of all, existing Ethereum develop-ers can easily come and work on the Polys platform without too much onboarding.Secondly, the tweaks and findings that Ethereum has produced over time are auto-matically built in to this new system, reducing the chance of a major bug or securityrisk. While building a voting system on top of a cryptocurrency blockchain may re-quire some extra work, Ethereum has built in features such as smart contracts that

Chapter 5. Blockchain Voting 22

allow for more complex transactions to occur in a secure and immutable mannerwithout reprogramming the blockchain itself. For example, Polys uses a smart con-tract to handle the creation and validation of voter aliases to prevent a user fromcasting multiple ballots.

Polys has a solid start into the online voting market. By using an Ethereum base,they were able to get off the ground quickly with proven technology. Likewise, theirvoting-specific algorithms on top of Ethereum effectively solve many of the issueswith online voting, such as anonymity and prevention of voting multiple times.

5.2.2 Agora Vote (“Agora Vote” 2019)

Agora takes a different approach than Polys; however, the end product is intendedto be the same, provide a transparent and secure online voting system for the publicand private sector.

Architecture

Agora vote is built on a custom blockchain, not forked from any existing blockchain.This allows Agora to have the exact features that it needs to support the require-ments that a blockchain voting system requires. However, recognizing that estab-lished blockchains can offer higher security and immutability, Agora also uses Bit-Coin as an additional, highly immutable, store of information.

Agora is built on 5 layers, each layer providing a different way to store or interactwith auditable versions of the election/ballots. The first layer is Votapp, the applica-tion that voters interact with to cast ballots, upon casting a ballot, it is encrypted andsent to the bulletin board layer. The bulletin board layer is a custom blockchain thatallows for many ballots to be easily added and traversed through. Snapshots of thebulletin board are occasionally taken and added to an implementation of the Catenablockchain, a lightweight immutable blockchain used for logging. Finally, BitCoin isused as the most immutable blockchain, due to its large size in terms of transactionsand full nodes on the network. Once in a while, a log from the Catena blockchain isstored as a BitCoin transaction.

All of these layers work together to provide multiple ways to audit the electionin a secure manner. Similar to Polys, Agora encrypts the blockchain to ensure thatintermediary election results are kept secret, while the election authorities can stilldecrypt the results at the end of the election.

Auditing

Agora’s Valeda network is a consortium network that has election authority nodesand “Citizen Auditor Nodes”. These auditor nodes do not contribute to the consen-sus process; however, they have full access to the blockchain and can audit ballotsas they are cast and validate the election results at the end of the election. This is akey component to the transparency of Agora’s model because auditor nodes can beoperated by any third-party, allowing any cynical voters to verify that the election isbeing run correctly.

Chapter 5. Blockchain Voting 23

5.3 Block Vote

Block Vote is the name of a proposed architecture for a blockchain based electronicvoting system. The structure of this system has been inspired by the likes of cryp-tocurrencies, existing voting systems, and other blockchain based voting systemspreviously mentioned. Alongside this writeup is a stripped down implementationof Block Vote that bifurcates from the following proposal in some ways; this is dueto time constraints, the implementation is meant as an exploration and proof-of-concept.

5.3.1 Overview

FIGURE 5.1: A graphical overview of the entities involved in a BlockVote network.

Chapter 5. Blockchain Voting 24

Figure 5.1 provides a rough overview of how a Block Vote system is formed. ABlock Vote system is capable of running multiple elections simultaneously withoutany interaction between the elections. Every election has two main types of humanactors, voters and the election authority. The voters are each given the permission tocast exactly one ballot that is then included when counting the results of the election.The election authority is the creator of the election and is responsible for storing anddistributing ballot keys and election keys. Each election is represented by a singleblockchain that is stored amongst all the nodes in the network.

There are three types of nodes in this consortium network, full nodes, miners,and auditors. Full nodes and miners are privileged nodes that participate in theconsensus process and are maintained by the election authority. A full node is capa-ble of receiving/sending ballots, elections, and blocks and will verify any data that itreceives. A miner will perform the same actions as a full node but will also be able toproduce new blocks from unconfirmed transactions. An auditor is not a privilegednode, it is not able to send any type of data to the rest of the network; however, itis able to receive elections, blocks, and ballots in order to be able to verify that theprivileged nodes are executing the election correctly. Auditor nodes can be operatedby any third-party, allowing for a transparent election.

Outside of the network, the BitCoin cryptocurrency network is used as a highlyimmutable store of snapshots of elections. This adds another layer of election log-ging to increase the level of immutability and transparency that is lost when choos-ing to use a potentially private custom blockchain.

5.3.2 Election Process

This section will go over the entire election process from the creation of an electionby the election authority to the computation of the election results.

Election Setup

With a Block Vote network, each election is managed by a dedicated blockchain thatis created upon creation of the election. Before creating an election, the electionauthority must start up one or more privileged nodes in the same network. To createan election, an election creation request must be sent to a privileged node containingthe following information.

1. election label

2. candidate names

3. ballot count

4. start time

5. end time

The election label will be used for humans to identify which election they are inter-acting with, the list of candidate names will be what voters see when creating theirballot, and the ballot count is used to determine how many voting keys are to begenerated. The start and end time are used to control when ballots will be accepted.In response to this request, the election authority will receive the following data.

1. Unique election ID

Chapter 5. Blockchain Voting 25

2. Voting keys

3. Election key

The unique election ID is a non-human oriented ID that is guaranteed to be globallyunique. The response will have a number of voting keys equal to the ballot countrequested, and each key can be used to cast exactly one ballot. The election key is akey that will be used to encrypt the blockchain during the election and can be usedto decrypt the blockchain at the end of the election.

At this point, the election authority has taken on the responsibility to ensure thatthe voting keys and election key are kept secure. Likewise, the election authority isresponsible for determining how to distribute voting keys to the voters, this problemwill be addressed in the next section.

Now that the election has been created, privileged nodes are ready to receivesigned ballots and execute the election once the start of the voting period has beenreached.

Small Election Voting Process

The election is ready to begin, now the election authority must determine how vot-ers will cast their ballots. For elections less demanding of security such as clubs,education, small organizations, etc... an Internet based system is likely going to suf-fice. In this situation, voters would authenticate with the voting website using ausername/password/OTP and would be provided with a random voting key. Thevoter would prepare their ballot using a web form, enter their assigned voting key,and submit their ballot to a privileged node. In order to prevent double voting, theelection authority must maintain a list of voters that have already voted, preventingthem from receiving another voting key from the voting website. While this systemis simple for both the election authority and voters, for larger elections, particularlyfor a public election, there are several flaws.

First of all, running an election on the Internet opens up the whole network tonew attack vectors with low barriers to entry. Secondly, the anonymity of votersbecomes easy to lose. In order to prevent double voting, the election authority mustmaintain a list of voters who have already voted; unfortunately, this also means thatthe election authority could maintain a lookup table that maps voting keys to theindividual who voted with them. By having the system completely computerized,this lookup table could be generated and analyzed without the public ever knowing.For a public election, this is simply unacceptable and creates mistrust in the votingsystem.

Current public election systems mitigate this problem by requiring voters to pro-vide proof of identity at a physical voting location to a member of the election au-thority. Upon verification of a voters identity, they are given a physical ballot, andthe process from this step onwards is totally anonymous. In order for a ballot-to-voter lookup table to be created using this system, the member of the election au-thority responsible for verifying voter identities would have to manually associatethe voter’s information with the ballot given to them, this is more difficult to do atscale without the public finding out.

Large Election Voting Process

The best way to incorporate this new technology into existing public election pro-cesses is likely creating a hybrid of old and new systems. Voting keys should be

Chapter 5. Blockchain Voting 26

distributed to voting locations based on the number of voters that are registered tovote at that location, these voting keys should be manifested physically such as a QRcode printed on paper or some kind of conductive material. The existing voter in-dentity verification process can be kept exactly the same, using physical interaction,except instead of receiving a paper ballot, a voter receives a physical voting key. Thisvoting key is then taken and inserted into the voting booth. The voting booth canthen be used to prepare, sign, and send the ballot to a privileged node in the BlockVote network. Using this method of distributing voting keys, the Block Vote systemcan be seamlessly integrated into existing public elections without confusing or in-hibiting voters or the election authority while still reaping the benefits of storing theelection in a blockchain.

The issue of running the Block Vote network on the Internet still remains. Byusing existing election processes, this greatly reduces the number of devices thatneed to be connected to the Block Vote network, from potentially a device for everyvoter, to just the voting booths for each voting location and potentially some devicesfor absantee voting. Because of this, it is much more feasible to take the privilegednodes off of the Internet and onto a private network, this closes off the blockchainnetwork from the vulnerabilities opened up by the Internet; however, the networkalso becomes closed off to the public for auditing, one of the main benefits of usinga blockchain.

This loss of transparency can be resolved in several ways. One possibility isto expose part of the Block Vote network to the Internet while closing off the rest.While this still opens up the network to some risk, the entry points to the Block Votenetwork can be more tightly controlled while still allowing third-parties to operateauditor nodes on the network.

Another possible solution is to provide a process by which third-parties mustapply to be given permission to operate an auditor node. In order to operate anauditor node, the third-party must conform to certain security requirements, andupon approval, they are given permission to start an auditor node connected to theprivate Block Vote network.

These solutions trade off security risk for public access and transparency. Nei-ther is clearly more optimal, but it is likely that keeping the Block Vote networkcompletely private with only vetted third-parties having access would be the solu-tion chosen for a public election.

Election Results

Once the election is over (the end time of the election has been reached), no moreballots will be accepted by privileged nodes and the election authority can countthe ballots. In order to count the ballots, the election authority must decrypt theblockchain using the election key; to provide election transparency, the election au-thority should also release the election key to the auditor nodes so that they canverify the integrity of the blockchain. The ballot counting is performed by iteratingthrough every block in the blockchain and every ballot in each block, dependingon the type of the election (Borda count, instant run-off, etc.), the ballots will becounted differently. After the election has ended, the blockchain can be archivedand kept as a reference in case the election is contended. However, hopefully, thephysical processes in place and blockchain security will prevent an election frombeing fraudulent in the first place.

Chapter 5. Blockchain Voting 27

Conclusion

This section has provided a general overview of the way an election can be runusing Block Vote. A Block Vote network is set up, the election authority creates anew election with the necessary paremeters, and the election authority receives thekeys necessary to secure the blockchain and cast ballots. From there, dependingon the requirements of the election, the election authority has multiple options todistribute voting keys and enable voters to cast ballots. After the voting period hasconcluded, the election authority decrypts the blockchain and allows the public toaudit the blockchain and verify the integrity of the election. In the next section, thetechnology used in each of the layers of Block Vote will be laid out.

5.3.3 Technology

Block Vote is built on multiple layers, the custom Block Vote blockchain network,BitCoin, and the user-facing election management and ballot casting applications.While the first two layers will remain consistent for every Block Vote election, theuser-facing applications can vary depending on the needs of the election authority.

Privileged Nodes

Privileged nodes can come in multiple types, full nodes and miners depending onthe consensus algorithm in use. While Block Vote uses a proof-of-work consensusalgorithm (requiring miners), the network could also use a Byzantine Fault Toler-ant(BFT) consensus algorithm that only requires full nodes.

A full node is a node on the Block Vote network that stores a full copy of theblockchain and is capable of receiving and verifying new elections, blocks, and bal-lots. When a full node receives any new data, it will broadcast the new data to it’speers in the network, allowing for ballots to eventually make it to a miner to bemined. While a full node does not contribute new blocks, it provides an endpoint toreceive new ballots and verify that the blockchain is being constructed correctly. Ina BFT network, full nodes would also be a part of the consensus process.

A miner node is a full node that also is capable of generating and propagatingnew blocks into the blockchain network. When a miner receives a new ballot, itadds the ballot to a pool of unconfirmed ballots, ballots that have been verified asvalid but not added to a block yet. A block has a certain capacity for ballots, ca-pable of storing one or more ballots in a single block, depending on the election.Once enough unconfirmed ballots are added to the pool to populate a block, theminer will select these ballots, construct a new block with a UUID and other headerinformation, including a reference to the previous block’s ID/hash, and attempt tomine the new block. The mining process is executed by continuously calculating theSHA256 digest of the block header+ballots changing a nonce after each calculationuntil the digest conforms to a certain rule. Depending on the election and size of theBlock Vote network, this digest rule will vary in difficulty, making it take more orless hashing iterations to find a valid hash. Once the block’s digest conforms to therule, the miner will broadcast the new block to the Block Vote network where othernodes will verify the block is valid and append it to the end of their local copiesof the blockchain. If multiple miners broadcast conflicting blocks simultaneously,there may be multiple versions of the blockchain on the network, but eventually thenetwork will accept the longest chain, and consensus will be reached.

Together, full nodes and miner nodes ensure that the Block Vote network canreceive, verify, and store ballots in an immutable fashion. An important detail to

Chapter 5. Blockchain Voting 28

remember, is that during the voting period of the election, all blocks/ballots arestored in an encrypted manner, so intermediary election results can not be used tosway voters. The encryption algorithm used can vary but is recommended to beAES-256.

Auditor Nodes

Auditor nodes are part of the Block Vote network layer; however, they are not op-erated by the election authority. An auditor node is similar to a full node, but anauditor node is only capable of receiving data. Any broadcasts coming from an au-ditor node are ignored by a privileged node, but when a privileged node broadcastsnew data to the network, an auditor node will receive it. The purpose of auditornodes is to allow third-party organizations/individuals who are interested in ver-ifying the election process to be able to monitor the ballots/blocks being passedaround the Block Vote network. Auditor nodes can also be used to verify that a bal-lot has been received. When a voter casts a ballot, their ballot is added to the poolof unconfirmed ballots and eventually added to a block in the blockchain. Once thenew block is propagated to the whole network, the voter can query a node to checkif the ballot associated with their voting key has been added to the chain yet. Whilevoters are not able to see the contents of their ballot until the blockchain has beendecrypted at the end of the election, they are able to verify that some ballot withtheir voting key is in the chain.

5.3.4 Ballot Casting

In order to cast a ballot, a voter must have two components, a voting key and anordered list of candidates. To create a valid ballot, the voter will send the key andlist to a local Block Vote node that does not store the whole blockchain but is ableto create and broadcast ballots. The ballot is created by generating a random ballotUUID along with some other header information(including the verifying key) that isthen put together with the list of candidates and digitally signed using ECDSA andthe voting key. This digital signature is then broadcast to the Block Vote networkalongside the ballot header+list. When any node receives a new ballot, before doinganything else, it will use ECDSA to verify that the digital signature sent with theballot matches the verifying key stored in the header of the ballot. This processensures that the owner of the voting key must have created and signed the ballot.

BitCoin

BitCoin is used as a way to ensure the immutability of the blockchain while alsoallowing more transparency. Depending on the security requirements of the election,the Block Vote may be running on a private network, only allowing trusted third-parties to participate in auditing, this makes the system less visible to the generalpublic. By storing some information on a public blockchain, such as BitCoin, theelection is more exposed to the public without affecting security.

The BitCoin cryptocurrency blockchain network is used as a store of snapshotsof the election blockchain throughout the election. Every n blocks that are added tothe chain, a privileged node is selected to create a BitCoin transaction containing aSHA256 digest of the entire blockchain and a count of the blocks in the chain. SinceBitCoin is an enormous, long-standing blockchain, the transaction will be immutableand visible to the public. After the election has ended and the decrypted blockchain

Chapter 5. Blockchain Voting 29

is released, third-parties can check the snapshots stored in BitCoin against calculateddigests of the Block Vote blockchain. Since these snapshots are stored in the BitCoinblockchain as the voting period commences, if the released blockchain matches thesnapshots, then it is clear that the blockchain was tampered with during or after theelection ended.

Ballot Counting

Once the voting period for the election has ended, the chain can be decrypted and theballots can be counted. Depending on the election process being used, this countingwill vary, but the core process remains the same. When counting ballots, each blockin the blockchain should be iterated through, verified for integrity, and then eachballot within the block should be verified and included in the count. Performingthis last check for valid signatures and block digests ensures that each ballot is atrusted ballot.

30

Chapter 6

Block Vote POC

6.1 Overview

The proof-of-concept included with this writeup provides a step towards a com-plete Block Vote implementation, including user-facing applications for managingthe Block Vote network, casting ballots, and reviewing election results.

6.1.1 Missing Features

The following features of Block Vote are not implemented in the POC.

• Chain encryption

• Voting key distribution(election dependent)

• Support for multiple consensus algorithms

• Auditor nodes

6.1.2 Block Vote Nodes

Block Vote nodes are implemented using a Python web framework called Flask. Fullnodes expose a stateless REST API that allows other nodes and user-facing applica-tions to request or send data to. Likewise, nodes expose a WebSocket API that al-lows user-facing applications to get information about the state of each node pusheddown to the client without the need for polling. Miner nodes expose the same APIsas full nodes but also spawn a mining thread that continuously looks for ballots inthe unconfirmed ballots to pool to mine. Once a block is mined, the miner threadwill broadcast the block to the network and continue waiting for more unconfirmedballots to mine.

Blockchains, blocks, and ballots are all represented as Python dictionaries ofbuilt-in Python types. This allows for simple serialization to the data transmis-sion/storage format used, JSON.

6.1.3 User-Facing Application

The front-end application in the POC is a single page web application built usingReactJS. The application includes four main functionalities, Block Vote network vi-sualization, election creation, ballot casting, and election monitoring.

Chapter 6. Block Vote POC 31

Network Visualization

The network visualization function of the front-end application allows users to seeevery node in the network and the connections between them. Likewise, once a con-nection has been established with each node, updates about the nodes data/statusis pushed down to the front-end, showing live updates.

FIGURE 6.1: The network visualization page.

Election Creation

Using a web form, users can create new elections with a specified label, candidateslist, and ballot count. The creation request is sent to a node, and the response con-taining the election UUID and voting keys is outputted in the front-end.

FIGURE 6.2: The election creation page.

Ballot Casting

A web form displaying a random ordering of the candidates and a voting key inputallows users to cast ballots. The form will send the ballot information to a node

Chapter 6. Block Vote POC 32

that will then create a signed ballot and broadcast it to the network. Likewise, fordemonstration purposes, batches of ballots can be cast simultaneously with randomcandidate ordering.

FIGURE 6.3: The ballot casting page.

Election Monitoring

While an election is active in the network, the election monitoring function allowsusers to visualize the current state of the blockchain. Moreover, the blockchain canbe processed using a ballot count algorithm to see the intermediary results of theelection.

FIGURE 6.4: The election monitoring page.

33

Chapter 7

Conclusion

This writeup has given an overview of basic blockchain technology, blockchain se-curity, electoral systems, existing blockchain based voting systems, and a proposedelectronic blockchain based voting system called Block Vote. Alongside this writeupis a proof-of-concept implementation of Block Vote with a subset of its proposedfeatures.

Blockchain technology is going through a turbulent time where many new ap-plications are popping up. The most popular application at the moment is cryp-tocurrency and its great volatility that attracts risk tolerant investors and forward-thinking people alike. However, it is likely that the largest impact of blockchain isgoing to come from the many benefits that it can bring to other applications. One ofthese applications, which is becoming more and more popular, is electronic voting.Introducing blockchain technology to voting allows for more secure and transpar-ent elections. As opposed to the complete trust in government that is required bycurrent voting systems, blockchain subscribes to the Russian proverb of “trust, butverify”, by leveraging immutability, auditability, and decentralization.

Based on current cryptography practices, digital signatures, secure hashing al-gorithms, and secure encryption algorithms, blockchains offers mathematical proofthat the ballots cast in an election were accepted and counted correctly. While thesecryptographic properties ensure a secure election, there are still inherent weaknessesthat stem from the use of a peer-to-peer network. Whether using general peer-to-peer network attacks such as a sybil attack, or leveraging a blockchain network spe-cific attack such as selfish mining or a 51% attack, blockchain networks are able tobe cheated. Fortunately, many of these attacks can be mitigated through careful de-signing of consensus algorithms and network structure. Likewise, with the use of aconsortium network of nodes on a private network, the blockchain network can beprotected from attacks while still allowing third-party access.

Several organizations have already began cracking the problem of electronic vot-ing, and many of them, such as Agora and Polys, have decided to leverage variousblockchain technologies. The system proposed in this paper, Block Vote, is anotherpossible blockchain system that could be leveraged for large scale elections. Votinghas been a keystone of democracy for millenia, as the voting population increasesand technology advances, electoral systems have to scale also.

34

Appendix A

Usage

A.1 Getting Started

This appendix will provide the necessary steps to acquire and run the BlockVoteproof-of-concept.

A.1.1 System Requirements

The following are system requirements that must be installed to run the POC code.

• Some flavor of Linux (developed using Ubuntu 18.04)

• The more CPU/RAM the better, as multiple servers will be running simulta-neously and performing crypto calculations.

• node (v10.15.3+) and npm (6.4.1), recommend installing using nvm.

• python3

• pip3

• tmux

A.1.2 Getting the Code

The code for the POC is stored in the GitHub repository, ericdudley/blockvote.To start working with the code, you can fork the repository into your GitHub

account and clone your fork to a local workstation. If you desire to contribute to theoriginal repository, feel free to for open a well-formed pull request.

The code is split into two top-level directories, “client” and “server”. The clientdirectory contains an npm project that uses ReactJS. The server direcotry contains apython project using Flask.

A.1.3 Installing Dependencies

Before running either the client or server, third-party dependencies have to be down-loaded. This process is mostly automated using pip and npm.

Server

Enter the server directory and install python dependencies using pip.

$ cd server$ pip3 i n s t a l l −r requirements . t x t

Appendix A. Usage 35

Client

Enter the client directory and install npm dependencies using npm.

$ cd c l i e n t$ npm i n s t a l l

A.1.4 Running the Code

To run both client and server with a fairly small network size, simply run the fol-lowing command in the top-level directory. It will split your terminal into 2 tmuxpanes, server on the left, and client on the right. This tmux guide is helpful.

$ ./ run . sh

Server

Enter the server directory and run one or more nodes. The “-p” flag specifies theport that the node will listen for requests on, the “–servers” flag specifies the portsof other nodes the node should know about, and the “–mine” flag specifices that thisnode is a miner.

$ cd server$ python3 app . py −p 5006 −−s e r v e r s 5003 −−mine

To run multiple nodes, the “run.sh” script in the “server” directory can be used.The following command will start 8 nodes with random connections between them;likewise, the letters ‘a’ and ‘b’ will start example network configurations of size 8and 4 respectively. Logging from all nodes will be outputted to the terminal and allnodes can be terminated together using “Ctrl+c” .

$ cd server$ ./ run . sh 8$ # . / run . sh a

Client

Enter the client directory and use npm to start the development server.

$ cd c l i e n t$ npm s t a r t

This will start the development server and automatically open the application in thebrowser. The development server supports live reload so code changes will auto-matically be loaded in the browser.

A.1.5 Code Guide

Server

The server application is split into three modules, “app.py” which holds all the Flaskapplication functions and is the entry point for the application. “util.py” whichholds application state and non-Flask functions, and “blockchain.py” which con-tains all blockchain related functions and constants.

Appendix A. Usage 36

Client

The client application is split into components for the view, and uses a central MobXstore in “store.ts” that is injected into each page. Blockchain related type definitionsand functions are in “blockchain.ts”. The rest of the application is written using astandard React application layout.

37

Appendix B

Work Log

Week # M T W T F S S Total LogWeek 1 0 3 0 3 0 3 0 9 intro to blockchain researchWeek 2 0 3 0 3 0 3 3 12 starting implementationWeek 3 0 4 0 3 0 0 2 9 peer-to-peer network researchWeek 4 3 1 0 0 0 3 3 10 consensus researchWeek 5 2 4 0 0 0 3 0 9 consensus implementationWeek 6 0 4 0 4 0 4 0 12 blockchain voting researchWeek 7 0 3 0 0 0 3 3 9 voting researchWeek 8 4 3 3 0 0 0 0 10 implementation refactoringWeek 9 4 0 0 0 0 0 0 4 attacks writeupWeek 10 3 0 2 0 0 4 0 9 other voting systemsWeek 11 2 0 3 0 0 4 0 9 block voteWeek 12 3 2 0 3 0 3 0 11 finishing writeupWeek 13 3 0 3 0 0 4 0 10 writeup reviewWeek 14 3 0 3 0 0 0 4 10 finish implementationWeek 15 4 0 0 0 0 0 0 4 reviewHours/Week 2 2 1 1 0 3 1 9.5Total Hours 29 27 13 17 2 42 11 143

38

References

Acheson, Noelle (Mar. 2018). “Hard Fork vs Soft Fork”. In: Coin Desk 1.1, p. 3. URL:https://www.coindesk.com/information/hard-fork-vs-soft-fork (visitedon 03/04/2019).

“Agora Vote” (Mar. 2019). In: Agora Vote 1.1, p. 1. URL: https://www.agora.vote(visited on 04/21/2019).

Bao, Zijian, Bin Wang, and Wenbo Shi (Sept. 2018). “A privacy-preserving, decen-tralized and functional Bitcoin e-voting protocol”. In: Arxiv, p. 5. URL: https://arxiv.org/abs/1809.08362 (visited on 03/20/2019).

“Blockchain Attack Vectors” (Nov. 2018). In: Apriorit 1.1, p. 5. URL: https://www.apriorit.com/dev-blog/578-blockchain-attack-vectors (visited on 04/05/2019).

Curran, Brian (2018). “Practical Byzantine Fault Tolerance”. In: Blockonomi, p. 4. URL:https://blockonomi.com/practical-byzantine-fault-tolerance/ (visitedon 04/20/2019).

Garner, Bennett (2019). “What’s a Sybil Attack”. In: Coin Central. URL: https://coincentral.com/sybil-attack-blockchain/ (visited on 04/10/2019).

Haon (Oct. 2018). “Blockchain forks and chain splits: why we should avoid them”.In: Medium 1.1, p. 3. URL: https://blog.goodaudience.com/blockchain-forks-and- chain- splits- why- we- should- avoid- them- f54c693a90f1 (visited on02/27/2019).

“Instant Runoff Voting” (2019). In: Fair Vote. URL: http://archive.fairvote.org/oaklandirv/webarchive/howirvworks.html (visited on 04/10/2019).

Joshi, Archana Prashanth, Meng Han, and Yan Wang (May 2018). “A survey on secu-rity and privacy issues of blockchain technology”. In: American Institue of Math-ematical Sciences 1.1, p. 10. URL: https://www.aimsciences.org/article/doi/10.3934/mfc.2018007 (visited on 04/03/2019).

King, Charles (Mar. 2000). “Electoral Systems”. In: Georgetown University 1.1, p. 4.URL: http://faculty.georgetown.edu/kingch/Electoral_Systems.htm (vis-ited on 03/18/2019).

“Peer-to-peer” (2019). In: Wikipedia. URL: https://en.wikipedia.org/wiki/Peer-to-peer (visited on 04/10/2019).

“Polys – Online Voting System” (Mar. 2019). In: Kaspersky Lab 1.1, p. 1. URL: https://polys.me/ (visited on 04/21/2019).

“Ranked Voting” (Mar. 2019). In: Wikipedia 1.1, p. 5. URL: https://en.wikipedia.org/wiki/Ranked_voting (visited on 03/21/2019).

Ray, Shaan (Nov. 2017). “Blockchain Forks”. In: Hacker Noon. URL: https://hackernoon.com/blockchain-forks-b0dca84db0b0 (visited on 04/10/2019).

Ross, Rosa (2016). “The Borda Count Method”. In: Slide Player. URL: https://slideplayer.com/slide/4478750/ (visited on 04/10/2019).

Suryateja, Pericherla Satya (2018). “Denial of Service”. In: Research Gate. URL: https://www.researchgate.net/figure/Denial-of-Service-DoS-attack-A-DDoS-

Distributed- Denial- of- Service- attack- as- shown- in_fig2_324562008

(visited on 04/10/2019).

References 39

Tar, Andrew (Jan. 2018). “Proof-of-Work Explained”. In: Cointelegraph 1, p. 4. URL:https://cointelegraph.com/explained/proof-of-work-explained (visitedon 02/25/2019).

Zaghloul, Ehab (July 2018). “Beginners Guide on Blockchain Security Attacks”. In:Medium 1.1, p. 4. URL: https://medium.com/zkcapital/beginners- guide-on-blockchain-security-attacks-part-1-network-ca4e74435723 (visited on04/04/2019).

Zheng, Zibin et al. (June 2017). “An Overview of Blockchain Technology: Architec-ture, Consensus, and Future Trends”. In: IEE International Congress on Big Data,pp. 1–8. URL: https://www.researchgate.net/publication/318131748_An_Overview_of_Blockchain_Technology_Architecture_Consensus_and_Future_

Trends (visited on 02/19/2019).