In this section, we discuss the difficulties faced while implementing the Open Vote Network on Ethereum.
Lack of support for cryptography.Ethereum supports up to 256-bit unsigned integers. For this reason, we chose to implement the protocol over an elliptic curve instead of a finite field. However, Solidity does not currently support Elliptic Curve cryptography, and we had
6.6 Discussion on Technical Difficulties 87 0 500,000 1,000,000 1,500,000 2,000,000 2,500,000 3,000,000 3,500,000 4,000,000 4,500,000 5,000,000 5 10 15 20 25 30 35 40 45 50 55 60 G as Number of voters Gas Limit
Compute Reconstructed Keys Set Voters as Eligible Compute Tally Begin Registration
Figure 6.3 The gas cost for the election administrator based on the number of voters participating in the election.
to include an external library to perform the computation. Including the library led to our voting contract becoming too large to store on the Blockchain. As previously discussed, we separated the program into two smart contracts: one voting contract and one cryptography contract. The cryptographic computations are expensive and this results in a block only being able to support six voter registrations, or a single vote.
Call stack issues. The call stack of a program has a hard-coded limit of 1024 stack frames. This limits the amount of local memory available, and the number of function calls allowed. These limitations led to difficulty while implementing the 1-out-of-2 ZKP as the temporary variables typically required exceeded the hard-coded limit of 16 local variables [61]. We had to use variables extremely sparingly to ensure that the 1-out-of-2 ZKP could be implemented.
Lack of debugging tools. The Mix IDE that provides a solidity source code debugger has been discountined [37] and could not be used for our work. Remix is the replacement for the Mix IDE and it provides a debugger for contracts at the assembly level, but this is too low for debugging Solidity contracts. Instead, we had to createEvents that log data along with the contract to help with debugging which is incorporated into the contract before deployment.
Mitigate loss of voting key.The voting key is kept secret by the voter and needs to be stored on their local machine. This is important to ensure that if the voter’s web browser crashes or is closed, then the voting key is not lost. We provide a standalone Java program
votingcodes.jarto generate the voting key and store it invotingcodes.txt. The voter is required to upload this file to their web browser.
Maximum number of voters. Figure 6.3 demonstrates the results of our experiment and highlights the breakdown of the election administrator’s gas consumption. Except for opening registration, the gas cost for each task increases linearly with the number of voters. The gas limit for a block was set at 4.7 million gas by the miners before the recent DoS attacks. This means that the smart contract reaches the computation and storage limit if it
88 A Smart Contract for Boardroom Voting with Maximum Voter Privacy
is computing the voter’s reconstructed keys for around sixty registered voters. This limit exists as all keys are computed in a single transaction and the gas used must be less than the block’s gas limit. To avoid reaching this block limit, we currently recommend a safe upper limit of around 50 voters. However, the contract can be modified to perform the processing in batches and allow multiple transactions to complete the task.
6.7
Conclusion
In this chapter, we have presented a smart contract implementation for the Open Vote Network that runs on Ethereum. Our implementation was tested on the official Ethereum test network with forty simulated voters. We have shown that our implementation can be readily used with minimal setup for elections at a cost of $0.73 per voter. The cost can be considered reasonable as this voting protocol provides maximum voter privacy and is publicly verifiable. This is the first implementation of a decentralised internet voting protocol running on a Blockchain. It uses the Ethereum blockchain not just as a public bulletin board, but more importantly, as a platform forconsensus computingthat enforces the correct execution of the voting protocol.
Chapter 7
Conclusion
7.1
Summary
This thesis explored bootstrapping trust from the blockchain in order to build and run cryptographic applications. Remarkably, each application leveraged the blockchain in subtly different ways. We provide a final summary on how the blockchain was used for each cryptographic application before concluding.
Chapters 3 and 4 relied on the blockchain’s immutability for storing information. The former chapter stored each party’s pseudonymous identity in the blockchain to bootstrap authenticated key exchange. We proposed two protocols Diffie-Hellman over Bitcoin and YAK over Bitcoin in response to observing that real-world merchants are unable to correctly re-authenticate customers that used Bitcoin as a payment method. On the other hand, the latter chapter relied on the blockchain for storing transaction information (i.e. origin/recipient of coins). This transaction substantiates the publicly verifiable evidence that is privately exchanged during the revised BIP70: Payment Protocol.
Chapter 5 re-purposed the blockchain to become an arbitrator for dispute resolution. This re-purposing is heralded as a scaling approach for cryptocurrencies. It permits two parties to store a depoist in the blockchain, privately transact (i.e. re-distribute each party’s share of this deposit) and then confirm the aggregation of all payments in a single transaction. If there is a dispute, both parties can submit transactions to the blockchain (i.e. cryptographic evidence) within a grace period, and the blockchain will enforce the correct determination. Remarkably, the only academically published protocol is Duplex Micropayment Channels [33], whereas basic payment channels, Lightning Channels and Hashed Time-Locked Con- tracts are scattered across mailing lists, chat rooms and forums. Unfortunately, this increases the difficulty for researchers to find and comprehend this emerging field’s state-of-the-art.
90 Conclusion
As such, the contribution and motivation for our survey was to concisely summarise payment channel protocols and provide future research directions.
Chapter 6 relied on the blockchain to enforce the cryptographic application’s correct execution using the same consensus protocol that secures the blockchain. This allowed us to demonstrate the first practical implementation of a self-tallying and decentralised internet voting protocol as a smart contract for Ethereum. Most importantly, this research also provided the first empirical study of executing cryptographic protocols on the Ethereum network. This research concluded that the Etheruem network as deployed can support cryptography, but it is not ready for wide-spread use. For example, each encrypted vote in the Open Vote Network required 53% of a block’s capacity which effectively only allows Ethereum to permit one vote every twelve seconds.
To conclude, our research focused on demonstrating the feasibility of running crypto- graphic applications that bootstrap trust from the Blockchain. Both the secure end-to-end communication protocols and the revised Payment Protocol relied on the blockchain’s im- mutability for storing information in order to bootstrapping trust for the protocols. On the other hand, payment networks re-purposed the blockchain to become an arbitrator that could enforce the correct outcome for the protocol based on cryptographic evidence provided by each party. Finally, the Open Vote Network relied on the Blockchain to bootstrap correct enforcement of the protocol and to act as a central bulletin board that provides a consistent view to all overs.