Hyperledger Fabric – Are Channels Private Blockchain? (Deep Dive)

This article represents Hyperledger Fabric Channels concepts and related details in form of some of the following topics:

• What are Channels?
• Hyperledger Fabric Blockchain Network is a channel
• Channels are private and permissioned Blockchain
• Channels explained with examples
• Channels – channel configuration, genesis block
• Ordering service creates a transaction block per channel

Blockchain network is categorized into two broad classes:

• Public network: Anyone can join this type of network. For example, bitcoin network.
• Private or permissioned network: A member needs to be authenticated by the assigned membership service provider (identity issuing authority service) for joining and conducting transactions in the network.

Hyperledger Fabric can be said to be private or permissioned blockchain.

What are Channels?

Hyperledger Fabric Channels can be defined as a logical entity which represents a grouping of two or more Blockchain network members/participants for the purpose of conducting private and confidential transactions between themselves. The following are key building blocks of a channel:

• Organization as members
• One or more anchor peers per member organization
• Channel policies
• Distributed shared ledger (private to the members of channel)
• Chaincode applications
• Ordering service nodes

Hyperledger Fabric Blockchain Network is, actually, a Channel

• A Hyperledger Fabric blockchain network, in itself, is a channel which consists of all that forms a part of the channel as described in preceding section. This essentially means that all member organizations who join the network become part of this channel.
• Therefore, any transaction on a Hyperledger Fabric Blockchain network executes in the channel.
• In case, there is a need for a section of the member organization to conduct private and confidential transactions which they do not want to make public to all the participants of the network, they can become part of the new channel. This would mean that these members would now form two ledgers, one for the larger network which they are part of, and another for the channel they became part of, for conducting transactions in private.

Channels are Private & Permissioned Blockchain

• Not anyone and everyone can join a channel.
• Each peer joining a channel has its own identity. This identity is given by a membership services provider (MSP).
• Each peer in a channel must be authenticated and authorized to conduct transactions on that channel.

Channels Explained with Examples

The following screenshot represents two channels, red and blue.

Make a note of some of the following in above diagram:

• A peer node can be part of multiple channels. In above diagram, peer node E0 is part of both red and blue channels while peer node E1 is only part of the blue channel.
• Given above, anchor peers can maintain multiple ledgers. IN above diagram, peer E0 maintains ledgers for both red and blue channels.
• Above said, the ledger data maintained by specific peer members cannot be shared between different channels. From above diagram, it can be understood that even though peer node E0, being part of both red and blue channels, is maintaining corresponding ledgers, E0 cannot share the data of blue channel with members of the red channel.

The following screenshot represents another view of the two channels, red and blue.

Make a note of some of the following in above diagram:

• E0 and E3 peer nodes maintain the ledger of red channel; They work with smart contract (chaincode) Y and Z
• E1 and E2 peer nodes maintain the ledgers of blue channel; They work with smart contract (chaincode) A and B
• Peer nodes send the transactions to ordering service; Ordering service creates the block of transactions for both red and channels and broadcast to the respective peers.
• Client app invokes chaincode (smart contract) for conducting a transaction.

Channels – Channel Configuration, Genesis Block

• Channel Configuration
  • Channel configuration is stored in form of a configuration transaction in a block with no other transactions. This configuration transaction is also termed as configtx.
  • Any update to channel configuration has to be conducted as like any other transaction. This implies that a configuration change is wrapped as a transaction and sent as configtx to the ordering service. The ordering service, after validation, sends the block of configtx back to the peer. This configtx block is then written to ledger as configuration block.
• Genesis Block
  • Each channel has a genesis block which consists of configuration information related to above. As part of channel creation, first and foremost, the genesis block is created. This genesis block is used to bootstrap the ordering system channel which is used by the orderers to authorize and orchestrate the creation of other channels.
  • Any addition of newer members requires updating of this genesis block or a new configuration block is shared with the channel members.
  • The genesis block is created using the channel configuration tool, namely, configtxgen. Read the details on this page, Channel Configuration (configtxgen).

Ordering Service creates Transaction Block per Channel

• One ordering service can cater to the needs of multiple different channels.
• Leading member of different channels send the transaction to the ordering service.
• Ordering service groups the transactions related to a specific channel in a block.
• Ordering service, then, sends the block related to a specific channel to members of that channel.