Two methods for achieving decentralization are: disintermediation and competition.
Disintermediation
The concept of disintermediation can be explained with the aid of an example. Imagine that you want to send money to a friend in another country.
You go to a bank, which, for a fee, will transfer your money to the bank in that country. In this case, the bank maintains a central database that is updated, confirming that you have sent the money.
With blockchain technology, it is possible to send this money directly to your friend without the need for a bank. All you need is the address of your friend on the blockchain.
This way, the intermediary (that is, the bank) is no longer required, and decentralization is achieved by disintermediation.
It is debatable, however, how practical decentralization through disintermediation is in the financial sector due to the massive regulatory and compliance requirements.
Nevertheless, this model can be used not only in finance but in many other industries as well, such as health, law, and the public sector.
Contest-driven Decentralization
In this method involving competition, different service providers compete with each other in order to be selected for the provision of services by the system.
This paradigm does not achieve complete decentralization. However, to a certain degree, it ensures that an intermediary or service provider is not monopolizing the service.
In the context of blockchain technology, a system can be envisioned in which smart contracts can choose an external data provider from a large number of providers based on their reputation, previous score, reviews, and quality of service.
This method will not result in full decentralization, but it allows smart contracts to make a free choice based on the criteria just mentioned.
This way, an environment of competition is cultivated among service providers where they compete with each other to become the data provider of choice.
In the following diagram, varying levels of decentralization are shown.
There are many benefits of decentralization, including transparency, efficiency, cost saving, development of trusted ecosystems, and in some cases privacy and anonymity.
Some challenges, such as security requirements, software bugs, and human error, need to be examined thoroughly.
For example, in a decentralized system such as Bitcoin or Ethereum where security is normally provided by private keys, how can we ensure that an asset or a token associated with these private keys cannot be rendered useless due to negligence or bugs in the code?
What if the private keys are lost due to user negligence? What if due to a bug in the smart contract code the decentralized application becomes vulnerable to attack?
This view raises some fundamental questions. Is a blockchain really needed? When is a blockchain required? In what circumstances is blockchain preferable to traditional databases?
To answer these questions, go through the simple set of questions presented below:
Question | Yes/No | Recommended Solution |
Is high data throughput required? | Yes | Use a traditional database |
No | A central database might still be useful if other requirements are met. For example, if users trust each other, then perhaps there is no need for a blockchain. However, if they don’t or trust cannot be established for any reason, blockchain can be helpful. | |
Are updates centrally controlled? | Yes | Use a traditional database |
No | Use public/private blockchain | |
Do users trust each other? | Yes | Use a traditional database |
No | Use a public blockchain | |
Are users anonymous? | Yes | Use a public blockchain |
No | Use a private blockchain | |
Is consensus required to be maintained within a consortium? | Yes | Use a private blockchain |
No | Use a public blockchain | |
Is strict data immutability required? | Yes | Use a blockchain |
No | Use a central/traditional database |
Answering all of these questions can help you decide whether or not a blockchain is required or suitable for solving the problem.
Beyond the questions posed in this model, there are many other issues to consider, such as latency, choice of consensus mechanisms, whether consensus is required or not, and where consensus is going to be achieved.

Suryateja Pericherla, at present is a Research Scholar (full-time Ph.D.) in the Dept. of Computer Science & Systems Engineering at Andhra University, Visakhapatnam. Previously worked as an Associate Professor in the Dept. of CSE at Vishnu Institute of Technology, India.
He has 11+ years of teaching experience and is an individual researcher whose research interests are Cloud Computing, Internet of Things, Computer Security, Network Security and Blockchain.
He is a member of professional societies like IEEE, ACM, CSI and ISCA. He published several research papers which are indexed by SCIE, WoS, Scopus, Springer and others.
Leave a Reply