總目錄：
(0) 如何利用區塊鏈保護知識產權
(一)HyperLedger Fabric 2.0-release測試網絡部署
(二)Fabric2.0 first-network 生成配置說明
(三)Fabric2.0啓動網絡腳本配置剖析
(四)Fabric2.0通道實踐
(五)Fabric2.0 智能合約實踐- 安裝以及定義智能合約
(六)Fabric2.0 智能合約實踐- 升級智能合約
(七)Fabric2.0智能合約實踐-設置背書策略
(八)Fabric2.0Java SDK實踐-合約交易
(九)Fabric2.0 通道實踐-更新通道配置
(十)Fabric2.0-動態添加組織
(十一) Fabric2.0-使用編輯器調試go智能合約
(十二)Fabric2.0-實現外部構建啓動合約
工具人大膽試探raft共識-你沒見過的raft算法解釋
下面實踐將基於已部署好的first-network.
1.通道配置說明
我們再前面創建通道的時候，通過configtx.yaml定義通道的基礎配置包括
- 策略：
通道的讀寫權限策略等
- Capabilities：
確保網絡和通道以相同的方式處理交易，使用版本號進行定義。
-
Channel/Application：
控制應用程序通道的配置參數(添加/刪除組織):修改這一部分配置需要大部分組織管理管理員的簽名。 將組織添加到通道：要實現添加到通道必須將組織的MSP等配置參數添加到組織配置，下一章將詳細講。 組織相關參數:可以更改組織特定的任何參數（例如，標識錨點對等體或組織管理員的證書）。請注意，默認情況下，更改這些值將不需要大多數應用程序組織管理員，而僅需要組織本身的管理員 -
Channel/Orderer：
控制排序節點相關參數
-
Batch size
Batch size：這些參數決定了一個區塊中交易的數量和大小。 Batch timeout 在第一個交易到達其他交易之後，在切割區塊之前要等待的時間。減小該值將改善等待時間，但是減小該值可能會由於不允許塊填滿其最大容量而降低吞吐量。 Block validation: 該策略指定了被視爲有效的塊的簽名要求。默認情況下，它需要訂購組織的某些成員的簽名。 -
Channel：
控制peer跟orderer都需要同意的參數，需要大部分應用程序管理者同意
orderer地址：客戶端可以在其中調用orderer的Broadcast和Deliver功能的地址列表。peer在這些地址中隨機選擇，並在它們之間進行拉取塊。
Hashing structure ：塊數據是字節數組的數組。塊數據的哈希計算爲默克爾樹。此值指定該Merkle樹的寬度。目前，該值固定爲4294967295。
散列算法：用於計算編碼到區塊鏈塊中的哈希值的算法。特別是，這會影響數據散列以及該塊的先前的塊散列字段。請注意，此字段當前只有一個有效值（SHA256），不應更改。
Consensus type 共識類型： 爲了能夠將基於Kafka的orderer服務遷移到基於Raft的orderer服務，可以更改渠道的共識類型。
2.更新通道
2.1提取並解析通道配置
更新通道配置的第一步是獲取最新的配置塊。這是一個三步過程。首先，我們將以protobuf格式提取通道配置，創建一個名爲的文件config_block.pb。
控制檯數據docker exec -it cli bash進入cli
peer channel fetch config config_block.pb -o $ORDERER_CONTAINER -c mychannel --tls --cafile $TLS_ROOT_CA
控制檯輸入獲取通道區塊數碼，並生成config_block.pb文件
.pb是protobuf格式，我們將他轉成json版本
繼續再當前目錄輸入以下命令
configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
--input .pb文件路徑
--output 轉json格式後輸出文件路徑
生成config_block.json文件
看一下輸出的config_block.json文件，數據很多
最後，我們將從配置中排除所有不必要的元數據，使其更易於閱讀。您可以隨意調用該文件，但是在本示例中，我們將其稱爲config.json。
執行以下命令
jq .data.data[0].payload.data.config config_block.json > config.json
部分數據截取如下：
爲了待會比較，我們先複製一份
cp config.json modified_config.json
2.2 修改配置
修改Batch size，將區塊最大交易數量提高，原本max_message_count是10，我們修改爲100。
原本：
vi modified_config.json
修改後：
2.2 重新編碼跟提交配置
首先，我們將config.json文件恢復爲protobuf格式，創建一個名爲的文件config.pb。然後，我們將對我們的modified_config.json文件執行相同的操作。之後，我們將計算兩個文件之間的差，創建一個名爲的文件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
現在我們已經計算出舊配置和新配置之間的差異config_update.pb，我們可以將更改應用於配置。
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json
查看差異配置
將差異配置重新編碼
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
提交配置
peer channel update -f config_update_in_envelope.pb -c mychannel -o $ORDERER_CONTAINER --tls true --cafile $TLS_ROOT_CA
控制檯輸出：
implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
上面的錯誤應該是很熟悉了，就是修改這個配置不夠權限，提示需要Admin，由於batchSize屬於排序節點的配置，所以這裏的Admin是OrdererMSP.admin
這裏要注意一點的是 first-network的排序節點是沒有區份admin、client這些需要再crypto-config.yaml打開配置如下：
切換OrdererMSP.admin環境變量如下：
CORE_PEER_LOCALMSPID=OrdererMSP
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/[email protected]/msp/
原本應該調用peer channel signconfigtx 進行簽名的，但是peer channel update 的時候會自動帶客戶端簽名，這裏我們直接update就行了，因爲他需要1個Admin而已
控制檯輸入：
peer channel update -f config_update_in_envelope.pb -c mychannel -o $ORDERER_CONTAINER --tls true --cafile $TLS_ROOT_CA
輸出結果如下：
通道配置更新成功
3. 總結
更新通道配置步驟主要是獲取現有配置，修改配置，提交配置，看起來比較簡單，但是有一點要留意的是權限問題，想剛剛上面就提示沒有收集夠簽名，這時候我們應該關注日誌輸出內容，回顧我們原本configtx.yaml的配置，找到需要的簽名，滿足策略。
推薦閱讀：(十)Fabric2.0-動態添加組織