So far we have only started an orderer node that is aware of identities of various participants in the network. Before we go further and start the other nodes in the network we need to talk about the most important concept in Hyperledger Fabric i.e Channels.
If you are familiar with pub-sub concept in a typical message queue implementation then you can consider that a channel is akin to ‘topic’. In other words, it is not a transport layer but a way to logical isolate the communication between various nodes. Entities that are the members of a channel may transact on it and more importantly the transactions on a channel are not visible on other channels. This ensures both authorization and the privacy aspects of transactions being committed on the network.
The Hyperledger Fabric wiki has a pretty good description of the channels.
Important things to note/consider are -
- A channel may be created for a subset of the members on network to transact.
- A member who is not authorized on a channel may not join the channel and cannot transact on that channel.
- There is a ledger per channel i.e. if a peer participates on two channels that it has two ledgers.
So how do we create a channel in the first place ? And quite possibly there will be more than one channel in a given network and it is also possible that more participants will join an existing channel in future. Given all this we can see that there is a requirement to create/update/read/delete the configuration related to the channels i.e. a database (or a ledger). This ledger resides with the orderer nodes of the network.
We should also note that a participating entity/user should have the permission to create a new channel. How to assign the permissions (or define the policies around) is a different blog post that I would do in near future. For now you should know that the default policy allows the Admin users to create the new channels. In Part 1 we had created the necessary cryptographic key material and in Part 2 we had provided the information about this aspect as part of genesis block to the orderer nodes.
Since the configuration of channels is stored in form of a ledger we can easily see that we should be creating a transaction and send it to the orderer nodes. At present the creation of this transaction is done using the same tool that we used to create the genesis block for orderer nodes i.e. configtxgen. We use a different profile specified in the configtx.yaml that specify the channel and its participants (all three organizations intend to be on this channel).
configtxgen -profile ThreeOrgsChannel -outputCreateChannelTx ./ksachdeva-exp-channel-1.tx -channelID ksachdeva-exp-channel-1
The file ksachdeva-exp-channel-1.tx contains the transaction block however it is not signed. Before we can send the request to the orderer node we need to sign this request using the cryptographic material of admin user of one of the participating organizations.