The system of voting to (s)elect the the governing body of a nation is the core concept of Democracy. In the earliest of its forms, the Spartans would democratically elect their leaders by casting stones into marked bowls. Today, we use "cutting-edge" technology to conduct these vital election procedures, but since the prize at stake is control of the population, elections continue to be an easy target for a malicious candidate who is intent on seizing power. With the recent revival of Blockchain and increased interest in decentralisation, consensus and Merkle trees, perhaps we are now better equipped with techniques to solve large scale voting.
In India, nation-scale elections are conducted using an Electronic Voting Machine (EVM) that is distributed to various voting regions(we call them constituencies), spanning from large metropolitan cities to remote villages with no connectivity. Each machine can hold 3840 votes, and the voting machines are manually transported to the central voting commission for counting. This process is difficult and time consuming, and there have also been reports that the procedure is prone to manual error or intentional miscounting1.
More recently the Election Commission of India has devised a system called the 'Voter Verifiable Paper Audit Trail' (VVPAT), which involves the voter's choice being printed on a physical receipt which is displayed briefly before being dropped into a sealed box. This allows the voter to know that the vote was placed correctly and addressed previous concerns that votes were being cast to a default candidate on a potentially rigged machine. Further, the paper trail would add more accountability in the counting process, unless, somehow, a huge number of them were to go missing :^).
The key benefits of this system are:
a. The hardware is designed to be extremely robust, and can be run off a 6 volt alkaline battery even in remote regions without power.
b. The polling is offline, and all machines are returned to the election commission who is responsible for preventing voter fraud.
c. Indians have more faith in a paper verifiable system, as they feel purely software based solutions would be more vulnerable to manipulation.
It doesn't stop there. Nepal, Bhutan, Namibia and Kenya have purchased India-manufactured EVMs with the intent of employing them in national elections. I begin to worry that being more reliant on labour-intensive manual counting processes might not be the best way forward.
Further, the manual authentication method of physically identifying yourself in your registered voting constituency is also something that we should avoid, potentially allowing people to place votes for a candidate in their home state even if they are travelling, which can drastically increase voter turnout.
In traditional voting systems, votes are cast on a client (either dedicated or through a website), and the choice is then submitted to a server where a central database keeps track of all the cast votes. Each individual vote is stored in the database, so it is possible to re-count all the votes, instead of merely tracking the votes with a counter for each candidate. This makes it easier to verify that no voter fraud has occurred, such that there were no duplicate votes or if a vote failed to be cast. Since votes are not placed until they are sent to the server, we can ensure that the server validates the voter's identity and choice to prevent fraud.
While any of the more obvious security concerns of a software application could apply, some of the more domain-specific ones are:
- A single voting server would not be able to handle the load from many votes being placed at once. We would need to use sharding or allow voters to place votes to one of many servers.
- As the number of voting servers increase, it becomes more difficult to ensure that no duplicate votes are placed across servers.
- An attacker could spoof a voting machine's signature over the network and place unauthorised votes.
Blockchain architecture provides great solutions to many of our key problems:
- High volume: Since voting is decentralised, votes can be placed across nodes on the network, without requiring a single central server taking all the load.
- Merkle trees: Can ensure that only the longest chain of verified votes is accepted, making it difficult to place unauthorised votes or to modify a vote that has already been placed.
- Redundancy: There are multiple exact replicas of the voting results, created at the time of voting. It would be necessary to fake a vote on all of the redundant servers.
The original implementation of the Blockchain in Satoshi Nakamoto's Bitcoin used a technique called Proof of Work to add new blocks to the chain. This method requires all miners on the network to solve a difficult mathematical problem for a reward, while also adding all previous transactions to the chain. This can be very intensive, and one of my professors smugly told me that it would cost Rs. 250 to propagate a vote in a PoW blockchain across the nation.
Consensus is the process of making sure that every node can agree on all the votes that have been placed, and that their ledgers are exactly the same and updated. Achieving faster consensus at scale is one of the problems in the spotlight of various ICOs and Cryptocurrency focused startups. This would lead to faster confirmation of transactions which could probably bring us one step closer to the perfect solution. Right now, it takes 15-30 minutes to confirm a Bitcoin transaction, which is a whole half hour of wondering if you sent it to the wrong address, or at least that much time in which the receiving party will have to wait before they can access it. Visa, in comparison, can handle an estimated 24,000 transactions per second. That's more like it.
Delegated Proof of Stake (DPoS) is one of the faster consensus algorithms, as used by the EOS token. They claim to confirm 3,000 transactions a second across 21 'delegated' servers. The catch with Proof of Stake is that EOS doesn't aim to achieve consensus on all available nodes. In each confirmation round (known as an epoch), a random server is chosen to be the 'block producer', the node responsible for creating the new block and sending it to all the other delegates. The block producer then tallies all votes that were placed on it and sends it to every other delegate to confirm it. If any unauthorised node tries to propose a block out of turn, the block is rejected by it's peers since only the chosen delegate for each epoch is allowed to propose a block.
When the network adds a block of votes to the chain, one of the ‘delegates’ is randomly chosen to confirm the validity of the votes that make up the current block. This block is then propagated to all the other delegates to achieve consensus on the votes that have been placed. A malicious actor would have to bypass the voter authentication method and successfully place the invalid vote on the randomly chosen delegate server.
By distributing the vote confirmation effort across multiple delegates, we can evenly spread the load faced during balloting. Through deterministic selection of the block producer in each epoch, we can ensure that the system maintains redundancy in the case of certain delegates experiencing excess load or unexpected failure. In this manner we will design a fault tolerant system that will significantly streamline the balloting process.
I've never really written a piece like this before, and I'm not too sure how to write a conclusion so I'm looking for suggestions and feedback :)
In part 2, we discuss the voting process, including voter authentication, biometric hashing, offline voting.