向通道中添加组织--fabric--release-1.4

上接--构建你的第一个网络

一、脚本自动添加组织

进入 first-network 目录下

使用 byfn.sh 脚本清理环境

./byfn.sh down

生成默认的 BYFN 构件：

./byfn.sh generate

启动网络，并执行 CLI 容器内的脚本

./byfn.sh up

使用脚本将 Org3 加入通道

./eyfn.sh up

如果一切顺利，你会看到以下信息：

========= All GOOD, EYFN test execution completed ===========

二、手动添加组织

1.生成 Org3 加密材料

为组织 Org3 生成证书

# 在另一个终端，切换到 first-network 的子目录 org3-artifacts 中
cd org3-artifacts

# 为组织生成证书
cryptogen generate --config=./org3-crypto.yaml

创建一个 JSON 文件 – org3.json – 并把文件输出到 first-network 的 channel-artifacts 子目录下

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

拷贝排序节点的 MSP 材料到 Org3 的 crypto-config 目录下

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

2.获取配置

准备工作

# 进入CLI容器
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 这两个环境变量

获取通道 mychannel 的最新的配置区块

# 命令将通道配置区块以二进制 protobuf 形式保存在 config_block.pb
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

会有如下输出

# 表示最新的 mychannel 的配置区块实际上是区块 2，并非初始区块
2020-07-05 07:24:50.777 UTC [cli.common] readBlock -> INFO 003 Received block: 2
2020-07-05 07:24:50.777 UTC [channelCmd] fetch -> INFO 004 Retrieving last config block: 2

3.将配置转换到 JSON 格式并裁剪

用 configtxlator 工具将通道配置解码为 JSON 格式，通过 jq 来完成裁剪

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

4.添加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

将 config.json 和 modified_config.json 重新编码并计算出差异部分

# 首先，将 config.json 文件倒回到 protobuf 格式，命名为 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 去计算两个protobuf 配置的差异
# 会输出一个新的 protobuf 二进制文件 org3_update.pb
configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output org3_update.pb

提交通道更新前还需要进一步的处理

# 将 org3_update.pb 解码成可编辑的 JSON 格式，并命名为 org3_update.json
configtxlator proto_decode --input org3_update.pb --type common.ConfigUpdate | jq . > org3_update.json

# 用信封消息来包装它，把之前裁剪掉的头部信息还原
echo '{"payload":{"header":{"channel_header":{"channel_id":"'$CHANNEL_NAME'", "type":2}},"data":{"config_update":'$(cat org3_update.json)'}}}' | jq . > org3_update_in_envelope.json

# 转换为 Fabric 需要的完整独立的 protobuf 格式
configtxlator proto_encode --input org3_update_in_envelope.json --type common.Envelope --output org3_update_in_envelope.pb

5.签名并提交配置更新

Org1 管理员来签名这个更新 proto

# 由于 CLI 容器是以 Org1 MSP 材料启动的， 所以我们只需要执行 peer channel signconfigtx 命令
peer channel signconfigtx -f org3_update_in_envelope.pb

将 CLI 容器的身份切换为 Org2 管理员

# 配置环境变量
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

# Org2 管理员在这个命令中会附带签名
peer channel update -f org3_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA

成功则会看到如下输出

2020-07-05 08:56:29.157 UTC [channelCmd] update -> INFO 002 Successfully submitted channel update

6.将 Org3 加入通道

 部署 Org3 节点容器和 Org3-specific CLI容器

# 打开一个新的终端并从 first-network 目录启动 Org3 docker compose 
docker-compose -f docker-compose-org3.yaml up -d

# 进入 Org3-specific CLI 容器
docker exec -it Org3cli bash

# 配置环境变量
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 初始区块的请求

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

执行 peer channel join 命令并指定初始区块 – mychannel.block

peer channel join -b mychannel.block

将第二个节点加入到 Org3 中

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

7.升级和调用链码

从 Org3 CLI 执行

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

回到原始CLI 容器，在 Org1 和 Org2 节点上安装新版本链码

# 由于使用 Org2 管理员身份提交通道更新请求，所以容器仍代表 “peer0.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/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=peer0.org1.example.com:7051

# 为 Org1 安装新链码
peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

升级链码

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')"

查询

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

调用，从 a 转移 10 到 b

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

8.更新 Org3 的锚节点

在Org3的CLI容器内，使用peer channel fetch命令获取通道的最新配置块

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

提取配置块后，我们将其转换为JSON格式，使用jq工具裁剪不需要的头部信息

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

再次使用jq工具，添加 Org3 锚节点的配置信息

jq '.channel_group.groups.Application.groups.Org3MSP.values += {"AnchorPeers":{"mod_policy": "Admins","value":{"anchor_peers": [{"host": "peer0.org3.example.com","port": 11051}]},"version": "0"}}' config.json > modified_anchor_config.json

将 config.json 和 modified_anchor_config.json 转换回 protobuf 格式，并计算两者之间的差异

# 将 config.json 转换回 protobuf 格式为 config.pb
configtxlator proto_encode --input config.json --type common.Config --output config.pb

# 将 modified_anchor_config.json 转换为 protobuf 格式为 modified_anchor_config.pb
configtxlator proto_encode --input modified_anchor_config.json --type common.Config --output modified_anchor_config.pb

# 计算差异
configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_anchor_config.pb --output anchor_update.pb

将 anchor_update.pb 解码成可编辑的 JSON 格式，并命名为 anchor_update.json

configtxlator proto_decode --input anchor_update.pb --type common.ConfigUpdate | jq . > anchor_update.json

用信封消息来包装它，把之前裁剪掉的头部信息还原

echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat anchor_update.json)'}}}' | jq . > anchor_update_in_envelope.json

转换为 Fabric 需要的完整独立的 protobuf 格式

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

更新

peer channel update -f anchor_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA

总结

本质就是为了构建一个用 protobuf 二进制表达的差异化的交易对象，然后获取必要数量的管理员签名来满足通道的修改策略