Channel, one of the key abstractions in Hyperledger Fabric — what is it for?

My first blockchain that I started working with was Ethereum. Ethereum is a public blockchain, which means that anyone can join the network, send transactions, and query the state of the ledger. There are also private blockchains, like Hyperledger Fabric. Private networks could be more suitable for some business cases, where you need to deliver all the perks of the blockchain technology, but you don't necessarily want to share the ledger with the outside world or with everybody on the network, and you need fine-grained permission control. In the case of Hyperledger Fabric, that is where channels become useful.

What is a channel?

If I were asked to describe what a channel is in one sentence, I would say that it is an abstraction that forms a permissioned boundary around the ledger and the chaincodes.
Before I move to an example use case, let’s have a look at what a channel is in a more technical overview.

Channel is one of the basic building blocks in Hyperledger Fabric. You cannot have a network without a single channel. In fact, one of the first things to do when bootstrapping a new network is creating the system channel that is used to propagate configuration about the network and its members. It also contains system chaincodes you can use throughout the life of the network.

There is also another type of channel — an application channel. From a developer's perspective, it's the main and most commonly used one. You can have as many of them as you want and each of them can have multiple chaincodes deployed. Whenever you want to create a new channel, you have to specify what members will have access to it, and what permissions they will have. For example, you could limit some clients to just querying the ledger, which could be useful for auditing.

Business case

Let’s say we are building an application for a Law Firm. They came to us and shared that they are handling many cases for their clients, they need to exchange lots of paper documents before the interested parties are ready to sign any of them. Unfortunately, it happens that some documents are lost, sometimes there are changes someone was not aware of, in short, they have a lot of problems everyone would like to avoid. On top of that, clients get mad, so we have to do something or the firm will start losing clients.

We proposed to build an application based on blockchain technology, so they and their clients would be able to cooperate on documents, track all changes, and verify document integrity at any point in time. That way, we could avoid a lot of misunderstandings.

After a surprisingly short amount of time, we are ready to deploy a pilot. Our biggest client agreed to take part in it. Let’s name them Client A. We have all Hyperledger Fabric pieces in place, but what I would like to focus on are peer nodes. They will have copies of the ledger where the application will store data, like an audit of changes made to the documents. To give an assurance that the data is truly valid, our client needs to have peer nodes on the infrastructure owned by them. All that is left right now is to join all peer nodes with our newly created application channel where we have already deployed all relevant chaincodes.

Our client admitted they are very happy with the way the application is working. Finally, there is no need to exchange so many paper documents and we can keep track of everything related to them.

The next step for our Law Firm is to implement this solution with the next client, let’s call them Client B. We have a working network with one application channel that is used by us and Client A. We don’t want to share that channel with Client B as they would be able to see everything from the ledger or maybe even write data to it too. What we're gonna do next is add peer nodes to the infrastructure owned by Client B and create a new channel which will join our and their peers. In that way, we will have two ledgers, one for each client we are cooperating with, but only peers that are members of the channel will have a copy of its ledger.

I bet you already see the pattern here. Every time we implement a solution with another client, they need to set up peer nodes on their side, then we join them to a newly created channel and the ledger is stored only on the participating peer nodes. Though in our example, we use a channel to communicate just between two organizations, it is possible to add more parties to a single channel.

As word about our application is spreading across the world, more and more clients are interested in using it and we also landed a few new clientes. We came to a point where we noticed that our peer nodes are handling a lot of load and joining them to another channel could be fatal to the performance of the network.

Thankfully, each of the peer nodes can be a member in a different set of channels. Given that at the beginning we had three peers and each of them was a member of two different channels, now we can spawn more peer nodes and utilize them with new clients. That way, we can achieve some sort of sharding. For the sake of the simplicity of the diagram, let’s say we have four peer nodes and three clients. We can configure the network in the way that each channel will be placed on two of our peers.

Summary

As you can see, a channel is pretty much a basic building block of a Hyperledger Fabric network, without it, you cannot build one. It also separates data in a secure way, so only peers that are members of a particular channel, will store the data, and only actors with proper permissions can read and write to the ledger of the channel. The last thing to remember is that you can freely configure your peers so that each of them can know about different sets of channels, in that way the network can be more fail proof or you can achieve sharding.

Want to start a Hyperledger Fabric network faster and with a lot more features onboard? Check out the newest version of Fablo, our Open Source code project that tackles the complexity of setting up and managing a Hyperledger Fabric network.