A few weeks ago I wrote a post called The Heist: How Big Blue stole Blockchain! in which I contended that Hyperledger Fabric, currently the most used "blockchain" in corporate projects (ahead of Enterprise Ethereum, Quorum and Corda) was likely to disappoint in the long run by proving to be "yet another classical IT architecture" which solves the same problems that other IT solutions can solve already (while being cheaper to deploy), and which fails to solve the problems on which existing IT architectures had until now no bearing at all, but which can be solved by real blockchains - those fitting the characterization of "trust machines"

Three months ago, in an article titled Why Blockchain Is a Revolution I had implicitly set out my "yardstick" for comparing different blockchain architectures when writing "blockchain enables better organizational paradigms than were socially and economically viable before."

As it happens, Hyperledger Fabric has been engineered with precisely the opposite goal, of reinforcing existing organizational paradigms and allowing them to include the blockchain technology in typical IT projects that would most often cost less and risk less by shunning the complexity of Hyperledger Fabric.

The main theses of this article are:

1. Hyperledger Fabric has a very complex architecture. This implies high risks and high costs to implement.
2. Hyperledger Fabric allows the purchasing organisation to customize almost everything. The flip side is that configuring and customizing the Fabric "toolkit" takes time, costs money and entails implementation risks for the projects.
3. The complexity of the architecture makes resulting software systems hard to operate, costly and brittle.
4. As a direct consequence, the selling organization is offered a straight path to commercial Nirvana: implementation is long and costly (jackpot for the seller); resulting systems are hard and costly to operate (double jackpot for the seller); complexity leads to brittleness and bugs which translate in high system maintenance costs (triple jackpot for the seller).

These things were not lost on IBM's competitors, which were caught by surprise by the "blockchain craze" and had not much to offer to their customers before Big Blue came along. They were thus quick to embrace IBM and its free, open source Hyperledger Fabric platform as their saviour.

Indeed IBM cannot serve everybody. For the "enterprise IT" giants, joining a free open-source platform that has been designed to maximize the revenue of the seller is a "no-brainer": it's been developed already at no cost to them, they can use it for free and those customers who cannot or do not want to work with IBM will come knocking on their doors!

As for Big Blue, it already has more customers which love it than it has capacity to staff blockchain projects. Therefore it gets to select the best ones in both business- and reputation-wise. What's not to like?

Complexity means high costs and high risks

In the previous article I explained that the fundamental shortcoming of Hyperledger Fabric is that it does not align the incentives of the participants. Quite the contrary, it does everything to preserve a clear separation between a customer of the blockchain solution who pays a supplier of the blockchain solution to customise, implement and operate it on the customer's behalf for a price.

If you are a supplier of blockchain-related services, you want the price paid by the customer to be as high as possible (while remaining bearable). Your best bet is to sell a solution as complex as possible because then the customer will be bound to you.

Indeed, the central argument revolves around complexity. Thus I'll follow here IBM's engineers and lead you, too, into a "technical deep-dive" on Hyperledger Fabric 1.0 - the full presentation is available on-line on SlideShare since January 2018.

All the slides below are (c) IBM

Here is the first step (out of seven) for running a Hyperledger Fabric transaction (any transaction)

You first need to understand that unlike bitcoin, or ethereum where all the nodes participating in the consensus are basically the same, in Fabric consensus is reached in three big steps "Endorse" - "Order" - "Validate", each performed by a different type of node.

It is also crucial to note that there are no "native transactions" on Fabric, the transactions are entirely defined in the application layer and need to be coded up from scratch.

In the image above you see that the client application sends its proposed transaction to "Endorser" nodes. The transactions are then ordered by an "Ordering-Service" node and then are validated and committed by a "Committing Peer".

Now of course if, as in the above example, E₀, E₁ and E₃ are three machines and if they all must sign (as IBM exemplifies here), and if one of them is down for whatever reasons ... you understand that you need to run all of these "Endorser" machines in "high availability" mode, right?

In step 2 the endorsers each run the chaincode. Which the developers have coded ... and which might have bugs that you'll have to hunt after, on a distributed execution environment (as if hunting bugs was not difficult enough in a centralized environment).

In step 3 the endorsers return the results of their computation to the client application. Imagine that one of the network connection breaks and the client application is left hanging out to dry, waiting for one of the endorsers to return its "RW set" ... but that never happens, right? Or you can put in place a nice extra monitoring layer to make sure each and every endorser defined in the policy is always reachable by the client applications. Can you see the complexity of the architecture building up?

In step 4 endorsed transactions from all applications get ordered by the "non BFT" ordering service.

By looking closely at steps 4 and 5 one can realise that the ordering service, concentrating all the proposed transactions and then sending them out for validation, is a single point of failure in Fabric's architecture. You really need to make sure the ordering service is super available, load balanced, fault tolerant and everything.

Steps 6 and 7 see the transaction validated by the various peers and the validations confirmed back to the client application

A final perspective on the importance of the ordering service (and hence the risks it brings in the picture) can be glimpsed from this proposed (by IBM) "Consortium Network" which assigns the ordering service to one particular member ... who thus becomes both the lynchpin of the system and liable to all the other participants in the business exchange if something goes wrong ...

Conclusion

Hyperledger Fabric is the ideal blockchain platform of every CIO in a big organisation:

1. It is endorsed by IBM (and as we all know "nobody ever got fired for buying IBM")
2. If you don't like IBM (or you are too small for IBM) you can have it implemented by a large number of other suppliers including Oracle.
3. The CIO can proudly say he's overseeing an advanced blockchain project.
4. That project is pleasantly expensive and offers justification for increasing the IT budget - what CxO does not want a good reason to ask for a bigger budget?
5. The whole system is so complex nobody outside the IT dept. will be able to challenge it

^source

In the end, with a lot of heroism from the IT teams and a bit of luck, it might even work. And because comparisons are not possible (nobody does the same project in parallel with two different technologies), the risk that someone comes along and says: "We could have achieved the same objective for a fraction of the price, if we had avoided Hyperledger Fabric" is really small.

The Happy End

If you know what witnesses are and agree that people commited to keeping this blockchain ticking play an important role ...

(by simply clicking on the picture - thanks to SteemConnect)

Other posts on blockchain technology that you might enjoy:

• The Heist: How Big Blue stole Blockchain!
• Blockchain in large organizations
• Why Blockchain Is a Revolution
• The Holy Blockchain
• Blockchain revolution: the CIOs' dilemma

You might also want to check out my “lighthearted” account, @sorin.lite, perhaps you’ll like what you’ll see.