The following practice has been based on the first-network deployed.
1. Channel Configuration Description
We then created earlier passage of time, through basic configuration includes defining the channel configtx.yaml
- Strategy:
Strategies such as read and write permissions channel
- Capabilities：
Ensure that the network and the channel in the same way to process transactions, use the version number to be defined.
-
Channel/Application：
控制应用程序通道的配置参数(添加/删除组织):修改这一部分配置需要大部分组织管理管理员的签名。 将组织添加到通道：要实现添加到通道必须将组织的MSP等配置参数添加到组织配置，下一章将详细讲。 组织相关参数:可以更改组织特定的任何参数（例如，标识锚点对等体或组织管理员的证书）。请注意，默认情况下，更改这些值将不需要大多数应用程序组织管理员，而仅需要组织本身的管理员 -
Channel/Orderer：
Sort node control parameters
-
Batch size
Batch size：这些参数决定了一个区块中交易的数量和大小。 Batch timeout 在第一个交易到达其他交易之后，在切割区块之前要等待的时间。减小该值将改善等待时间，但是减小该值可能会由于不允许块填满其最大容量而降低吞吐量。 Block validation: 该策略指定了被视为有效的块的签名要求。默认情况下，它需要订购组织的某些成员的签名。 -
Channel：
Control peer with orderer require the consent of the parameters, most applications require managers agree
orderer地址：客户端可以在其中调用orderer的Broadcast和Deliver功能的地址列表。peer在这些地址中随机选择，并在它们之间进行拉取块。
Hashing structure ：块数据是字节数组的数组。块数据的哈希计算为默克尔树。此值指定该Merkle树的宽度。目前，该值固定为4294967295。
散列算法：用于计算编码到区块链块中的哈希值的算法。特别是，这会影响数据散列以及该块的先前的块散列字段。请注意，此字段当前只有一个有效值（SHA256），不应更改。
Consensus type 共识类型： 为了能够将基于Kafka的orderer服务迁移到基于Raft的orderer服务，可以更改渠道的共识类型。
2. Update channel
2.1 channel configuration extract and parse
The first step is to update the channel configuration for the latest configuration block. This is a three-step process. First of all, we will extract the channel configuration protobuf format, create a file named config_block.pb.
Console data docker exec -it cli bashinto the cli
peer channel fetch config config_block.pb -o $ORDERER_CONTAINER -c mychannel --tls --cafile $TLS_ROOT_CA
Console input acquisition channel digital block, file and generate config_block.pb
.pb is protobuf format, we will turn him into a json version
Continue the current directory and then enter the following command
configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
--input .pb文件路径
--output 转json格式后输出文件路径
Generate config_block.json file
Config_block.json look at the output file, a lot of data
Finally, we will exclude all unnecessary configuration metadata, making it easier to read. You can call free to the file, but in this example, we will call config.json.
Execute the following command
jq .data.data[0].payload.data.config config_block.json > config.json
Interception part as follows:
In order to be more to be, let's copy
cp config.json modified_config.json
2.2 modify the configuration
Modify Batch size, the transaction will increase the maximum number of blocks, originally max_message_count 10, we revised to 100.
original:
vi modified_config.json
Modified:
2.2 re-coding configuration with submission
First, we will revert to protobuf config.json file format, create a file named config.pb. Then, we will do the same thing our modified_config.json file. After that, we will calculate the difference between the two files, create a file named config_update.pb.
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 mychannel --original config.pb --updated modified_config.pb --output config_update.pb
Now that we have calculated config_update.pb difference between the old and new configurations, we can apply the changes to the configuration.
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json
Check the configuration differences
The difference Configure re-coding
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "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
Commit the configuration
peer channel update -f config_update_in_envelope.pb -c mychannel -o $ORDERER_CONTAINER --tls true --cafile $TLS_ROOT_CA
Console output:
implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
The above error should be very familiar with, it is to modify the configuration is not enough rights, suggesting the need Admin, due batchSize belongs to the configuration node ordering, so here is OrdererMSP.admin Admin
to note here is that the sort of first-network node is no Fraction admin, client these need to crypto-config.yaml open configuration as follows:
Switching OrdererMSP.admin environment variable as follows:
CORE_PEER_LOCALMSPID=OrdererMSP
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/[email protected]/msp/
Call peer channel signconfigtx supposed to sign, but peer channel update time automatically with the client signature, here we direct update on the line, because he needs only one Admin
Console input:
peer channel update -f config_update_in_envelope.pb -c mychannel -o $ORDERER_CONTAINER --tls true --cafile $TLS_ROOT_CA
Output:
Channel configuration updated successfully
3. Summary
The main update channel configuration step is to get the existing configuration, modify the configuration The configuration is submitted, it seems simple, but one thing to note is that rights issues, would like to just above tips do not collect enough signatures, this time we should be concerned about the contents of log output Recalling the configuration we had configtx.yaml to find signatures needed to meet the policy.
