TL:DR - Clr.fund uses attack-resistant methods to create a way to allocate funding for public goods projects in the Ethereum ecosystem. It’s coming soon.
Originally posted on Max Goodman's Blog, 22 June 2020.
This post explains clr.fund technical terms for engineers seeking a better understanding of quadratic funding, quadratic voting, zk-SNARKs, and MACI. In this post, I’ll explain what clr.fund is, then I’ll go into why clr.fund instead of traditional sources of funding, as well as tackle the top relevant attacks to a protocol like clr.fund.
In my second post (coming soon!), I’ll explain exactly how clr.fund works under the hood, step by step, with MACI.
What is Clr.fund?
Clr.fund is creating a protocol for funding public goods projects in the Ethereum ecosystem. Using a combination of quadratic funding, zk-SNARKs, MACI, sybil resistance, and more, it aims to provide better, less biased funding for these public goods projects in Ethereum. In other words, it sorts the signal vs. the noise in public goods funding in the Ethereum ecosystem by allowing the strength of preferences to be heard by individual community members at aggregate.
Compared to traditional grants available (say by the Ethereum Foundation or Consensys) -- clr.fund is more accessible, has a quicker turn around between voting/allocating funding quadratically to projects and also receiving funding as a project. The cons of traditional grant funding can best be explained by Colony:
“These [traditional grants] programs, while not ineffective, do have some shortcomings: they centralize decision-making power in a small grants committee; they are not self-perpetuating and require ongoing administration on the part of the protocol; they provide only a finite amount of funding to execute on a specific project: essentially a large bounty, not sustainable income, so the incentive to maximize the utility of the application is limited.” (Kronovet, Fischer, and du Rose 2018).
Compared to Gitcoin — Clr.fund is more attack-resistant.
In the past, attempts at quadratic funding have been more vulnerable to attacks, specifically collusion,sybil attacks/sockpuppet attack, bribery, and many other attacks (Kronovet, Fischer, du Rose 2018). Using 1 person 1 vote (1p1v), people have not been able to signal the strength of their preferences to do with different project funding. Clr.fund seeks to solve for all of these issues by creating a protocol that is attack-resistant and has more effective voting and funding mechanisms (quadratic voting/quadratic funding). In other words, the deserving projects get the funds as allocated by the Ethereum community in a timely fashion.
What exactly are the top attacks?
There are a variety of attacks relevant to peer to peer, permissionless, and decentralized applications, but we will focus on the main three that are particular threats to clr.fund: sybil attacks, bribery, and collusion.
A Sybil Attack is "an attack orchestrated by creating multiple identities and using them to gain undue influence" (Wikipedia). This is a problem because clr.fund could get multiple users swinging the quadratic funding in one way or another so as to destroy the equitable notion of quadratic funding: to allocate funding to public goods projects that deserve it. So, sybil resistance is a prevention of these attacks by proof of uniqueness of each account. In Clr.fund, BrightID is used for sybil resistance by providing proof of unique identities.
For more detailed information on Sybil attacks, see also FlatOutCrypto.
Bribery is when someone is given money to do something illegal or unethical or exercise undue influence. In clr.fund, the only foreseeable way for bribery to happen is for the coordinator of the funding round to be bribed. While the members of the community voting to allocate the funding do not have access to any of the messages for voting and cannot decrypt them, the coordinator can, which is where discretion needs to be in place. To counter this, clr.fund coordinators must be trustworthy by the community.
Collusion as defined by Wikipedia is essentially a secret agreement to coordinate in order to deceive others. It is currently in the works as to how to protect against all collusion, however clr.fund protects users from coercion and bribery by using MACI. MACI (Minimum Anti-Collusion Infrastructure) will be explained in the upcoming "Part Two: Main Mechanisms".
For more information on Collusion, check out:
Buterin, Hitzig, and Weyl 2018 Section: 5.2 Collusion and deterrence.