Hyperledger Fabric中系统通道和应用程序通道的配置更新

在这里，我记录了为探索该主题而进行的测试，希望您也能从中获得一些有关其背后机制的想法。

假设您已经对系统通道和应用程序通道有了一定的了解。这是描述系统（orderer）通道和应用通道的阅读文档。为了使本文减少这个那个文章的幅度，省略了大多数对等命令和区块操作。将在适当的地方提供参考。

测试概述

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

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

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

测试1：两个通道之间的配置不同

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

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

cd test-network./network.sh up createChannel -c channel-one./network.sh deployCC -c channel-one -ccn sacc -ccp ../chaincode/sacc/

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

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

docker logs -f peer0.org1.example.com

这是peer chaincode invoke后，peer0.org1上的log输出。

我们看到背书时间是02:55:22:120，收到的是02:55:24.137。差异接近配置的批处理超时2s。

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

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

在这里，我使用编辑器来修改解码的区块文件。

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

现在我们可以再次peer chaincode invoke调用，这是日志。

我们看到背书的时间是03:05:06:629，收到的是03:05:16.651。差异接近配置的批处理超时10s。我们的配置更新工作正常。

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

现在我们可以再创建一个通道，第二个通道，并对批处理超时进行观察。我们可以使用network.sh脚本创建此通道。

./network.sh createChannel -c channel-two

我们无法使用network.sh部署链码，因为链码已安装在peer中。相反我使用peer lifecycle chaincode approveformyorg和对channel-two的peer lifecycle chaincode commit。

步骤1.6：从channel-two的peer chaincode invoke批处理超时

现在我们可以在channel-two上执行peer链代码调用，并从日志中观察批处理超时。

我们看到背书的时间是03:09:39:948，收到的是03:09:41.966。两者之间的差异接近于配置的批处理超时2s，即configtx.yaml中的原始超时。现在我们了解到批处理超时在不同的通道（通道1 10s，通道2 2s）中可能不同。Hyperledger Fabric为我们提供了灵活设置不同通道的批处理超时（和其他可配置参数）的能力。

这是测试1的总结

测试2：系统信道配置更新

部署链1.1，启动通道1.1测试代码

cd test-network./network.sh up createChannel -c channel-one./network.sh deployCC -c channel-one -ccn sacc -ccp ../chaincode/sacc/

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

步骤2.2：将系统通道批处理超时时间从2s修改为10s

同样，我省略了整个过程。在这里，您可以在“将Org3添加到系统通道

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

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

我们看到背书的时间是03:17:45:499，收到的是03:17:47.517。差异接近原始配置的批处理超时2s。这意味着更新系统通道后，那些创建的通道（此处为通道一）不会受到影响。

步骤2.4：创建channel-two并在channel-two上部署链码SACC

与步骤1.5相似，我们使用network.sh调出channel-two和peer lifecycle chaincode链码命令，以将SACC部署到channel-two。

./network.sh createChannel -c channel-two

步骤2.5：从channel-two的日志中观察批处理超时

我们重复步骤2.3，但这一次是在channel-two。

我们看到背书的时间是03:20:09.359，收到的是03:20:19.377。两者的差异接近已配置的批处理超时10s，即修改后的10s。我们了解到通道的批量超时是从系统通道中继承的。虽然创建的通道（channel-one）不受影响，但是新创建的通道（channel-two）遵循新的修改配置。

这是测试2的摘要。

总结

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