IBM’s Hyperledger isn’t a real blockchain — here’s why – The Next Web


Back in 2016, enterprise “private blockchain” was a new, unfamiliar idea. There were not many major players in the private permissioned blockchain space; a big name was IBM, whose contributions to Hyperledger Fabric has since brought its tech in front of the likes of Walmart, Nestlé, and Aetna.

You would think that the prominence and history of IBM’s brand would result in wide industry adoption of their blockchain tech, but instead, adoption has been sluggish and most solutions are still in the nascent proof-of-concept stages. This suggests that many of IBM’s enterprise customers are not satisfied.

The reason might be fundamentally about IBM’s technology; IBM’s Hyperledger isn’t really a “blockchain,” and what it does offer is hard to use and difficult to scale.

When I worked at JP Morgan in 2016, I led an emerging technology group that researched and vetted blockchains for the bank’s potential use and strategic investment. At the time, we did in-depth analyses of early versions of Hyperledger, Axoni, Symbiont, Tendermint, Ripple, and Ethereum.

My team discovered that the blockchain options in the market were technologically subpar for real enterprise use cases. These tech problems ranged from having code compiled down to computer “bytecode” that rendered business logic unreadable — and therefore hard to check for auditors — to running so slowly that one couldn’t perform helpful business transactions any better than with a traditional database.

We used to joke if we were to go to our bosses at JP Morgan and tell them that you couldn’t upgrade your business smart contracts in Ethereum without hard forking the entire network, we would be laughed out of the room.

So we came up with a list of questions that we asked at JP Morgan while looking at blockchain vendors. Questions like:

  • What language will this blockchain use?
  • Is the language designed for safety?
  • Can the system easily express complex business rules?
  • Can you upgrade your contracts, i.e. establish a governance regime over any contract?
  • Can the system interact with external blockchains?
  • Can the system add participants (nodes) without drastically slowing down performance?

Using these questions as a framework, I believe that blockchain requires architectural elements that IBM’s system fundamentally lacks.

I’m also not the only one who has since suggested that IBM’s performance claims don’t add up; and while my colleagues and I don’t see the numbers game (transactions per second, node count) as the only factor in blockchain adoption, we do think it’s important to educate people on what a blockchain is and is not. This education will hopefully help everyone better understand the landscape of this emerging technology.

What blockchain is and isn’t

In order to really understand where IBM’s blockchain fails to satisfy, we need to look at the very definition of a blockchain itself. A blockchain is a decentralized and distributed database, an immutable ledger of events or transactions where truth is determined by a consensus mechanism — such as participants voting to agree on what gets written — so that no central authority arbitrates what is true.

IBM’s definition of blockchain captures the distributed and immutable elements of blockchain but conveniently leaves out decentralized consensus — that’s because IBM Hyperledger Fabric doesn’t require a true consensus mechanism at all.

Instead, it suggests using an “ordering service” called Kafka, but without enforced, democratized, cryptographically-secure voting between participants, you can’t really prove whether an agent tampers with the ledger. In effect, IBM’s “blockchain” is nothing more than a glorified time-stamped list of entries.

IBM’s architecture exposes numerous potential vulnerabilities that require a very small amount of malicious coordination. For instance, IBM introduces public-key cryptography “inside the network” with validator signatures, which fundamentally invalidates the proven security model of Bitcoin and other real blockchains, where the network can never intermediate a user’s externally-provided public key signature.

In a Hyperledger node, the only signatures that matter for consensus are the validator’s, while the user signatures disappear into arbitrary data in the “RWSet” which is replicated through the network (see diagram below).

Credit: IBM