In July, Phil Daian, Tyler Kell, Ian Miers, and Ari Juels, all of Cornell University, published an exploratory blog post describing the risks and promise of blockchain voting. The post described blockchain, and EDCCs (also known as smart contracts) specifically, as just the type of technology that e-voting research has sought for decades. However, in the next breath they presented a well-known problem:
"Unfortunately, smart contracts aren't just good for running elections. They're also good for buying them."
They went on to illuminate three possible means by which vote-buying could take place under current circumstances:
- Simple vote-buying contracts that would allow people to pay others for proving they voted a certain way. This method is the least concerning of the three because it would be relatively easy to determine how many votes were bought.
- Trusted hardware that a vote buyer can use to force another into a certain vote. Currently, the primary manufacturer of this hardware is Intel, which calls it SGX. The researchers predict other companies will produce similar products at some point. Using this hardware, voters "can be bribed to put/generate their keys in an SGX enclave that only allows them to vote in certain ways." In a vote-buying situation, this would work by "simply allow[ing] users to prove they are running a vote buyer's malicious wallet code in exchange for a payment, secured on both sides by [trusted hardware]." This is more concerning because, at the time of writing, the authors referred to this type of attack as "irresolvable."
- Hidden trusted hardware cartels (dark DAOs). This type of vote-buying attack presents the highest degree of risk, because it combines the former attack with the idea of a dark DAO, "spawning a trustless organization whose goal centers on manipulating cryptocurrency votes." Under this scheme, voters and vote buyers alike may not know how many users are participating in the system. That's problematic because "if small users believe their vote doesn't matter, they are likely to take the payoff with no perceived marginal downside." The authors wrote that a dark DAO could be used to delegitimize the outcome of an election.
For some time now, these threats have remained unsolved. Now, Daian, Miers, and Juels, along with fellow Cornell researcher Oded Naor, have released an exploratory proposal for bribery-resistance in blockchain voting. But there's a major caveat. It relies on a trusted third party, which they admit is a major assumption. The proposal, then, both elaborates on the potential solution and asks the question, "Are these assumptions acceptable for blockchain based voting?"
The method the researchers come up with utilizes the very technology which makes such effective bribery possible in the first place. But instead of allowing a voter to generate and possess their own key, which they could then sell to a vote buyer with an SGX enclave, all voters would enter a designated enclave, allowing it to generate their keys. Voters continue to use the SGX enclave as they register to vote. The authors write that the SGX "protocol provides privacy and integrity, but not coercion resistance." This makes the trusted hardware great for voter registration, but not a good way to actually vote.
Once users have allowed the trusted hardware to generate their key and register to vote, they could still sell their vote. To protect against this concern, the Cornell team suggests an already known method where voters could submit unlimited votes, but only one would be genuine. The genuine vote would only be determinable by a trusted election authority (EA). In this way, voters would be free to sell their votes, but the vote-buyer could never know whether the voter truly voted in accordance to the buyer's wishes. This would make blockchain voting as bribery-proof as your standard off-chain US government-style election. Technically, you can allow someone to buy your vote in a US election – it's just difficult to prove that you voted as you were paid to.
Juels described to ETHNews what happens after password generation through the SGX enclave:
"Voter registration is done in an anonymous way using trusted hardware (SGX). A voter registers by anonymously placing the equivalent of an encrypted password on chain along with an anonymous attestation that: (1) The voter is entitled to vote and (2) The registration is unique and thus the voter can't vote twice. There should be no linkage visible even to the EA between passwords and user identities."
After voters register, they cast votes in an anonymous channel, like Tor. To vote, participants submit a ciphertext, their preference (e.g., candidate name or the initiative they approve), and a zero-knowledge proof. Juels told ETHNews what happens next:
"When a vote comes in, the EA matches the password proffered with the vote against those in the list. All of this is done blindly, but if the EA's private key leaks, then the passwords will be visible. Because votes are sent through an anonymous channel, however, the votes of individual users remain private to the EA even if the passwords themselves are visible to the EA."
Note that the votes of the users remain private to the EA. However, if the private key is leaked, "the vote buyer can ask a particular user to provide her vote for inspection non-anonymously before it is submitted. The vote-buyer can check whether this vote contains a valid password, i.e., is legitimate, and pay only if it is." In other words, if the EA is to collude with a vote buyer, then they can rig the election. Juels went on to say that "there is probably fundamentally no way to protect against such behavior without trusted hardware and a program that permits only limited execution."
When all's said and done, this strategy requires a fair amount of trust: It requires that voters trust the SGX enclave that generates their passwords and oversees their registration; it also requires that voters trust the EA's will and ability to protect the private key from vote buyers. The researchers are not vague about this; the entire purpose of the post is to ask the community whether or not these terms are acceptable.
The methods described in the post will likely evolve following community feedback and collaboration. Juels told ETHNews that the team is still in the process of writing a more formal paper.