向通道添加组织¶
注解
确保您已经下载了适当的镜像和二进制文件，如 Install Samples, Binaries and Docker Images 和:doc:`prereqs`中所述，这些文件都符合本文档的版本(可以在左边目录的底部找到)。特别是，“fabric-samples”文件夹的版本必须包含``eyfn.sh``(“扩展您的第一个网络”)脚本及其相关脚本。
本教程作为对:doc:build_network (BYFN)教程的扩展，并将演示如何向BYFN自动生成的应用程序通道(mychannel)添加一个新的组织``Org3``。它假设对BYFN有很好的理解，包括前面提到的实用程序的用法和功能。
虽然我们在这里只关注新组织的集成，但是在执行其他通道配置更新(例如，更新修改策略或更改批大小)时也可以采用相同的方法。要了解更多关于通道配置更新的过程和可能性，请查看:doc:config_update)。同样值得注意的是，像这里演示的通道配置更新通常由组织管理员(而不是链码或应用程序开发人员)负责。
注解
在继续之前确保自动’byfn.sh``脚本在您的机器上没有错误地运行。如果您已经将二进制文件和相关工具(``cryptogen, configtxgen, 等)导出到PATH变量中，那么您就可以相应地修改命令，而无需传递完全限定的路径。
设置环境¶
我们将在您的本地从``first-network`` 子目录克隆``fabric-samples``。现在切换到那个目录。您还需要打开一些额外的终端以方便使用。
首先，使用``byfn.sh``脚本整理。该命令将杀死所有活动的或陈旧的docker容器，并删除以前生成的构件。要执行通道配置更新任务，并不**必需**关闭Fabric网络。但是，出于本教程的考虑，我们希望从已知的初始状态开始操作。因此，让我们运行以下命令来清理以前的环境:
./byfn.sh down
现在生成默认的BYFN构件:
./byfn.sh generate
并利用CLI容器内的脚本执行启动网络:
./byfn.sh up
现在您的机器上已经运行了一个干净的BYFN版本，您可以使用两条不同的路径。首先，我们提供了一个完整的带注释脚本，它将执行配置交易更新以将Org3引入网络。
此外，我们还将显示相同流程的“手动”版本，显示每个步骤并解释它所完成的工作(因为我们在此手动过程之前向您展示了如何关闭您的网络，所以您也可以运行脚本，然后查看每个步骤)。
使用脚本将Org3加入通道¶
你应该在``first-network``中。要使用该脚本，只需发出以下命令:
./eyfn.sh up
这里的输出很值得一读。您将看到添加了Org3加密原料，创建并签名了配置更新，然后安装了链码，以允许Org3执行账本查询。
如果一切顺利，你会得到这样的信息:
========= All GOOD, EYFN test execution completed ===========
eyfn.sh can be used with the same Node.js chaincode and database options
as byfn.sh by issuing the following (instead of ./byfn.sh up):
./byfn.sh up -c testchannel -s couchdb -l node
然后：
./eyfn.sh up -c testchannel -s couchdb -l node
对于那些希望更深入地了解这个过程的人，文档的其余部分将向您展示用于进行通道更新的每个命令及其功能。
手动将Org3导入通道¶
注解
下面列出了手动步骤，假定“cli”和“Org3cli”容器中的“FABRIC_LOGGING_SPEC”设置为“DEBUG”。
对于 ``cli``容器，您可以通过修改 ``first-network``目录下的文件 ``docker-compose-cli.yaml``来设置它。
cli:
container_name: cli
image: hyperledger/fabric-tools:$IMAGE_TAG
tty: true
stdin_open: true
environment:
- GOPATH=/opt/gopath
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
#- FABRIC_LOGGING_SPEC=INFO
- FABRIC_LOGGING_SPEC=DEBUG
对于 ``Org3cli``容器，您可以通过修改``first-network``目录下的文件``docker-compose-org3.yaml``来设置它。
Org3cli:
container_name: Org3cli
image: hyperledger/fabric-tools:$IMAGE_TAG
tty: true
stdin_open: true
environment:
- GOPATH=/opt/gopath
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
#- FABRIC_LOGGING_SPEC=INFO
- FABRIC_LOGGING_SPEC=DEBUG
如果你用过``eyfn.sh``脚本，你需要关闭你的网络。这可以通过发出下列命令做到:
./eyfn.sh down
这将关闭网络，删除所有容器，并撤消我们为添加Org3所做的操作。
当网络关闭时，请将其重新恢复。
./byfn.sh generate
然后：
./byfn.sh up
这将使您的网络恢复到执行 ``eyfn.sh``之前的状态。
现在我们准备手动添加Org3。作为第一步，我们需要生成Org3的加密材料。
生成Org3加密材料¶
在另一个终端，从``first-network``切换到``org3-artifacts``子目录。
cd org3-artifacts
这里有两个有趣的``yaml``文件: org3-crypto.yaml 和``configtx.yaml``。首先，生成Org3的加密材料:
../../bin/cryptogen generate --config=./org3-crypto.yaml
这个命令读取我们新的密码 yaml``文件——``org3-crypto.yaml，并利用``cryptogen`` 为Org3 CA生成密钥和证书，以及绑定两个peer节点到这个新组织。与BYFN实现一样，这个加密材料被放入当前工作目录(在我们的示例中是“org3-artifacts”)中新生成的“crypto-config”文件夹中。
现在使用 configtxgen 实用程序用JSON格式输出Org3专用的配置材料。在命令开始之前，我们将告诉工具在当前目录中查找它需要提取的``configtx.yaml`` 文件。
export FABRIC_CFG_PATH=$PWD && ../../bin/configtxgen -printOrg Org3MSP > ../channel-artifacts/org3.json
上面的命令创建一个JSON文件– org3.json – 并将其输出到``first-network``根目录下的``channel-artifacts`` 子目录中。这个文件包含Org3策略定义，以及三个重要的base64格式的证书在：admin用户证书(之后用作Org3的管理员)、CA根证书和TLS根证书。在即将到来的步骤中,我们将这个JSON文件附加到通道配置。
最后一项管理工作是将排序器Org的MSP材料转移到Org3``crypto-config`` 目录中。我们特别关注排序器的TLS根证书，它将允许在Org3实体和网络的排序节点之间进行安全通信。
cd ../ && cp -r crypto-config/ordererOrganizations org3-artifacts/crypto-config/
现在我们准备更新通道配置…
准备CLI环境¶
更新过程使用配置转换工具——’configtxlator。该工具提供了一个独立于SDK的无状态REST API。此外，它还提供了一个CLI，以简化Fabric网络中的配置工作。该工具允许在不同的等效数据表示/格式之间进行简单的转换(在本例中，是在protobufs和JSON之间)。此外，该工具可以根据两个通道配置之间的差异计算配置更新交易。
首先，exec 进入CLI容器。回想一下，这个容器已经安装了BYFN``crypto-config``库，使我们能够访问两个最初的peer组织和排序器Org的MSP材料。引导的身份是Org1管理用户，这意味着我们想要扮演Org2的任何步骤都需要导出特定于MSP的环境变量。
docker exec -it cli bash
导出“ORDERER_CA”和“CHANNEL_NAME”变量:
export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem && export CHANNEL_NAME=mychannel
检查变量是否设置正确:
echo $ORDERER_CA && echo $CHANNEL_NAME
注解
如果出于任何原因需要重新启动CLI容器，还需要重新导出两个环境变量—— ORDERER_CA``和``CHANNEL_NAME。
获取配置¶
现在我们有了一个CLI容器，其中包含两个关键的环境变量—— ORDERER_CA 和``CHANNEL_NAME``已导出 。让我们去获取通道``mychannel``的最新配置块。
我们必须提取配置的最新版本的原因是，通道配置元素是经过版本控制的。版本控制之所以重要，有几个原因。它可以防止配置更改被重复或重播(例如用旧的CRL恢复到通道配置会带来安全风险)。它还有助于确保并发性(例如如果您想从通道中删除一个组织，在添加了一个新的组织之后，版本控制将有助于防止您同时删除两个组织，从而只删除您想要删除的组织)。
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA
该命令将二进制protobuf通道配置块保存为``config_block.pb``。注意，名称和文件扩展名的选择是任意的。但是，建议遵循一种约定，即同时标识所表示对象的类型及其编码(protobuf或JSON)。
当您发出``peer channel fetch``命令时，终端中有相当数量的输出。日志中的最后一行很有趣:
2017-11-07 17:17:57.383 UTC [channelCmd] readBlock -> DEBU 011 Received block: 2
这告诉我们，mychannel``的最新配置区块实际上是2号区块，**不是** 创世区块。默认情况下， ``peer channel fetch config 命令返回目标通道**最近的**配置区块，在本例中是第三个区块。这是因为BYFN脚本在两个独立的通道更新交易中为我们的两个组织(Org1``和``Org2)定义了锚点peer。
因此，我们得到如下配置序列:
区块0：创世区块
区块1：Org1锚点区块更新
区块2：Org2锚点区块更新
将配置转换为JSON并对其进行修剪¶
现在，我们将使用``configtxlator``工具将这个通道配置块解码为JSON格式(可以由人类读取和修改)。我们还必须删除与我们想要进行的更改无关的所有头部、元数据、创建者签名等等。我们通过“jq”工具来实现:
configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json
这就留给我们一个经过修剪的JSON对象—— config.json，位于``first-network``中的``fabric-samples``文件夹中—这将作为配置更新的基线。
花点时间在您选择的文本编辑器(或浏览器)中打开这个文件。即使您已经完成了本教程的学习，也值得研究它，因为它揭示了底层配置结构和其他可以进行的通道更新。我们将在:doc:`config_update`中更详细地讨论它们。
添加Org3加密材料¶
注解
到目前为止，您所采取的步骤几乎是相同的，无论您试图进行哪种配置更新。我们选择在本教程中添加一个组织，因为它是您可以尝试的最复杂的通道配置更新之一。
我们将再次使用``jq``工具来添加Org3配置定义—— org3.json ——到通道的应用程序groups字段，并将输出命名为——modified_config.json。
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' config.json ./channel-artifacts/org3.json > modified_config.json
现在，在CLI容器中我们有两个感兴趣的JSON文件—— config.json``和``modified_config.json。初始文件只包含Org1和Org2材料，而“修改”文件包含所有三个Org。此时，只需重新编码这两个JSON文件并计算增量。
首先，转换 config.json 回到名为 ``config.pb``的protobuf :
configtxlator proto_encode --input config.json --type common.Config --output config.pb
接下来，编码``modified_config.json``为``modified_config.pb``:
configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb
现在使用 configtxlator 来计算这两个配置protobuf之间的增量。这个命令将输出一个新的protobuf二进制文件，名为``org3_update.pb``:
configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output org3_update.pb
这个新的proto——org3_update.pb——包含Org3定义和指向Org1和Org2材料的高级指针。我们能够抛弃为Org1和Org2提供的大量MSP材料和修改策略信息，因为这些数据已经存在于通道的创世区块中。因此，我们只需要两个构型之间的增量。
在提交通道更新之前，我们需要执行一些最后的步骤。首先，让我们将这个对象解码为可编辑的JSON格式，并将其命名为’org3_update.json:
configtxlator proto_decode --input org3_update.pb --type common.ConfigUpdate | jq . > org3_update.json
现在，我们有一个解码的更新文件 – org3_update.json – 我们需要将其封装在信封消息中。这一步将返回我们之前删除的头部字段。我们将这个文件命名为``org3_update_in_envelope.json``:
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat org3_update.json)'}}}' | jq . > org3_update_in_envelope.json
使用格式正确的JSON – org3_update_in_envelope.json – 我们将最后一次使用``configtxlator``工具，并将其转换为Fabric所需的完全成熟的protobuf格式。我们将最终的更新对象命名为 org3_update_in_envelope.pb:
configtxlator proto_encode --input org3_update_in_envelope.json --type common.Envelope --output org3_update_in_envelope.pb
签署并提交配置更新¶
差不多完成了！
在CLI容器中，现在我们有了一个protobuf二进制文件 ，org3_update_in_envelope.pb 。然而，在将配置写入账本之前，我们需要来自必需的管理用户的签名。通道应用程序组的修改策略(mod_policy)被设置为默认的“多数”，这意味着我们需要大多数现有的org管理员来签署它。因为我们只有两个org——Org1和Org2——而两个中的大多数是2，所以我们需要他们两个都签名。如果没有这两个签名，排序服务将因为未能满足策略而拒绝交易。
首先，让我们以Org1管理员的身份签署这个更新proto。请记住，CLI容器是用Org1 MSP材料引导的，所以我们只需要发出``peer channel signconfigtx``命令:
peer channel signconfigtx -f org3_update_in_envelope.pb
最后一步是切换CLI容器的身份，以反映Org2管理用户。为此，我们导出了四个特定于Org2 MSP的环境变量。
注解
在组织之间切换以签署配置交易(或执行任何其他操作)并不反映实际的Fabric操作。单个容器永远不会安装整个网络的加密材料。相反，配置更新将需要安全地通过带外传递给一个Org2管理员进行检查和批准。
导出Org2环境变量:
# you can issue all of these commands at once
export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=peer0.org2.example.com:9051
最后，我们会发出``peer channel update`` 命令。Org2管理员签名将附加到这个调用，所以不需要手动签署第二次protobuf:
注解
即将对排序服务进行的更新调用将经过一系列系统签名和策略检查。因此，您可能会发现，对排序节点的日志进行流处理和检查非常有用。从另一个shell发出一个``docker logs -f orderer.example.com``命令来显示它们。
发送更新调用:
peer channel update -f org3_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA
如果你的更新成功提交，你应该会看到一个类似于下面的消息摘要提示:
2018-02-24 18:56:33.499 UTC [msp/identity] Sign -> DEBU 00f Sign: digest: 3207B24E40DE2FAB87A2E42BC004FEAA1E6FDCA42977CB78C64F05A88E556ABA
您还将看到我们的配置交易提交:
2018-02-24 18:56:33.499 UTC [channelCmd] update -> INFO 010 Successfully submitted channel update
成功的通道更新调用将向通道上的所有peer节点返回一个新区块–区块5。可能您还记得，区块0-2是初始通道配置，而区块3和4是 ``mycc``链码的实例化和调用。因此，第5区块作为最近的通道配置，现在在通道上定义了Org3。
为了 ``peer0.org1.example.com``检查日志:
docker logs -f peer0.org1.example.com
如果希望检查新配置区块的内容，请遵循演示的过程来获取和解码新配置区块。
配置领导选举¶
注解
本节作为一般参考，用于理解在初始通道配置完成后将组织添加到网络时的领导人选举设置。这个示例默认为动态领导人选举，它在“peer-base.yaml”中为网络中的所有peer节点设置。
新加入的peer节点使用创世区块引导，该区块不包含有关正在通道配置更新中添加的组织的信息。因此，新peer节点不能使用gossip，因为它们无法验证其他peer节点从自己的组织转发的区块，直到它们获得将组织添加到通道的配置交易。因此，新添加的peer节点必须具有以下配置之一，以便从排序服务接收区块:
1. To utilize static leader mode, configure the peer to be an organization leader:
CORE_PEER_GOSSIP_USELEADERELECTION=false
CORE_PEER_GOSSIP_ORGLEADER=true
注解
对于添加到通道的所有新peer节点，此配置必须相同。
2. To utilize dynamic leader election, configure the peer to use leader election:
CORE_PEER_GOSSIP_USELEADERELECTION=true
CORE_PEER_GOSSIP_ORGLEADER=false
注解
因为新添加的组织的peer节点将无法形成成员视图，所以这个选项将类似于静态配置，因为每个peer节点将开始声明自己是领导人。然而，一旦使用将组织添加到通道的配置交易对其进行更新，组织将只有一个活动领导人。因此，如果您最终希望组织的peer节点利用领导人选举，建议利用这个选项。
将Org3加入通道¶
此时，为了包含我们的新组织– Org3，通道配置已经更新， 这意味着连接到它的peer节点现在可以加入``mychannel``。
首先，让我们启动Org3的peer节点和特定于Org3的CLI容器。
打开一个新的终端，并从``first-network``启动Org3 docker compose:
docker-compose -f docker-compose-org3.yaml up -d
这个新的compose文件已配置为跨初始网络进行桥接，因此两个peer节点和CLI容器将能够使用现有peer节点和排序节点进行解析。现在运行了三个新的容器，exec到特定于org3的CLI容器中:
docker exec -it Org3cli bash
正如我们对初始CLI容器所做的那样，导出两个关键的环境变量: ORDERER_CA``和``CHANNEL_NAME:
export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem && export CHANNEL_NAME=mychannel
检查变量是否设置正确:
echo $ORDERER_CA && echo $CHANNEL_NAME
现在让我们向排序服务发送一个调用，请求“mychannel”的创世区块。由于我们的通道更新成功，排序服务能够验证附加到此调用的Org3签名。如果没有成功地将Org3附加到通道配置中，排序服务会拒绝此请求。
注解
同样，您可能会发现，对排序节点的日志进行流处理以显示签名/验证逻辑和策略检查非常有用。
使用 ``peer channel fetch``命令检索此区块:
peer channel fetch 0 mychannel.block -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA
注意，我们传递了一个``0``来表示我们想要通道账本上的第一个区块(即创世区块)。如果我们只是通过 peer channel fetch config 命令，那么我们将接收到区块5——定义了Org3的更新配置。然而，我们不能从下游区块开始账本——我们必须从区块0开始。
发出``peer channel join``命令，并传入创世区块 – mychannel.block:
peer channel join -b mychannel.block
如果您想加入Org3的第二个peer节点，导出 TLS``和``ADDRESS 变量并重新发出``peer channel join command``:
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org3.example.com/peers/peer1.org3.example.com/tls/ca.crt && export CORE_PEER_ADDRESS=peer1.org3.example.com:12051
peer channel join -b mychannel.block
安装、定义和调用链码¶
一旦您加入了通道，您就可以在Org3的peer节点上打包并安装一个链码。然后需要将链码定义批准为Org3。因为链码定义已经提交到您已经加入的通道，所以您可以在批准定义之后开始使用链码。
注解
这些指令使用了在v2.0 Alpha版本中引入的Fabric 链码生命周期。如果您想使用以前的生命周期来安装和实例化链码，请访问“将org添加到通道教程”的v1.4版本 <https://hyperledger-fabric.readthedocs.io/en/release-1.4/channel_update_tutorial.html>`__。
第一步是打包来自Org3 CLI的链码:
peer lifecycle chaincode package mycc.tar.gz --path github.com/hyperledger/fabric-samples/chaincode/abstore/go/ --lang golang --label mycc_1
这个命令将创建一个名为``mycc.tar.gz``的链码包，我们可以使用它在我们的peer节点上安装链码。在这个命令中，您需要提供一个链码包标签来描述链码。如果通道正在运行用Java或Node.js编写的链码，则相应地修改该命令。发出以下命令在Org3的peer0上安装包:
# this command installs a chaincode package on your peer
peer lifecycle chaincode install mycc.tar.gz
如果希望在Org3的第二个peer点上安装链码，还可以修改环境变量并重新发出命令。注意，第二次安装并不是强制的，因为您只需要将链码安装在peer节点充当背书者，或以其他方式与账本接口(即仅查询)。peer节点仍将运行验证逻辑，并在没有运行链码容器的情况下充当提交者。
下一步是将``mycc``的链码定义批准为Org3。Org3需要批准与Org1和Org2已批准并提交给通道的相同的定义。链码定义还需要包括链码包标识符。你可以通过查询你的peer节点来找到包的标识符:
# this returns the details of the packages installed on your peers
peer lifecycle chaincode queryinstalled
您应该会看到类似如下的输出:
Get installed chaincodes on peer:
Package ID: mycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173, Label: mycc_1
我们将在将来的命令中需要包ID，所以让我们继续将它保存为一个环境变量。将`peer lifecycle chaincode queryinstalled` 返回的包ID粘贴到下面的命令中。包ID可能不适合所有用户，因此需要使用从控制台返回的包ID完成此步骤。
# Save the package ID as an environment variable.
CC_PACKAGE_ID=mycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173
使用以下命令来批准Org3的 ``mycc``链码的定义:
# this approves a chaincode definition for your org
# use the --package-id flag to provide the package identifier
# use the --init-required flag to request the ``Init`` function be invoked to initialize the chaincode
peer lifecycle chaincode approveformyorg --channelID $CHANNEL_NAME --name mycc --version 1.0 --init-required --package-id $CC_PACKAGE_ID --sequence 1 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --waitForEvent
您可以使用 peer lifecycle chaincode querycommitted 命令来检查您已批准的链码定义是否已提交到通道。
# use the --name flag to select the chaincode whose definition you want to query
peer lifecycle chaincode querycommitted --channelID $CHANNEL_NAME --name mycc --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
一个成功的命令将返回关于提交定义的信息:
Committed chaincode definition for chaincode 'mycc' on channel 'mychannel':
Version: 1, Sequence: 1, Endorsement Plugin: escc, Validation Plugin: vscc
由于链码定义已经提交，所以在您批准定义之后，就可以使用’mycc 链码了。链码定义使用默认的背书策略，这要求通道上的大多数组织对交易进行背书。这意味着，如果一个组织被添加到或从通道中删除，背书策略将自动更新。我们之前需要来自Org1和Org2(2个中的2个)的背书，现在我们需要来自Org1、Org2和Org3中的两个(3个中的2个)的背书。
查询链码以确保它已经启动。注意，您可能需要等待链码容器启动。
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'
我们应该看到 ``Query Result: 90``的响应。
现在发出一个调用，将“10”从“a”转账到“b”。在下面的命令中，我们的目标是在Org1和Org3中收集足够数量的背书。
peer chaincode invoke -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -c '{"Args":["invoke","a","b","10"]}' --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses peer0.org3.example.com:11051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org3.example.com/peers/peer0.org3.example.com/tls/ca.crt
最后一次查询:
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'
我们应该看到 ``Query Result: 80``的响应，准确地反映了这个链码的世界状态的更新。