Web Excursions 2022-01-18
The Meaning of Decentralization
[Note: The article was written by Vitalik Buterin back in 2017. It's substantially objective and well-thought — although not without murkier points worth debating/elaboration — than most "write-ups" by ethereum evangelists nowadays. ]
Three types of Decentralization
When people talk about software decentralization, there are actually three separate axes of centralization/decentralization that they may be talking about.
in general they are quite independent of each other.
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?
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?
a lot of these placements are very rough and highly debatable
[Application of the model]
Traditional corporations are
politically centralized (one CEO),
architecturally centralized (one head office) and
logically centralized (can’t really 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
BitTorrent
is logically decentralized similarly to how English is.
Content delivery networks are similar,
but are controlled by one single company.
Blockchains are
politically decentralized (no one controls them) and
architecturally decentralized (no infrastructural central point of failure) but
they are logically centralized (there is one commonly agreed state and the system behaves like a single computer)
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
Architectural centralization often leads to political centralization,
though not necessarily — in a formal democracy, politicians meet and hold votes in some physical governance chamber, but the maintainers of this chamber do not end up deriving any substantial amount of power over decision-making as a result.
In computerized systems, architectural but not political decentralization might happen
if there is an online community which uses a centralized forum for convenience,
but where there is a widely agreed social contract that if the owners of the forum act maliciously then everyone will move to a different forum
Logical centralization makes architectural decentralization harder,
but not impossible — see how decentralized consensus networks have already been proven to work, but are more difficult than maintaining BitTorrent.
And logical centralization makes political decentralization harder — in logically centralized systems, it’s harder to resolve contention by simply agreeing to “live and let live”.
Three reasons for Decentralization
Fault tolerance, Attack resistance, & Collusion resistance
Regarding fault tolerance, 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?
However, this kind of decentralization, while still effective and highly important, often turns out to be far less of a panacea than a naive mathematical model would sometimes predict.
The reason is common mode failure
Do blockchains as they are today manage to protect against common mode failure? Not necessarily.
A holistic view of fault tolerance decentralization would look at all of these aspects, and see how they can be minimized.
Some natural conclusions that arise are fairly obvious
Note that the fault tolerance requirement in its naive form focuses on architectural decentralization,
but once you start thinking about fault tolerance of the community that governs the protocol’s ongoing development, then political decentralization is important too.
[Regarding Attack resistance]
In some pure economic models, you sometimes get the result that decentralization does not even matter.
If you create a protocol where the validators are guaranteed to lose $50 million if a 51% attack (ie. finality reversion) happens,
then it doesn’t really matter if the validators are controlled by one company or 100 companies
once you adopt a richer economic model, and particularly one that admits the possibility of coercion (or much milder things like targeted DoS attacks against nodes), decentralization becomes more important
the modern world is in many cases characterized by an attack/defense asymmetry in favor of the attacker
the attacker’s leverage is often sublinear
In fact, there are deep game-theoretic reasons why centralization may even maximize this notion of economic security
(the transaction selection model of existing blockchains reflects this insight,
as transaction inclusion into blocks through miners/block proposers is actually a very rapidly rotating dictatorship).
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.
What does this reasoning lead to?
First of all, it pushes strongly in favor of proof of stake over proof of work, as computer hardware is easy to detect, regulate, or attack, whereas coins can be much more easily hidden (proof of stake also has strong attack resistance for other reasons).
Second, it is a point in favor of having widely distributed development teams, including geographic distribution.
Third, it implies that both the economic model and the fault-tolerance model need to be looked at when designing consensus protocols.
how can we foster and improve the good kind of coordination, but at the same time prevent “bad coordination” that consists of miners trying to screw everyone else over by repeatedly coordinating 51% attacks?
the fact that bitcoin’s core developers generally speak English but miners generally speak Chinese can be viewed as a happy accident,
as it creates a kind of “bicameral” governance that makes coordination more difficult,
with the side benefit of reducing the risk of common mode failure,
as the English and Chinese communities will reason at least somewhat separately due to distance and communication difficulties and are therefore less likely to both make the same mistake.
The third is a social challenge more than anything else; solutions in this regard may include:
Promoting communication between different “sides of the market” in the same context
Social interventions that try to increase participants’ loyalty to the community
Perhaps the best solution may be to rely heavily on the one group that is guaranteed to be fairly decentralized: the protocol’s users.