One of the biggest challenges with on-chain governance is the impact of credible smart-contract based bribes on blockchain voting systems. In general, such a contract would hold a credible commitment of funds, and have a public function that allows users to provide proof that they did the request action and receive payment in a trustless way.
This is a significant issue as it does not require direct or provable interaction between any party involved, and the parties do not need to trust each other. From the perspective of dishonest actors, this solves two common challenges related to taking/offering bribes: Both parties are unsure their counterparty will actually follow through, and the person being bribed is unsure if wether the person bribing them will use the fact that they took a bribe as leverage in the future.
In order to mitigate the issue of “trustless” bribery issues its possible to explore mechanisms which make it difficult or impossible for voters to prove to a smart-contract how they voted.
Such a mechanism would require the following two properties:
- Voters should be confident that their vote was included and tabulated correctly
- Voters must not be able to prove to a smart-contract how they voted
These properties are very difficult to achieve simultaneously, because if a user can publicly verify that their vote was included correctly, then they can generally provide proof to a smart contract how they voted.
Systems that rely on zero-knowledge proofs or ring signatures can provide voters with the option of privacy, but cannot prevent them from proving how they voted if they choose to. Such systems would offer some benefit, in that they force the person taking the bribe to make public information that was previously private, and those users could therefore be punished. However, in order to punish a bad actor they have to have some sort of deposit, and they can generally remove their deposit and only then accept a bribe, so assuming there is some withdrawal period for a stake based system, the punishment can be avoided by waiting until stake has been withdrawn before accepting the bribe.
In an ideal case, the voter would not be able to prove how they voted even by making private information public. One way to accomplish this is by using a Group Signature scheme, combined with a sMPC or a secure enclave acting as a trusted group manager. Projects like Keep and Enigma are actively working on infrastructure to support this type of computation in a secure way.
- Voters are are granted a group signing key
- Voters submit encrypted votes using the group managers public key, and validating with their group signature
- group manager decrypts, validates, and tabulates votes returning only the result.
This mechanism ensures that voters are unable to prove to a smart contract how they voted, unless the group manager is compromised. Users are not able to verify that their vote was included or that the tabulation was correct, but assuming they trust the security of the KEEP/Enigma based group manager then they can be reasonably confident that the operation occurred as expected.
Some possible issues:
- It is unclear what the cost overhead of using something like this or how it scales with group size.
- Since how people voted remains private, mechanism which reward/punish voters based on how they voted become challenging.