Hey everyone,
This post contains a series of arguments and suggestions aimed at improving Gitcoinâs sybil resistance. It is informed by our own experience and investigation of some of the networks of sybil accounts that have targeted the Gitcoin platform as a whole, and individual grants more specifically.
We have a strong appreciation for how important this problem is because we were recently put in a position where our own motivations were questioned. Our grant was attacked by fraudulent donations and it put us in a position where we had to prove our own innocence. The burden of proof should never be on a victim of an uncontrollable external event they were harmed by.
The first contribution we would like to make is open sourcing a tool for on-chain sybil analysis. Many of the addresses behind the sybil accounts donating to our grant on Gitcoin were conducting most of their activities on Zksync, which is a relatively new L2 with technical properties that can be helpful to malicious actors conducting automated sybil attacks.
This tool helped us aggregate data from different blockchains and analyse them. We hope that it can help others, especially grant owners, that may want to take a proactive role in Gitcoin sybil resistance, by starting with their own grant: GitHub - fileverse/sybil-analysis
We are confident that if we were able to find so many connections between networks of sybil accounts with the limited data and resources we had, these connections will be even clearer using a larger dataset and by crowdsourcing the analysis.
Recommendations:
By analysing our own sybil attackers we were able to discover some important patterns of attack that can be prevented by changing certain verification and account management features on the gitcoin platform. We focus on five areas of intervention:
- Targeting of Grant
- Discovery of Grant
- Automation
- Evolving Sybil Behaviour
[Targeting a Grant] Capping the number of donations that can be made to a particular grant based on the trust score. Eg: Anyone donating more than 10 times to a particular grant should have a trust score of 100+ on the gitcoin passport.
[Targeting a Grant] Allowing grants to flag sybil behaviour on their grant - similar to flag grant function.
[Targeting a Grant] Give grant owners the ability to reject QF matching tied to a specific donorsâ. Because donations come directly to grant addresses, what grant owners can at least do is identify malicious actors and put them in a category of ânot to be counted for QF matchingâ. This is useful on many levels. First, it allows GitcoinDAO to see that a grant being targeted is actively fighting off the attackers. Second, it creates a quick response mechanism that leads to faster identification of attackers and a safer, fairer round. Third, it allows for corroboration to occur. For example, you will be able to see that of the top 10 grantsâ owners, 7 of them have reported at least 60% of the same accounts. Grant owners are the best front line you have, given the appropriate tools, to create a sybil resistant Gitcoin platform.
[Discovery of Grant] For the âtrendingâ category only using the donations made from the users that have a trust score greater than 100.
[Automation] Add some value to the trust score automatically by checking the activity / age of the github account.
[Automation] Add recaptcha score to each transaction made from the gitcoin platform.
[Evolving Sybil Behaviour] Real time sybil flagging engine (see below).
Real Time Sybil Flagging System
This system relies on the assumption that parts of sybil networks are automated systems and exist to manipulate the Gitcoin platform in ways which might not be obvious to someone looking from the outside.
This is an attempt to design an adaptive system that can take advantage of external analysis and FDD teams investigators. Participation from the FDD Team and community members is a very important factor for its success.
In the above graph A and B Node transfer some money to C which then donates that money to some grant.
In our case and of some other grants this pattern was followed:
We analysed donations made to our and othersâ grants and found that the addresses associated with potential sybil accounts were all donating to us by following the same script / pattern of transactions which we describe below:
- Retrieve money from the same bridge.
- Do the similar type of transactions prior to the donation (do some token swaps and/or mint some NFT).
- Donate on low nonce, below nonce 15.
- Donate to one grant only.
- Return the rest of the money back into the bridge.
- Stop all activity once nonce 15 is reached or before.
- Rarely have any activity on the ethereum blockchain.
Finding from this that formed the base of assumption for the proposed system:
- There is always a source of funds in the sybil
- Sybil addresses usually interact with similar services (bridges, mixers, DEX, CEX)
- Sybil usually do txns among their accounts to keep the total cost of doing the sybil attack low
A more proactive system:
- Penalise all the other nodes interacting with the known sybil nodes in realtime
- Penalise all the other nodes using services used by known sybil nodes for cycling of funds. This assumes that there are unique mixers or other smart contracts being used by sybil nodes that would be very unlikely to be used by regular users.
- Take the input from community and FDD team of known sybil accounts in real time
Output of this system is the likelihood with which any given input account is a sybil node. Using sybil node score in real time matching calculation.
How it works:
- Start with a known sybill set that might expand or contract
- Keep a list two sets - one hop, two hop from the sybil set nodes
- Any donation is received by a grant. Get all the nodes that are one hop away from the node. Both in and out txns.
- Check if there are matches in this from the sybil set(1), sybil set hop 1(0.5) and sybil set hop 2(0.25). Depending on the match, add all the values. To get the sybil score
- In this case drop off per hop is ½, and can be tweaked depending on the performance of the system in real time.
- Keep the min and max values of sybil score to map this value on that spectrum and get a percentage. Can use different ways to get the percentage.
If any account doing the donation has a high sybil score above sybil threshold â reduce their impact on the grant donation matching metric calculation.
Areas of Improvement:
- Include hops on different networks for generating one hop and two hop of known sybil set for step 2.
- Include hops on different networks for step 3.
- Tweak the sybil threshold depending on grantâs reputation
- Tweak the sybil threshold depending on rounds progression
- 0.1 on day 1
- 0.2 on day 2
- 0.4 on day 3
- ⌠so on
- FDD keeps adding nodes to sybil set during the round from their independent analysis
- Independent analysis of sybils flagged by the grant and their addition to sybil set
The above system is not a âone stop solutionâ, but a way to increase the attack cost involved with the sybil attacks as we can catch basic patterns from this. In most cases systems get attacked frequently by bots because itâs easy to do so and has low or no penalty.
The parameters should be tweaked to reflect the situation at hand and sophistication of the sybil attackers.
Hope this post is useful to anyone out there trying to solve sybil resistance.