Blockchain – Disruption or Hype?

The following is an extract from one of the Ethereum-related websites. It is a description of the different types of blockchains, which is as good as any other description used elsewhere. Please note, the purported benefits of private or enterprise-type blockchains as quoted in the contents below are not endorsed or supported by SIOTech World. We will outline the benefits as they are generally perceived but provide our own opposing perspectives as well.

Public blockchains:

A public blockchain is a blockchain that anyone in the world can read, one that anyone in the world can send transactions to and expect to see them included if they are valid, and one where anyone in the world can participate in the consensus process – the process for determining what blocks get added to the chain and what the current state is. As a substitute for centralized or quasi-centralized trust, public blockchains are secured by crypto-economics – the combination of economic incentives and cryptographic verification using mechanisms such as proof of work or proof of stake, following a general principle that the degree to which someone can have an influence in the consensus process is proportional to the quantity of economic resources that they can bring to bear. These blockchains are generally considered to be “fully decentralized”. In our view, this is not accurate because the degree of decentralization differs from one public blockchain network to the next.

Consortium blockchains:

A consortium blockchain is a blockchain where the consensus process is controlled by a pre-selected set of nodes. For example, one might imagine a consortium of 15 financial institutions, each of which operates a node and of which 10 must sign every block in order for the block to be valid. The right to read the blockchain may be public, or restricted to the participants, and there are also hybrid routes such as the root hashes of the blocks being public together with an API that allows members of the public to make a limited number of queries and get back cryptographic proofs of some parts of the blockchain state. These blockchains may be considered “partially decentralized”.

Private blockchains:

A fully private blockchain is a blockchain where write permissions are kept centralized to one organization. Read permissions may be public or restricted to an arbitrary extent. Likely applications include database management, auditing, etc internal to a single company, and so public readability may not be necessary in many cases at all, though in other cases public auditability is desired.

Well, that’s the logic being touted out there. An interesting quote from a passionate blockchain enthusiast that is very representative of the general mindset, reads as follows: “users are able to create database environments where multiple mutually untrusting users can exchange value … without a central coordinator. By combining concepts from cryptography …, blockchains remove the need for trust in a system, ensuring that users … interact with reduced reliance on third party authorities”.

However, there already are ‘trusted’ participants in these enterprises or value chains. Attempting to create ‘trustless’ transactions makes no sense. Immutability is not achieved either. What makes an open blockchain such as Bitcoin immutable is not the fact that it uses a blockchain or cryptography. Immutability is achieved when the blockchain, the Proof of Work protocol and incentives work together in a sufficiently decentralized context. The Bitcoin consensus mechanism overrides any one individual’s personal ambition. The system is designed to avoid one person taking control. So why would you want to replicate these concepts in an enterprise or B2B context? Bitcoin is designed to be inefficient. It is a deliberate feature. Attempting to create faster but less secure consensus mechanisms completely misses the point.

It is clear that the adaptation of ‘blockchains’ to the enterprise context focuses more on the technology, the security, the transaction-throughput and so-forth. Too little consideration for practical reality is given. The use-cases touted for enterprise blockchains have clearly emerged from an insular technical paradigm, a paradigm that appears to be oblivious to the cooperative processes already entrenched between competitive participants.

In banking, for example, it ignores the extensive legal, compliance and contractual mechanisms already in place to enforce honest cooperation, the regulatory oversight to protect consumers and the lack of the political will for participants to focus on interoperability projects rather than their own profit motives. Using blockchains to resolve interoperability issues reflects the mindset of a techie or consultant, not the mindset of CEOs or managing directors who will have to approve and sign off on the spend for a blockchain project that simply gives them what they already have.

Let’s use a poignant, real-life example that highlights the issues around interoperability between competitors, viz. banking.

Banks already have contractual obligations and payment reconciliation mechanisms between them to ensure that the correct transaction amounts are cleared and settled between them. They already have the central bank that further ensures that the correct amounts are settled between them. In the case of card payments, the likes of Visa and Mastercard also keep records of transactions (that need to match the bank’s records) in order to appropriately charge banks for their services.

Furthermore, various interbank payment bodies and forums are in place to ensure continued interoperability. Do you honestly believe that banks do not have the ability for example to share debit order information, beneficiary payment information, or even KYC information so as to enable customers to seamlessly switch between banks? Of course they have the ability. But they do not. It is not a priority for them. Why should they lower the hurdles to make it easier for their clients to leave them for another bank?

Banks offer an excellent illustration of where it makes no business sense to spend money on an interoperability project that could potentially hurt its own bottom line. Banking CEO’s do not have the time or inclination to approve and sign off the spend for projects that will give them what they already have.

In any context where decision-making about transaction records is not decentralized, where trust in one or more entities is required to validate transactions, or where transactions can be censored or approved by senior authorities, the use of the term ‘blockchain’ becomes problematic and causes confusion and fierce debates. Furthermore, when the average layman hears the word blockchain, Bitcoin or cryptocurrency comes to mind. It would, therefore, be circumspect to use the term ‘DLT’ rather than ‘blockchain’ in an enterprise context.

Most importantly, distributed ledger solutions in a business, non-monetary context, do not solve for anything that today’s technology can’t already handle. DLTs become a complicated and needless waste of resources in its attempt to solve an interoperability problem, which is a business/political problem, not a technology problem. A normal database would very likely be a much more efficient solution in just about any B2B context, assuming you can get competing parties to agree to work together in the first place.

The videos below are examples of where others share our views that the perceived value added by enterprise blockchains are minimal.