Debunking the myths of enterprise blockchain

We’ve made great progress as an industry illustrating how enterprise blockchain can help change everyday life. Heck, I rarely get the sorts of questions that confuse Bitcoin with the broader applications of blockchain. This is progress!

However, with the torrid rate and pace of blockchain innovation in our industry, confusion is a given. I plan to use this article as an on-going FAQ on “myths” that I hear, that don’t quite jive with my perception. Here goes:

Myth: Enterprise blockchain is all hype, no substance

Or, today there is little to no traction on real transacting consortiums on enterprise blockchain.

Reality: I have many daily thrills (along with some new grey hairs) that are the direct result of real transacting consortia running on the IBM Blockchain Platform, powered by The Linux Foundation’s Hyperledger Fabric. Some consortia, such as global trade finance, have generated several million blocks on the ledger. Members of this consortium have yielded real value from their blockchain solution. It has reduced the average time to settle disputes across suppliers and partners from 44 days to under 10, returning those in-dispute funds back to the business.

The IBM Food Trust network is continually generating blocks and the number of participants continues to grow — now over 12 food industry leaders and influencers anchor the community. Members benefit from an ability to trace-back and trace-forward food supply chain data. This is particularly important when identifying and containing the source of contaminated food for recalls. Frank Yannis of Walmart said, before blockchain it took them over six days to trace food back to its source; now it takes seconds.

In total, our blockchain service is providing support for over 40 transacting consortia where multiple institutions are deriving value daily via the IBM Blockchain Platform. We also have a couple thousand worldwide, cross-industry customers on IBM Blockchain Platform, who are expanding the “transacting consortia” list on a daily basis.

Recently, we added TrueTickets, Loyyal, Tririga and Integra. This is no small feat. Some of these consortia have taken over two years to stand up on blockchain, getting business, legal and regulatory approval across multiple institutions. To say there is, “just hype, no substance” would not fairly represent the hard work that these trail blazers have put into their live running consortia on blockchain. Myth busted!

Myth: Enterprise blockchains are always private blockchain

Reality: It is important to understand the distinction of private versus public, and permissioned versus permissionless. I would agree that enterprise blockchains are always permissioned. I do not agree that enterprise blockchains are always private. They most certainly can be public as well.

Enterprise blockchain distributed ledger technologies (DLTs), like Hyperledger Fabric, Hyperledger Sawtooth, EEA-Quorum and Corda, are all permissioned blockchains where the members (trust anchors) are known to the network based on cryptographic identities. Permission is key to enterprise blockchain, enabling the accountability needed for the institutions participating in the blockchain network to do know your customer (KYC) on members and pass audits.

The decision on whether an enterprise network is public or private is mostly a decision left to the board that governs a consortium. They can decide to publicly list the “phone number” of the network or keep it private as an unlisted number. We will soon see the emergence of enterprise blockchain registries to provide a directory of listed consortia — think programmable web for blockchain. The registry listing will describe how institutions can join and use the network’s features, including business obligations and rewards, and the technical application programming interfaces (APIs) to connect to the network.

These blockchain registries will go a long way to making enterprise consortia known, and will create a network of networks effect, where new business processes can leverage capability across multiple networks — as a trade finance consortium network can use a payments network to pay for goods. This will help fuel Metcalfe’s Law — where the number in a network is square to the number of nodes — to grow membership in enterprise blockchain networks and bust the myth that enterprise networks are always private.

Myth: Hyperledger Fabric only runs on mainframes

Reality: This is simply not true. While IBM Blockchain Platform “rocks” on a mainframe (as I say, they go together like peanut butter and chocolate), IBM Blockchain Platform can deploy and operate Hyperledger Fabric peers just about any place, whether that be hardware architecture or any cloud. In fact, Hyperledger Fabric is well on its way of becoming standard issuance — a de facto standard — running on all these clouds, which is a strong testimony that it does not require a mainframe to run.

Now, regarding running on a mainframe, IBM Blockchain Platform’s Enterprise and Enterprise+ deployment plans, do dispense Fabric peers to mainframes, running across IBM Cloud data centers. While this is transparent to the end-user, we do this because — as a service provider — the mainframe provides us a high degree of assurance around security, crypto-key management, resiliency and compliance (GDPR and others). Our newly announced Starter Plan, dispenses to our Intel-based Kubernetes clusters spread across our worldwide cloud. So, in short, IBM Blockchain powered by Hyperledger Fabric is designed to run anywhere. Myth busted!

Myth: Blockchains do not perform

Reality: It is known that Bitcoin and Ethereum operate in the tens of transactions per second and have transaction latency of confirmation in minutes to sometimes hours. However, permissioned enterprise blockchains can and do perform well, and at levels that satisfy many enterprise use cases. We are starting to see the first set of performance reports showing evidence that enterprise platforms such as Hyperledger Fabric, Hyperledger Sawthooth, and R3 Corda can achieve performance in the range of hundreds to thousands of transactions per second, often with sub-second response times.

It’s important to note that “your mileage may vary” depending on the computational complexity of the smart contracts, the data types and payload sizes being processed, the type of consensus algorithm, as well as the number of peers involved in endorsing, validating transactions during the consensus process. Of course, your performance is also a function of the cloud/infrastructure provider and service levels selected.

It should also be understood that the major cryptocurrency vendors purposely throttle transactions during the consensus process to ensure those with the fastest computers gain control over the network. These permissionless blockchains cleverly gain consensus while keeping the identity of network members anonymous, using a computationally intensive activity called mining.

To me, mining is like the hazing process used to test the determination of a pledge to join a college fraternity. If you keep successfully passing trials, you are trusted and accepted into the group. With this, mining is a huge drag on time, energy and performance. Permissioned enterprise blockchain technology, on the other hand, do not employ such throttles or mining. Given the members are known in a permissioned network, permissioned consensus algorithms (like PBFT, CFT, POET) can get right down to business and perform without mining overhead. Different consensus algorithms and smart contract construction will ultimately dictate your results.

In an attempt to create an apples-to-apples comparison, an IBM Research paper documented a use case called Fabcoin, which simulated the unspent transaction output (UTXO) model used by Bitcoin.

Using Hyperledger Fabric 1.1 preview, against a specific network configuration, a very high rate (1000+/tps) was achieved. Hyperledger Fabric 1.1, available today, is even further tuned. Identifying cryptographic signatures, an early bottleneck in Fabric performance, IBM engineers cleverly implemented a parallel signature scheme which boosts performance even further.

Keep an eye out for a new project called Hyperledger Caliper, which intends to deliver a framework to measure DLT performance and scale. That project is working closely with the Hyperledger Performance and Scale Working Group who are defining a set of metrics and the means by which they should be measured, so that blockchain performance can be compared fairly. All said, enterprise blockchains do perform, and we are already seeing a track record for delivering continual improvement. Myth busted!

Myth: Smart contracts pose a security vulnerability for the enterprises

Reality: Well, this myth can hold some truth if casual choices are made in blockchain platform and network governance schemes. Most Blockchain platforms do not come with warning labels stating how to write trustworthy smart contracts and deploy them in a controlled and democratic way. The Ethereum DAO attack was not as much a flaw in Ethereum but rather, as a flaw in governance of the DAO. If Ethereum was a permissioned network, the hackers would have been known to the network’s other members and would be accountable for their actions. That said, what happened with the DAO on the public Ethereum network could happen in an enterprise blockchain network.

There is a path forward here where the three ingredients I mentioned — permissions, governance and mainstream programming languages — can be applied to positively change the attack surface on smart contracts and ultimately debunks this myth. While enterprise blockchain technologies all address the permissioning point, the other two areas vary widely.

Governance is the big one, and includes consortium charters, legal frameworks and agreements, as well as tooling. When done right, governance tools maintain decentralization checks and balances, where everyone has control, but no one is exclusively in control. Most popular enterprise blockchains do not explicitly support governance processes. However, Hyperledger Fabric has a policy-based configuration that enables governance to be built on top. Specifically, IBM Blockchain Platform (IBP) offers a rich set of governance tools, enabling decentralized systems management for members joining a network, smart contract deployment and transaction channel administration. Using a signature workflow tool, members vote on changes to the network. The policy dictates the outcome (fore example, majority rules). IBP makes it easy for governing members of a blockchain network to reduce venerability due to unknown, bad or sloppy actors. I have not seen any other enterprise DLTs support this level of governance right out of the box. With that said, tools are just one aspect of governance. Vulnerability is best mitigated when a consortium has a governance model that is comprehensive, enforceable and measured.

Hyperledger Fabric also employs the most comprehensive and mainstream approach to writing smart contracts. With Fabric, you have the choice to write smart contracts in the industry’s most popular programming languages. Contracts can be written in Javascript, Go and soon, in Java. In Fabric, these languages run unmodified in secure Docker containers. Fabric also supports smart contracts written in the Hyperledger Composer framework, which provides an easy to use, Javascript-based modeling language for creating human readable contract definitions. This is not the case for other enterprise platforms that use obscure or heavily modified programming languages.

Security and vulnerability of smart contracts is a topic worthy of your time an attention. Poor choices can present security issues in the Enterprise. We have made this a priority in our work with Hyperledger Fabric, Composer and IBP. Using these tools and services, this myth is bus-table.

Myth: Hyperledger Fabric blockchain channels do not scale

With Equifax, Facebook and GDPR in the news, privacy is a hot topic these days. Channels is one way to achieve privacy in a Hyperledger Fabric network. For this myth, I’ve called upon the help of Bobbie Cochrane and Chris Ferris to assist in the debunking process of this important topic.

Reality: Introduced in the Linux Foundation’s Hyperledger Fabric v1.0 last summer, channels provide a much sought-after data-partitioning capability, limiting the distribution of information to only those with a need to know. A Hyperledger Fabric channel enables private communication amongst a subset of network members. Akin to Slack channels, which direct communications to channel subscribers, Fabric’s channels limit the visibility of information to channel members. Each channel maintains a separate distributed ledger that shares the infrastructure and contract logic of the blockchain network while defining its own governance policies.

Channels are being effectively used to achieve privacy requirements in several major blockchain deployments, including the we.trade trade finance consortium, CLS group’s bilateral payment netting solution, and SecureKey’s verified:me identity verification network. For these users, channels do perform and scale and I’m sure each of them would bust the myth here and now.

Also, the Hyperledger Fabric community continues to test and tune channels. In one recent test, a configuration of 325 channels supporting bilateral communications between 26 organizations and 6 auditors — a total of 128 peer nodes — was able to achieve 1500 tps with sub-second latency without taxing the peers.

Fabric channels were recently criticized in SWIFT’s Nostro reconciliation proof-of-concept, where the number of channels needed was projected to grow to 100,000 to ensure the privacy of asset exchange across participants and all permutations of their relationships. Gideon Greenspan comments in his blog that “assets cannot be moved from one channel to another without the help of a trusted intermediary which is active on both [channels]”.

The requirement to keep data private, using trusted intermediaries across a complex set of relationships will certainly present operational challenges. This is true of all blockchain architectures that introduce a “intermediary” (such as Fabric channels, Corda notaries and others). For these cases, Hyperledger Fabric has started to introduce new features, such as private transactions and zero knowledge proofs (ZKP), which are used in conjunction with channels to achieve the required privacy goals without the constraint of an intermediary.

Admittedly, the operational user experience for configuring channels and deploying chaincode could be improved. However, once established, adding or removing members to and from a channel’s consortium is less cumbersome. The IBM Blockchain Platform adds operational tools that shield the user from much of this complexity, and we continue to work with the IBM Design team to improve this experience.

Elli Androulaki, Sharon Weed Cocco, and Chris Ferris wrote the article, Private and confidential transactions with Hyperledger Fabric, that really gets to the essence of busting this myth by describing how and when to use channels most effectively, and how private transactions and ZKP can be used to create the right level of privacy and confidentiality for any given solution.

In summary, channels are just one tool to achieve privacy in Fabric-based networks. When used correctly, like in the references and performance data shared above, they scale just fine. There are cases where using channels can present operational challenges, like the SWIFT example. For these cases, Fabric has an emerging set of privacy features, like private transactions and ZKP to address these challenges.