Our current blockchain solution: Hyperledger Fabric and Composer

A starting point

We are looking for blockchain(ish) technology to use. One of the most important characteristics is that we want to be able to control who participates.

On an earlier project, we had worked with a predecessor of one of the Hyperledger family products, named Monax. Which has been renamed/donated into Burrow. This seemed like a logical starting point for our quest for our flexible blockchain tech. Their Github page says they are a 'permissioned Ethereum smart-contract blockchain node' which seems interesting enough. Permissioned blockchain means we can determine who joins our party, which matches with the initial wishes.

Initial struggles

We downloaded burrow and started testing locally. The documentation didn't result in a working chain, after some tweaking we got a local burrow up and running with a smart contract deployed. This did take some time however, because of the not quite up to date documentation. We also tried the deploying a local kubernetes version of burrow but this did not work. As real developers, we started reading the manual a bit better and discovered it was still in the incubation phase. After this small setback, we added 'stability and easy to deploy' as a requirement.

Fabric

Since we started working with a Hyperledger product we decided to try another product of the same family, but one which is a bit more mature. Because of the permissioned needs and the fact that we needed to be able to serve different customers, we also wanted something more flexible.

We came across Fabric, in our case version 1.2. Fabric is, according to their site, a platform for distributed ledger solutions, underpinned by a modular architecture delivering high degrees of confidentiality, resiliency, flexibility, and scalability. Which sounds cool and all but also a bit complicated. So we started reading the manual this time and found some very good development tutorials, which led us to Hyperledger Composer. Composer is an extra layer on top of the Fabric blockchain that simplifies the development of the chain code. Composer also offers a convenient REST interface that can easily be used in Proof of Concepts. It is still in the incubation phase but since it is not in the runtime core and provides us with great flexibility it seems to be a good choice. Composer provides us with a simple way to create business data definitions with corresponding chain code and deploy these on fabric.

We succeeded in setting up the development environment with custom chain code in a few hours, which contained a setup with one peer, one ca and one orderer. I will not go into detail on how Fabric works; this is described in detail on the Fabric website, e.g. network. We used a tutorial to get us up and running. This setup does not make a lot of sense for production purposes, even for test purposes you can argue the usefulness of one peer.

Some technical stuff

For test purposes, we added one other peer. This seemed easy enough, but it required a little more configuration than flipping the number 1 to 2. We encountered some interesting scripts in the download located in fabric-scripts/hlfv12/composer. Which contains several files of which the most important one for our case is crypto-config.yaml. Changing the Template section to

Template:
     Count: 2
     Hostname: peer

And running the generation script

cryptogen generate --config=./crypto-config.yaml

Which creates new peer crypto for us. We also wanted the two peers to communicate over the same channel, for this we updated the fabric start script.

docker exec peer0.org1.example.com peer channel create -o orderer.example.com:7050 -c composerchannel -f /etc/hyperledger/configtx/composer-channel.tx
docker exec peer0.org1.example.com cp composerchannel.block /etc/hyperledger/configtx/
 
# # Join peer0.org1.example.com to the channel.
docker exec -e "CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/users/Admin@org1.example.com/msp" peer0.org1.example.com peer channel join -b /etc/hyperledger/configtx/composerchannel.block
docker exec -e "CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/users/Admin@org1.example.com/msp" peer1.org1.example.com peer channel join -b /etc/hyperledger/configtx/composerchannel.block

This created a composerchannel.tx file which we shared between the containers. Not the cleanest way, but we thought of this solution during a hackathon which makes our choice one we can live with. We did explore a lot of options and had some nice errors during our discovery period. The next step is creating a multi-organisation multi-peer setup. The steps are very similar to the steps above, the difficulty lies in certificate generation and trusting these cross organization. We succeeded in creating a setup which works for us. I could describe all the steps on how we did this but a week or two after our hackathon, there was an updated tutorial on the composer site. I have not tried this tutorial yet, but I think this would have saved us a great deal of time. But also, less understanding of the platform. The updated tutorial can be found here.

Conclusions

Fabric and Composer

These tools seem to work for us. They provide an easy way to model data models and control the chain. The current setup has to prove itself in production and for a longer period of time, but the first signs are positive.

Update only mindset

One of the main advantages we had when using blockchain(ish) technology was the mindset change it provided. Everything you do with the chain is connected to the chain. There is no way to alter the older states of the chain. This helps when solving business cases in which this is essential, like compliance software. This does not mean you should always use blockchain to solve these issues, most of the time, a datomic database might work just as well.

How quickly can I move away

An important question to ask yourself when using new technology is 'how quickly can I move away?'. In this case, it depends. If you have to preserve the ledger state in some form, it might be more difficult. Just moving the raw data is very easy, especially with composer rest server integration.