Understanding Hyperledger Fabric — Channel Lifecycle

In a Hyperledger Fabric network, there can be multiple ledgers. These ledgers are called channels, and each has its own set of peers that are allowed to participate — by proposing and receiving transactions.

Channels can be dynamically created and reconfigured. Peers can also be added on the fly. The peer binary, which is used as the running process for each peer, may also be used as a client for managing the lifecycle of Fabric channels.

Creating a Channel

A channel is created using a channel config update transaction. Specifically, it’s a transaction to create a configuration for the new channel.

Channel Configuration

Channel configuration transactions are interesting because they affect metadata about the channel rather than the ledger’s state-of-the-world data. However, both configuration transactions (called configtx) and normal transactions are stored on the same blockchain.

The difference is that each configtx is stored in a special block that contains not only the incremental configuration update but the entire configuration as well. Normal transactions are stored only as incremental updates and they’re bundled together into a block. When a peer or client needs to know the channel’s configuration, it only needs to get the latest configtx block.

Submitting the Create-Channel Transaction

The manual workflow for creating a new channel is this:

• Generate the data of the transaction using the configtxgen (configuration transaction generator) tool. This writes a file that contains a configtx.
• Use the peer channel create client command, which loads the configtx from the file, signs it as the specified admin user, and submits it to the orderer.

Joining a Peer to a Channel

Adding a peer to a channel is a simple process. Here are the steps executed by the peer channel join client command:

• Load the channel’s genesis block — the first block in the chain, which contains the channel’s initial configuration.
• Build a transaction proposal for invoking the Configuration System Chaincode's JoinChannel function on the genesis block.
• Send the proposal to the peer, which executes the JoinChannel function of its Configuration System Chaincode (called CSCC).

It’s important to understand how the genesis block is used here. The genesis block contains the channel’s configuration, including information about the orderer. Here, it’s passed as an argument to the JoinChannel CSCC function. When the JoinChannel function executes on the peer, it uses the genesis block to start a local copy of the ledger. Now that the peer has the channel’s genesis block, it knows how to connect to the orderer so it can receive the rest of the blocks in the chain.

Adding New Organizations

Joining a peer to a channel is simple, but the peer must belong to an organization that is part of the channel. Otherwise, neither the orderer nor other peers will send it blocks or accept transactions from it.

Adding an organization is a channel configuration update, which can be performed using the peer channel update client command. Here’s what the process looks like:

• Get the latest config block for the channel — config blocks are special blocks on the channel’s blockchain that each contain the entire channel configuration.
• Create a modified configuration, e.g. to add a new organization.
• Create a configtx from the change in the configuration.
• Use peer channel update to sign the configtx as an admin user and submit it to the orderer.

Currently, creating the channel-update configtx is a manual process involving a set of specialized tools. However, the architecture of the system doesn’t preclude automating the process in the future.

Conclusion

Channels are a core concept in Hyperledger Fabric. Managing channels touches on many important aspects of how Fabric is structured. Follow us for more posts like this, and send us your questions in the comments!

Check out the different Hyperledger projects at https://www.hyperledger.org/