介绍(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.

今年7月初，我的文章《系统通道和应用程序通道》是关于“添加组织到通道”(链接)的教程，该教程由读者提出来。 本周我收到了另一个问题，这又使我重新考虑了这个话题。 问题在于在Hyperledger Fabric中修改批处理超时(创建块之前要等待的时间)。 尽管很明显，我们可以通过标准(且乏味)的过程来更新配置，但一开始让我困惑的是我应该在哪个通道上工作：系统通道或应用程序通道。

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.

这里设计了两个测试。 在这两个测试中，我们都建立了一个测试网络(v2.2)，该网络由一个订购者组织和两个对等组织组成。 创建通道，并且所有对等方都加入了通道，并且链码已部署在通道上。 Test Network带有脚本network.sh ，可帮助我们在通道和链码中进行部署。

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.

在测试1中，我们专注于应用程序渠道。 我们首先建立测试网络，创建通道一，并部署链码SACC。 我们观察到了背书和接收到新块之间的时间，这大约是在configtx.yaml设置的批处理超时(2s)。 然后，我们构造配置更新，将通道一中的超时修改为10s。 更新完成后，我们再次测试通道一，现在看到超时为10秒。 最后，我们创建另一个通道，通道2，并观察对通道1所做的修改是否对通道2有影响。

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.

在测试2中，我们在系统通道上工作。 我们再次启动测试网络，创建通道一，并部署链码SACC。 我们在系统通道中将超时设置为10s来构造配置更新。 更新完成后，我们再次进行测试并观察通道1的超时，并查看系统通道上的更新是否对通道1产生影响。 最后，我们创建另一个通道，通道2，并观察在系统通道上修改后创建该通道时发生了什么。

测试1：两个通道之间的配置不同 (Test 1: Different configuration between two channels)

Step 1.1: Bring up Test Network, channel-one and deploy chaincode SACC

步骤1.1：建立测试网络，通道一并部署链码SACC

We are using the network.sh script to speed up the whole process.

我们正在使用network.sh脚本来加快整个过程。

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

步骤1.2：从日志中观察批处理超时

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

为了观察超时，我们调用chaincode函数。 一个对等方(例如peer0.org1.example.com)将首先按照对等方链调用命令的要求执行背书，然后从订购者处接收到一个新块。 它们之间的时间可以衡量批处理超时(非常接近，但不完全准确)。

docker logs -f peer0.org1.example.com

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

这是peer chaincode invoke代码后在peer0.org1.example.com上的日志输出。

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.

我们看到签注是02：55：22：120并收到了02：55：24.137的阻止。 差异接近已配置的批处理超时2s。

Step 1.3: Modify channel-one batch timeout from 2s to 10s

步骤1.3：将通道1的批处理超时时间从2秒修改为10秒

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.

在这里，我省略了整个过程。 简而言之，我们需要从通道1获取配置块，计算2s到10s之间的差，然后签名并使用OrdererMSP提交。 它与本教程中的将组织添加到通道( link )中的过程相同，不同之处在于(a)对值进行更改，并且(b)更新事务由订购者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

步骤1.4：更改后再次从日志中观察批处理超时

Now we can perform peer chaincode invoke again. Here is the log.

现在我们可以再次执行peer chaincode invoke 。 这是日志。

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.

我们看到签注是在03：05：06：629进行的，并且收到了03：05：16.651的阻止。 差异接近已配置的批处理超时10s。 我们的配置更新运行良好。

Step 1.5: Create channel-two and deploy chaincode SACC on channel-two

步骤1.5：创建第二个频道并在第二个频道上部署链码SACC

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脚本创建此通道。

./network.sh createChannel -c channel-two

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

我们无法使用network.sh部署链码，因为链码已安装在对等方中。 相反，我使用peer lifecycle chaincode approveformyorg和peer lifecycle chaincode commit渠道的peer lifecycle chaincode commit 。 在这里，我再次省略此步骤，您可以参考readthedoc或我的文章以获取更多详细信息。

Step 1.6: Observe batch timeout from log on channel-two

步骤1.6：从第二个通道登录观察批处理超时

Now we can perform a peer chaincode invoke on channel-two, and observe batch timeout from the log.

现在，我们可以在第二个通道上执行peer chaincode invoke ，并从日志中观察批处理超时。

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.

我们看到签注是03：09：39：948并收到了封锁03：09：41.966 。 两者之间的差异接近于配置的批处理超时2s，即configtx.yaml的原始超时。 现在我们了解到，在不同的通道(通道1的10s，通道2的2s)中批处理超时可以不同。 Hyperledger Fabric使我们可以灵活地为不同通道设置批处理超时(和其他可配置参数)。

Here is the summary of Test 1

这是测试1的总结

测试2：系统通道配置更新(Test 2: System channel configuration update)

Step 2.1: Bring up Test Network, channel-one and deploy chaincode SACC

步骤2.1：建立测试网络，通道一并部署链码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)

在不做任何更改的情况下，我们知道根据configtx.yaml设置的配置，当前批处理超时为2秒(请参阅步骤1.2)

Step 2.2: Modify system-channel batch timeout from 2s to 10s

步骤2.2：将系统通道批处理超时时间从2s修改为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”.

同样，我省略了整个过程。 在这里，您可以在“将Org3添加到系统通道，然后使用Org3创建通道”部分中找到我的文章，其中描述了更多详细信息。

Step 2.3: Observe batch timeout from logs on channel-one after the update on system channel

步骤2.3：在系统通道更新后，从通道一的日志中观察批处理超时

We perform peer chaincode invoke and here is the log.

我们执行peer chaincode invoke ，这是日志。

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.

我们看到签注是在03：17：45：499进行的，并且收到了03：17：47.517的阻止。 差异接近于原始配置的批处理超时2s。 这意味着更新系统通道后，那些创建的通道(此处为通道一)不会受到影响。

Step 2.4: Create channel-two and deploy chaincode SACC on channel-two

步骤2.4：创建第二个频道并在第二个频道上部署链码SACC

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.

与步骤1.5相似，我们使用network.sh调出通道2和对等生命周期链码命令，以将SACC部署到通道2。

./network.sh createChannel -c channel-two

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

步骤2.5：从第二个通道的日志中观察批处理超时

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

我们重复步骤2.3，但这一次是在第二频道。

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.

我们看到签注是在03：20：09.359进行的，并且收到了03：20：19.377的阻止。 差异接近已配置的批处理超时10s，即修改后的10s。 现在，我们了解到通道的批量超时是从系统通道中继承的。 虽然创建的通道(通道一)不受影响，但是新创建的通道(通道二)遵循新的修改配置。

Here is the summary of Test 2.

这是测试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.

通过这个小练习，我们了解了一些有关系统通道和应用程序通道的知识。 首先，在应用程序通道上修改诸如批处理超时之类的可配置参数，并且不同的应用程序通道可以具有自己的批处理超时来满足其要求。 同时，在创建应用程序通道时，它将获得系统通道中当前的配置。 如果修改了系统通道中的参数，则此更改不会对那些已创建的应用程序通道产生影响，并且在修改之后创建的那些将接受更改。