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.