Preamble
This is a knowledge transfer post. With my recent disaffiliation from leadership in GitcoinDAO, I would like to pass along knowledge I have ascertained from 2.5 years of watching Gitcoin Grants grow. This post is a data point for the DAO, whose governance structures continue to retain full control & have final say of how to design Gitcoin Passport.
TLDR
As Daniel Schmachtenberger likes to say, “A Problem Well-Stated is Half-Solved”.
In this post I will try to articulate what I have seen and convey my limited but earnest view on the design space of sybil resistance as it pertains to Gitcoin & the web3 ecosystem.
In this post, I make these assertions:
- Sybil resistance is an important problem to address.
- Sybil resistance is an adversarial game.
- Sybil resistance is an iterative game.
- Sybil resistance is an evolutionary game.
- Sybil resistance is an infinite evolutionary iterative game between a diversity of adversaries.
- What are the criteria for addressing sybil resistance?
This post is a 13 minute read.
Table of Contents
- TLDR
- Wait, what are sybil attacks?
- The high upside of addressing this problem space.
- Meet your adversaries
- Criteria for desirable approaches to this problem.
- Criteria 0: The complexity of large social systems
- Criteria 1: The need for privacy-centricity & sovereignty
- Criteria 2: The need to avoid plutocracy
- Criteria 3: Collusion
- Criteria 4: The need to build in systemic defensibility
- Criteria 5: The need to build network effects
- Criteria 6: Enabling Innovation & Preventing Capture with Modularity & Forkability
- Criteria 7: Enabling Innovation & Preventing Capture with Decentralization
- Criteria 8: The evolutionary nature of this game
- What will round 69 look like?
- In closing
Wait, what are sybil attacks?
Many systems that aim to democratically decide outcomes, like Gitcoin Grants, assume each participant is a unique human.
This makes them vulnerable to sybil attacks, where a bad actor creates a large number of pseudonymous identities to subvert the service’s reputation system and gain a disproportionate amount of influence.
Sybil attacks undermine the legitimacy of blockchain-based democratic pluralistic processes. Learn more about sybil attacks here.
The high upside of addressing this problem space.
GitcoinDAO’s impact on the world depends on the success of Gitcoin Grants, which depends on Quadratic Funding, which depends on sybil/fraud resistance.
Without sybil resistance, Gitcoin Grants is a castle in the sky. Sybil resistance is the bedrock of Gitcoin Grant’s legitimacy & the lack of a solid foundational understanding of the problem is a constraint on it’s growth.
But the stakes are larger than GitcoinDAO.
Sybil attacks are why we can’t have nice things. Right now, the DAO ecosystem is built around one-token-one-vote or one-cpu-one-vote schemes. If sybil resistance was addressed, the ecosystem could move to systems built more on one-human-one-vote.
Addressing sybil resistance is very desirable if we want web3 systems that provide utility to everyday citizens of the world, not just the moneyed elite.
Addressing sybil resistance unlocks use cases like:
- quadratic funding
- quadratic voting
- Gini coefficient measurements
- UBI
- one-person-one-vote DAOs
- data collectives
- sybil resistant airdrops
-
- other use cases we haven’t discovered yet!
Meet your adversaries
Script Kiddies
Petty Criminals
Rational Economic Actors
Solana DEFI Developers
Organized Crime
Nation States
Criteria for desirable approaches to this problem.
Criteria 0: The complexity of large social systems
There are different sophistication levels for each of these adversaries. A script kiddie may lack the skills, organization, and conviction to pull off a sophisticated attack, whereas organized crime & nation states may have nearly infinite budgets, skills, organization, and conviction to attack a system. More sophisticated adversaries will grow & evolve over time, which requires either (1) constant vigilance or (2) systemic anti-fragility on behalf of DAOs that function as digital identity providers.
Adversaries have different motivations. Some adversaries may be in it for the money. Some are in it for the lolz. Some are in it to help you, some are in it to pwn you. Some are just bored and seeking a thrill.
Different adversaries may attempt attacks that are diverse from one another. Some adversaries may pursue schemes that are invulnerable to biometric identity + government identity countermeasures, but are vulnerable to timing-attack countermeasures. Other adversaries may try things that are invulnerable to web of trust and presence based countermeasures, but vulnerable to biometric countermeasures.
Because of the varying types of adversaries, the most comprehensively anti-fragile approach to sybil/fraud resistance will aggregate different types of countermeasures.
(A good guy aggreagting countermeasuroooooors)
Because we’ve read Impact Networks, we know that networks are good at sensing & responding to complex environments. Because of the complexity of the problem, a network is a better institution to address the problem than a company could be.
(Lessons from Impact Networks)
Criteria 1: The need for privacy-centricity & sovereignty
On challenge with building a system that can address sybil attacks is to manage identity information. Identity information is essential to identifying sybil attackers.
But there are countervailing forces to the need for identity.
In a world where control of data is a liability, any designer of said system must avoid becoming a data honeypot - lest it become a headline one day, or worse, silently drift into becoming a deep-state style intelligence agency.
Another requirement of web3 based DID systems is to make them sovereign to their users (eg users can own/manage/delete their data) and privacy preserving. Eg when a dapp discovers whether a user is a unique user or not, they should not find out more information about the user than that without express consent.
Criteria 2: The need to avoid plutocracy
Sybil resistance is a spectrum, from protecting against script kiddies to protecting against nation states.
One metric that has been kicked around to manage this is the idea of a TrustBonus. Basically you just amplify or dampen quadratic matching according to some percentage. Eg a user with
- 100% trustbonus + $100 in matching will be able to allocate $100 in matching
- 50% trustbonus + $100 in matching will be able to allocate $50 in matching
- 150% trustbonus + $100 in matching will be able to allocate $150 in matching
- And so on……
I was there in rounds 4-6 when Gitcoin first started introducing SMS verification and later bright. I know how duct taped together that conception of sybil resistance was 2 years ago. I’m glad it has evolved but I think TrustBonuses are outliving their usefulness.
One reason i have such an aversion to continuing to talk about this as a TrustBonus is that its a legacy concept from the cGrants days that only applies to QF products (other sybil resistant dapps wont have trust bonuses since they don’t have quadratic matches).
OK, but what next?
One way of moving to a more manageable metric is moving to the idea of a Personhood Score = cost of forgery = the cost in USD it would take to forge a users identity. For a system wide KPI, that would make TCF = Total Cost of Forgery in the system, the ultimate KPI that the DAO shoots for to bootstrap a sybil resistant economy.
As the personhood score for a passport grows, it becomes more resistant to certain types of adversaries. Here is a rough estimate of personhood scores by adversary sophistication level:
Cost of forgery is built by connecting multiple stamps. A very rudimentary example:
- If a user connects twitter (+ gitcoin governance decides twitter has a $.10 cost of forgery)
- and a user connects POH (+ gitcoin governance decides POH has a $100 cost of forgery)
- and a user connects brightID (+ gitcoin governance decides brightid has a $10 cost of forgery)
- then the total cost of forgery for that users identity is $110.10
Cost of forgery is how value is transmitted around the ecosystem of Passport users. If I am designing a dapp, and I know the cost of forgery for this user is $110.10, I can rationally reward the user with up to $110.10 worth of sybil resistant rewards.
So in the case of gitcoin, it can give $110.10 worth of matching. Rabbithole (if it integrates with Passport) can give $110.10 worth of rewards. POAP (if it integrates with Passport) can give $110.10 worth of POAP gas fees, and so on
The key insight behind personhood scores is that in an adversarial world there are different levels of sophistication of adversaries Gitcoin wants to protect against (script kiddies => organized crime => nation states). Instead of treating sybil resistance as a binary (yes/no), we instead treat sybil resistance as a spectrum, making the problem more manageable.
Conceptually, you can back into PersonhoodScores with the current architecture of TrustBonus, eg your trust bonus * your matching amount = current dollars at risk.
IMO cGrants is architected backwards. It makes more sense to start with the personhood score + guide the user to either increasing it or muting their contributions by computing their trustbonus.
I wrote more about this here.
The Problem with Plutocracy
This brings me to the one major problem with PersonhoodScores. It puts the sybil resistance in economic terms. If designers of the sybil resistant game are not careful, this could give the system very dystopian attributes.
If the TCF (Total Cost of Forgery) of the system is put into parity with the amount of capital in the system, then only rich people can have identities, that is dystopian
If there is not a way for everyday citizens to reliably create a high enough personhood score without having money, that is dystopian.
For this reason, it could be important to prioritize verification mechanisms that don’t filter out citizens without wealth. It could be important to track the number of moneyed identities active in the system vs non-monied identities. Such examples of these systems: BrightID, Proof of Humanity, biometric identification systems. (You can learn more about this problem here)
Criteria 3: Collusion
Say that you’ve architected the perfect sybil resistant identity system.
Or a good enough system. A good enough IMO is a system where the TCF (Total cost of forgery) is greater than the amount of rewards that is available to citizens of the system to exploit it.
So a good enough sybil resistant identity system is one where
- there is $3,000,000 TCF and there is a $2,999,999 matching pool.
- Or, in a world where passport is implemented by multiple dApps, there is $3,000,000 TCF and there is a $2,999,999 aggregate economic opportunity across all of those dapps.
- Or, perhaps the DAOI decides it is willing to accept a 10% fraud risk, so when it has a $3,000,000 TCF, it supports a $3,299,999 aggregate economic opportunity across all of the dapps in Passport-ecosystem.
In this scenario, you still have to deal with collusion attacks. Stuff like “Hey if you contribute to my grant I’ll give you a bribe.” or “I’ll buy your identity from you”.
Really a good enough system is one where The TCB (Total cost of bribery) + TCF (Total cost of forgery) is greater than the amount of rewards that is available to citizens of the system to exploit it.
The bribery/collusion attack surface area is still under research, and deserves its own post.
Criteria 4: The need to build in systemic defensibility
One of the things I find most inspiring about how Proof of Stake and Proof of Work are designed is how well they function by acknowledging that adversaries exist + fundamentally tilt the design of the system towards defensibility and anti-fragility. Both PoW/Pow, they both boil down to the simple principle of making a system much cheaper to defend than to attack.
- In PoW, it is way more profitable (and way less risky) to use my mining hardware to mine the next block than it is to try and 51% attack the network.
- In PoS, it is way more profitable (and way less risky) to use my mining hardware to mine the next block than it is to try and 51% attack the network.
This leads me to the following criteria: In Gitcoin Passport, it should be way more profitable (and way less risky) to participate in the network legitimately than to attack the network.
Criteria 5: The need to build network effects
If you build the most perfect sybil resistant ecosystem, and no one is there to use it, does it make a sound?
This is called the cold start problem in n-sided networks.
The flywheel of passport could grow like this: The more users use Gitcoin Passport, the more the TCF of Passport increases, the more dApps/stamps will integrate with it, the more utility it will provide, which causes more users to use it (and the cycle repeats).
How does one cold start this network? With Gitcoin Grants scale.
With the right configuration - as this flywheel spins, because networks fundamentally grow exponentially, TCF should start to grow exponentially. Here is an example of one such model of how this could grow (this is an illustration + not a promise of any sort):
Learn more about the network effects of the Gitcoin ecosystem here.
Criteria 6: Enabling Innovation & Preventing Capture with Modularity & Forkability
One thing I think is really important about Gitcoin Passport is how forkable it is.
Don’t agree with Gitcoin’s (stamps|scoring algorithm|focus on sybil resistance). Fork it! Create your own. Over time, one could build a marketplace of stamping tools, scoring algorithms around Gitcoin Passport. Such a rich ecosystem is the foundation of the network effects of Decentralized Society.
Forkability requires great documentation and a great devrel campaign. I’ll be curious to see what evolves here. Let me know if the DAO wants an intro to anyone I know who does DevRel!
A great devrel campaign enables decentralized innovation on top of the Passport Protocol. It invites contributions from everywhere and turns Passport into a schelling point for addressing sybil resistance & creating plural cooperation across social distance that grows stronger over time.
A great devrel campaign would be an attractor that would act as a memetic schelling point for people who want to solve this problem + enable them to contribute their resources (coding skills, capital, anti fraud data analysis, etc) to solving the problem.
If done right, this memetic schelling point could even increase in “gravity” over time as more resources are added to it, compounding in strength over time.
Criteria 7: Enabling Innovation & Preventing Capture with Decentralization
As Gitcoin Progressively decentralizes over time, I think itll move from centralization to a decentralized and modular set of protocol based codebases.
It will move from socialware to trustware.
- “Socialware - Mechanisms that create assurances through human relationships, incurring a high social coordination cost”
- “Trustware - Mechanisms that create assurances through technology, incurring a low social coordination cost”
- “By using blockchains as our underlying assurance mechanism, we can codify organizational governance through code and not purely documented principles that rely on humans to coordinate around. In doing so, we foster greater trust between parties by minimizing trust in people and maximizing trust in technology.”
I think that Gitcoin’s final form could be that of a Hyperstructure. Hyperstructures are crypto protocols that can run for free and forever, without maintenance, interruption or intermediaries… The trustware in the center is the hyperstructure (blue). The rest of the things the push the network effects forwards are just humans doing whats rational / in their incentive set (purple). In a well designed system this hyperstructure will grow according to network effects (on the right)
On tradeoff I think is interesting to manage here is the time preference of the systems ability to manage attacks.
How can the base of the protocol harden (bc its trustware), but also evolve to continuously ongoing threats (socialware well governed)? Where are yearly, quarterly, weekly, daily, or instant feedback incorporated? Where is more governance oversight needed over socialware, and where can the system move to trustware? And on what time preference? As the attackers evolve, how can the fraud defense evolve (0) effectively (1) without tipping off the attackers (2) but still in a legitimate (eg transparent to governance) way?
Which brings me to…
Criteria 8: The evolutionary nature of this game
Gall’s Law states that all complex systems that work evolved from simpler systems that worked.
With Gitcoin Grants, the simple rules are the rules of Quadratic Funding. Basically.
- Funds are continuously raised into a matching pool.
- For 2 weeks every quarter, there will be a matching campaign where contributions from the crowd to grants in matching rounds n1-x that fill eligibility criteria ec[n] will be matched with funds from matching pool m[n] according to the pairwse quadratic funding formula with sybil resistant identity mechanisms i1-x.
- Every quarter,
- Gitcoin’s governance structure creates consensus about how to evolve each of these rules & mechanism, & the evolves.
- The ecosystems taste in projects evolves
- Adversaries that want to capture the matching funds evolve.
These simple rules have evolved Gitcoin Grants from:
Round 1 in Q1 2019 - 200(ish) Contributions - $38k raised
(economic contribution graph - round 1 - each contribution is an edge + each grant/user is a node)
Round 14 in June 2022 - 100k+ contributions + $5mm raised
(economic contribution graph - round 14 - each contribution is an edge + each grant/user is a node)
The emergent, iterative, evolutionary, zero sum game between the red team & blue team
The primary stated goal of Gitcoin Grants has been fund public goods. But if you look at it from a certain angle, because Gitcoin Grants requires sybil resistance, every Gitcoin Grants round is actually a giant red team / blue team exercise for battle testing Digitally Native Sybil Resistance technologies.
I believe that accepting the iterative, evolutionary, and zero sum nature of this aspect of the grants rounds is key to designing a manageable way of addressing the problem.
Gitcoin’s sybil resistance will evolve as the attackers evolve. It is important to embrace this as an evolutionary game and recognize that the ecosystem is fluid, adversaries will come and go (and possibly get more advanced).
What will round 69 look like?
IMO the north star is to build a system that:
- Is anti-fragile to many types of attackoooors.
- Is privacy preserving & respecting of the users sovereignty
- Avoids plutocracy/dystopic outcomes
- Avoids collusion
- Is systemically anti-fragile because its cheaper to defend than it is to attack.
- Has network effects
- Enables Innovation
- Prevents Capture
- Embraces the evolutionary nature of this problem
In closing
In this post, I made these assertions:
- Sybil resistance is an important problem to address.
- Sybil resistance is an adversarial game.
- Sybil resistance is an iterative game.
- Sybil resistance is an evolutionary game.
- Sybil resistance is an infinite evolutionary iterative game between a diversity of adversaries.
- What are the criteria for addressing sybil resistance?
Thanks for reading to the end.
If you want to follow my continued research efforts on these subjects checkout season 2 of the Greenpill podcast which is all about the subject of digital identity & sybil resistance.
I hope this knowledge transfer post was a valuable data point for you, DAO citizens.
Thank you to @DisruptionJoe @kevin.olsen, Takuya Kitagawa, Razvan, Carl Cervone, @GTChase, @brent @erich + countless others for proofreading earlier drafts of this post. I welcome feedback/comments below.
…
. Ie we are well suited to be great at devrel++
