Where we are
Earlier this year, we published an article in CoinDesk about using crypto to secure our elections. You can read and discuss more on this forum in part 1 and part 2 that go into some detail about how crypto-powered voting would work, and why it would solve many problems that we face today.
A few months ago, Intercoin started building applications and smart contracts on the Ethereum platform. While it’s not scalable enough to power everyday money or massive elections, perhaps Ethereum 2.0 (Serenity) will one day become scalable enough that these smart contracts can see wider adoption, even without having to migrate to the Intercoin back-end platform.
In the meantime, Intercoin is planning to release its own Intercoin App in the app stores, and turn intercoin.org into a web-based portal that will let anyone with a Chrome Extension to deploy the smart contracts we developed, invite friends from their contact list, and manage their community together. We also plan to roll out the Intercoin Crypto Show to teach people more about crypto and smart contracts. In the meantime, if you have questions, feel free to ask them in this forum.
Start of the Art in Crypto Voting
For every technology we use today, there was a time it was laughably inadequate as a replacement for what came before. For decades, chess engines were a mere curiosity, but now a smart phone can beat any grandmaster. The same is now true of voting technology. There have been early experiments in Russia running elections on Ethereum as well as proprietary platforms like Waves. It’s still early, but we will see tremendous growth in the coming years.
What if people could vote securely online? Then they would be able to make decisions collectively about a variety of things. Technology can lower the cost of running a secure election, and make it available to any organization, large or small. But who can vote, and when? How do we know that it will be secure? Below, we explore exactly these issues.
Who Can Vote?
The first step in democratic elections is determining who can vote, and ensuring that everyone has an equal amount of say. There needs to be some process in place to make sure people don’t create multiple identities to cheat the system. This is accomplished by voter registration, which itself has controversial issues like purging inactive voters and disadvantaged voters and other ways of disenfranchising voters from even having their voice heard in the election.
Perhaps one day we will come up with better solutions for voter registration, but – for now – this step will have to be done via some established process that a community has. We have deployed the CommunityContract specifically to give communities the ability to determine who can vote, and who can’t.
When Can They Vote?
In the USA, voting normally takes place on Election Day, the Tuesday after the first Monday in November. Some states allow early voting, so people can cast ballots before Election Day.
Five years ago, I wrote about how polling is better than elections. What I meant is that, expecting the entire population to turn out for an election on a specific day will lead to problems with voter turnout. Having a referendum where only 20% of people vote can cast doubt on the legitimacy of whether the outcome faithfully represents the will of the overall population, or just those who bothered to show up. For example, Puerto Rico voted in 2017 to join the United States by an overwhelming 97%, but that is partly due to a boycott by the opposition, who didn’t show up to vote, resulting in a 22.93% turnout. Opinion polls, on the other hand, show 52% support for joining the United States – a majority to be sure, but nowhere near as overwhelming, and possibly within a margin of error.
Polling vs Elections is less about who can vote, but rather about when. You can have a poll take place over a 5 year period, and in any given window of time, a certain small, random representative sample is able to vote. Any given participant can vote at most once in that rolling window, before it moves on to others. Participants can also fail to cast a vote, which is similar to sitting out an election, but at least timing of the eligibility window would be randomized for everyone, and can be lengthened to several days, removing major impediments to voting. Of course, all these parameters are customizable, and letting 100% of the people vote 100% of the time throughout the poll is just like a regular election.
People without a phone or active notifications would be underrepresented, but presumably, those who opted into elections and polls conducted with digital technology, especially about smart contract issues, would take care to have them turned on.
Selecting Voters
Each block in Ethereum has a hash of all transactions it contains, and it is pretty much impossible to control this hash without controlling a majority of mining power on the network. Moreover, controlling this hash would only allow one to possibly control the outcome of a tiny window in a single given election. A lot of effort resulting in almost no vandalism.
It is possible for smart contracts to use the hashes from previously mined blocks as a “random” seed (better to call “uncontrolled” seed). Based on this seed, we can select members of the voting community who are eligible to vote in any given block, by calling:
eligible(address, blockNumber)
Blocks can go by pretty fast, and someone eligible to vote in block M could be eligible to vote in blocks M+1, M+2, …, M+N. Actually, rather than base it on block number, we use timestamps. That’s because we can’t rely on how quickly blocks will be mined, especially after Ethereum Serenity 2.0 rolls out. Timestamps may sometimes be off by 2 hours or so (if miners are malicious) but this shouldn’t seriously affect the window in a biased way if we’re talking about random samples and polling windows that last several days.
Periodically, the Intercoin app (or another dapp) running on one or more servers somewhere can watch the VotingContract on the blockchain and find out if the user has recently become eligible to vote in the poll. It then sends a notification, sms or email to the user, with a link to the poll. Upon receiving it, the user would typically have a bunch of time to visit the link and cast their vote. Rather than having the smart contract waste gas looping through a ton of previous block hashes and execute the eligible() function, the client dapp interface helpfully submits the blockNumber together with the vote. The smart contract them simply verifies the eligibility before allowing the vote to proceed.
The eligible() function takes into account blockNumber, but also the memberCount from CommunityContract and fraction of them that can vote in any given window. The eligible() function must be continuous in the latter two variables, since e.g. memberCount of a community can change between the time the user learns they can vote, and then when their transaction is finally mined.
What Can They Vote For?
Our VotingContract is designed to be a general-purpose smart contract, to work with many types of elections, referendums, and polls. Those who are eligible to vote will call:
contract VotingContract {
address externalContract;
address externalMethod;
uint fraction; // eligible people to vote in any given window, out of 1e10
uint minimum; // minimum number of eligible people in any window
function vote(VotingData data, uint eligibleBlock) {
if (eligible(msg.sender)
&& !hasVotedSince(msg.sender, eligibleBlock)) {
// valid vote as far as eligibility and voting once
// but external contract might roll back this transaction
// if the vote contains invalid data, for instance
externalContract.call(
abi.encodeWithSignature(
concat(externalMethod, "(uint256,uint256)"),
data
)
);
}
}
}
Here, the VotingData is a struct that can contain arbitrary properties, which are interpreted by the externalMethod of the externalContract, which may choose to rollback() the transaction. It is not the business of VotingContract about how the vote is interpreted. It may be tallied in various ways (First past the post, ranked choice, approval vote) and it may be a vote among two or more candidates (although for more than two, keep in mind Arrow’s Impossibility Theorem). For example, the IncomeContract can use the VotingContract and CommunityContract to allow a community to vote on whether the level of UBI should go up or down by 1%.
Threat Profiles
The set of threat profiles for an election or poll differs from, say, a banking app. Although both require security, in the banking app:
- people are managing relatively large amounts of money which are dear to them, and therefore take care to make sure their transaction was properly executed
- people use the app that the bank releases, cryptographically signs and distributes on the app store or the web through https
- people trust the bank and the bank is prepared to reverse individual transactions through chargebacks and fraud investigations
On the other hand, with a voting app:
- people are casting one vote in a sea of votes, and it won’t harm them much if only their transaction was executed incorrectly, so most won’t check
- if everyone used a particular app to cast their vote, the creator of the app could be compromised, and no one voter would be incentivized to check
- people trust a system consisting of multiple actors, which is not prepared to let only some people recast their votes and not others
The combination of 1 and 2 with voting means that most people won’t bother to check that their vote was properly recorded, and even if they do, they won’t know about everyone else whose vote may have been recorded incorrectly. A malicious actor could create a voting app that a large portion of the community ends up using, and this voting app might switch the vote on the back end. We would not expect Apple to modify their iOS or Google to modify their Chrome browser to rig an election, but when it comes to large national elections, we can never really be sure and we shouldn’t have to give any one vendor that kind of power, anyway.
That’s why casting a vote has to involve at least two, independent apps running on two different computers. A voter would visit a website running on their desktop, say, and scan a QR code with an app on their phone. Both the desktop and the phone should display the same VotingData – for example the same choices for President, Governor, Senators etc. – or one of them is rigged. Only if they match will the transaction be submitted, signed by the voter’s private keys on the two different apps running on two different machines.
The VotingContract therefore would have a whitelist of apps that can sign votes with their private keys, and each vote has to be submitted by at least two of those apps, to count. (More would be better, but we need to balance security with usability for the user, who often has at most two Trusted Computing Environments.)
Security Caveats
It is still possible that two computing environments made by the same company are being used to vote (Safari on Mac, and Safari on iOS, or Google Chrome and Android) but that is the feudal nature of today’s digital society, that we are locked into an oligopoly of Google, Facebook, Microsoft, and are forced to trust them. Having all our legislative and judicial institutions run by two major parties is not much better. If anything, the large corporations have less incentive to put such obvious backdoors in their own products, than the current system of partisan judges and governors working together to gerrymander and suppress votes. Hardly any system is immune to corruption, and REDMAP was sponsored by Walmart, Reynolds American, Pfizer, AT&T, and Citigroup, among others. But presumably, if the whitelisted apps can be audited by any third parties and found to match the compiled open source on github, then the only parties that can hack the election are the makers of the Trusted Computing Environments - the operating system and the hardware. It’s not like that hasn’t happened before.
So perhaps, at the end of the day, the real problem is with the size of the organizations and concentration of power, money and data in the hands of a few elites (large corporations, federal governments, etc.) On the largest and most significant elections, we can never really be sure that some chip maker or OS vendor might not try to sneak in a backdoor for that particular election. But presumably, for the vast majority of elections which are smaller (such as the local chess club), Apple would have no interest in doing that. The risk vs reward would be too great.
Security Improvements
We can improve this solution by requiring everyone (or a certain random sample of people) to view the blockchain using a certain website and “endorse” their vote. The vote wouldn’t count unless it that happened. This “endorsement” step is similar to step #5 in the Intercoin Consensus Process in the design of the Intercoin Platform. Now, to hack the election, someone would have to control:
- The user’s phone operating system and browser
- The user’s laptop operating system and browser
- The gateway from the web site to the blockchain
It’s very unlikely for all combinations of these to be operated by the same company or colluding set of companies, and when people notice a discrepancy, they would have the evidence to prove it (similar to Intercoin’s Proof of Corruption).
Thus we reach the same conclusion as we have already found in all other areas when we analyze the benefits of Intercoin vs Global Consensus. Namely, by decentralizing power, and splitting up the data under the control of any one company, we reduce the incentive to hack the resulting elections.
