Contest-driven decentralization
In the 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. On the left-hand side, the conventional approach is shown where a central system is in control; on the right-hand side, complete disintermediation is achieved as intermediaries are entirely removed. Competing intermediaries or service providers are shown in the center. At that level, intermediaries or service providers are selected based on reputation or voting, thus achieving partial decentralization.
While 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 errors 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 one ensure that a smart property associated with these private keys cannot be rendered useless if the private keys are lost or, due to a bug in the smart contract code or the decentralized application becomes vulnerable to attack? Before embarking on a journey to decentralize everything using blockchain and decentralized applications, it is essential that you understand that not everything can or needs to be decentralized.
This view raises few fundamental questions. Is a blockchain really needed? When is a blockchain required? In what circumstances is blockchain preferred over traditional databases? To answer these questions, go through the simple set of questions presented here:
- Is high data throughput required? If the answer to this question is yes, then use a traditional database.
- Are updates centrally controlled? If yes, then use a conventional database.
- Do users trust each other? If yes, then use a traditional database.
- Are users anonymous? If yes, then use a public blockchain; if not, then use a private blockchain.
- If consensus is required to be maintained within a consortium then use a private blockchain, otherwise use a public blockchain.
Answering all of these questions can provide an understanding of whether or not a blockchain is required. 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. If consensus is maintained internally by a consortium, then a private blockchain should be used; otherwise, if consensus is required publicly among multiple entities, then a public blockchain solution should be considered. Other aspects like immutably should also be considered while making a decision about whether to use a blockchain or a traditional database. If strict data immutability is required, then a public blockchain should be used; otherwise, a central database may be an option.
As blockchain technology matures, there will be more questions raised regarding this model. For now, however, this set of questions is sufficient to decide whether a blockchain-based solution is required or not.