Vitalik Buterin: What decentralization really means

The word “decentralization” is one of the most used words in cryptoeconomics and is often considered a criterion for what is or is not a blockchain. However, this word may also be the most inappropriate one to be defined. Thousands of hours of research and billions of dollars worth of hash power have been used to try to achieve, protect and improve decentralization. When people discuss protocols and things start to get heated, it is very common for supporters of one protocol (and by extension the protocol) to claim that the other protocol proposal is “centralized” and use this as a final argument to knock down the other party’s reasoning.

However, there is often a lot of confusion about what the word “decentralization” actually means. Take, for example, these three completely unhelpful, but all too common diagrams:

Now, let's look at two different answers to the question "What is the difference between distributed and decentralized?" on Quora. The first answer is actually a mechanical retelling of the above diagram, while the second answer is completely different, saying: "Distributed means that not all processes of transactions are processed in the same place, and decentralized means that no single entity can control the processing of transactions." At the same time, the top answer on the Ethereum Q&A community "Ethereum stack exchange" gives a very similar diagram to the above one, except that the positions of "distributed" and "decentralized" are switched. Obviously, this clarification and explanation is very necessary.

Three Types of Decentralization

When people discuss the decentralization of software, they are actually discussing three separate axes of centralization/decentralization. In some cases it is hard to see how one can be centralized or decentralized without the other. In general, centralization and decentralization are independent of each other, and the three axes are as follows:

1. Architectural (de)centralization — How many computers does this system consist of? How many computers can the system tolerate crashing at any one time and still continue to operate?

2. Political (de)centralization — How many individuals and organizations ultimately control the computers that make up the system?

3. Logical (de)centralization — Does the system present and maintain interfaces and database structures like a single entity? Or an unstructured group? A simple heuristic is: if you split the users and providers of this system into two, can they still operate as completely independent units?

We can try to illustrate these three dimensions in one chart:

Note that a lot of this chart is open to debate, but let's try to understand it:

1. Traditional companies are politically centralized (one CEO), architecturally centralized (one headquarters), and logically centralized (you can’t really cut them in half).

2. Civil law relies on a centralized legislature, while common law is based on precedents set by many individual judges. Civil law is now partially decentralized in structure because there are many different courts and they have the freedom to make their own decisions, but common law is more decentralized. Both civil and common law are logically centralized (law is law).

3. Languages ​​are logically decentralized: the English spoken between Alice and Bob need not be the same as the English spoken between Charlie and David. No language requires a centralized infrastructure to exist, and the grammatical rules of English are not created or controlled by a single individual (whereas Esperanto was originally invented by Ludwig Zamenhof, and is now evolving more like a living language, without authority).

4. BitTorrent, like the English language, is logically decentralized, but content delivery networks, like it, are controlled by a single company.

5. Blockchains are politically decentralized (no one controls them) and architecturally decentralized (no central point of failure in the infrastructure), but logically centralized (there is a commonly agreed upon state, and the system behaves like a single computer).

Often times when people talk about the merits of blockchain, they are describing the convenience benefits of having a “central database”; centralization is logical centralization, which can be considered a good thing in many cases (although Juan Benet from IPFS supports pushing logical decentralization as far as possible, because logically decentralized systems are more likely to survive in decentralized areas of the network, and work well in areas of the world with poor connectivity, etc., and see this article starting with Scuttlebot for explicit advocacy of logical decentralization).

Architectural decentralization often leads to political centralization, but not necessarily - in formal democracies, politicians meet and vote in some meeting room, but the maintainers of the room do not have the power to make decisions that change the outcome. In computerized systems, architectural rather than logical decentralization can occur if there is an online community that uses a centralized forum for convenience, but if there is a widely accepted social contract that is violated by the forum's owners with malicious intent, then everyone in the forum will leave and go to another forum (the community is made up of a group of people who are rebellious about seeing censorship in practice in other forums)

Logical centralization makes architectural decentralization more difficult, but not impossible - see decentralized consensus networks that have proven useful, but are more difficult than maintaining BitTorrent. Logical centralization makes political decentralization more difficult - it is harder to resolve disputes with a simple "live and let live" in a logically centralized system.

Three reasons for decentralization:

The next question is, why is decentralization useful? There are usually the following points of view:

1. 容错力: Decentralized systems are less likely to fail unexpectedly because they rely on many independent components that are less likely to fail unexpectedly together.

2. 抗攻击力: Decentralized systems make it more expensive to attack, disrupt, and manipulate because they lack sensitive central points that are more vulnerable to attack at a lower cost than the size of the surrounding economic system.

3. 防勾结串通: It is much harder for participants in a decentralized system to conspire to benefit themselves at the expense of other participants. It has to be said that it is common for leaders of companies and governments to conspire to do things that benefit themselves and harm citizens, customers, employees, and the public.

All three arguments are important and valid. But once you start thinking about decision protocols, all three lead to some interesting and different conclusions. Let me take each of these arguments one by one.

The core argument for fault tolerance is simple. What is less likely to happen: one computer failing? Or five out of ten failing at the same time? The principle is unquestionable and applies to many real-life situations, including jet engines, backup generators, infrastructure such as hospitals, military bases, diversified investment portfolios, and, of course, computer networks.

However, this effective and important decentralization is sometimes far less effective than a mathematical model that is occasionally used for prediction. The reason is common mode failure. Sure, four jet engines are less likely to fail than one, but what if all four jet engines were manufactured in the same factory? And all four jet engines were made by the same unqualified employee?

Can today's blockchain effectively prevent common mode failures? Not necessarily. You can refer to the following scenarios:

1. All nodes of the blockchain run the same client software, which actually has a bug.

2. All nodes of the blockchain are running on the same client software, and the development team of this client software is actually corrupt elements in society.

3. The research and development team that proposed the upgraded protocol turned out to be corrupt elements in society.

4. In the proof of work blockchain, 70% of the miners are in the same country, and the government of that country decided to seize all mining farms for national security reasons.

5. Most of the mining hardware was built by the same company, which was bribed or coerced into creating a backdoor that allowed the hardware to be shut down at will.

6. In blockchain proof of stake, 70% of all interest-bearing currencies are on the same exchange.

From a holistic perspective of decentralization of fault tolerance, we look at all of these aspects and wonder how to minimize them. From this, some conclusions are obvious;

1. It is crucial to achieve a multi-party competitive relationship

2. Knowledge of the technical considerations behind protocol upgrades must be democratized so that more people can more naturally participate in researching, discussing, and criticizing apparently bad protocol changes.

3. The core development and research staff should be employed by multiple companies or organizations (or filled by many volunteers)

4. Mining algorithms should be designed with minimal centralization in mind.

5. Ideally, we use proof-of-stake to completely get rid of the risk of hardware centralization (of course, we must also be very careful about the new risks that may be brought to us by using proof-of-stake).

It is important to note that the initial form of fault tolerance requires decentralization in architecture, but if you think about it, once the community's fault tolerance controls the continued development of the protocol, then it can be seen that political decentralization is also very important.

Now, let’s look at attack resistance. In some purely economic models, you can get the results you want even if decentralization doesn’t matter at all. If you create a protocol where a validator guarantees that you will lose $50 million in the event of a 51% attack (i.e., reversion to finality), it doesn’t matter if the validator is controlled by one company or a hundred companies. A $50 million economic security deposit is a $50 million marginal cost of economic security. In fact, there is a deep game-theoretic reasoning behind why centralization even maximizes this notion of economic security (the transaction model of existing blockchains reflects this view, as transactions included in blocks are effectively a form of dictatorship by miners/block applicants).

However, once you adopt richer economic models, especially ones that admit the possibility of coercion (or milder ones like targeted DOS attacks on nodes), decentralization becomes more important. If you threaten the life of one person, then $50 million is no longer important to them. But if $50 million is spread among ten people, then you have to threaten 10 times as many people, and do it at the same time. In general, in many cases, the modern world is characterized by an attack/defense asymmetry that favors the attacker - a building that costs $10 million can be destroyed for less than $100,000, but the leverage of the attacker is often sublinear: if it only costs $100,000 to destroy a building that costs $10 million, then a building that costs $1 million may only cost $30,000 to destroy. Smaller costs give good ratios.

Where does this reasoning lead? First, it strongly promotes proof-of-stake over proof-of-work because computer hardware is easier to detect, adjust, and attack, while coins are easier to hide (proof-of-stake is also more resistant to attacks from other nodes for other reasons). Second, it also supports widely distributed development teams. Third, it also implies that when designing consensus protocols, you need to consider both the economic model and the fault tolerance model.

Finally, we can get to the most complex of the three arguments, anti-collusion. Collusion is difficult to define, and perhaps the only real and effective way to express it is to say "a combination that none of us likes." In many cases in real life, the ideal situation is that everyone can coordinate perfectly, but if one person can coordinate but others can't, then it is very dangerous.

A simple example is antitrust law, which sets regulatory barriers to make it harder for participants on one side of a market to come together and act like a monopolist to gain external benefits at the expense of participants on the other side of the market and social welfare. Another example is the rules on coordination between candidates and super PACs in the United States, although these have proven difficult to implement in practice. A smaller example is the rules in some chess tournaments to prevent two players from playing a game many times in an attempt to improve the score of one of them. Wherever you look, attempts by established institutions to prevent unwanted coordination are everywhere.

In the case of blockchain protocols, the mathematical and economic reasoning behind consensus often relies on a crucial uncoordinated choice model. Or let's say a game consists of many small characters that can make independent decisions, and if one character gets more than 1/3 of the mining power in the proof of work, then he can make huge profits by mining privately. But can we really say that when 90% of Bitcoin's mining power is so good that they can show up at the same meeting, this uncoordinated choice model is really realistic?

Blockchain advocates also point out that blockchains are more secure because they cannot change their rules at will. But if the developers of the software and protocols all work for the same company, or if the same family sits in the same room, then this security is not necessarily guaranteed. In general, these systems should not be monopolized by one party. Therefore, you can definitely say that blockchains will provide more security if the parties involved are not coordinated.

Of course, this also presents a fundamental paradox. Many communities, including Ethereum, are often praised for having strong community spirit and being able to quickly coordinate the implementation, release, and activation of a fork, resolving a server denial of access issue within six days. But how do we promote and improve this kind of positive coordination while preventing “bad coordination” where bad miners repeatedly coordinate 51% attacks to put others in trouble?

There are three ways to answer this question:

1. Instead of thinking too much about bad coordination problems, try more to build protocols that can resist it.

2. Try to find a good medium that allows enough coordination for the protocol to evolve and move forward, but not enough coordination to launch an attack.

3. Try to learn to distinguish between favorable coordination and unfavorable coordination, and try to make favorable coordination easier and unfavorable coordination more difficult.

The first approach is largely the idea of ​​Casper’s design, however, it is not enough by itself because economics alone cannot handle the decentralization considerations of the other two approaches. The second approach is difficult to be clear in program development, especially long-term development work, and there are often surprises where development is unclear. For example, Bitcoin’s core developers often speak English, while miners mostly speak Chinese, which is a beautiful surprise. Because it creates a “bicameral” management method that makes coordination more difficult, it helps reduce the risk of the same model being produced, because the English and Chinese communities will disagree and argue due to distance and communication difficulties, so it is unlikely that both sides will agree on the same mistake.

The third is the social challenge. Solutions in this regard can be:

1. Social intervention attempts to increase participants’ loyalty to the blockchain community to prevent players on one side of the market from being loyal only to their own side.

2. Improve communication between all market participants in the same context, and make it clear to them that validators, developers and miners are all in the same camp, so they must coordinate to safeguard their own interests against other camps.

3. The protocol is designed in a way that reduces incentives for validators/miners to develop one-on-one "special relationships", reduces centralized delivery networks, and other similar super-protocol mechanisms.

4. Make it clear what the basic properties of this agreement should be, what should not be done, or what can only be done in extreme circumstances.

The third type of decentralization, which is decentralization to avoid undesired coordination, is probably the most difficult to achieve, and trade-offs are inevitable. Perhaps the best solution is to rely heavily on a group that is guaranteed to be very decentralized: the users of the protocol.