Vitalik Buterin

“Decentralization” is one of the words that is used in the blockchain space the most frequently, defended the most strongly, and is often even viewed as a blockchain's raison d’être, but it is also one of the words that is perhaps defined the most poorly. Although whether or not a system is decentralized is often viewed as an either-or question, it is in fact a concept that can be viewed in many ways, and each individual system may have varying degrees of decentralization depending on how you think about it.

When people talk about software decentralization, there are in fact three separate axes of centralization/decentralization that they may be talking about. While in some cases it is difficult to see how you can have one without the other, in general they are quite independent of each other. The axes are as follows:

●Architectural (de)centralization — how many physical computers is a system made up of? How many of those computers can it tolerate breaking down at any single time?
●Political (de)centralization — how many individuals or organizations ultimately control the computers that the system is made up of? Control may be direct, or indirect, through controlling the social consensus around updating a protocol.
●Logical (de)centralization— does the interface and data structures that the system presents and maintains look more like a single monolithic object, or an amorphous swarm? One simple heuristic is: if you cut the system in half, including both providers and users, will both halves continue to fully operate as independent units?

We can try to put this into a chart:

Note that a lot of these placements are rough and highly debatable. But let's go through some of them:

●Traditional corporations are politically centralized (one CEO), architecturally centralized (one head office) and logically centralized (can't split them in half)
●Civil law relies on a centralized law-making body, whereas common law is built up of precedent made by many individual judges. Civil law still has some architectural decentralization as there are many courts that nevertheless have large discretion, but common law have more of it. Both are logically centralized (“the law is the law”).
●Languages are logically decentralized; the English spoken between Alice and Bob and the English spoken between Charlie and David do not need to agree at all. There is no centralized infrastructure required for a language to exist, and the rules of English grammar are not created or controlled by any one single person.
●Systems like BitTorrent are logically decentralized, whereas blockchains are logically centralized.

Many times when people talk about the virtues of a blockchain, they describe the convenience benefits of having “one central database”; that centralization is logical centralization, and it's a kind of centralization that is arguably in many cases good.

The three types of centralization sometimes feed into each other, but not always; for example, a democracy with a parliament may be architecturally centralized into one building, but it is much less politically centralized.

Four Reasons for Decentralization

The next question is, why is decentralization useful in the first place? There are generally several arguments raised:
●Efficiency – decentralized systems may be, in limited cases, more efficient, for example because instead of buying all of their infrastructure they can use the spare capacity that their users already have (this is the rationale behind some software developers using torrent networks to upload files to their users, or sharing economy projects such as Uber and AirBnB)
●Fault tolerance – decentralized systems are less likely to fail accidentally because they rely on many separate components that are not likely.
●Attack resistance – decentralized systems are more expensive to attack and destroy or manipulate because they lack sensitive central points that can be attacked at much lower cost than the economic size of the surrounding system.
●Collusion resistance –  it is much harder for participants in decentralized systems to collude to act in ways that benefit them at the expense of other participants, whereas the leaderships of corporations and governments collude in ways that benefit themselves but harm less well-coordinated citizens, customers, employees and the general public all the time.

All three arguments are important and valid, but all three arguments lead to some interesting and different conclusions once you start thinking about protocol decisions with the three individual perspectives in mind. Let us try to expand out each of these arguments one by one.

Efficiency

Blockchains do not have a very strong case for efficiency by themselves; even though they do benefit from spare capacity advantages, transaction processing is very highly replicated, and we can see from transaction fees in Bitcoin and even Ethereum that processing is much more expensive than centralized systems. However, we can make a case that blockchains are much cheaper than other kinds of systems given a particular required level of fault tolerance, and that blockchains can serve as a base layer for other decentralized protocols that are much more efficient.

Fault Tolerance

Here the core argument is simple. What's less likely to happen: one single computer failing, or five out of ten computers all failing at the same time? The principle is uncontroversial, and is used in real life in many situations, including jet engines, backup power generators particularly in places like hospitals, military infrastructure, financial portfolio diversification, and yes, computer networks.

Blockchains are interesting because they have so many users participating that their reliability can be very high even if the reliability of each individual node is very low; as a result, a blockchain-based system can achieve reliability higher than that of many centralized systems run by professional companies even if each individual node is run by an amateur. This can lead to large reductions in barriers to entry for application developers.

Attack Resistance

In the modern world, adversarial conflict is increasingly becoming distributed, and large expensive defensive infrastructure such as castles and walls, popular in the medieval era, falls quickly to modern weaponry, and the only solutions that still work have to do with removing single points of failure and relying on defense in depth. Cybersecurity is no different; a system that costs $10 million to build is certainly not ten times more secure than a system that costs $1 million to build, but a network of ten systems, where you need to take down five in order to bring down the whole system altogether, is most secure of all.

Collusion Resistance

Finally, we can get to perhaps the most intricate argument of the four, collusion resistance. Collusion is difficult to define; perhaps the only truly valid way to put it is to simply say that collusion is “coordination that we don't like”. There are many situations in real life where even though having perfect coordination between everyone would be ideal, one sub-group being able to coordinate while the others cannot is dangerous.

One simple example is antitrust law — deliberate regulatory barriers that get placed in order to make it more difficult for participants on one side of the marketplace to come together and act like a monopolist and get outsized profits at the expense of both the other side of the marketplace and general social welfare. Another example is rules against active coordination between candidates and super-PACs in the United States, though those have proven difficult to enforce in practice. A much smaller example is a rule in some chess tournaments preventing two players from playing many games against each other to try to raise one player's score. No matter where you look, attempts to prevent undesired coordination in sophisticated institutions are everywhere.

Blockchains are interesting because they allow many participants to coordinate in a highly automated way, without creating pathways for high levels of social coordination that could later on, for example, be used to form a cartel.

Ethereum

Ethereum was originally conceived in 2013, and released in 2015, as a general-purpose platform for building decentralized applications. It includes a blockchain with a built-in Turing-complete programming language, allowing applications (often called “contracts”) with any kind of rules and logic to be built on top of it with a relatively easy-to-use high-level programming language. The project was initially conceived because of the realization that there is a very large number of applications that could potentially be built on a blockchain-like architecture, and it is not reasonable to expect a separate blockchain to be built for each one. Instead, by building a common platform, the barriers to entry to building each individual blockchain use case could be greatly reduced.

As an example, here is what the high-level code for a digital currency issued on a blockchain might look like:

A user would call the function send of this contract by sending a transaction with specially formatted data to the Ethereum blockchain. The process of validating the transaction includes executing the Ethereum virtual machine (EVM) code that this contract code compiles down to. Very many types of applications can be put onto Ethereum by having their application logic embedded into code and uploaded onto the blockchain in this way.

Blockchain Development in Taiwan

Taiwan is in some ways an ideal market for adoption of many kinds of blockchain applications, as there are many industries that are quite decentralized already; there are fewer large monopolists, and in some cases dozens or hundreds of competitors. Here, blockchain applications would not be fighting against incumbents, but rather helping existing decentralized industries remain decentralized but at the same time get many of the same network effect benefits that would arise from a monopoly. A particular use case is in the financial industry, where there are currently many banks and payment providers, but a relative lack of interoperability between them; a blockchain-based layer may prove to be the answer.