Blockchain is not a magic bullet for all applications. (Part 2)

by Lumai Mubanga

In part one, we stated that blockchain is not the answer or magic bullet for any challenge or problem. Any application designed for the blockchain must meet a certain specific criterion to adapt to that complex ecosystem. Three specific requirements discussed in part 1 included the need for that application to use a database, the absence of a central authority and immutability of its data. This article considers three more.

Will it involve multiple parties?

Some applications are designed for a few individuals while others are designed for multiple or millions of users. This deserves serious consideration. If less than three parties are involved, they may not need to use a blockchain. The reason is that two people or entities can easily reach a consensus. Since the main characteristic of blockchain is decentralization based on a trust model, few individuals who may be using an application can easily reach a consensus. However, huge applications with millions of users will need a mechanism to reach a quick consensus. Such an application will definitely require the use of a blockchain. The number of parties is another criteria.

Transactions processing speed

The rate at which an application is required to process the transaction is a critical consideration before deciding whether it should be placed on a black chain or not. If the application is required to process many transactions per second, it is not recommended to place it on the blockchain. At most, many blockchain systems can only handle seven or eight transactions per second. Compare this to VISA for example which can handle close to 2000 transactions per second. Thus, a transaction with a high-frequency rate of transactions should not use a blockchain because of the potential delays that will definitely affect its performance. Blockchain as at now cannot handle that kind of volume.

Another example of applications that may not use blockchain is high-frequency trading in the stock market. With almost a million transactions per second, it may not be able to use the blockchain platform to handle this kind of transaction volume.

Of course, hyper ledger design is currently undertaking tests regarding high volume transactions and in a few years, these criteria may well be outdated sooner or later.

Does the application require enough Active Entities?

Blockchain thrives on consensus mechanisms and if the system will employ a voting system to reach that consensus, then the system or application will require enough entities actively participating. This brings to mind permissionless blockchain systems, which allows as many participants as possible to enable enough entities to participate. Enough entities are required to maintain the blockchain. As a public system, it will require quite a number of entities to help maintain the fairness of the decisions. Otherwise, some dishonest elements may cheat. From this requirement, an application needs to be robust, flexible and the complexity to absorb these dynamics.

In conclusion, an application will need the above characteristics to adopt the blockchain and leverage on its dynamism, advantages and security features. Frequency or rate of completing transactions, enough active users and millions of users who may require a quick consensus will remain critical criterion far into the future until such a time that technology will avail us with alternative solutions.