A Quick Look At The Implementation of Fabric V1.0.0-alpha2

I have recently landed on a project based on the blockchain technologies and smart contracts. As the architect of the project I had to make some early decisions on which framework to use. The first decision which I had to make was whether I should use a permissioned or open non-permissioned framework.

Now this decision turned out to be far more difficult than I had expected it to be. Should I make it open and governed by the people or make it permissioned and governed by an enterprise? I suddenly found myself battling with conflicting ideas where I could not reach a firm decision. Hence, I decided to keep both options open.

Last year I had a chance to play with Ethereum and I experimented with the Solidity script and smart contracts. During my experiments I found that some straight forward coding practices usually done in a normal scripting language cannot be done on the blockchain. There were many technical limitations which I had to live with which left me thinking that although the framework is stable it is still not mature enough for complex designs. And of course looking at the volatility of the ETHER (built-in crypto currency) made it difficult to make a stable business platform. So I decided to evaluate Hyperledger/Fabric which is driven mainly by IBM.

Fabric is an open source Apache project which is currently in version 1.0.0-alpha2 and the production version is due to be released this month. It is a permissioned blockchain based framework designed for the enterprise.

Before version 1.0 there was version 0.6 which received a lot of criticism from the technical community for many different reasons. One is that it introduced the membership service as a gate keeper to the framework and as a single node which created a single point of failure. Second, the replications between the peers where not efficient and in some cases some transactions where lost. This is a big problem in reliability. Version 1.0 promised to fix these issues.

The news about version 1.0 got me excited and I decided to get wet and dive straight into it. I downloaded the source code to my machine and got the included samples up and running fairly quickly. So far all is good, but something still bugging me and I can’t quite figure it out yet. I started to examine the source code trying to understand how the framework is designed. It was a typical IBM design which I had been familiar with through out my career. Slightly over engineered, but very modular and uses pluggable technologies. Unlike Ehtereum, IBM did not write its own VM (Virtual Machine) and scripting language, the architects decided to rely heavily on the Docker Container technology for the smart contract VM and used GRPC for communication between these containers. I know I am getting little technical here. Just bare with me. This container creates an isolated space where a smart contract resides. What this means is that even if your smart contract known as chaincode is not behaving properly, it will not affect the stability of the over all system. Another advantage of such an implementation is that GRPC is supported by many languages such as Go, java…etc. Hence, the smart contract can be written in many languages. Nice. I like it. Yet still something is bugging me.

Fabric supports endorsement policies by multiple organizations which can form a consortium. Your transaction will not go through until the majority of the peers from one or multiple organizations, depending on how you set it up, agree on it. Pretty democratic (within the consortium of course). Now these endorsement policies are set during the initiation of the smart contract. Once the endorsement is done, than a transaction request takes place with simulated output and get sent to special nodes called “Orderers”. The job of these orderers is to insure that all transactions are in order, runs a simple consensus algorithm when in solo mode to create a block encapsulating the transactions, and do an atomic broadcast of the block back to the peers. The peers validate the block and decide whether to accept it or not. It turns out that this validation process is yet another pluggable technology. This means you can plug in any consensus algorithm you choose or you can develop your own. Another surprise was that the endorsement and the validation algorithms are developed as smart contracts. They support the same “shim” interface as regular smart contract with one difference. These smart contracts do not live in an isolated container. They live in the same address space as the peer node and they are called system chaincode. I am feeling really good now. Why? I believe that deep down, IBM architects and engineers are feeling like me, uneasy. By using pluggable technologies you can turn Fabric into a system similar yet more powerful than Ethereum. You can easily open the gates in a gated community. You can plug in PoW, PoS , PoET or whatever flavor of PoXX you choose into the framework. You can build a native crypto currency into the framework just like Ethereum.

What is even more surprising is that the source code of Fabric comes with a less advertised sample chaincode to support UTXO which is hardly discussed anywhere in the Fabric community. This chaincode uses the BitCoin libconsensus C library underneath to include the support of unspent output. Hence, a bridge to the BitCoin network built right into Fabric.