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 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 . 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 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.com

Here is an output of log on peer0.org1.example.com after is made.

Image for post
Image for post

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.

Image for post
Image for post
Modify the Batch Timeout from 2s (default) to 10s

Step 1.4: Observe batch timeout from logs again after the change

Now we can perform again. Here is the log.

Image for post
Image for post

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 script to create this channel.

./network.sh createChannel -c channel-two

We cannot use to deploy chaincode as the chaincode is already installed in the peer. Instead, I am using and 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 on channel-two, and observe batch timeout from the log.

Image for post
Image for post

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 . 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

Image for post
Image for post

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 (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 and here is the log.

Image for post
Image for post

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-two

Step 2.5: Observe batch timeout from logs on channel-two

We repeat Step 2.3 but this time on channel-two.

Image for post
Image for post

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.

Image for post
Image for post

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.

Happy to share what I learn on blockchain. Visit http://www.ledgertech.biz/kcarticles.html for my works. or reach me on https://www.linkedin.com/in/ktam1/.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store