Blockchain and related decentralization technologies are in the spotlight. More and more businesses are trying to innovate and optimize by implementing decentralization. But what exactly is decentralization?
Is it really any good and necessary? How can it improve anything? An in-depth analysis of many projects shows that there is some confusion when those questions arise, even among projects leaders. In this article, we will try to clarify, what decentralization really is.
The word implies that decentralization is the absence of a single center. The center is a system’s unit that cannot be substituted by something or someone else, so, if it is removed from a system, the whole system degrades or even ceases functioning altogether. Not long ago, the Google cloud went offline only because of a small bug in the settings of a certain unit, which made this setting a center for the whole Google cloud. Such an incorrect setting that can paralyze the system is an example of a technical center.
Another example. Google+ no longer exists simply because Google decided to shut it down. One centralized solution by the company management leads to the network’s shutdown despite some user’s wishes to carry on using it. This is a control center.
In a word, one of the advantages of decentralization is the higher stability of a system. The truly decentralized system must remain operational even when a large part of its units (hardware) or nodes (users) went offline, are restricted or operate in improper ways. For instance, Bitcoin remains operational as long as at least one node exists. It also works properly even if one node less than half of all nodes show malicious behavior, collaborating to take the network out.
To make a system totally decentralized, numerous rules, followed by all users, are required. It is like a traffic code – many cars ride in a decentralized manner, each controlled by its driver, each of whom can be unaware of one another. Yet, when everybody follows the same rules everything works efficiently and even securely.
Can those universal rules be considered a center of some sort? No, because it’s neither a unit nor a system’s component. Since rules are pre-defined, they cannot be withdrawn or taken away. Rules are what the system is, and it is worth to fully grasp this concept. In a decentralized system, rules are unchangeable. In the best-case scenario, rules should stay forever. However, it is never possible to foresee everything that might happen in the future, so rules must also contain some rules on how they can be changed. For instance, Bitcoin protocol requires validation by all miners of the network, otherwise, the network forks and continues to exist in several forks.
The most vibrant fork took place back in 2016 when the Ethereum community could not reach a consensus on how bugs in smart-contracts should be fixed, so the network forked into Ethereum (ETH) and Ethereum Classic (ETC).
A decentralized system has to be tolerant to changes in users numbers and to users malicious behavior. Speaking of the traffic code analogy, what makes people follow the rules? We can say that it is something similar to proof of stake. By disobeying the rules, people face the risk to pay a significant fine, and sometimes put their lives (and that of others) in danger. Both are serious reasons to obey the rules, and it (mostly) works. Even when certain users break the rules, it does not cause a total breakdown of the system.
Thus, a decentralized system shell poses the following properties:
- No technical center – losing components (servers, users, nodes) does not make the system non-operational.
- No control center – any decision by a small group of users does not make the system non-operational.
- Attacks tolerance – Rules on how users and nodes cooperate are stipulated. Following the rules is rewarded and malicious behavior is punished.
- All users are equal – anyone can join the system under the rules.
Unfortunately, most projects trying to decentralize successful business models often concentrate only on the first rule. Most try to create a single governing center. What usually happens, in that case, is, that innovation is squashed, since it remained centralized, just as the original successful business they took for a model. The main reason for this is, that most CIOs have a very imprecise concept of decentralization. Hopefully, this article will change that.
Among the most serious issues surrounding decentralized projects are data storage and access to that data. The problem is, that at the moment there are no complete solutions for decentralized data search and storage. Files storages like IPFS, Sia, Storj and Ethereum Swarm only allows you to store data, but not to search it.
Usually, databases are utilized for data storage and swift data search. Databases should not be confused with file storages. It is important to understand, those file storages simply store data as a pack of bytes – it is not concerned with what’s inside. Therefore, the data can be found only using the exact name, not the content itself. A database is a structured data storage. The data are stored in tables and it enables you to quickly find particular rows that match your search request.
To better understand the difference between data storage and database, let’s imagine a pack of files that are digital spreadsheets, like Excel or Numbers, called “My June spending”, “My July spending” and so on. From a file system’s perspective, each file is just bytes. Its content may be judged only superficially, using its name. Using file storage, you can find data about spending on a precise month, but to get a detailed understanding of what each spending was about you will need to use a special application. This way, you can recall that this June you bought a new iPhone, as well as Toblerone chocolate in the grocery store.
But what if you remember that you bought an iPhone, but you need to know what exact month you purchased it? Normal file storage won’t help you to find the answer quickly. You will need to open the files individually and search them manually whether it mentions your iPhone purchase, which would take far too much time for any company.
A database can solve this problem. With some simplification, your spending records are no longer in different files, but in one database, so you can make queries like “How many Toblerone have I purchased this year” or “when did I buy an iPhone” or even “what is my month total spending” and the database will give you the answer immediately.
When it comes to apps, databases are irreplaceable, since all apps work with data. The trouble for dApps is – there are still no decentralized databases yet. Naturally, projects, that claim to be decentralized, either do their best to stay decentralized and use data storages like IPFS (losing the ability to search data) or use centralized databases (thus putting an end to their decentralization). Whichever way, they lose the competition to centralized apps in either productivity and functionality, or in decentralization.
That’s why creating a decentralized database is so important. Just as the programmable blockchain Ethereum gave a boost to simple apps on smart-contracts, a decentralized database will start an era of serious, competitive, world-scale decentralized apps.
From our research, the most advanced decentralized database we have seen so far is Ties.DB. This DBMS is based on a distributed DBMS Apache Cassandra and implements it with publicity BFT protocol and incentive system for users. Ties.DB forms a decentralized network of farming computers with Ties.DB software that provides its resources (storage space, processing power). Their combined resources is what forms Ties.DB. Users of dApps built upon Ties.DB use those resources, paying a small price in TIE tokens. This payment is transferred to the farmers according to their contribution to processing user queries. Data that users upload to the database are replicated and split into packages to guarantee data security and high accessibility speed. Each table is stored on many nodes, but each node only stores a piece, so nodes are not complete copies of one another as may be the case in some popular blockchains.
Since everything is public, anyone with sufficient hardware resources can become a farmer, similar to most blockchain mining principles, so the network can be easily scaled to meet increasing demand.
Presently, Ties.DB is in Alpha-Version and running a test network, welcoming dApp’s designers to test it. You can give it a try at https://github.com/TiesNetwork/ties.db/releases. It also has a demo app to show how dApps can use Ties.DB: https://github.com/TiesNetwork/demo-app/releases.