Blockchain explained

Understanding blockchain: Debunking the myths of enterprise blockchain

Share this post:

Since being published, the next generation of the IBM Blockchain Platform has been announced. Therefore, IBM Blockchain Platform Starter Plan will be removed from the IBM Cloud Catalog starting July 5th, 2019 and you will not be able to provision new instances after that. However, existing instances will be supported until June 4, 2020. To continue your blockchain developer journey with the next gen version of the IBM Blockchain Platform, go here.

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:

The following busted myth was added May 10, 2019

Myth: The quantity of DLTs offered is more important than quality and depth of support when selecting a blockchain vendor

Steve Jobs once said, “Do not try to do everything. Do one thing well.”

Reality: Some blockchain-as-a-service vendors have taken the approach of offering several DLTs to their clients, the implication being that quantity of choice is what’s best. Sure, this might be appealing to tourists looking to explore and evaluate the blockchain landscape, but in reality, what do those options provide? Often, vendors provide only shallow support and capabilities, and clients spend more of their valuable time, energy and money filling in the missing pieces of the technology and less time building out their blockchain solution, where the real business value is derived. More often than not, this mismanagement of focus leads to failed projects. Don’t get me wrong, there is nothing wrong with having choices, but ultimately you do have to make a choice and the choice(s) you make can have profound consequences. IBM Blockchain Platform is built around one DLT, The Linux Foundation’s Hyperledger Fabric, for several important reasons, including the following:

Innovation through open source and record time to quality

Some DLTs are proprietary, closed, or nearly closed. These options contradict the blockchain promise of transparency and distribution, as they rely on centralized bodies of decision makers to direct the technological roadmap. This is like designing a single point of failure into your solution. Blockchain is a team sport and innovations are found via the collective IQ of the group, not through a lone organization.

True open source projects like Linux, Apache web server and open collaborations like Java, combined to accelerate the e-business era. While there were other choices (Solaris, Netscape Web Server, SmallTalk) Linux, Apache and Java where vaulted by an odd balance of fierce collaboration and fierce competition. Vendors openly collaborated to create these de-facto standards, contributing diversity of thought, leading to innovative features and increased quality, all in record time. These technologies were also designed to be modular, enabling vendors to develop their own unique value as “plug-ins.” Vendors monetize their investment in open source by offering their own value-added distribution of the technology, fueling fierce completion. This behavior produced a wonderful outcome for the industry, driving quality up, innovation up, adoption risk down and price down. If a vendor in this community let a consumer down (for example, raised their prices), the consumer had freedom of action to move to another vendor in the community with little friction.

Deploy the IBM Blockchain Platform across multiple environments

That same trajectory is happening today with open coopetition within Hyperledger Fabric, resulting in rapid maturity, diverse innovation and broad choice with price competitiveness.

The openness of Fabric has led to true open innovation. For example, eesearchers with the University of Waterloo and University of Massachusetts developed a way to optimize Hyperledger Fabric peer design resulting in increased transaction throughput from 3,000 to 20,000 transactions per second. This example is one of many and why a well-managed, true open source blockchain project is critical, and enables the project to see rapid, quality innovation at scale.

Today, Fabric is now offered by many commercial vendors including IBM, Oracle, Amazon, Microsoft, Huawei, Cisco and Alibaba. Each vendor offers the same de-facto-standard Hyperledger Fabric, while enhancing it with their own value. For example, Oracle offers differentiated ledger database options, IBM offers developer, operational and governance tools enabling Fabric to run on any Public or Private Cloud, Microsoft offers deployment templates to Azure and integration with their IAM Services. IBM and Microsoft have even demonstrated how a Fabric network can be co-created across IBM Cloud and Azure.

When done right, a single DLT choice like Hyperledger Fabric, can lead to multiple, viable choices for consumers that is poised to repeat the formula of Linux, Apache and Java, to create the next chapter of the internet.

Hyperledger Fabric is a DLT built for business

For a DLT to be suitable for enterprise use, it must have several essential business elements: accountability, privacy, scalability and security. This video from IBM THINK describes why these characteristics are fundamental needs of business blockchains. Blockchain-as-a-Service providers offering several DLTs often don’t have the experience to help clients adequately evaluate which to use. All DLTs are not equal, and IBM has built its offerings around the one which was expressly designed with the modularity, pluggability, security and scalability required to build custom solutions for business.

A vendor’s depth of expertise and investment in a technology that is designed for business can save clients significant time and money. Look for vendors that make an investment in developer tools, governance tools and operational tools, who provide blockchain deployment workshops and consulting services, who support a variety of deployment options, fight against vendor lock-in and offer real 24x7x365 support for the DLTs they offer. Try this experiment. Ask a Blockchain-as-a-Service provider if they accept “trouble tickets” against the DLTs they offer. Ask about their service level agreements (SLAs). You might be surprised to learn very few actually support the DLT. This is not a problem if you are “tire kicking” but can be a huge risk if you are running a production consortium network.

A recent example occurred when a large production blockchain exposed a bug in the Hyperledger Fabric open source code. Within a few hours, IBM Blockchain Support provided a work-around to prevent any setbacks and in three days had a fix deployed to the client and delivered the fix to the opensource community. Software is never 100% perfect (because it is written by imperfect humans ;–) and when it comes to enterprise applications, it is essential that issues are resolved efficiently and effectively. The client told us that is exactly why they went with the IBM Blockchain Platform and Hyperledger Fabric, due to the depth of expertise and IBM and the open source community’s ability to respond quickly to address issues at any level.

In the end, Mr. Jobs’ advice to “do one thing well” is advice worth taking. Find a vendor that is collaborating and openly innovating by day, and fiercely competing by night. Depth of investment in the right DLT is a far superior strategy for clients wanting to make real blockchain progress. The myth of more is better is only good for exploration without commitment. If you are ready to commit, but are fearful of picking too early, or being locked in — fear not. There are low risk, high reward options. Vendors like IBM, that are all in on a single DLT, but are also collaborating with others who also offer that same technology, are by far your best choice to take your blockchain venture to the next level toward production.

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 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.

I have already added new myths and busted them. Stay tuned to this space, there will be more to come!

Connect with me @JerryCuomo on Twitter to continue the discussion.

Earlier additions to this post may reference Beta, but IBM Blockchain Platform has been officially released.

Simplicity, speed and value for blockchain developers

IBM Fellow, Vice President Blockchain Technologies, IBM Blockchain

More Blockchain explained stories

Why open source isn’t free: Support as a best practice

The use of open source code is on the rise. Red Hat’s 2021 Enterprise Open Source Report found that 90% of companies use open source code and 79% of IT leaders expect their business use of open source to increase. Also on the rise, unfortunately, is malware and ransomware up 158% in 2020 according to […]

Continue reading

Accelerating your journey to decarbonization through digitalization

Corporations around the world are increasingly focused on sustainability and implementing strategies for achieving net-zero emissions in greenhouse gases (GHG) by 2050 or sooner. To stop global warming and the impacts of climate change, we need to reduce the 51 billion tons of carbon emitted into the atmosphere annually down to zero, and limit global […]

Continue reading

Revolutionizing renewable energy certificate markets with tokenization

The Paris Agreement sets out a global framework to avoid dangerous climate change by limiting global warming to well below 2°C (3.6°F) and pursuing efforts to limit it to 1.5°C (2.5°F). It also aims to strengthen countries’ ability to deal with the impacts of climate change and support them in their efforts. More organizations are […]

Continue reading