DigixDAO Governance Model — Update #7

This governance update is dedicated to discussing the bribery attacks on on-chain voting, and how we plan to deal with them in DigixDAO governance.

Reference article that started our discussion on bribery attacks: http://hackingdistributed.com/2018/07/02/on-chain-vote-buying/

On-chain bribery attack

In any on-chain voting scheme, an attacker can set up a contract that pays bribes to people who vote in his favour. This contract, most of the time, can easily verify the votes and pays bribes in a secure and trustless way.

In DigixDAO, this on-chain bribery attack could take several forms:

• An attacker-proposer sets up a contract to automatically pay bribes to voters if they vote for him and the proposal goes through
• With such a possibility of the above attack, an attacker can even fake a bribery attack by deploying the bribery contract for a proposal that he/she doesn’t like. This can de-legitimize a genuine proposal.

Naive off-chain bribery attack

There can be bribery schemes using off-chain coordination methods, which involve:

• Off-chain methods of keeping track of who participated in the scheme
• Off-chain verification that they indeed voted as instructed
• Off-chain/on-chain sending of the bribes, which could be in different forms, to the vote sellers. This could be done either before or after the voting happens.

However, these schemes require some trust between the vote sellers and vote buyers. If the bribes are sent before voting, the vote buyers need to trust the vote sellers to vote as instructed. Otherwise, the vote sellers need to trust the vote buyers to actually send the bribes.

Off-chain bribery attacks using trusted hardware

With trusted hardwares like Intel SGX, a piece of code can attest to a remote entity that it is indeed a specific piece of code that is running on a trusted hardware and has not been tampered with. This makes it possible for the vote buyers and sellers to coordinate a trustless off-chain bribery scheme by running specific softwares on their machines. For example:

• The vote sellers can run a specialized Ethereum wallet software that can do everything a normal wallet can, except for that it will vote according to the vote buyers.
• The vote buyers can run a specific software that will keep track of which vote sellers have been using the specialized Ethereum wallet software and pays the bribes to them.
• Both the vote buyers and sellers will be able to check that the other party is indeed running the correct software, thanks to remote attestation using the trusted hardwares.

Defense against bribery attacks in DigixDAO

Regarding on-chain bribery contracts, the bribery contract will have to verify that the vote sellers have indeed voted as instructed before paying them the bribes. To do so, the bribery contract would have to read from DigixDAO contracts on how the vote sellers have voted. To stop this kind of on-chain bribery attacks, we will disallow any potentially malicious contracts from reading the votes from DigixDAO contracts. This could be done by a simple whitelist of contracts that are allowed to read votes from DigixDAO contracts. As such, no malicious contract can verify the voter sellers’ votes to pay the bribes.

As for naive off-chain bribery attacks, it is a phenomenon that does not have a fool-proof way to stop. However, it requires much trust among the vote buyers and sellers, which we believe would be difficult to establish over the internet, or even when the parties have real life connections.

Finally, the bribery attacks using trusted hardware is a hard problem with no easy solution. At the very least, it is currently not practical, as the attacker would need a license from Intel to use its trusted hardware. In the future, we could explore the possibility of using trusted hardwares ourselves to run a trusted Ethereum wallet software that would not be able to participate in vote buying and selling.