this post is intended to summarize the discussions around privacy and security happenming in fdd, and to stimulate further discussion among the wider community
Gitcoin currently reviews grants and defends against Sybils using a small set of highly trusted reviewers and analysts. However, Gitcoin is undergoing a process of decentralization that relies upon developing composable protocols that can be tuned and deployed by individual grant owners. Instead of being a centralized grant funding platform, Gitcoin will be a funding factory, doing R&D and manufacturing of grant management tools. The aim of this is to empower individual communities to take control of their own grant rounds and configure them to their own needs.
While this decentralized approach has the potential to level up the public goods funding landscape through real community ownership, it is not risk free. It is difficult to open a protocol to honest users without also opening it to adversaries. This post outlines some of the risks decentralization and composability introduce into Sybil defense and grant reviewing, how they are mitigated and what opportunities remain.
What keeps grant owners honest?
Composable, configurable protocols give individual grant owners the power to tune their security to their needs. For example, a grant owner might decide the standard grant eligibility requirements are not fit for purpose for their grant - they have the freedom to amend them to something more fitting. Similarly, they might identify a particular vulnerability in their community to a certain type of Sybil (maybe some subcommunity finds a way to farm certain stamps, for example) and chooses to tune their Sybil defenses to down-regulate those stamps. This flexibility offers great strength because individual grants can defend their specific vulnerabilities rather than relying on generic defenses in a way that is not possible for a centralized system.
On the other hand, what happens if a grant owner chooses to deliberately weaken their own defenses, or is manipulated into doing so?
It is not hard to imagine a scenario where a grant owner is bribed, blackmailed, threatened or otherwise manipulated into allowing Sybil attacks that favour certain projects. There are many versions of this issue - the minimal example being legitimate projects applying some social pressure or subtle social engineering to gain some small edge through tuning the Sybil defenses or grant review configuration. The maximal example is an outright scam project pressuring a grant owner to tune down their defenses sufficiently to enable a pre-prepared Sybil attack that enriches some person or group who then walk away with the funds. Perhaps some certain combination of easily farmable stamps, known to attackers in advance, is given a “free-pass” to non-Sybil status. In effect, migrating to a composable protocol adds some risk in that now not only can adversaries devise new ways to circumvent the rules of the platform, the configuration of the rules themselves becomes a viable attack vector.
The plausible defenses against this include whistleblower rewards or “whitehat” bounty that rewards ethical hacks that are honestly disclosed. Alternatively, some form of heirarchical oversight or retroactive slashing system that requires users to collaterize their good behaviour with something of value (perhaps staked $GTC). The “slashed” funds could be used to reward the whistleblowers. Round manager are very important in this context. Round managers determine eligibility conditions, matching amounts, quadratic funding calculation details, trust scoring weightings etc to provide a configuration that is common across all grants in the round. The grant owners then have tools to fine-tune their security and monitor other grants in their round.
It seems like a combination of all of these might be necessary to strongly disincentivize dishonest behaviour. Perhaps some incentivized inter-grant reviewing could lead to crowd-sourced assurance that security meets some threshold, but it is hard to see how to defend against cartels forming that recycle incentives into payments to mutually turn blind eyes. Whistleblower rewards could be a powerful way to protect against grant-owner dishonesty, but only if the grant owner has something tangible to lose when the whistle is blown on them, and there is no inadvertent incentive to whistleblow on honest actors.
The transition to protocol-based grant-giving brings to mind Kerckoff’s principle that a system should be secure even under the assumption that adversaries have complete knowledge of how it works and its dependencies. In an open-source environment this is a hard requirement as everyone has access to the source code and protocol rules by default. To satisfy this, the protocol must be secured without using secrets or private interactions between trusted individuals, but instead be secure because resilience emerges as a natural consequence of the way the protocol is designed. A composable system might come with security benefits in that each component should be a self-contained package that can be unit tested, pen-tested etc to identify vulnerabilities and fix them quickly. It could be that communities form around each component and domain experts emerge for each composable unit, and continuous testing could be a crowd-sourced effort (maybe even supported by gitcoin grants). On the other hand, integration and system testing can be very difficult because complete coverage of all the various configurations and combinations of composable units is probably out of reach. There are also social factors and vulnerabilities that are hard to test for such as perverse incentives that are not baked into the protocol but emerge from real-world usage, maybe even using apps and social structures emerging on top of the protocol.
Privacy
The model of Sybil defense that is being built for the new composable grant system relies upon users creating a Gitcoin Passport in which stamps are collected and used as evidence of personhood. The idea is that these stamps are sufficiently costly in terms of time, effort and/or money that they are difficult to collect dishonestly and at scale. At the same time, a retrospective machine learning model aims to identify Sybils from their observed behaviours.
Anonymity is difficult to preserve in a system designed to look for evidence of personhood, because it is difficult to distinguish that an individual is a human without also revealing that they are a specific human. Proof of personhood is akin to evidence of uniqueness, and uniqueness is antithetical to anonymity. There is a risk that participation in a Gitcoin grant round could provide a portal into the personhood attached to a specific address. In the original Grants 1.0 system Gitcoin collected user’s email addresses, Github usernames and ip addresses along with their Ethereum address in order to identify Sybil’s. That data could reveal a lot of information about an individual, including their approximate physical location and the projects they had contributed to. In Grants 2.0 this data will no longer be needed because it is replaced by Gitcoin Passport stamps - a more provate way to participate in Gitcoin grant rounds.
At the moment, there are a limited set of credentials that can become Gitcoin Passport stamps (Google, Facebook, BrightID, ENS, Proof-of-Humanity) meaning many users will share the same combination of stamps. This mitigates any doxxing risk. However, when individual communities are able to define their own authenticators the number of potential stamps and therefore their potential possible combinations could explode, creating a scenario where it is possible to “fingerprint” a wallet by its unique combination of credentials. The risk is then that an adversary could track an individuals “participation history” along with the financial history that comes for free on the blockchain. There may be tricky balances to strike between specificity of stamp combinations and privacy, since a tightly defined, specific set of credentials would enable high fidelity community curation but potentially also have a negative externality in the form of fingerprinting.
Passports with stamps are actually just DIDs (Decentralized Identifiers) mapped to a specific wallet address and they are set to expire after a fixed time. The DiDs do not contain any personally identifying informtion whle they exist - they are just an attestation that some truested issuer has observed a connection between an address and some credential of interest. When they expire, the stamp ceases to exist and leaves no trace that could connect the address to the stamp. This means an individual can present their honest credentials to the world when they need to but not have them become indelible tattoos that reveal their past activities to the world. Making passports ephemeral mitigates the problem of unwanted digital footprints.
Personhood <> Projecthood
One way to refactor the protocol in favour of security and privacy is to make projects, rather than grants, a fundamental unit of account. It would be expected that projects request multiple grants and they accrue a legacy of honest activity that benefits them in successive rounds. Project owners are incentivized to act honestly, defend robustly against Sybils, make effective and efficient use of composable grant reviewing tools and build a genuine user base because these factors can influence their reputation. The projecthood score, in turn, lowers the bar of proof required for successive funding because evidence of trustability accrues over time. The concepts developed for individual proof-of-personhood (i.e. stamps associated with an address) can be adapted for proof-of-projecthood. This promotes decentralized quality control for grants and might help stimulate a transition to a more composable, protocol based Gitcoin. It might also address some of the problems discussed earlier related to gameable incentives for grant owners - by making them project owners that accrue reputation and consequently more frictionless access to follow-on funds promotes integrity over the long term. This could be how project owners are incentivized to tune up their own Sybil defenses and review stringency. However, proof-of-projecthood is no silver bullet - there are vulnerabilities that adversaries could feasibly exploit. One example is generating copycat projects - fake projects mirroring the activities of honest projects in order to gather sufficient credentials to successfully attack in some future round. Defining the projecthood criteria might fall into the remit of a round manager.
Attack surface
The transition to a decentralized, protocol-based grant system undoubtedly increases the system complexity and as a result expands the attack surface in ways that might be hard to detect in advance. We already mentioned the potential for composable Sybil defense and grant review configurations to be a new attack vector. There is also the risk of accidentally creating perverse incentives, especially if ideas such as $GTC staking are progressed further. It is hard to be precise about these kinds of risks in advance, especially when the protocol design is not finalized, but one could imagine a system where it might benefit adversaries to act honestly for multiple rounds until they cross some threshold of trust before launching an attack that is then much harder to defend, or perhaps investing in the trustability of individuals until they become grant owners, at which point they can game the protocol’s composability in favour of a certain outcome. The more complex the system becomes the harder it is to anticipate edge cases and close all the possible exploits. It is harder, for a more complex system, to see in advance what unintended consequences might arise. This is especially true for Gitcoin because this is untrodden ground with few analogs to learn from.
The defense against this is basically to do lots of conceptual and numerical modelling in advance to be as well informed as possible, and have a strong social layer backing up the protocol. The counter-argument, of course, is that although new attack vectors may be exposed by the transition from platform to protocol, it is all in the service of closing a critical one: the centralized control over funding distribution that Gitcoin currently relies on.
Unknown unknowns
There is a finite set of vulnerabilties and scenarios that can feasibly be identified and wargamed in advance. Like any software there will be unforeseen issues and potentially zero-day exploits that only come to light once the product is in the wild. In order to safely transition from centralized to decentralized public goods funding there should be an incremental wilding of the protocol that hands control over the protocol to the community incrementally - for example, it might be prudent to maintain some degree of centralized control over the source code for the composable tools until they have been deployed and demonstrated to be running well, in case a rapid response to a bug or exploit is required.
Summary/outlook
The transition to Grants 2.0 - a composable, protocol for community ownersip of Gitcoin grants - is a huge opportunity to level up public goods funding in web3. However, this large upgrade brings with it a new set of attack vectors and privacy concerns that must be mitigated. Overall, increased security and privacy are the likely outcomes from the transition thanks to the removal of data from the protocol through the integration of Gitcoin Passport.