Fabric网络下如何为通道添加新的组织

首先要明确添加通道应该要做哪些事！一要通知orderering service服务器，新组织加入到通道，验证过的建议交易封装后是要提交给orderering service服务器，由它分发到commit peer节点。二是通道配置要改变，新组织极有可能成为背书策略贡献者。

一、生成Org3密钥资料

进入/first-network/org3-artifacts/目录，该目录有2个文件：org3-crypto.yaml和configtx.yaml，执行下列命令

 

../../bin/cryptogen generate --config=./org3-crypto.yaml

通过org3-crypto.yaml为org3 CA及两个与之绑定的peer节点生成密钥和证书，这些文件保存在 org3-artifacts目录下。

再使用configtxgen以JSON格式打印出Org3-specific配置资料，这个过程用到了 configtx.yaml文件，命令如下：

export FABRIC_CFG_PATH=$PWD && ../../bin/configtxgen -printOrg Org3MSP > ../channel-artifacts/org3.json

生成org3.json文件，保存在/first-network/channel-artifacts/目录下。这个文件包含了org3的策略定义和以base-64编码格式的3个重要证书:admin、CA根证书、TLS根证书，这些信息将会被追加到通道配置文件中去。

最后一项任务是把Orderer Org’s MSP资料导入到Org3的crypto-config目录。我们主要关注Orderer’s TLS 根证书，用来保证Org3组织与ordering节点通讯。命令如下：

cd ../ && cp -r crypto-config/ordererOrganizations org3-artifacts/crypto-config/

现在我们可以更新通道配置了。

二、准备CLI环境

首先进入CLI容器，这个容器是执行BYFN启动的，可获取2个peer组织和orderer组织的MSP资料，可由org1 admin用户引导。命令如下：

docker exec -it cli bash

Export the ORDERER_CA and CHANNEL_NAME variables:

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容器，你必须要重复上面的命令。

三、获取配置

现在我们有了2个关键环境变量的CLI容器： ORDERER_CA和CHANNEL_NAME。接下来要从mychannel通道获取最近的配置区块。

为什么要拉取最新版本的配置文件呢？这是因为通道配置元素是版本化的。版本化的原因有几个，可以防止配置更改，另外还可以确保一致性。（例如当新组织加入到通道后，如果你想将一个组织从通道中移出，版本化可以防止你将这两个组织同时移出），命令如下所述：

peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

 将二进制通道配置块写入到config_block.pb文件中 ，文件名及后缀有助于识别文件类型。

以上命令行执行结果如下：

2017-11-07 17:17:57.383 UTC [channelCmd] readBlock -> DEBU 011 Received block: 2

这句话告诉我们最近mychannel配置块是block 2而不是创世纪块。因此块序列如下描述：

• block 0: genesis block

• block 1: Org1 anchor peer update

• block 2: Org2 anchor peer update

四、转换格式（由pb转为JSON并进行裁减）

现在要用configtxlator工具解码通道配置块至JSON格式。同时将头、元数据、创建者签名无关修改的信息去掉，这可以用jq工具来完成，命令如下：

configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json

生成config.json文件，位于/fabric-samples/first-network/目录下。

五、添加Org3加密资料

我们将用jq工具把Org3配置定义（org3.json）追加到通道应用组域中并命名为 modified_config.json。命令如下：

jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' config.json ./channel-artifacts/org3.json > modified_config.json

现在CLI容器有2个JSON文件：config.json和modified_config.json。第一个文件只包含 Org1和Org2资料，而 “modified”文件则包含3个Org。先把config.json转换成 config.pb文件，命令如下：

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工具计算两pb文件的delta。命令如下并输出org3_update.pb文件：

configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output org3_update.pb

org3_update.pb文件包含Org3定义和指向Org1和Org2资料的链接。我们现在可以放弃org1和org2的扩展MSP资料和修改策略。因为这个数据已在通道创世纪块中了。我们只需要两个配置之间的差异了。

在提交通道更新之前，我们需要执行最后几步。前行解码org3_update.pb转成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

再利用configtxlator工具将org3_update_in_envelope.json转成org3_update_in_envelope.pb文件，命令行如下：

configtxlator proto_encode --input org3_update_in_envelope.json --type common.Envelope --output org3_update_in_envelope.pb

六、签署和提交配置更新

org3_update_in_envelope.pb文件是在CLI容器中的。在写入到账本之前还需要Admin签名。通道应用组修改策略设置为缺省  “MAJORITY”表示需要存在的组管理员主体签名。此处则为Org1和Org2都要签名。否则ordering服务器将拒绝交易。 

第一步由Org1 Admin签名，CLI容器是基于Org1 MSP资料启动的，可直接在CLI中使用signconfigtx工具，命令如下：

peer channel signconfigtx -f org3_update_in_envelope.pb

第二步切换到Org2 Admin身份，通过输出四个环境变量来实现，命令如下：

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/[email protected]/msp

export CORE_PEER_ADDRESS=peer0.org2.example.com:7051

同样也要执行如下命令：

peer channel signconfigtx -f org3_update_in_envelope.pb

注意：向orderering服务器申请的即将更新调用将会经历一系列签名、策略检验等动作，可以通过如下命令来观察：

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

通道更新成功会返回新的区块block 5，并通知到通道中的每个peer节点。blocks 0-2是初始通道配置，blocks 3和4是链码的初始化与调用，block 5则是包含org3的通道配置交易。

可以登录到peer0.org1.example.com查看日志：

docker logs -f peer0.org1.example.com

如果想检查内容，则按演示过程提取、解码新的配置区块。

七、配置选择策略

注意：

这部分主要描述当完成通道配置初始化后，当加入新的组织时选择策略的设置问题。这个例子缺省针对的是动态策略，该策略是对网络中所有的peer节点，内容在peer-base.yaml文件中。 

最新加入的peer节点是基于创世纪块启动的，它不包含通新组织加入后的道配置更新信息。所以新的peer节点不能利用gossip协议，正如它们也不能验证来自于同组织提交的块，除非它们获得已将组织加入到通道的配置交易后。因此新加入的peer节点必须有下列的其中一个配置才能接收来自ordering服务器的区块：

1. 利用静态选举策略，将peer配置为一个组织的leader：

CORE_PEER_GOSSIP_USELEADERELECTION=false
CORE_PEER_GOSSIP_ORGLEADER=true

注意这个配置对加入通道的所有新peer节点必须相同

2. 利用动态选举策略，将peer节点配置为使用选举策略：

CORE_PEER_GOSSIP_USELEADERELECTION=true
CORE_PEER_GOSSIP_ORGLEADER=false

注意：

新加组织的peer节点不能构建成员视图，这个选项类似于静态配置，每个peer将自主声明为leader。等到更新后这个组织只有一个激活的leader。因此建议利用这一选项。

八、将Org3加入到通道

此时通道配置已更新到包含新组织Org3，这意味着该组织的peer节点可以加入到通道中去。

首先启动Org3组织的CLI：Org3-specific CLI。命令如下：

docker-compose -f docker-compose-org3.yaml up -d

这个新的组织文件配置用来连接初始网络。2个peer节点1个CLI容器和已存在的peer节点及ordering节点能解决问题了。进入org3-cli容器，命令如下：

docker exec -it Org3cli bash

输出2个重要环境变量：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

现在发送请求给ordering服务器获取创世纪块。 利用如下命令获取返回块： 

peer channel fetch 0 mychannel.block -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

以上将0参数传入表明获取第一个区块。如果没有0则将获得5个区块。 然而我们以顺流的方式开始我们的账本，而只能从0区块开始。通过以下命令让peer加入到通道：

peer channel join -b mychannel.block

输出TLS和ADDRESS变量，将其它peer节点加入到通道： 

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:7051

peer channel join -b mychannel.block

九、升级并调用链码

最后的任务是升级链码版本和更新包括org3的背书策略。

 在Org3 CLI容器进行如下操作：

peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

修改环境变量重复以上命令将org3的第二个peer节点装上链码。第二个不是必须的。你只需要将负责背书或与账本有接口的peer节点装上链码就可以了。 无需链码容器，peer节点仍执行验证逻辑并提交服务。

现在回到初始的CLI容器，在org1和org2上安装新版本链码。命令如下： 

peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

切换到peer0.org1：

export CORE_PEER_LOCALMSPID="Org1MSP"

export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/[email protected]/msp

export CORE_PEER_ADDRESS=peer0.org1.example.com:7051

再次安装 ：

peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

链码安装完毕，现在要实例化，这一过程将org3包含到背书策略之中。执行如下命令：

peer chaincode upgrade -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -v 2.0 -c '{"Args":["init","a","90","b","210"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')"

升级调用新增block 6区块至账本。切回到Org3 CLI容器进行query查询。 

peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

结果为： Query Result: 90.

调用从a转移b10支付过程：

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"]}'

查询

peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

结果为：Query Result: 80

十、总结

通道配置更新过程是复杂的。但每一步都有其严格的逻辑， 最后的阶段是构建protobuf二进制的delta交易对象，获取签名，完成通道策略的修改。

configtxlator、jq、peer channel命令为我们完成任务提供了很好的帮助。