# Anti-Collusion Infrastructure RFP

## Introduction

This all originated from a [blog post](https://vitalik.ca/general/2019/04/03/collusion.html) by Vitalik.

Among the Polkadot RFPs, I think this has quite a large potential: Anti-Collusion Infrastructure. It could actually constitute one (or more) PhD thesi(e)s for the size of all the possible deliverables. As Vitalik writes in this post:

> Bribing attacks may sound farfetched (who here has ever accepted a bribe in real life?), but in a mature ecosystem they are much more realistic than they seem.

and the following sounds quite bad, in a future where blockchain voting will have more serious applications:

> In the /r/ethtrader experiment, fear of people coming in and buying donuts to shift governance polls led to the community deciding to make only locked (ie. untradeable) donuts eligible for use in voting. But there's an even cheaper attack than buying donuts (an attack that can be thought of as a kind of obfuscated bribe): renting them.

Donuts are used for governance in that subreddit and are obtained by upvoting, i.e. it's a measure of popularity. so, if you're popular, you have more voting rights.

> If an attacker is already holding ETH, they can use it as collateral on a platform like Compound to take out a loan of some token, giving you the full right to use that token for whatever purpose including participating in votes, and when they're done they simply send the tokens back to the loan contract to get their collateral back - all without having to endure even a second of price exposure to the token that they just used to swing a coin vote, even if the coin vote mechanism includes a time lockup (as eg. Bihu does).

Basically this means mechanisms like those can be manipulated by the wealthier people. Same with AAVE, with Flash loans you could theoretically swing votes on stuff having large collaterals available.

From the RFP:

> The goal of this RFP is to encourage people to try to research and come up with their own solutions or to implement existing solutions, like Minimal anti-collusion infrastructure

This is basically an open-ended research grant, with the potential of gathering expertise to use on other BC projects. Most of the work is intellectual and doesn't require specific programming skills, so it could be done by basically any engineer we have in the company.

## Using government-issued IDs?

We would be bound to centralized entities, and inherit the same issues.

> simply going up to higher-security centralized identity systems, like passports and other government IDs, will not work at scale; in a sufficiently incentivized context, they are very insecure and vulnerable to the issuing governments themselves!

### Proposal: zkSnarked hardware

Identity? Use zkSNARKS with the claim "I own a passport", "I own a bank account"
I own a device! (not related to government)

## problems we are trying to tackle

- an identity-free mechanism that empowers distributed communities cannot avoid over-empowering centralized plutocrats pretending to be distributed communities.

- initial distribution of the key. What happens if a user creates their identity inside a third-party custodial service that then stores the private key and uses it to clandestinely make votes on things?

- good mechanisms for identifying public goods and bads unfortunately cannot be identity-free or collusion-safe. If one tries to preserve the property of a game being identity-free, building a system where identities don't matter and only coins do, there is an impossible tradeoff between either failing to incentivize legitimate public goods or over-subsidizing plutocracy.

- we want an identity that you cannot credibly rent or sell. Obviously, we can't prevent people from making a deal "you send me $50, I'll send you my key", but what we can try to do is prevent such deals from being credible

i.e. We need to unincentivize an eventual "identity-market"

- coin holders and users interests don't always align ([medium blog post](https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca))

## Minimal anti-collusion infrastructure (MACI)

Vitalik [proposed a basic protocol](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) for avoiding collusion. A user under the post summarized it as follow:

>If I understand the problem correctly: you are proposing a scheme where users, identified cryptographically, can vote on something, but are disincentivized from selling their votes to each other (“collusion resistance”).

> If I understand the solution correctly: users are to be indexed, in exchange for a deposit, in a centralized registry operated by a trusted third party, and may update their identity there by providing proof of it. Both updates and votes are sent signed and encrypted to the operator, so no one can enumerate the full history of a user’s actions, even though the user can prove any individual update or vote by producing the corresponding signed message that encrypts to one that has been put on-chain. Therefore, no one can really trust another user they are trying to buy a vote from, who may be hiding the fact that what they are selling is no longer in the registry.

- how MACI works? [youtube link](https://www.youtube.com/watch?v=sKuNj_IQVYI)

## General solution

> In blockchain governance, it seems like this is the only way forward as well. The approach for blockchain governance that I advocate is "multifactorial consensus", where different coordination flags and different mechanisms and groups are polled, and the ultimate decision depends on [the collective result of all of these mechanisms together](https://vitalik.ca/general/2017/12/17/voting.html).

## Clear fund?

[Clr.fund](https://ethresear.ch/t/trust-minimized-quadratic-matching-clr-fund/7352) is a dApp with a minimal trust setup, with the main objective to provide a decentralized and transparent process for assigning grants

## Proposal: quadratic randomized voting

After voting, the chain will randomly sample subsets of a subset of the votes to get a definitive voting percentage. The voting depends up to a cap on the coins one owes. This works for account-based blockchains. for UTxOs-based, a user needs to demonstrate, through transactions, that all accounts with all the value belong to him. Also, before the vote, we have to ensure there is sufficient distribution among addresses/individuals. There are costs to voting: If the vote goes as the user wished, the coins are returned. If the vote goes against, the coin is kept. Voting gives you a discount on all transactions. Coin holders vote per individual, not per address or per coin hold. There should be a minimum of tokens to own to even enter the votation.