A Smart Contract for Boardroom Voting with Maximum Voter Privacy
2017 Mccorry, P., Shahandashti, S. F., & Hao, F. (n.d.).
Introduction
-
There already exist proposals to use a Blockchain for e-voting
-
These solutions achieve voter privacy with the involvement of a trusted authority
-
-
We show that the voter’s privacy does not need to rely on a central authority
-
decouple the voter’s real world identity from their voting key
-
votes can be counted without the cooperation of a central authority
-
Introduction
-
To date, both Bitcoin and Ethereum have inherent scalability issues
-
cannot readily support storing the data or enforcing the voting protocol’s execution for national scale elections
-
- => we chose a boardroom election over the Blockchain which involves a small group of voters (i.e. 40 participants)
Introduction
-
Contributions
-
provide the first implementation of a decentralised and self-tallying internet voting protocol
-
provides maximum voter privacy as an individual vote can only be revealed by a full-collusion attack
-
all voting data is publicly available
-
allows the tally to be computed without requiring a tallying authority
-
Drawback of self tallying
-
self-tallying protocols have a fairness drawback
-
adaptive issue
-
knowledge of the tally can potentially influence how the last voter casts their vote
-
-
abortive issue
-
if the final voter is dissatisfied with the tally, they can abort without casting their vote
-
-
Structure of Implementation
-
Open Vote Network base
-
two smart contracts
-
voting contract
-
ZKP for secret key
-
-
cryptography contract
-
ZKP for showing that vote is 0/1
-
-
-
assume that voters and admin have their own Ethereum accounts
Election Stages
Setup
-
admin
-
update the list of eligible voters
-
set election timer
-
begin registration, begin election, ...
-
-
set deposit \(d\)
-
mesures for abortive issue
-
-
set voting question
-
Signup
voter 1
voter 2
voter n
\(g^{x_1}\), \(ZKP(x_1), d\)
\(g^{x_n}\), \(ZKP(x_n),d\)
\(g^{x_2}\), \(ZKP(x_2),d\)
Ethreum
Signup
- computing each voter's reconstructed key
\(g^{y_i} = \sum_{j=1}^{i-1}g^{x_j} / \sum_{j=i+1}^{n}g^{x_j}\)
- e.g) n=5
- \(g^{y_3} = (g^{x_1}*g^{x_2}) / (g^{x_4}*g^{x_5})\)
Commit(optional)
- public hash value of vote to the Ethereum
- The contract automatically transitions to the VOTE stage once the final commitment is accepted into the Blockchain
- mesures for adaptive issue
- The contract automatically transitions to the VOTE stage once the final commitment is accepted into the Blockchain
Vote
voter 1
voter 2
voter n
\(g^{x_1y_1}g^{v_1}\), \(ZKP(v_1)\)
Ethreum
\(g^{x_2y_2}g^{v_2}\), \(ZKP(v_2)\)
\(g^{x_ny_n}g^{v_n}\), \(ZKP(v_n)\)
The deposit \(d\) is refunded to the voter
when their vote is accepted by Ethereum
Vote
mapping (uint => Voter) public voters;
// Given the 1 out of 2 ZKP - record the users vote!
function submitVote(uint[4] params, uint[2] y, uint[2] a1, uint[2] b1, uint[2] a2, uint[2] b2) inState(State.VOTE) returns (bool) {
uint c = addressid[msg.sender];
// Make sure the sender can vote, and hasn't already voted.
if(registered[msg.sender] && !votecast[msg.sender]) {
// OPTIONAL Phase: Voters need to commit to their vote in advance.
// Time to verify if this vote matches the voter's previous commitment.
if(commitmentphase) {
// Voter has previously committed to the entire zero knowledge proof...
bytes32 h = sha3(msg.sender, params, voters[c].registeredkey, voters[c].reconstructedkey, y, a1, b1, a2, b2);
// No point verifying the ZKP if it doesn't match the voter's commitment.
if(voters[c].commitment != h) {
return false;
}
}
// Verify the ZKP for the vote being cast
if(verify1outof2ZKP(params, y, a1, b1, a2, b2)) {
voters[c].vote[0] = y[0];
voters[c].vote[1] = y[1];
votecast[msg.sender] = true;
totalvoted += 1;
// Refund the sender their ether..
// Voter has finished their part of the protocol...
uint refund = refunds[msg.sender];
refunds[msg.sender] = 0;
// We can still fail... Safety first.
// If failed... voter can call withdrawRefund()
// to collect their money once the election has finished.
if (!msg.sender.send(refund)) {
refunds[msg.sender] = refund;
}
return true;
}
}
// Either vote has already been cast, or ZKP verification failed.
return false;
}Tally
-
compute the product of all vote \(\prod_ig^{x_iy_i}g^{v_i} = g^{\sum_iv_i}\)
-
brute forces the discrete logarithm of the result to find the number of yes votes
-
Attack and trust assumption
-
no coercion-resistance
-
replay attack resistance
-
Ethereum will not accept ZKP if msg.sender does not match the account that is calling the contract
-
Attack and trust assumption
-
An election admin is required
-
smart contracts cannot execute code without the notification of an external user-controlled account
-
-
All voters need to download the full Ethereum blockchain
-
In the future, voters will be able to use the Light Ethereum Subprotocol
-
In LES, not be required to store the full Blockchain
-
-
Cost Analysis
-
40 participants 126 transactions
-
Ethereum block's capacity is approximately 4.7 million gas
-
=> V: Register 16%, V: Vote 52%
-
Register <= 6, Vote <= 1 per block
-
-
Cost Analysis
-
election administrator’s cost increases linearly based on the number of voters
-
voter’s cost remains constant
Time Analysis
-
Running the code on the voter’s local daemon is significantly slower than using OpenSSL
-
due to the lack of native support for elliptic curve math in Ethereum smart contracts
-
Technical Difficulties
- Because of Gas Limit maximum number of voters is 60
Future work
- investigate the feasibility of running a national-scale election over the Blockchain
- Allow more than just "yes" or "no" as voting options
A Smart Contract for Boardroom Voting with Maximum Voter Privacy
By mmnk
