Blockchain seems like the perfect technology for online voting. They can act as "bulletin boards," the global ledgers that have been hypothesized (but never realized) in decades of electronic voting research. Even better, the blockchain enables smart contracts that autonomously enforce on-chain elections and exclude electoral bodies.
But unfortunately, smart contracts are not only suitable for elections, but also create good conditions for bribery and vote-buying. In this blog post, we explain how and why.
As a case study, we present a fully implemented simple vote-buying attack against the popular on-chain CarbonVote system. We'll also discuss how trusted hardware enables stronger bribery techniques that seem intractable even with state-of-the-art encrypted voting protocols.
Finally, we introduce a new form of attack called Dark DAO (Dark DAO, Decentralized Dark Organization), not to be confused with "Dark DAO", just like DAO should not be confused with The DAO. A DarkDAO is a decentralized cartel that opaquely (aka "in the dark") buys tickets on-chain. We propose a specific implementation based on Intel SGX.
In such an attack, it is possible that no one, not even the creator of the DAO, can determine the number of participants in the DAO, the total amount of funds committed to the attack, or the exact logic of the attack: for example, a dark DAO could attack a token project such as Tezos, secretly Collect its tokens until it reaches some hidden threshold, then tell its members to short. Dark DAOs like this also have the unique ability to enforce information asymmetry by sending, for example, deniable short notices: members within the cartel will be able to verify short signals, but themselves can generate false signals that appear to be genuine and send to outsider.
The existence of trust-minimized ticket buying and dark DAO primitives means that all on-chain voting users are vulnerable to restraint, manipulation and control by plutocrats and coercive forces. This directly means that all on-chain voting schemes inherently degenerate into plutocracy if users can generate their own keys outside of a trusted environment. This model is generally considered to be inferior to the democratic model, and this agreement tries to approach the democratic model on the chain.
secondary title
Blockchain Voting Mechanisms Today
Blockchain voting schemes abound these days. Votem is an end-to-end verifiable voting scheme that allows voting using mobile devices and utilizes the blockchain as a place to securely publish and tally election results. The popular smart contract IDE Remix provides an election management smart contract as its training example.
On-chain voting faces many challenges, including privacy, latency, and scaling. None of this is unique to the voting mechanism itself, and all of these are ultimately surmountable. And vote bribery is another matter.
Buying votes is a pervasive and corrosive form of electoral fraud in the political system, with a long history of undermining electoral integrity around the world. Sometimes, the cost of bribes is as little as a glass of beer. Thankfully, as scholars have observed, normal market mechanisms often break down in ticket buying for three reasons. First, buying a ticket is a crime in most cases. In the United States, this carries penalties under federal law. Second, it is difficult to enforce compliance where secret voting is used. Voters can ostensibly accept your bribe (simply drink your beer) and secretly vote however they like. Third, even if voters do sell their votes, there is no guarantee that the other side will pay.
No such barriers arise in a blockchain system. Buying markets can be efficiently run using the same powerful election management tool: smart contracts. As always, pseudonyms and jurisdictional complexities offer (some) safeguards against prosecution.
In general, electronic voting schemes are in some ways more difficult to prevent fraud than in-person voting, and have been the subject of academic interest for many years. A fundamental building block introduced early on by David Chaum is to provide an anonymous mixing network for messages that can be sent anonymously by participants and receive contained receipts. Such end-to-end verifiable voting systems, where users can check that their votes were counted correctly without sacrificing privacy, are not only the domain of theorists, but have actually been used in binding elections.
Later work by Benaloh and Tuinstra called electronic voting schemes into question, noting that they provided voters with a "receipt" that provided cryptographic proof of how a given vote was cast. This would allow extremely efficient bribery and coercion, clearly undesirable properties. The authors define a new property, receipt freedom, to describe voting schemes for which such cryptographic proofs are impossible. Further work by Juels, Catalano, and Jakobsson modeled stronger coercion opponents, showing that even a no-receipt scheme is insufficient to prevent coercion and vote-buying. This work defines a new security definition for voting schemes, called "coercive resistance," providing a protocol in which malicious parties cannot successfully coerce users in a way that could alter election outcomes.
In their work, Juels et al. state that "the security of our construction relies on... the generation of key pairs by trusted third parties, or, on interactive, computationally secure key generation protocol". this kind"Trusted Key Generation"、"or"or"trusted settings"The assumption of is standard in the academic literature on duress-resistant voting schemes. Unfortunately, these requirements do not translate into a permissionless model where nodes can go back and forth at any time without prior knowledge of each other. This (to some extent) naturally means that users generate their own keys in all such deployed systems, and cannot take advantage of trusted multi-party key generation or any centralized arbiter of key services.
Today's blockchain space, with predictable results, continues its tradition of ignoring decades of research in favor of implementing the most naive form of voting: an upstart calculation of token-weighted votes directly, stored in plain text on the chain. Unfortunately, it is unclear whether voting better than this tyranny can be achieved on-chain. We show that the permissionless model is fundamentally bad for voting. Despite any identity-based or second-layer mitigation attempts, all permissionless voting systems (or schemes that allow users to generate their own keys in a distrusted environment) are vulnerable to the same style of ticket-buying and duress attacks. Many vote-buying attacks can also be used for coercion, tying users to specific voting choices by force.
"Your voting on this chain is very good..."
secondary title
Different features of the attack
Consider a very simple voting scheme: a token holder gets one vote for every token they hold, and can keep changing their votes until a certain ending block number. We'll use this simple "EZVote" scheme to build our intuition on how our attack would work in any on-chain voting mechanism.
There are several possible escalation attacks for this scheme.
(1) Simple smart contract
The simplest low-coordination attack on an on-chain voting system involves buying a smart contract. Such a smart contract would simply pay the user a fee based on a provable vote on an option (or participation in the vote, or abstention if the vote was not anonymous). In EZVote, a smart contract can be a simple contract that holds your ERC20 past the end date, votes for it, and returns it to you; all guarantees in the contract can be enforced by the underlying blockchain.
The advantage of this scheme is that it only requires the trust assumptions already inherent in the underlying system, but it also has significant disadvantages. On the one hand, it would be possible to make public how many votes were bought after the election, as this is necessary to handle the flow of payments in today's smart contract systems. Additionally, the platform-nature nature of bribery exposes it to scrutiny by parties interested in maintaining the health of the underlying platform/system.
Depending on the voting scheme and the nature of the underlying protocol, there may be some workarounds for these shortcomings. For example, a voter could provide a ring signature to a vote buyer proving that they were on the list of voters who voted yes in exchange for payment. We leave the implementation details and generality of these schemes open.
In general, any mechanism used for private smart contracts can also be used for private vote purchases, addressing the public nature of smart contract-based attacks; cryptographically, the equivalent is that vote buyers and sellers generate together via MPC for fund storage key, which signs two transactions: the one that approves the vote and releases the funds to the vote seller after the interval ends. Vote sellers will only transfer funds to that key if they have a transaction that guarantees refunds and payments.
secondary title
Trusted Hardware Buys
A more worrisome vote-buying attack scenario involves the use of trusted hardware, such as Intel SGX. Such hardware has a key feature called remote attestation. Essentially, if Alice and Bob communicate over the Internet, the trusted computing enabled by SGX allows Alice to prove to Bob that she is running a certain piece of code.
Trusted hardware is often seen as a way of proving that the code you're running isn't malicious: for example, it's used in DRM to prove that users won't copy files that are only temporarily licensed to them, like movies. Instead, we will use trusted hardware to tie down cryptocurrency users, pay them, or force them to use cryptocurrency wallets based on trusted hardware that provably limits the space for their permissible behavior (for example, by forcing them not to vote in elections) Vote in some way) or allow bribers to trust minimal but limited use of user keys (e.g. a vote buyer can force a user to sign "I voted A", but cannot steal or spend the user's money).
The easiest way to use such technology for vote buying is to simply allow the user to prove that they are running the vote buyer's malicious wallet code in exchange for payment, with both parties protected by remote authentication technology.
The easiest way to use such technology for bribery is to allow users to prove that they are running a vote buyer's malicious wallet code in exchange for payment, with both parties protected by remote authentication technology.
In our "EZVote" example, the user simply uses a cryptocurrency wallet loaded on the Intel SGX, and runs the vote-buying program. SGX will assure users that the wallet will never steal users' money (unless Intel colludes with vote buyers). Users can prove to use the wallet to do everything they can do with a regular Ethereum wallet, including transferring their money out (although they won't get paid in this case). Users run their own wallets and do not need to trust a third party to control or secure their funds. Users may not even need to trust Intel or trusted hardware vendors to keep their funds safe, since they can compile their own wallets!
secondary title
Hidden Trusted Hardware Cartel (Dark DAO)
An even more worrisome attack emerges when trusted hardware is combined with the DAO philosophy, resulting in a trustless organization with the goal of manipulating cryptocurrency votes.
An example of a basic dark DAO
The diagram above outlines one possible architecture. Buyouts will support the DAO by running a network of SGX enclaves, which themselves execute the consensus protocol (shown here as dark clouds to indicate that they are not visible from the outside). Users will communicate with this enclave network and provide proof that they are running a "buy bribe" (for example) Ethereum wallet with a current balance of X coins. This "evil wallet" proves to run the attack code that the briber pays for, and the briber proves that they run code that guarantees payment to the user at the end of the attack (possibly in conjunction with a smart contract based protocol, cryptoeconomically energized and honesty).
The briber can track the total amount of funds committed to voting through the system, using SGX's built-in privacy features to hide this fact from the outside world. Users can earn provable payouts by participating in such a system, enabling an all-or-nothing settlement-like property on a SGX-based decentralized exchange. Buyouts gain provable guarantees that clients will never issue votes that contradict their desired voting policy.
What makes such an organization dark is that the bribers don't need to reveal to anyone (possibly even themselves) how many users are participating in the system. The system could simply accumulate users, paying users for running the attacker's custom wallet software, until a certain threshold (such as coins held by such software) is reached that activates the attack; try. Even more damaging, any small user has a clear personal incentive to join the system. If small users think their votes don't matter, they may be rewarded with no perceived marginal downside. This is especially true in on-chain voting, where turnout has been empirically observed to be extremely low. Users who do not vote may be ideal targets for selling votes.
Dark DAO operators can further muddy the waters by launching attacks on options that bribers actually oppose as potential false flagging operations or smear campaigns; for example, Bob could run a Dark DAO that favors Alice so that Bob thinks he is Legitimize election results that could fail. Activation thresholds, payment schedules, overall attack strategies, number of users in the system, total amount committed to the system, etc. can all be kept private or selectively or globally disclosed, allowing such DAOs to eventually adjust for structured incentive changes.
Because the group exists off-chain, the cartel of block producers or other system participants cannot detect, censor, or prevent attacks.
secondary title
Attacks on Classical Schemes: CarbonVote and EIP999
To demonstrate the effectiveness of these vote-buying strategies, we first look at governance-critical cointoss performed in existing cryptocurrency systems. Perhaps the most important such vote is the DAO CarbonVote. The operation of this vote is simple: the account transfers money to one address to vote yes, and the other to vote no. Each address is a contract that records votes for a given address. The CarbonVote frontend then counts the votes and displays the net balance of all accounts that voted yes and/or no. Later votes supersede earlier votes, allowing users to change their minds. At the close of voting, a snapshot of support was taken and used to gauge community sentiment. This voting method is reused for other contentious ecosystem issues, including EIP-186.
One possible trust-minimized vote-buying smart contract in this framework involves the use of escrow; users send ether to an ERC20 token contract, which holds ether until the vote closes. For every ETH they deposit, users will receive 1 VOTECOIN.
The contract is pre-programmed to vote yes at the end of the vote, holding 100% of the user's ether. After voting, each VOTECOIN token is fully refundable to the original Ethereum that created it. Users get back their original ether, along with any bribes vote buyers wished to pay them for this service.
We have implemented a full open source proof of concept of such a contract, enabling any vote buyer to contribute funds to the contract's BRIBEPOOL. Users can pay from BRIBEPOOL by temporarily locking their Ether in the contract, and can withdraw 100% of the Ether at the end of the target voting. Attacks can be paid upfront from BRIBEPOOL to vote sellers (votes are guaranteed once they lock up tokens), over time as a dividend, or both.
Buy the voting code for the Ethereum smart contract for DAO Carbonvote
Users can also sell their VOTECOIN after locking their Ether, essentially making VOTECOIN a tokenized vote-buying derivative. Vote sellers can then immediately offload any risk associated with locked funds to parties indifferent to the outcome of the vote: since every ERC20 is programmatically guaranteed to eventually receive all of the original ETH, this essentially translates from an underlying asset to a dedicated Derivative assets for voting in a predefined way. Buyers who are not interested in voting results should always lock up their ETH if non-negative returns are guaranteed, and essentially have the option to unload later to other buyers who are also not interested. If BRIBEPOOL dividends are paid over time to VOTECOIN in addition to being paid up front, these derivative tokens can even be used to speculate on the success of the attack itself.
This smart contract can be simplified by using an oracle such as Town Crier (it is also possible to combine multiple oracles, prediction markets, etc.). Because the CarbonVote system publishes the results including the full voter log on Etherscan, it is relatively simple to check how someone voted using any external web scraping oracle, and pay if the vote contained in the final snapshot matches the buyer's preferences .
A Dark DAO-like model can also be easily used. Each user only needs to run one wallet, and sometime after each transfer transaction, it also votes in the desired way on CarbonVote (in fact this may become standard behavior for many wallets). Users are only paid if such votes are registered, so users are incentivized to ensure that this voting transaction is included on-chain. The network cannot determine how many votes in a given CarbonVote were generated by such vote-buying cartels, and how many were legitimate.
Inherent in any of these schemes is the ability to minimize trust when pooling assets to multiple vote buyers; a bribe smart contract could simply allow anyone to pay BRIBEPOOL, and the SGX network could similarly Open to participation.
Some schemes, such as EIP999 voting, have more serious problems. In these schemes, if a user votes twice, the later vote is chosen. A simple yet serious attack is to simply collect user signatures for "yes" and "no" votes, spam the selected signatures at the end of the election period, and rely on overwhelming the blockchain's ability to ensure a majority of this Class ballots last. Alternatively, since the contract deployer is able to vote for all funds in a given contract, another attack is to simply force users to use a contract-based wallet during voting, deployed by a briber, who can then arbitrarily control all funds locked in Voting rights over funds in a contract without the need for custody of those funds.
secondary title
Beyond Voting - Attacking Consensus
Astute readers may point out that all permissionless blockchains essentially rely on some form of permissionless voting, the consensus algorithm itself. Every time a blockchain reaches global consensus on some property of state, what happens is essentially a permissionless (usually coin- or PoW-weighted) vote in a permissionless setup.
In these cases, it's perhaps not surprising that "buying" has been explored a bit. For example, smart contracts on Ethereum can be used to attack Ethereum and other blockchains through censorship, revision of history, or incentivizing empty blocks. This attack works directly on the proof-of-work vote itself, bribing miners based on their weighted work. There is little reason to believe that proof-of-stake systems will be immune to similar attacks, especially in the presence of complex delegated voting structures whose incentives may be unclear and whose formal analysis may be incomplete or non-existent.
A disturbing concept related to our exploration of a Dark DAO for buying votes is what we call a "Fishy DAO", named after the classic Flash game. In this (super fun!) game, you start out as a small fish. The rules are simple; you can eat smaller rival fish, but not fish that are the same or bigger than you. You grow a little bigger after each meal until you eventually (if you're lucky) grow to dominate the ocean. A modern analog that doesn't require Flash and adds networking is agar.io.
Just like Fishy, but small fish can ally with big fish too!
Fishy DAO will use the aforementioned Dark DAO-like technology to do the same for the blockchain. Using SGX, Fishy DAO members can receive a non-transferable (DAO members can verify message authenticity, but non-members cannot tell if a message is forged) notification when an attack threshold is reached, allowing them to short money markets shortly before such an attack occurs. Every blockchain Fishy DAO attack generates some profit for Fishy DAO, and even the failed attacks come with the ensuing publicity that makes Fishy DAO notorious for being profit-seeking but possibly unethical (in some frameworks) . If Fishy DAO fails to meet the required threshold, Fishy DAO simply disappears and refunds its participants, possibly but not necessarily burning some of their money to incentivize them to recruit participation.
secondary title
other applications
Note that the impact of Dark DAO goes far beyond the above. For example, one Dark DAO aims to buy users' Basic Income status at a profit, paid upfront for a small fee to get users' regular Basic Income payments. Or a Dark DAO by renting (with minimal trust constraints) such keys from creditworthy users to pass credit checks based on key-based identities. Or a Dark DAO running an evil mining pool that could prove to attack an ASIC-based proof-of-work cryptocurrency with a potentially undetectable, unstoppable attack pool size.
It is also conceivable that with identity, the identity system itself might have social security against purchases. For example, some identity systems may allow users to be physically present to revoke or manage identities, which may socially circumvent automated technical protections against identity theft. There is still a way around this problem: the classic solution for loans is through collateral. Potential "guarantors" like businesses can also provide social repayment guarantees to users who cannot afford collateral through physical/legal intimidation and contracts. If this permissionless system of basic income were deployed alongside the current market system, payday loan and bail bond agencies would be a perfect fit for this type of business, at least in the US (and in many other places, there may be less popular ones.) Agencies are willing to step in to make appropriate cuts).
secondary title
core insight
Maybe you're an academic looking at this article, or an interested user wondering what it all means. Some interesting and quite surprising insights can be gleaned from our above thought experiment (see references).
Permissionless electronic voting *requires* trusted hardware. Perhaps the most surprising result was this. In any model where users are able to generate their own keys (required for the "permissionless" model), low-coordination bribing attacks are inherently possible using trusted hardware, as described above. The only defense is more trusted hardware: knowing that a user has access to their own key material (and thus cannot be coerced or bribed) requires assurance that the user has seen their key. Trusted hardware can do this through trusted hardware token setup channels (similar to how governments use e-voting for democracy) or through an SGX-based system that guarantees that any voter has their key material revealed to them whatever operating system is running. This essentially implements the kind of trusted setup/generation assumptions that academic e-voting schemes have used for years. Obviously, in the presence of trusted hardware, such an assumption is required for any voting, and in the absence of this assumption, it can be shown that votes can be bought/sold/bribed/coerced with low friction, which is a surprising As a result, there are serious implications for on-chain voting.
There is a lot of room for voting and coordination mechanisms, and they are poorly understood. Explored with concrete examples of how this is done, such as smart contract voting and voting changes on Ethereum, it becomes clear that broad design decisions fundamentally change the incentive structure of voting mechanisms (we explore these in Appendix A below. ). These mechanisms are extremely complex, and their incentive structures can be changed through other coordination mechanisms such as smart contracts and trusted hardware-based DAOs. The properties of these mechanisms, especially when multiple such mechanisms interact or are actively attacked by resource actors, are poorly understood. Such mechanisms should not be used for direct on-chain decision making in the short term
The same class of vote-buying attacks applies to any identity system. These attacks are not just for votes. Imagine an identity system that entitles users to a weekly paid basic income. I could simply pay cash up front to buy your status and thus a share of income for the next year, which I should do if my time value of money is lower than yours (as wealth asymmetry usually implies ). This is true of any system involving identity: with relatively low levels of trust, the behavior of user identities can be constrained, and such constraints can be bought and sold on the open market. This has serious and fundamental implications for the robustness of any on-chain economic mechanism with a permissionless identity component.
On-chain voting essentially degenerates into plutocracy. Voting and democracy fundamentally rely on secret ballot assumptions and an identity infrastructure that exists only in the physical world (meatspace). These assumptions do not carry over to the blockchain, making the same technology fundamentally broken in a permissionless model. As long as users can generate their own keys (see above), external, even trusted identity systems cannot solve this problem.
Governance based on hard forks provides users with the only exit from this plutocratic rule. Given the above, a natural question to ask is whether we have reached the era of plutocracy. The answer is "probably not". There is evidence that the ad-hoc, informal, fork-based governance models that govern blockchains like Bitcoin and Ethereum actually provide strong user rights protections. In this model, any escalation must offer users an active choice, with groups of users able to opt out if they disagree with the rule change. On-chain voting, on the other hand, creates a natural default that, especially when combined with inattentive or indifferent users, creates strong anti-fork inertia.
Multiple blockchain interactions break incentive compatibility across all chains. Importantly and critically, the Fishy DAO-style attack we explore demonstrates the ability of multiple competing blockchains to fundamentally affect the internal balance of all such chains. For example, in a world where there is only one smart contract system, Ethereum, internal incentives may lead to a stable equilibrium. With two players, and the weaker ones are incentivized to launch bribery attacks to destroy their rivals, the balance can be upset, shifted and disrupted. A key and surprisingly open area of research is modeling the macroeconomics of competition between blockchains, gaining insight into exactly how this internal equilibrium fails. We intuit that ~ identifying critical black swan events currently lurks in the complexities of blockchain governance and interoperability.
in conclusion
in conclusion
The trend of on-chain voting in the blockchain is inspired by humanity's long tradition of voting and democracy. Unfortunately, the protections we have available in the real world, such as enforcing private/rejectable voting, approximate identity control, and attribution of widespread fraud, are simply not available in a permissionless model. On-chain voting does not provide any anti-coercion guarantees to users when using their own generated public keys. Well-crafted voting schemes do little to quell (and, in many cases, indeed exacerbate) the problem. On-chain voting schemes further complicate incentives, creating unstable and chaotic incentives that can be changed at any time through trustless smart contracts or Dark DAO-style vote-buying, bribery and mourning schemes.
We encourage the community to be highly skeptical of the outcome of any on-chain vote, especially since on-chain voting becomes an important part of blockchain system decision-making. The space for devising mechanisms that enable new forms of abuse with lower coordination costs than ever before favors voting should be used for signaling rather than decision-making positions, and a wide variety of voting mechanisms should fill these roles. Without such safeguards, all on-chain voting systems still risk degenerating into plutocracy through direct voting and participation purchases, or even vote tokenization.
thank you
thank you
We would like to thank Patrick McCorry for his helpful and comprehensive feedback throughout the life of this post, as well as for his pioneering work on vote buying and on-chain voting systems.
secondary title
Appendix A - Differentiation Metrics for On-Chain Voting
We noticed several different differentiating factors in the on-chain voting system:
Vote Changing Capability: If users are unable to change their votes, any method that provides cryptographically checked receipts can be used to buy tickets for ordinary votes. Smart contracts can simply bribe users upfront to get their votes, which can never be changed now. However, most schemes allow users to change or withdraw their votes, which means that bribery requires some continuous time component (or takes place after a voting snapshot is taken). Payouts that grow exponentially over time offer an interesting solution to deter coin movement and encourage long-term signaling, while payout bonuses on vote completion are a tool potential vote buyers can use when users are allowed to change When voting, it can be used to create a viable vote-buying program.
Smart Contracts/Delegated Voting: Who gets to vote for funds stored in a smart contract? This is an open issue that plagued the existing design; the original CarbonVote allowed any contract that could call a function to vote and then change its mind. The EIP999 vote allows contract deployers to vote on behalf of the contract, a decision widely criticized as designed to influence the outcome of the vote. However, neither design seems ideal. In fact, intuitively, it seems difficult for a single design to fairly capture all the nuances of custody in smart contracts: smart contracts holding funds can range from simple multi-signature accounts to ones with their own revenue streams and inter-contract finances Complex decentralized organization of relationships. Which of these tokens have voting rights, and how to fairly distribute those rights, remain completely unexplored philosophical requirements for building a fair on-chain voting system. Forcing contract authors to provide explicit functionality may also not be sufficient, as the need for this functionality may change in the future without backwards compatibility (via chain voting or forking).
Deniability/Provability: All of the schemes explored in this article have features that make them particularly suitable for ticket buying: they provide voters with some form of trust-minimized cryptographic proof, either via an on-chain log, a secure web interface, or a smart The state of the contract. Such schemes are particularly vulnerable to bribery because they allow smart contract-style logic to easily verify votes. Some traditional electronic voting schemes in the academic literature offer a property known as coercion resistance. In these schemes, users can change their minds after coercion using the keys they used to vote, and votes do not belong to individual users. In general, the privacy concerns associated with voting with any type of long-term identity, especially those holding tokens, are serious. Such concerns would completely disqualify any serious voting system in the real world, and probably should disqualify all thoughtful on-chain voting design criteria.
