2.3　應用通道配置

應用通道配置定義了所使用的聯盟和該聯盟的參與者，原始數據也來自configtx.yaml，但這里，我們從通道賬本的角度講述應用通道配置。configtxgen工具依據configtx.yaml為創建應用通道生成的配置交易文件，為Envelope結構。創建時，應用通道會從已運行的系統通道中復制一部分系統通道配置，補充到自己的配置中，最終形成一個以配置為核心數據的區塊，作為應用通道的第一個塊，寫入賬本。

我們可以通過peer channel fetch 0命令，從應用通道獲取第一個塊，然后使用configtxlator工具，將區塊轉為可讀的JSON格式，具體命令如下。

peer channel fetch config config_block.pb -o orderer.example.com:7050 -c mychannel --tls --cafile /path/to/orderer_ca#獲取mychannel通道的最新配置塊，存入config_block.pb文件中。
configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json#使用configtxlator工具，從config_block.pb文件中讀取數據，將配置從區塊轉為可讀的JSON格式，并使用jq工具獲取其中的配置，存入config.json文件中。

一個典型的JSON格式應用通道配置如圖2-2所示。

從圖2-2中，我們可以看出應用通道配置的如下特性。

包含系統通道配置。每一個應用通道配置都包含一個Application配置（第5～24行）和一個Orderer配置（第25行，在創建應用通道時，從系統通道配置中復制而來）。

遞歸性。配置的層級是遞歸的。頂層，即第3行的channel_group，就是一個組（groups），作為整個Fabric區塊鏈網絡的配置對象，對應fabric-protos-go倉庫下common/ configtx.pb.go中定義的ConfigGroup。參見ConfigGroup的成員和對應的JSON標簽，每一層配置都包含groups、policies、values、mod_policy和version這5個成員。

●子組。groups代表當前層級配置下的子組，也可稱為當前層級下的參與者。這個參與者可以是一個通道，如第5行的Application所代表的應用通道，表示當前Fabric區塊鏈網絡中有應用通道Application的參與；也可以是一個組織，如第7行的Application通道下的組織Org1MSP。

●策略。policies代表當前層級下的策略，一般有Admins、Readers、Writers這3個策略。例如第10行的policies，指的是組織Org1MSP中的策略定義；第17行的policies，則是Application這個通道的策略定義；第28行的policies，則是頂層的channel_group，即整個Fabric區塊鏈網絡的策略定義。

●配置項。values代表當前層級使用到的具體的配置項和值。例如第11行，是組織Org1MSP所使用的配置項和對應的值，里面有Org1MSP使用的錨節點AnchorPeers、MSP；第22行，是應用通道Application所使用的配置項和對應的值，里面有指定應用通道的ACL策略和服務能力Capabilities。

●修改策略。mod_policy是當前層級下的修改策略，即誰有權力修改當前層級下的任一配置。修改策略值一般為Admins，即同層級下policies中所定義的Admins策略。例如第16行，設置了應用通道（第5行Application）的修改策略為Admins，即指應用通道下的policies（第17行）中的Admins策略（第18行）。

●版本號。version是當前層級配置的版本號，當前層級配置每修改一次，版本號自增1，但不影響上層級的版本號。版本號的值可用于比較配置的新舊。

提示

Fabric中關于通道配置路徑的表述有兩種方式：經典路徑方式和JSON路徑方式。以圖2-2中第 29 行所配置的區塊鏈網絡 Admins 策略為例，JSON 路徑表示為 config.channel_groups. policies.Admins。經典路徑則以簡潔的標識組成，如Channel代表聯盟網絡根配置、Orderer代表系統通道，Application代表應用通道，經典路徑表示為/Channel/Admins。

通道配置中的groups、values、mod_policy、version，較易于理解。但是policies則需基于配置的遞歸進行理解。在Fabric 2.0中，定義了多種類型的策略，應用在Fabric區塊鏈網絡中的各種主體和行為之上，細節會在第6章詳述，這里可以將策略簡單地理解為：以修改通道配置為例，因為一般只有管理員才能修改配置，策略規定了在當前層級哪些參與者的管理員同意的情況下，配置才能被修改。

圖2-2中第29行，定義了頂層整個Fabric區塊鏈網絡配置的Admins策略，值為MAJORITY Admins，表示當層級（頂層）擁有2個子組參與者Application（第5行）、Orderer（第25行）的情況下，必須有半數以上的參與者的管理員同意修改Fabric區塊鏈網絡的配置，才滿足該Admins策略。2的半數以上，即大于1，那只能是2個，即Application、Orderer的管理員都要同意。此時，若要Application的管理員同意，就需要滿足Application下的Admins策略；若要Orderer的管理員同意，就需要滿足Orderer下的Admins策略。

圖2-2中應用通道Application的Admins策略在第18行指定，值也為MAJORITY Admins，即若要滿足Application的Admins策略，就需要Application的2個子組參與者的半數以上同意修改配置，即Org1MSP（第7行）、Org2MSP（第14行）的管理員都要同意。此時，若要Org1MSP的管理員同意，就需要滿足Org1MSP的Admins策略；若要Org2MSP的管理員同意，就需要滿足Org2MSP的Admins策略。

如圖2-3所示，Org1MSP的Admins策略在第6行（圖左）指定，為Org1MSP.Admins，表示需要Org1MSP組織的管理員同意；Org2MSP的Admins策略在第7行（圖右）指定，為Org2MSP.Admins，表示需要Org2MSP組織的管理員同意。

系統通道Orderer下的Admins策略在圖2-2中未顯示，其設定值也為MAJORITY Admins。遵循的規則與Application一致，Orderer下只有一個參與者OrdererMSP，最終只需OrdererMSP組織的管理員同意，即可滿足Orderer下的Admins策略。

當遞歸至Org1MSP、Org2MSP、OrdererMSP的Admins策略時，策略已經遞歸至某參與者下的某個具體角色身份，即已遞歸到底。如此，總結一下，要滿足圖2-2中第29行定義的頂層整個Fabric區塊鏈網絡配置的Admins策略，經策略遞歸，最終需要OrdererMSP、Org1MSP、Org2MSP這3個組織的管理員同意。

提示

應用通道配置和系統通道配置在邏輯上是一致的，主要的不同點在于：系統通道中主要包含Orderer、Consortiums兩個子組，應用通道中主要包含Application、Orderer兩個子組。此外，第一次創建應用通道時，應用通道對應的聯盟和聯盟的參與者，必須是系統通道配置中已定義的。當應用通道啟動后，可自行管理聯盟的參與者，如添加新組織。