前言
通道配置中包含了区块链网络的结构以及控制网络交互的信息。这些配置由通道成员共同决定，并提交到通道的账本中，可以使用configtxgen工具来构建通道配置。
配置包含在创世块中，更新通道配置的过程（例如添加通道成员或更改通道策略）称为配置更新交易。在生产环境中，通常由单个通道管理员来配置更新。
虽然应用通道（application channel ）和排序系统通道（system channel）不完全相同，但却十分类似，具有相同的基本规则和结构，拉取和编辑的命令也是如此。因此这里我们以应用通道为例。由于通道配置信息比较长，这里不放上来了，感兴趣的朋友可以点击下载链接查看：通道配置文件 （提取码：33ox）。
配置信息主要分成三块：Channel，Application和Orderer。每个配置都会有与其相关的配置参数（例如MSP信息）。
通道配置参数
Channel/Application： 控制应用通道特有的配置参数（例如添加或删除通道成员）。 默认情况下，更改这些参数需要大多数组织管理员的签名，分以下两种情况：
（1）通道中添加组织：要想将组织添加到通道，必须生成其MSP和其它组织参数，并添加到Channel/Application/groups下。
（2）与组织相关的参数：任何组织相关的参数均可以修改，例如锚节点的配置，组织admin的证书。更改这些值仅需要组织本身的管理员同意。
Channel/Orderer： 控制排序服务或者排序系统通道的参数，需要大多数排序组织的管理员同意 。
（1）Batch size：这个参数决定了一个区块中的交易的数量和大小，区块不会大于absolute_max_bytes 或者交易数量大于max_message_count 。
（2）Batch timeout.：批等待时间，即第一个交易等待batch timeout时间才会切割区块。减小该值，将会降低等待时间，但如果这个值过小，将会影响吞吐量。
（3）Block validation：定义了某个块被视为有效的签名要求，默认情况，需要多个排序组织的签名。
（4）Consensus type：共识类型。
（5）Raft ordering service parameters：选用etcd raft共识时的参数。
（6）Kafka brokers：选用Kafka共识时brokers的配置。
Channel：
Orderer addresses：可以广播和传递的地址列表，Peer节点从中选择。
Hashing structure：块数据是字节数组。 块数据的哈希计算为默克尔树。 此值指定该Merkle树的宽度。 目前，此值固定为4294967295，它对应于块数据字节串联的简单平面哈希。
Hashing algorithm：哈希算法，用于计算编码到区块链块中的哈希值的算法。 特别是，这会影响数据散列以及该块的先前的块散列字段。 注意，此字段当前只有一个有效值（SHA256），不应更改。
更新通道配置
更新通道配置，一般分为以下三个步骤：
- 获取最新的通道配置
- 创建修改后的通道配置
- 重新编码并提交配置
获取最新的通道配置
作为更新通道步骤的第一步，我们需要获取最新的通道配置块。
先配置节点信息：
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/peerOrganizations/org1.example.com/users/[email protected]/msp
export CORE_PEER_ADDRESS=peer0.org1.example.com:7051
export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
export CHANNEL_NAME=mychannel
export ORDERER_ADRESS=orderer.example.com:7050
拉取protobuf格式的通道配置
peer channel fetch config config_block.pb -o $ORDERER_ADRESS -c $CHANNEL_NAME--tls --cafile $ORDERER_CA
使用configtxlator工具转化为易读的json格式:
configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
使用jq工具去掉不必要的配置信息:
jq .data.data[0].payload.data.config config_block.json > config.json
复制config.json得到modified_config.json:
cp config.json modified_config.json
创建修改后的通道配置
有两种修改配置的方法:
- 使用文本编辑器修改modified_config.json
- 使用jq工具
选择手动编辑配置还是使用jq取决于修改的用例。 由于jq简洁明了且可编写脚本（当对多个通道进行相同的配置更新时，这是一个优势），因此它是执行通道更新的推荐方法。
关于jq在更改通道配置时的使用，参考：Fabric 2.0 之动态添加组织
重新编码并提交配置
第一步是将config.json和修改后的modified_config.json转化为protobuf格式,然后计算两者差异:
configtxlator proto_encode --input config.json --type common.Config --output config.pb
configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb
configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output config_update.pb
更改配置:
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"'$CHANNEL_NAME'", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output config_update_in_envelope.pb
在提交交易前,我们需要获取足够数量（通道更新策略，默认大多数组织签名）的组织签名,命令如下,这里我们以组织一admin角色进行签名。
peer channel signconfigtx -f config_update_in_envelope.pb
如还需要组织二的签名，可以切换身份到组织二的admin角色：
export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/peerOrganizations/org2.example.com/users/[email protected]/msp
export CORE_PEER_ADDRESS=peer0.org2.example.com:9051
组织二签名并提交交易，排序服务会变换并得到一个全新的完整的通道配置:
peer channel update -f config_update_in_envelope.pb -c $CHANNEL_NAME -o $ORDERER_ADRESS --tls true --cafile $ORDERER_CA