Decentralized Systems Introduction
Decentralized systems is a class of systems that do not have any central coordinating or governing unit. In other words, there is no single, central server that coordinates or governs the system. Decentralized systems have both some advantages and disadvantages compared to centralized systems, so which of these two topological archetypes you choose for your system depends on which of the advantages you need or want.
Decentralized systems can be divided up into two categories:
- Decentralized Server Systems
- Peer-to-peer (P2P) Systems
Decentralized Server Systems
Decentralized server systems are systems where the server-side of a client-server system is decentralized. For instance, a decentralized database such as Cassandra or MongoDB.
Decentralized server systems typically only decentralize the server part of the total system. The overall architecture is still a client-server architecture - with some nodes in the system being clients, and other nodes being servers.
Examples of decentralized server systems are:
- Apache Cassandra
- Amazon DynamoDB
Peer-to-peer systems (P2P), also sometimes referred to as peer-to-peer networks, are systems where all nodes in the network are both clients and servers. Each node (peer) both provides a service to other nodes (peers) as a server, as well as consume that service from other nodes as a client. Thus, all the nodes in a peer-to-peer system are each others peers - meaning equal in functionality and roles. The diagram below shows a fully decentralized system where all nodes have the same level of functionality and authority. That is why they are often referred to as peers - each other's equals.
Examples of P2P networks and P2P network algorithms and topologies are:
- Chord (algorithm)
- Kademlia (algorithm)
- Polymorph polyring (algorithm)
Blockchain systems such as BitCoin, Ethereum, LBRY etc. also use P2P networks to communicate and collaborate. They do so because blockchain systems, like databases, keep a distributed state, so the nodes in a blockchain system need to reach a consensus about what that state is.
Note: Some blockchain systems have nodes that do not all perform the exact same job / role. For instance, some nodes are "validator nodes" and other nodes are "wallet nodes" etc. Such blockchain systems might be classified as decentralized server systems instead of pure P2P systems. However, what matters is not what classification you give a given blockchain system. What matter is that you understand how it works.
Decentralized Systems Benefits
Decentralized systems can have a few benefits compared to centralized systems - depending on how these decentralized systems are designed. Some of these benefits can be:
- Greater resilience
- Horizontal scalability
- Lower hardware costs
I will explain these benefits in a bit more detail in the following sections.
A well-designed decentralized system can have greater resilience than a centralized system, as a decentralized system does not have a single point of failure that can pull down the entire system. If one node in a decentralized system crashes, the other nodes in the system can take over.
A well-designed decentralized system can often scale reasonably well horizontally - meaning scaling by adding more nodes (computers) to the network, rather than having each node use more powerful hardware (vertical scaling).
Lower Hardware Costs
P2P networks can sometimes run directly and exclusively on the end users devices (computers, phones, consoles etc.). In these situations the end users are contributing the hardware needed to run the system. Thus, the creator of the software creating the P2P network can save a lot of costs on hardware. They will most likely not be able to have zero hardware costs - but probably significantly less than if they had to pay for all the hardware used to run the system.
Decentralized System Challenges
There are some types of functionality that are more challenging to achieve in a decentralized system than in a centralized system. Some of these types of functionality are:
- Decentralized consensus
- Broadcast, multicast, routing and lookup
One of the biggest challenges in decentralized systems is to reach consensus about a shared state - if changes to that state can be initiated by more than one node in the system. By "state" is typically meant some data stored in what corresponds to a database - a decentralized database, that is.
If two or more nodes in a decentralized system both try to change the state of the same logical object, somehow the system needs to be able to determine in what order the state changes should be applied.
Imagine if two nodes in a system both wants to change the "name" of the same "customer" in their shared state. If the first node wants to change the name to "Satoshi", while the second node wants to change the name to "Vitalik" - which of the names does the customer end up with? This situation is illustrated here:
Decentralized consensus, also sometimes referred to as distributed consensus, is an extensive topic, and there are several different approaches to how to achieve it - so I will not go into more detail about it here. I will probably write more about it in a separate tutorial trail in the future.
Broadcast, Multicast, Routing and Lookup
Depending on the topology of the decentralized system it can be challenging to broadcast or multicast messages effectively and efficiently to all, or a subset of the nodes in the network. By effectively I mean making sure that all the intended nodes actually receive the messages. By efficiently I mean without the nodes receiving the messages more than one time. Some models of decentralized broadcast may be able to guarantee one but not the other.
Similar issues exist around performing efficient message routing and lookup of nodes or data in the system. How do you efficiently discover what other nodes are part of the system? How do you efficiently lookup the location of a specific object if that object is only stored on one node in the system?
The topology used by a decentralized system has a lot of impact on these issues. You might have to design the topology of your system to fit your specific needs, rather than using the same, generic topology for all use cases.
The issues of broadcast, multicast, routing and lookup is what I designed the P2P topology of the Polymorph polyring topology to address.