Configuration Update on System Channel and Application Channel in Hyperledger Fabric
Introduction
Early this July my article System Channel and Application Channel was about a tutorial “Adding an Org to a Channel” (link), driven by a question from my readers. I received another question this week which again led me to revisit this topic. The question was about modifying a batch timeout (amount of time to wait before creating a block) in Hyperledger Fabric. While it is quite clear that we can update configuration through the standard (and tedious) process, what puzzled me at the beginning is which channel I should work on: system channel or application channel.
My very first guess is that, as blocks are created in an orderer, the configuration update should be made on the system (orderer) channel, and then the orderer will honour this new timeout for all channels. After some experiments my guess is wrong! (Always learn new things in each hands-on practice.)
Here I document what I have tested to explore this topic and hope you can also gain some ideas on the mechanism behind.
It is assumed that you have obtained certain understanding on the system channel and application channel. Here is the readthedoc describing the system (orderer) channel and application channel. To make the article less heavy, most of peer commands and block manipulation are omitted. The reference will be provided where appropriate.
Test Overview
Here two tests are designed. In both tests, we are bringing up Test Network (v2.2), which is composed of one orderer organization and two peer organizations. Channels are created and all peers join the channels, and chaincodes are deployed on the channels. Test Network comes with a script network.sh that facilitates our deployment in channels and chaincodes.
In Test 1, we focus on application channels. We first bring up the Test Network, create channel-one, and deploy chaincode SACC. We observe the time between an endorsement is made and a new block is received, which is about the batch timeout (2s) set in configtx.yaml. Then we construct a configuration update with timeout modified to 10s in channel-one. After the update is made, we test again channel-one, and we see now the timeout is 10s. Finally, we create another channel, channel-two, and observe whether the modification we make on channel-one has any effect on channel-two.
In Test 2, we work on the system channel. We again bring up the Test Network, create channel-one, and deploy chaincode SACC. We construct a configuration update with the timeout set to 10s in the system channel. After the update is made, we test again and make observations on the timeout in channel-one, and see if update on system channel has effect on channel-one. Finally we create another channel, channel-two, and observe what happens as it is created after the modification on the system channel.
Test 1: Different configuration between two channels
Step 1.1: Bring up Test Network, channel-one and deploy chaincode SACC
We are using the network.sh script to speed up the whole process.
cd test-network./network.sh up createChannel -c channel-one./network.sh deployCC -c channel-one -ccn sacc -ccp ../chaincode/sacc/
Step 1.2: Observe batch timeout from log
To observe the timeout, we invoke chaincode function. A peer (say peer0.org1.example.com) will first perform the endorsement as required by peer chaincode invoke command, and a new block is received from the orderer. The time between them can be a measurement of batch timeout (very close, but not exactly).
docker logs -f peer0.org1.example.comHere is an output of log on peer0.org1.example.com after peer chaincode invoke is made.
We see the endorsement is made 02:55:22:120 and a block is received 02:55:24.137. The difference is close to the configured batch timeout 2s.
Step 1.3: Modify channel-one batch timeout from 2s to 10s
Here I omit the whole process. In a nutshell, we need to fetch the configuration block from channel-one, compute the difference from 2s to 10s, and then sign and submit it with OrdererMSP. It is identical to the process in the tutorial Add an Org to a Channel (link) except that (a) the change is made on the value and (b) the update transaction is signed by orderer admin.
Here I am using an editor to modify the decoded block file.
Step 1.4: Observe batch timeout from logs again after the change
Now we can perform peer chaincode invoke again. Here is the log.
We see the endorsement is made 03:05:06:629 and a block is received 03:05:16.651. The difference is close to the configured batch timeout 10s. Our configuration update is working well.
Step 1.5: Create channel-two and deploy chaincode SACC on channel-two
Now we can create one more channel, channel-two, and make observations on the batch timeout. We can use network.sh script to create this channel.
./network.sh createChannel -c channel-twoWe cannot use network.sh to deploy chaincode as the chaincode is already installed in the peer. Instead, I am using peer lifecycle chaincode approveformyorg and peer lifecycle chaincode commit for channel-two. Here again I omit this step, and you can refer to readthedoc or my article for more detail.
Step 1.6: Observe batch timeout from log on channel-two
Now we can perform a peer chaincode invoke on channel-two, and observe batch timeout from the log.
We see the endorsement is made 03:09:39:948 and a block is received 03:09:41.966. The difference is close to the configured batch timeout 2s, the original timeout in configtx.yaml. Now we learn that batch timeout can be different in different channels (channel-one 10s, channel-two 2s). Hyperledger Fabric provides us the flexibility in setting the batch timeout (and other configurable parameters) for different channels.
Here is the summary of Test 1
Test 2: System channel configuration update
Step 2.1: Bring up Test Network, channel-one and deploy chaincode SACC
cd test-network./network.sh up createChannel -c channel-one./network.sh deployCC -c channel-one -ccn sacc -ccp ../chaincode/sacc/
Without changing anything, we know that the current batch timeout is 2s according to the configuration set in configtx.yaml (see Step 1.2)
Step 2.2: Modify system-channel batch timeout from 2s to 10s
Again, I omit the whole process. Here you can find my article describing more more detail in the section “Add Org3 to System Channel and then Create Channel with Org3”.
Step 2.3: Observe batch timeout from logs on channel-one after the update on system channel
We perform peer chaincode invoke and here is the log.
We see the endorsement is made 03:17:45:499 and a block is received 03:17:47.517. The difference is close to the original configured batch timeout 2s. This means that those created channels (here channel-one) are not affected after the system channel is being updated.
Step 2.4: Create channel-two and deploy chaincode SACC on channel-two
Similar to Step 1.5, we use network.sh to bring up channel-two and peer lifecycle chaincode commands to deploy SACC to channel-two.
./network.sh createChannel -c channel-twoStep 2.5: Observe batch timeout from logs on channel-two
We repeat Step 2.3 but this time on channel-two.
We see the endorsement is made 03:20:09.359 and a block is received 03:20:19.377. The difference is close to the configured batch timeout 10s, the modified one. Now we learn that batch timeout of a channel inherits from that in the system channel. While those created (channel-one) are not affected, the newly created channels (channel-two) follow the new modified configuration.
Here is the summary of Test 2.
Summary
Through this small exercise, we have learnt something about system channel and application channel. First, configurable parameters such as batch timeout are modified at the application channel, and different application channels can have their own batch timeout to meet their requirement. Meanwhile, when an application channel is created, it obtains the configuration currently in the system channel. If the parameters in the system channel are modified, this change does not have impact on those created application channels, and those created after the modification will honour the change.
