Viewpoint | Vitalik: The Meaning of Decentralization

"Decentralization" is perhaps the most frequently mentioned word in blockchain, but the definition of this word is also the most unclear.

It's actually quite incredible to think about it. Blockchain consumes a large amount of precious computer hash power precisely to ensure the decentralization of the network. However, when people argue about whether a certain token or a certain blockchain network is good or not, the word "decentralization" is often used as a weapon. A simple and crude sentence "Your thing is not decentralized" can easily end an argument.

So, what exactly does the word "decentralization" mean?

Not many people can truly explain it clearly. In fact, not many people are conscious of, or willing to, delve into the true meaning of this word.

Most people, when facing questions, are accustomed to citing the following three diagrams to explain the so-called "decentralization":

But unfortunately, the above three diagrams as a common explanation are basically invalid. It does not provide any essential help for us to understand "decentralization".

We need a more low-level way, and also a more explicit criterion, to define "decentralization". Because only by understanding the true meaning of this word can we better understand blockchain.

Three Rulers for Judging "Decentralization"

In the software world, the so-called "decentralization" can actually be discussed in three dimensions. These three dimensions are also the three rulers for judging whether something is "decentralized".

It should be noted that these three rulers may seem indispensable at first glance, but generally speaking, they are independent of each other.

Architectural Decentralization: In the physical world, how many computers make up a system? During the operation of this system, how many computers can it tolerate crashing without the system being affected?
Political Decentralization: How many individuals or organizations have ultimate control over the computers that make up the system?
Logical Decentralization: From the perspective of the interface and data structure designed for this system, does it look more like a complete single device, or does it look more like a cluster composed of countless units? — This dimension may be abstract and not easy to understand. We can use another relatively simple way to judge: If this system is cut in half, and both parts contain producers and consumers, can these two parts continue to operate fully as independent units?

These three rulers, one is used to measure system design at the architectural layer, one is used to measure control power at the political layer, and one is used to measure the belonging form at the logical layer.

Summarizing them, using a chart to represent might be clearer:

As you can see, there are already some representative examples in the chart. It should be noted that the classification and placement of these examples are tentatively rough, and there may be a lot of controversy logically, but we can still try to straighten out these examples, which is good for helping us understand "why these three criteria":

Traditional Corporations: Traditional corporations are centralized politically (every company has a CEO), centralized architecturally (every company has a headquarters), and logically, still centralized (you can't really split a company in half).
Law: Modern law has two systems, one is Civil Law and the other is Common Law. Civil Law relies on a centralized legislative body, and it is centralized at the architectural layer; comparing with Common Law, Common Law is constituted by many precedents made by many judges as individuals. Although many courts now enjoy great freedom and can make laws themselves, so Civil Law also has a small part of "decentralization" at the architectural layer, but compared with the Common Law system composed of many individual judges, the degree of decentralization of Common Law is obviously higher. Of course, both are centralized at the logical layer (law is law).
Language: Language is decentralized at the logical layer. The English spoken between Alice and Bob, and the English spoken between Charlie and David, do not need to be consistent. At the same time, the existence of no language requires centralized infrastructure support, and the grammatical rules of English are not created by any single individual, nor are they controlled by any organization (You might say that World English was originally invented by Ludwig Zamenhof, but looking at it now, the communication function of English looks more like a continuously self-evolving living language, it grew out of itself gradually).
BitTorrent: Similar to English, BitTorrent is decentralized at the logical layer. Content Delivery Networks (CDNs) are also like this, but they are all controlled independently by a single company.
Blockchain: Blockchain is decentralized at the political layer (no person or organization can control the blockchain), decentralized at the architectural layer (no unified server can be attacked), but at the logical layer, blockchain is centralized (every blockchain network has its own universal consensus, and the system's behavior is more like a single computer).

Okay, we have successfully straightened out whether various things are decentralized or not.

After straightening it out once, you should have already made the first discovery:

When talking about the advantages of blockchain, many people often mention the benefits brought by the "central database" (or public ledger). But isn't blockchain decentralized? Why is there still the concept of "central database"? Is this contradictory?

Looking at it with the standards provided by our three rulers, it is easy to understand: The so-called centralization of "central database" here is actually centralization at the logical layer.

In most cases, centralization at the logical layer represents a better choice. However, there are also many people who advocate that the logical layer also needs to be decentralized as much as possible, for example, Juan Benet from IPFS thinks so. His reason is that decentralized systems at the logical layer tend to be more survivable on network partitions. To explain it in human language, it is that "decentralization at the logical layer" works better in a world with poor connectivity (such as remote areas).

Why do we need "Decentralization"?

We have mastered the method of how to judge "decentralization". The next question is, why is decentralization important? Where are its benefits?

Decentralization has three advantages:

Fault Tolerance: Decentralized systems are less likely to stop working due to a local accidental failure because they rely on many independently working components, and their fault tolerance is stronger.
Attack Resistance: The cost of attacking and destroying decentralized systems is higher than that of centralized systems. From an economic benefit perspective, this is the difference between robbing a house and robbing a village.
Collusion Resistance: It is difficult for participants in decentralized systems to collude with each other. Whereas the leadership of traditional enterprises and governments often collude with each other for their own interests in ways that harm the interests of customers, employees, and the public.

Let's try to expand on the above three points in more detail one by one.

Fault Tolerance

The core of fault tolerance is actually "the ability to withstand errors to reduce the probability of system crashes". Which has a greater probability, one computer failing, or five out of ten computers failing at the same time? Obviously the former. This is actually a way to diversify risks. In real life, this fault tolerance has been widely used, such as jet engines, backup generators, hospital and military infrastructure, diversified financial investment portfolios, computer networks, etc.

However, although this fault tolerance of decentralization is effective and important, it is sometimes far less useful than a simple mathematical model. The reason lies in "common mode failure". Four jet engines are indeed less likely to fail than one jet engine, but what if these four jet engines are all manufactured by the same factory? Or, what if these four jet engines were all made by the same unqualified employee? This is common mode failure.

So, can current blockchains resist common mode failure?

Not necessarily.

If you don't believe it, look at these examples below:

All nodes of a blockchain run the same client software, and this client software has a BUG.
All nodes of a blockchain run the same client software, and the development team of this client software colludes and becomes corrupt.
The research team proposing upgrades to the blockchain network protocol colludes and becomes corrupt.
In a Proof of Work (POW) blockchain, 70% of miners are in the same country, and the government of this country decides to take over all mining farms for national security.
Most mining hardware is produced by the same company, and this company is bribed or threatened to open a backdoor on the mining hardware, allowing all mining hardware to be shut down at will.
In a Proof of Stake (POS) blockchain, 70% of the coins are held by one exchange.

Obviously, to ensure the fault tolerance of decentralization, all these problems above should be minimized as much as possible.

How to minimize?

The following measures may be helpful:

Maintain multi-party competitive relationships as much as possible;
The technology and knowledge for upgrading protocols must be democratized so that more people can participate in researching, discussing, and criticizing some obviously bad protocol changes;
Core development and research personnel should be employed by multiple companies or organizations (or many of them can be volunteers);
Mining algorithms should be designed with the lowest degree of centralization in mind;
Ideally, we use Proof of Stake (POS) to get rid of the risk of hardware centralization (of course, Proof of Stake may also bring new risks).

It is worth noting that when we focus on relatively basic fault tolerance, we tend to focus on decentralized design at the architectural layer, but if you start to consider the fault tolerance during the longer-term upgrade and development of a system, then decentralization at the political layer is also very important.

Attack Resistance

Now, let's look at attack resistance.

In pure economic models, decentralization actually doesn't matter much. If you create a protocol where "once a 51% attack occurs, the validator will lose $50 million", it doesn't matter if this validator is controlled by one company or 100 companies.$ 50 million is the marginal cost of ensuring the economic security of this protocol, so $50 million is$ 50 million. In fact, game theory also tells us that centralized systems can even maximize this concept of economic security marginal cost (existing blockchain transaction selection models also reflect this view, because miners/block proposers packaging transactions into blocks is actually a very rapid rotation dictatorship process).

But if it is in a richer economic model, especially if there is a possibility of coercion in this economic model (or targeted DOS attacks against nodes), then decentralization becomes very important. When a person's life safety is threatened, $50 million is irrelevant to him. You can easily rob his money, but if this$ 50 million is held separately by ten people, then the number of people you must threaten and blackmail instantly soars to 10 times, and this 10 times workload has to be completed at the same time. This is a nightmare for any robber.

However, an interesting point is that in most cases, the world we live in has a characteristic: "Attack/Defense" is asymmetric, and the attacker often has the advantage. For example, a building built at a cost of $10 million may be easily destroyed by an attack cost of$ 100,000. But this leverage effect of attack/defense is often sub-linear: destroying a $10 million building requires$ 100,000, a $1 million building requires$ 30,000, and further down, smaller buildings require higher ratios.

Wait, is knowing these things useful for us to understand blockchain?

Of course it is useful. This principle can at least let us understand three key points of blockchain mechanism design:

First, compared to Proof of Work (POW), Proof of Stake (POS) is safer. POW requires mining computers, and these hardware are easy to detect, manage, or attack, while POS targets proof of stake, which is tokens, and coins are easier to hide than computer hardware;
Second, the more widely distributed the blockchain development team (including geographical distribution), the more advantageous it is;
Third, when designing consensus protocols, both economic models and fault tolerance models need to be considered simultaneously.

Collusion Resistance

Finally, we can finally discuss the most complex point of the above three: collusion resistance.

The term collusion resistance sounds a bit weird because the word "collusion" itself is quite difficult to define. Simply put, we can think that "collusion" is "a way of coordination that we dislike". In an ideal state, we hope that everyone can have a perfect coordination relationship, but when a certain part of people can coordinate perfectly while another part cannot, the situation becomes very dangerous.

For example, antitrust laws are an example. In order to prevent market participants from gathering together, colluding with each other, implementing monopolies, harming the interests of market consumers and society to obtain excess profits, antitrust laws deliberately set regulatory obstacles in market operations.

Another example is the anti-active coordination rules between US presidential candidates and Super PACs. A Super PAC is equivalent to an independent association supporting a candidate, mainly used to help candidates raise unlimited funds needed for the election. In order to prevent it from colluding with candidates, the United States stipulates that Super PACs cannot have direct contact with elected political parties, which is a rule against active coordination. Of course, having said that, these rules are actually difficult to enforce in practice.

A smaller example is some rules made in chess competitions, which are used to prevent two players from playing frequently against each other to improve their respective scores.

It can be seen that this attempt of "anti-collusion" is actually ubiquitous in various complex systems in the real world.

And in blockchain protocols, the mathematical principles and economic principles behind establishing consensus security usually also rely on this setting of "anti-collusion".

"Anti-collusion" means avoiding coordination between nodes as much as possible. In other words, it assumes that a blockchain network consists of many nodes making independent decisions.

Blockchain proponents believe that blockchain is safer because any individual in the blockchain network cannot arbitrarily change the rules of the protocol itself. But if the developers of the software and protocol all serve the same company, belong to the same family, and work in the same office building, this situation is actually difficult to prevent.

To truly ensure security, the most critical point is to prevent the system from becoming a selfish centralized monopoly. Therefore, the looser a blockchain network is, the harder it is for them to collude with each other, and the safer it is.

However, this actually reveals a fundamental contradiction.

Many communities (including Ethereum) exist because they have a strong community spirit and have the advantage of rapid coordination in executing, releasing, and activating hard forks. The question we need to think about is how to cultivate and improve this good coordination relationship, while at the same time preventing those bad coordination relationships and preventing them from accidentally evolving into "collusion" (for example, miners trying to collude with each other to repeatedly carry out 51% attacks to commit fraud).

To solve this problem, three things may need to be done:

Don't try to reduce collusion, use protocols to completely eliminate collusion.
Try to find a balance point, which can provide enough coordination relationships to help the protocol develop better, but at the same time is not enough to evolve into collusion relationships and launch attacks.
Try to distinguish clearly between "good coordination relationships" and "harmful coordination relationships", and then find ways to make the former easier and the latter harder.

The first method, in the design of Ethereum's Casper mechanism, has used this guiding ideology in many places. However, the first point alone is not enough, because relying solely on economic methods cannot solve the other two types of problems of decentralization;

The second method is difficult to design explicitly, but it often happens accidentally on its own. For example, Bitcoin's core developers generally speak English, while miners generally speak Chinese. This can almost be called a "happy accident" because it inadvertently created a "bicameral" governance mechanism. On the one hand, it makes collusion between them difficult, and on the other hand, it reduces the risk of common mode failure - the English community and the Chinese community, because of communication difficulties, to some extent, are more likely to have their own independent thinking, so they are less likely to make the same mistakes at the same time.

The third method represents a sociological challenge, which may include:

Social intervention measures, that is, trying to increase participants' loyalty to the blockchain community as a whole, to replace or suppress the impact of market participants' direct loyalty to each other.
Promote different market participants to communicate in the same context, so that whether validators, developers, or miners, they are less likely to classify themselves as a certain class, thus reducing the possibility of them coordinating to fight against other classes and protect the interests of their own class.
When designing protocols, try to avoid or reduce the formation of one-to-one "special relationships" between validators and miners, or the formation of centralized relay networks, and other similar super protocol mechanisms.
Regarding the basic attributes that the protocol should possess, and what things should not be done, or what things can only be done in very extreme situations, these protocols themselves should be regulated very clearly.

Preventing collusion and collusion-resistant decentralization may be the most difficult to achieve at present.

To really achieve it, some trade-offs are inevitable. Perhaps the best solution might be to rely heavily on the group that can best ensure the degree of decentralization: that is, the users of the protocol.

Summary

Okay, if you read here, congratulations, you have beaten 99% of other readers.

Let's review the key points of "decentralization" again:

Three rulers to measure the degree of "decentralization", three independent judgment criteria: Architectural Layer, Political Layer, Logical Layer;
Three benefits brought by "decentralization": Fault Tolerance, Attack Resistance, Collusion Resistance;
Among them, fault tolerance currently needs to solve the problem brought by common mode failure;
Attack resistance is not important in pure economic models, but very important in richer economic models;
"Anti-collusion" is the most difficult to achieve among the three advantages of decentralization, and it requires constant trade-offs.

It is worth noting that the views of this article may not necessarily be correct, but at least it has helped you re-examine the four simple words "decentralization".

Whether the so-called coin circle and chain circle, whether their time difference with the real world is one day or one year, under the bombardment of various new terms and new concepts, we believe it is valuable to analyze and discuss some basic concepts that many people take for granted.

Any new word should be able to use existing words for the simplest explanation. This article, due to our limited ability, may not have done well enough in compilation, but if it can bring you some inspiration, we are satisfied.

Original Link: https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274 Author: Vitalik Buterin Translator: retric