A valid blockchain case
Since I joined my new company one of the projects I’d been involved in uses blockchain underneath. I didn’t have any blockchain experience at all so it’s been a massive learning for me so far. Blockchain was first developed for Bitcoin and thus it just generated a massive attraction in the tech community amid the huge spikes in bitcoin demand that happened just before the end of 2017. Now bitcoin and their alike seems to be declining but blockchain is still strong.
So what is really blockchain?
Blockchain is not more than a distributed immutable ledger that uses cryptographic techniques to ensure some of this features.
Being distributed means that exactly the same database can be replicated in many different places at the same time. This is not something new from blockchain, many relational and non-relational databases can have this type of setup, however, blockchain makes it easier to run this setup across non-trusting-each-other organisations. The way blockchain works in this sense is based on consensus. Once we define what should be considered a valid transaction the system will enforce those rules for us. This is important because it’s easy to agree on the rules (for instance at least one node in each organization has to endorse the transaction before it’s written to the ledger).
Being immutable means nobody can go and change the past. This again is important for not trusting organisations as none can modify the history after the facts. This pushes a huge number of challenges like for instance what happens if you are storing personal information in the ledger and now has to deal with GDPR legislation. The truth is that there are several mechanisms of modifying the past, but they are really hard to use. Stuff like a majority attack could change the past, or even using chameleon hashes.
Cryptographic techniques play a role in ensuring immutability, because each block has a hash of the previous block, changing the content of the block but keeping the same hash so the following block won’t conflict it is hard. Also, the hash is very simple to generate but very hard to reverse.
So what are the main components of a blockchain Fabric application?
We need the next components:
Very briefly the CA responsibility is validating the certificates of the different users and peers. The Orderer is responsible to send all the transactions to the peers in order. Orderer validates the endorsements and sends the transactions to the network in a certain order. Peers are responsible to endorse the new transactions and store the information. Finally, chaincode exposes a series of methods or function that can be used to store information in the system. These methods or functions are in a sense similar to an API and they are often referred to as a smart contract because they define what can be done in the network. In my opinion, they are quite similar to store procs in traditional RDBMSs.
Chaincode normally will contain the business logic of the application, while the other parts of the network are in essence the infrastructure that supports the application. Chaincode can be written in Java, nodejs, and Golang.
How to access the blockchain?
You can either create a wrapper around the CLI or use one of the SDKs. There are SDKs available for Java and nodejs. We decided to create an API using Express to access the blockchain and write the chaincode in nodejs as well, so we can have a single stack for the whole project.
Where to deploy this to?
You can deploy to Bluemix as IBM has a Blockchain as a service system in there, however, the price is quite high. IBM published a way to deploy a network to Kubernetes. Our approach is to leverage the benefits of Kubernetes and so far we have a working cluster with a working network on it. There’s something weird in this setup chaincode run as a separate container for isolation purposes. The chaincode container can’t be seen from
kubectlbut it can be seen if you connect to the docker daemon, directly. To do this you will need to install the docker tools and connect to a socket directly, this wasn’t expected but after having thought about it is the only real way.
Hyperledger Fabric is a quite complex technology that should probably be avoided unless you can’t. It has a learning curve and it’s not too different to a distributed DB with an audit trail, but using the technology is much harder as you will need to have a much deeper understanding of the technology and infrastructure than you need when using a DBMS.
When you really understand all the different concepts and how all the pieces work together, working with it is not so hard, so perhaps we are only talking about a technology that is in early days and for which some layers of surrounding tools will be created in the next years.