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输出。
Hyperledger Fabric中系统通道和应用程序通道的配置更新
我们看到背书时间是02:55:22:120,收到的是02:55:24.137。差异接近配置的批处理超时2s。 步骤1.3:将通道1的批处理超时时间从2秒修改为10秒 在这里,我省略了整个过程。简而言之,我们需要从channel-one获取配置块,计算2s到10s之间的差,然后签名并使用OrdererMSP提交。它与本教程中的将组织添加到通道(链接)中的过程相同,不同之处在于(a)对值进行更改,并且(b)更新事务由订购者admin签名。 在这里,我使用编辑器来修改解码的区块文件。
Hyperledger Fabric中系统通道和应用程序通道的配置更新
步骤1.4:更改后再次从日志中观察批处理超时 现在我们可以再次peer chaincode invoke调用,这是日志。
Hyperledger Fabric中系统通道和应用程序通道的配置更新
我们看到背书的时间是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链代码调用,并从日志中观察批处理超时。
Hyperledger Fabric中系统通道和应用程序通道的配置更新
我们看到背书的时间是03:09:39:948,收到的是03:09:41.966。两者之间的差异接近于配置的批处理超时2s,即configtx.yaml中的原始超时。现在我们了解到批处理超时在不同的通道(通道1 10s,通道2 2s)中可能不同。Hyperledger Fabric为我们提供了灵活设置不同通道的批处理超时(和其他可配置参数)的能力。 这是测试1的总结
Hyperledger Fabric中系统通道和应用程序通道的配置更新
测试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,这是日志。
Hyperledger Fabric中系统通道和应用程序通道的配置更新
我们看到背书的时间是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。
Hyperledger Fabric中系统通道和应用程序通道的配置更新
我们看到背书的时间是03:20:09.359,收到的是03:20:19.377。两者的差异接近已配置的批处理超时10s,即修改后的10s。我们了解到通道的批量超时是从系统通道中继承的。虽然创建的通道(channel-one)不受影响,但是新创建的通道(channel-two)遵循新的修改配置。 这是测试2的摘要。
Hyperledger Fabric中系统通道和应用程序通道的配置更新
总结 通过这个小练习,我们了解了一些有关系统通道和应用程序通道的知识。首先在应用程序通道上修改诸如批处理超时之类的可配置参数,并且不同的应用程序通道可以具有自己的批处理超时来满足其要求。同时在创建应用程序通道时,它将获得系统通道中当前的配置。如果修改了系统通道中的参数,则此更改不会对那些创建的应用程序通道产生影响,并且在修改之后创建的那些应用程序将接受该更改。

该内容来自于互联网公开内容,非区块链原创内容,如若转载,请注明出处:https://htzkw.com/archives/28990

联系我们

aliyinhang@gmail.com