In the blockchain world and DApps, we often hear the term “decentralized”. The term is used more often than we think because the “D” letter in DApp means “Decentralized” also. Same goes for DAO (Decentralized Autonomous Organization).
Some important questions arise about decentralization: How important is it really? Can we sacrifice some degree of it for other benefits (for example speed or safety)? At which degree are the various chains decentralized? Are the DApps really “D”?
The first question is the most important. But before trying to answer these questions we must define what is decentralization and what is the cost of it compared to other architectures.
What is decentralization?
The simplest architecture is that one server that contains a database. This architecture is really fast and can hold a large amount of data (how large depends of course on the storage capacity of the server). The basic problem in this architecture scheme is that there is a “single point a failure”.
A hacker, a hardware failure, a mistake by the administrator, a bankruptcy of the company that owns the server, a network failure or other causes can bring the server down temporally or, even worse, permanently. The data can be of any type: archives of government licenses, crucial data for applications with millions of users, medical records, balance accounts of a bank and anything else.
It is clear that a failure should never happen in the above cases. In some cases, even the owner of the server must not have the right to stop the server or destroy the data.
So, the most logical solution is to think of an architecture that backs up and replicates the data. This can be achieved with distributed computing. Many servers, usually not in the same physical location, keep a copy of the data. They keep backups (for rolling back the system if necessary), but most importantly they do replication: in real time, whenever a database changes in a “legit” way, all other databases copy the change so every database keeps the new state (current snapshot).
In this architecture, there is no “single point of failure”: a hardware failure can not bring the system down; a hacker can not corrupt all the databases; a network failure can’t keep the system unreachable; a careless administrator will not destroy all the database replicas at once.
Someone can ask how in this architecture the database replicas know when to change state, because if a database changes state as a result of a hardware failure (corrupted sectors in hard disk for example), or because of a hacker, all the databases will reach a wrong state.
The answer is that there is a mechanism, or more correct a protocol, which the servers (let’s call them “nodes” from now on) must follow. This architecture is trustful.
The importance and role of nodes
Each node trust one another (not completely because of hardware or network failure) with the sense that there are not many nodes that have intelligence and act maliciously. Because of these errors, for the replication architecture to function, some faults of the nodes must be tolerated.
In short, the system is fault tolerant (FT). Most protocols of trustful FT are f+1 (where f symbolize the number of faulty nodes). More simply, you need 50%+1 node in this architecture to be sure that the change of state is “legit” (it follows the protocol). Because the decision is a product of the majority of nodes, this use of protocol is also called “consensus”.
To summarize this type of architecture: there is no single point of failure, and as a trade off, it costs more (more hardware, telecommunication costs) and, of course, is slower than a single node (server).
A careful reader should already have noticed a mistake in the previous logic.
We said that there is no single point of failure. But the meaning of no single point of failure is that we must be sure that the database will exist in the next moment – the next state of change – without corruption. But in the previous architecture there is a single owner who controls all the servers (all the nodes).
As a consequence, he/she can bring down the whole system whenever he wants! So, from a decentralizing point of view, the owner can be considered as a “single point of failure”.
Trustless architecture and its trade-offs
The real problem is that the above architecture is trustful. If we want a really decentralized system, then the nodes must be really independent. In other words, they must belong to different entities. With this change, the system becomes TRUSTLESS. Also, as a trade off, the system will become more slow, because, for consensus to be achieved for the next “tic” (the next change of state), more steps are needed.
The reason is very simple: now, the nodes do not trust each other, so they must consider that other nodes may be malicious – that is, they don’t follow the protocol intentionally because they want to benefit for themselves or want to corrupt or destroy the common database for some reason- so, more verification steps are needed to ensure that the next change of state will take place by protocol rules.
Let’s see the new architecture. It is similar to the previous one, but there are more nodes that don’t trust each other and follow a protocol to reach consensus in a trustless way. Also, each node belongs to different entity.
This architecture is the slowest and more costly. However, it is truly decentralized. There is no easy way for someone to attack the system.
What is the degree of decentralization in this system? It really depends of the number of nodes and their physical location (ideally, they should not be located in the same geographical space). The more nodes, the more the system can be considered as decentralized.
There are some architectures that give asymmetric roles to the nodes. Some nodes get the role of a coordinator. The logic behind this is that the consensus will be faster, easier, and maybe safer. Unfortunately, this system has security problems. The reason is obvious if someone thinks of it. Here is a good analogy to easily grasp the logic.
Imagine an army with a general. All others are soldiers. Soldiers take orders only from the general. If someone successfully assassinates the general then the entire army is eliminated! Similarly, if you have many nodes with coordination roles (they have names like “masternodes” or any other exotic name), then someone can attack (only) them directly. The attacker does not need to stop all nodes, only the leader nodes to bring the system down.
But there is a more serious flaw in these architectures: they are not really decentralized. The master nodes have special rights, so they can control the whole system. It is easier for them because they have privileged rights in the consensus algorithm. Also, an attack from outside can be easier because they can be attacked directly with a Denial of Service attack (DoS or DDoS). That way the system is weaker (the example of the army with a general or generals).
Let us summarize so far. For a system to be really decentralized, all the following must hold true:
- The system must have many nodes. The more, the better.
- The nodes must have symmetric roles (no privileged rights for anyone).
- The nodes must belong to different owners.
- The nodes must not be located in the same area.
- The protocol (rules) they follow to reach consensus must be trustless.
When we are referring to a “system”, we mean state replicate machines or databases. Or even better, blocks of data connected between them, so we can also check the history (the change of state each time it occurs). A blockchain, for example 🙂
Now that we have clarified what is a real decentralized blockchain, we can go back to our original questions.
The importance of decentralization
- How important is decentralization? And how does it add value to a businesses?
- Regarding the remaining questions, you can read my next article: PoS (Proof-of-Stake) vs. dPoS (Delegated Proof-of-Stake).