Introduction and Definitions
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.
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.
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”.
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.
… the degree of decentralization differs from one public blockchain network to the next
The rationale for private blockchains
Enterprise blockchains came about as there was/is a perceived need for entities to exchange value or information in a trustless manner, similar to what Bitcoin and other open blockchains did. However, the requirements for enterprise blockchains are different in a B2B setting. Enterprises are concerned about the privacy and security of their data and IP. Enterprises also require faster transaction throughput compared to open blockchains. In a business context, open blockchains such as Bitcoin and Ethereum are criticized for their lack of scalability and performance. To quote, “Both Bitcoin and Ethereum blockchains suffer from poor scores in this area. For example, a recent blockchain game called Crypto kittles clogged the Ethereum network.”
As a result, enterprise or private/consortium blockchains operate differently in the following ways:
- They employ ‘permissioning’ whereby only ‘trusted’ participants run nodes, and users are given permission to participate in the system;
- Transactions can be made private; and
- They employ different consensus mechanisms to enable faster transaction throughput.
Somehow, the blockchain came to be known as “the technology underpinning Bitcoin”, and the blockchain somehow gained the status of being the real innovation. IBM is working with hundreds of enterprises on blockchain implementations. It appears that there have been tens of thousands of blockchain pilots run within corporations. So clearly the interest in blockchain is undeniable. The following video is a good demonstration of how blockchain technology is seen as the real disruption (a perspective that we do not agree with):
Because of the limitations of open blockchains as described above, the consensus protocols of private blockchains change the trade-off between speed, energy and security. The most secure protocols such as Proof of Work by design are energy-intensive and slow. In a private or permissioned chain, the network selects the groups that will run the nodes. Since these groups are selected from a pool of trusted entities, they create ‘trusted’ nodes. Trust is therefore much less of a concern in a business setting than it is for a public blockchain. Enterprise blockchains can therefore afford to use less secure consensus protocols to maximize the speed of transactions while reducing energy consumed.
Our perspectives on private blockchains
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.
The most secure protocols such as Proof of Work by design are energy-intensive and slow.
… Attempting to create ‘trustless’ transactions makes no sense. Immutability is not achieved either.
Enterprise blockchains are naively technology-driven
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.
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.
Banking – an industry that is apparently ripe for blockchain disruption:
Banking is an excellent example of where competitors have to cooperate. Banks need to facilitate transactions between their customers, and they have a fantastic example of a trusted authority, viz. the central bank. Enterprise blockchains would offer excellent value in such a setting right? Well, consider this.
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.
Enterprise ‘blockchains’ do not enable anything new.
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?
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.
…distributed ledger solutions in a B2B context do not solve for anything that today’s technology can’t already handle.