Gavin Wood: How to prevent Sybil attacks and conduct effective airdrops?

Speech: Gavin Wood

Gavin has been paying attention to the issue of civil resistance recently. PolkaWorld reviewed Dr. Gavin Wood’s keynote speech at Polkadot Decoded 2024 and wanted to explore some of Gavin’s insights on how to prevent civil resistance.

What is a Sybil Attack?

As you may know, I have been working on some projects. I am writing gray papers, focusing on the JAM project, and doing some code work in this direction. In fact, in the past two years, I have been thinking about a very critical problem, which is very important in this field, that is, how to prevent Sybil attacks (civil resistance). This problem is everywhere. Blockchain systems are based on game theory, and when analyzing games, we usually need to limit the number of participants or manage the arbitrariness that participants may show.

When we design digital systems, we very much want to be able to determine whether a particular endpoint — a digital endpoint, that is — is operated by a human. I want to be clear up front that I am not talking about identity here. Identity is certainly important, but it is not about determining the specific identity of a particular endpoint in the real world, but about distinguishing between this device and a device that is currently operated by a human. Beyond that, there is an additional question: if the device is indeed operated by a human, can we provide a pseudonym for this person so that they can be identified in a specific context and if they interact with us again using this device in the future, we can recognize them again.

As the way we interact gradually shifts from primarily communicating with other people (like the 1980s when I was born) to interacting with systems, these types of digital systems, especially decentralized Web3 systems, become increasingly important. In the 1980s, people primarily communicated directly with one another; by the 1990s, we began interacting with services over the phone, such as phone banking. This was a big change for us, and while originally phone banking just consisted of a lot of manually operated call centers where we talked to people over the phone, eventually those systems evolved into the automated voice systems that they have today. With the development of the Internet, this kind of human interaction has become less and less, and we almost no longer interact directly with humans in daily services. Of course, this trend has become even more pronounced with the rise of Web2 e-commerce. And Web3 solidifies this even further - in Web3, you barely interact with humans anymore. The core idea of ​​Web3 is to let you interact with machines, and even allow machines to interact with each other.

What is the significance of studying witch attacks?

So what is the point of this? It’s a fundamental element of any real society and is at the heart of many of our social systems, including commerce, governance, voting, opinion aggregation, and more. All of these rely heavily on the ability to prevent Sybil attacks to build community. Many of the mechanisms we take for granted in business are actually based on the assumption of Sybil prevention. Whether it’s fair use, noise control, or community management, they are all built on the basis of this defense. Many things require us to confirm that an entity is a real human being. If someone behaves inappropriately, we may want to temporarily exclude them from the community. You can see this phenomenon in digital services, and of course, in the real world as well.

By preventing Sybil attacks, we can introduce some mechanisms to constrain behavior without setting entry barriers or sacrificing the accessibility of the system. For example, there are two basic ways to incentivize behavior. One is a "carrot and stick" strategy (i.e. a reward and punishment mechanism). The stick (punishment) approach is to require you to pay a deposit, and if you behave improperly, the deposit will be confiscated. Staking is such a simple example. The carrot (reward) approach is to assume that you will behave well, and if you do not meet expectations, we will deprive you of some rights. This is actually the basic operation of most civil societies.

However, this approach cannot really be implemented without Sybil-proof mechanisms on the blockchain. In civil society, such mechanisms work because once someone is incarcerated, they cannot commit the same crime again, at least not while they are incarcerated. Freedom is inherent, and in principle governments can take it away. I am not saying to jail anyone on-chain, but I am saying that similar constraints are currently impossible to implement on-chain. This makes it difficult to disincentivize bad behavior by providing free services, rather than just encouraging good behavior. Commerce and promotion activities rely heavily on being able to confirm that the person transacting is a real person.

This is a screenshot of a website I use occasionally. This is a very good whisky that many people love very much and is very hard to get in its country of origin. It is relatively cheap to get in Europe, but it looks like they keep the price low by limiting the amount an individual can buy. However, this operation would be almost impossible in a true Web3 system.

There are also great difficulties with community building, airdrops, and identifying and distributing community members. In general, airdrops are very inefficient in terms of capital expenditures, because the goal of airdrops is to reach as many people as possible. When airdropping, to effectively achieve fair distribution, you need to first identify individuals and then give everyone the same amount. But in practice, there are various problems, such as different wallet balances. You can end up in a situation where the distribution curve becomes very unbalanced and shows a huge difference. As a result, most people are barely incentivized enough.

Regarding the issue of "fair and reasonable use", although the impact is smaller now, if you use too much network resources, the system will usually just slow you down, although you can still continue to use the network.

Back in the day, about 10 to 15 years ago, if you were using too much internet, the ISP would think you weren't using the unlimited service properly. So, they would basically shut down your service completely, instead of just slowing down your speed like they do now. This allowed them to provide nearly unlimited internet service to most users, because they could identify users to tell who was using the service properly.

One of the foundations of Web2 is the advanced service model, which relies heavily on the ability to identify users. More than 20 years ago, the user identification mechanism might not have been so complicated, but now the situation is very different. If you want to open an account, there are usually more than three mechanisms to confirm whether you are a real individual and whether they have not seen a user before. For example, if you try to register an Apple account without buying an iPhone, it is like a hurdle, and these companies are basically unwilling to give you an account. Of course, they advertise that you can get an account for free, but I don’t know what the AI ​​in the background is doing. It took me 10 attempts before I finally succeeded. In the end, I still had to buy an iPhone.

I think if we could better identify individuals, a lot of processes like "Oracleization" would become easier.

A classic example of using Sybil-proof "proof of humanity" to verify information in society is the jury system. When we need an impartial judge (i.e., Oracle) to decide whether someone is guilty or not, the system randomly selects an odd number of ordinary people from society to listen to the evidence and make a verdict. Similarly, in other areas of social life, such as representation and opinion gathering, representation is an important part of society, and we manage representation through Sybil-proof means. Of course, due to the current imperfect civic infrastructure, this management method is often not ideal, especially when representation is confused with identity. Many times, when you want to vote, you need to prove your true identity, such as showing a driver's license or passport. But in fact, voting represents a part of your voting rights, rather than directly linking this vote to your personal identity.

How to prevent Sybil attacks? What are the current solutions?

So, how should this be done?

In Web 2 and before Web 2, there were many ways to implement authentication. In today's Web 2 systems, these methods are often used in combination. For example, if you want to create a new Google account, you may need to pass a verification code, and perform email and SMS verification. Sometimes, SMS verification can replace talking to a real person. If you have ever been locked out of your Amazon account, you know what I mean. It's basically a complicated maze game until you find the right buttons and phone options to finally be able to talk to a real customer service. For more complex anti-sybil attacks, we might use information like ID or credit card.

However, as we enter the world of Web 3, my research has not revealed any perfect solution that really satisfies me. There are some candidates now, but they vary greatly in three aspects: whether they are decentralized, whether they protect privacy, and whether they are truly resilient (i.e., resistant to attacks).

Resilience is becoming a bigger and bigger issue. In fact, most systems face both problems.

There is a system that I call the "common confession system," where you give away your privacy to a particular authority, and that authority has information about you that you might not want to share with others. For example, you might scan your passport and submit it to an authority, and then that authority has everyone's passport information, and is in a powerful position because they have all this information. The common confession system is not suitable for Web3.

Additionally, you sometimes see personalized systems like Web3 that rely on a "common key management authority." There is an authority that has the power to decide who is a legitimate individual by holding the keys. In other words, this authority has the power to decide who can be considered a "real user" in the system. Sometimes, these authorities even keep the keys for users, but more often, they simply retain the power to decide who is a legitimate individual.

These all rely on centralized authorities to control user privacy or identity information, which is contrary to the concept of Web 3 decentralization and user autonomy.

Putting something on-chain does not make it Web3. You can take a Web2 policy or one that relies on a centralized authority and simply move it on-chain, but doing so does not change the policy itself. It just means that the policy may be more resilient to execution, but the policy itself is still not Web3. Just because a name is a long hex string does not mean it is necessarily private. If specific measures are not taken, such a string can still be linked to real-world identity information.

If a system relies on common "confession mechanisms", it is not a privacy-preserving solution. We have seen too many data breaches to understand that simply putting data behind a corporate file wall or in some trusted hardware is not safe. A personalized solution suitable for Web3 does not require local individual identity or local community membership, but global individual identity, which are completely different concepts.

There are some systems that try to solve this problem, but they rely on a single piece of hardware and a common key management authority, so they are not true Web3 solutions. For example, the Worldcoin project attempts to solve this problem through trusted hardware, but it uses a unified key management authority and a centralized data source, so it is not very consistent with the decentralized concept of Web3.

Another example is Gitcoin Passport, which is widely used in the Ethereum community and is a comprehensive platform for other identity and personalization solutions. It relies on a federated key management agency to determine individual identities, but these data sources are often based on centralized authorities, including centralized institutions like CoinBase (CC).

Idena, an interesting Web3 solution, has no common key management authority or centralized authority. However, it is a single mechanism and it is unclear whether it is resilient enough in the face of the growing AI industry. So far, it has performed well, but the number of users is relatively small, only about a thousand users.

In general, there is currently no method that can completely solve this problem.

Gavin's thoughts on solving Sybil attacks

There are two ways to think about individual identity: one is remote and the other is local. Machines don’t naturally understand “individual identity” and it’s unlikely that we’ll see some cryptographic technology suddenly solve this problem. One could argue that fingerprints or biometrics make humans unique, and machines can measure these, but it’s hard for purely digital systems to prove this. The system that may come closest to this goal is Worldcoin, but it’s also just a machine that can verify in a way that can’t be easily cracked.

So we need to understand that individual identity is more about authentication. It involves how elements within a digital system verify that other elements are real individuals. So the question is, what is the basis for this authentication? Is it physical contact, or other suspicion? Do we believe that an account is a real individual because we have met this person and when we met, we believed that he had no contact with others, so we can infer that he is the only individual in a specific environment, or just because we saw something on the screen and there is other evidence to support his individual identity?

When we talk about remote attestation (i.e. attestation without direct, non-physical evidence), AI (artificial intelligence) may cause some problems. If we rely on physical evidence, practicality may become an issue. So we are caught between these two limitations. However, I think that with innovation and imagination, we can still find some feasible solutions.

So what do we need to do?

So, what do we need? What is our plan?

I think the key to making Polkadot more useful in the real world (not just in DeFi, NFTs, and virtual blockchains) is to find a simple way to identify individuals. Identification here does not mean determining who the person is, such as saying "I know this is Gavin Wood", but identifying "this is a unique individual." I don't think there will be a single solution, so we need a modular and extensible framework.

First, existing, reasonable solutions (such as Idena) can be integrated. Second, the system should not be limited by one person's ideas and should not rely solely on one person's imagination of what mechanism might work. This should be open to some extent, allowing everyone to contribute solutions.

Second, we need strong contextualized pseudonymity. Actually, I originally wrote about anonymity, and to some extent I do mean anonymity, anonymity from your real-world identity. But at the same time, we also want pseudonymity so that in any particular context, you can not only prove that you are a unique individual, but when you use the system again in the same context, you can prove that you are that unique individual.

Finally, we need a strong SDK and API that makes this feature as easy to use as any other feature in Substrate or Polkadot smart contracts, or in the upcoming JAM ecosystem. It has to be easy to use. For example, to be specific, I don't know how many people here have written Frame code, but when writing a new blockchain, you will often see a line of code let account = ensure_signed (origin). What this line of code does is take the origin of the transaction and confirm whether the origin is from a certain account, and if so, tell me what the account is. But an account is not the same as a person. A person may use one or more accounts, and similarly, a script may use one or more accounts. Accounts themselves cannot provide any information about the identity of an individual, at least not alone. So if we want to ensure that a transaction comes from a real person and not one of a million accounts, we need to be able to replace this line of code with another line of code let alias = ensure_person (origin, &b "My context").

There are two benefits worth noting.

First, we are not just asking if this is an account signing a transaction, but rather if this is a person signing a transaction. This makes a huge difference in the functionality we can implement.

Second, and importantly, different operations have different contexts, and we implement anonymity and pseudonym protection within those contexts. When the context changes, the pseudonym changes, and there is no way to link the pseudonyms in different contexts to each other, or to link the pseudonyms to the people behind them. These are completely anonymous pseudonym systems, which makes them a very important tool in blockchain development, especially in developing systems that are useful in the real world.

So what constraints might we place on the mechanisms that actually identify individuals? First, the mechanism must be broadly accessible. If it only allows a subset of the population to participate, it won't be very useful. It shouldn't require assets, and it shouldn't require expensive fees, at least not exorbitant fees.

Inevitably, there will be tradeoffs between different mechanisms. I don't think there will be a one-size-fits-all solution. But some tradeoffs are acceptable and some are not. Resilience, decentralization, and sovereignty should not be compromised, but some mechanisms may require less effort but more commitment, while others may require more effort but less commitment. We should have a reasonable expectation that the individual verified by the system (i.e., an account linked to a person, or a pseudonym) is indeed a unique real-world individual.

There may be overlap between different mechanisms for measuring individual identities in a resilient and non-authoritative way in a decentralized Web3 system. This means that in practice we can't be perfect, but there shouldn't be orders of magnitude errors, and the difference should be significantly less than one order of magnitude. In addition, the system must be extremely resistant to identity abuse to prevent a small number of people or organizations from trying to obtain a large number of individual identities.

It's critical that the system has safeguards against this. There may be mechanisms that provide relatively low confidence scores about the identity of an individual, which is a higher goal. Some mechanisms may achieve this, some may not, some may be binary, either we believe this account is a unique individual, or we don't. Others may say we are 50% sure, but it may also be that this individual has two accounts, and we are 50% sure about both accounts.

Of course, this all has to be permissionless and it has to be easy to do. I shouldn't need to stress this, but there should be no common confession mechanism or common key management authority in the system.

What are the benefits of doing this?

So why do this? What are the benefits?

We’ve talked about some of the ways that society uses or relies on individual identities. But how can this be implemented on-chain? We can start to imagine a Polkadot system where there is no transaction fee to pay, that is, fair use is free. Imagine a “Plaza Chain”, if you are not familiar with it, it is basically an enhanced version of the Asset Hub, with smart contract functions and the ability to utilize the staking system.

If we imagine a Plaza chain like this, we can imagine a scenario where we don't have to pay gas fees. As long as you use it within reasonable limits, gas is free. Of course, if you write scripts or do a lot of transactions, then you need to pay fees because it is beyond the scope of the average individual's right to use. Imagine that these systems begin to be open to the public for free, and we can start communities in a targeted and efficient manner through airdrops and other means. At the same time, we can also imagine more advanced Polkadot governance methods.

Now, I'm not particularly convinced by the idea of ​​"one person, one vote." It's necessary in some cases to ensure legitimacy, but it doesn't usually lead to particularly good results. However, we can consider some other voting methods, such as quadratic voting, or district voting. In some representative elements, one person, one vote can be very inspiring.

We can also imagine an oracle system similar to a jury, where parachains and smart contracts can use local secondary oracle systems, perhaps for price predictions, perhaps for handling disputes between users. But they can also say that if necessary, we will use a "grand jury" or "supreme court" system, where members are selected from known random individuals to make decisions, help resolve disputes, and give some small rewards. Because these members are randomly selected from a large, impartial group, we can expect this approach to provide a resilient and reliable dispute resolution method.

You can imagine noise limiting systems, especially in decentralized social media integrations, to help manage spam and bad behavior. In DeFi, we can imagine reputation limiting systems similar to credit scores, but perhaps more focused on whether you have been caught not paying back on time, so that the system can provide a service similar to the freemium model.

Well, that's the first part of this speech, I hope it helps you.