建立Hyperledger Fabric的渠道

如何用configtx.yaml來建立渠道配置

15 min readOct 15, 2022

所謂的渠道是用渠道初始配置的channel creation transaction artifact來建立渠道的。渠道配置(channel configuration)存儲在分佈式帳本中，並管理加到渠道中的所有後續區塊(Block)。渠道配置指定哪些組織是渠道成員，這些組織擁有的排序節點(Ordering nodes)可以在渠道上加入新的區塊，以及管理渠道更新的政策。存儲在渠道創世區塊(channel genesis block)中的初始渠道配置可以用channel configuration updates來進行更版。如果有足夠數量的組織批准渠道更新，則新的渠道區塊(config block)將在提交到渠道後輩該渠道所管理。

雖然可以手動建立渠道建立交易檔案，但使用 configtx.yaml 檔案和 configtxgen 工具更容易建立渠道。 configtx.yaml 檔案是以人類看得的的格致來閱讀和編輯建立渠道配置所需的資訊。 configtxgen 工具讀取 configtx.yaml 檔案中的資訊，並將其寫入 Fabric 可以讀取的 protobuf 格式。

概述

本文將會講解如何使用 configtx.yaml 檔案來建立存儲在創世區塊中的初始渠道配置。我們將討論檔案中的每個部分，它們分別是:

Organization
Capabilities
Application
Orderer
Channel
Profiles

configtz.yaml的不同部分組合起來會共同建立管理渠道的政策，我們將在每一個部分討論渠道政策。

在建立渠道討論的基礎上，我們將使用用於部署 Fabric 測試網路的 configtx.yaml 檔案作為範例。在你自己的電腦(Linux OS)上打開一個terminal並切換到我們已經把Fabric 範例複製到我們電腦中的 test-network 目錄：

cd fabric-samples/test-network

測試網路使用的 configtx.yaml 檔案位於 configtx 文件夾中。在文字編輯器中打開檔案。當我們討論到每個部分時，都可以參考此檔案。我們可以在 Fabric Github範例配置中找到更詳細的 configtx.yaml 檔案版本。

Organization

渠道配置中第一個最重要資訊是渠道成員的組織。每個組織都由一個 MSP ID 和一個channle MSP來識別。Channel MSP 存儲在渠道配置中，並包含用於識別組織的節點(也就是電腦)、應用程式和管理員這三者的憑證。 configtx.yaml 檔案的 Organizations 部分用於為渠道的每個成員建立渠道 MSP 和它該有的 MSP ID。

測試網路使用的 configtx.yaml 檔案包含三個組織。兩個組織是對等組織(peer organizations) Org1 和 Org2，它們可以加入到應用程式渠道。一個組織 OrdererOrg 是Order service的管理員。因為使用不同的CA(憑證發行機構)來部署對等節點(peer nodes)和排序節點(Ordering nodes)是最佳實踐，所以組織通常被稱為對等組織或排序組織，即使它們實際上由同一家企業來運作。

我們可以在下面看到定義測試網路 Org1 的 configtx.yaml 部分：

- &Org1
    # DefaultOrg defines the organization which is used in the sampleconfig
    # of the fabric.git development environment
    Name: Org1MSP

    # ID to load the MSP definition as
    ID: Org1MSP

    MSPDir: ../organizations/peerOrganizations/org1.example.com/msp

    # Policies defines the set of policies at this level of the config tree
    # For organization policies, their canonical path is usually
    #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
    Policies:
        Readers:
            Type: Signature
            Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
        Writers:
            Type: Signature
            Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
        Admins:
            Type: Signature
            Rule: "OR('Org1MSP.admin')"
        Endorsement:
            Type: Signature
            Rule: "OR('Org1MSP.peer')"

    # OrdererEndpoints is a list of all orderers this org runs which clients
    # and peers may to connect to to push transactions and receive blocks respectively.
    OrdererEndpoints:
        - "orderer.example.com:7050"

上面的設定檔中，Name filed 是用於識別組織的非正式名稱。ID field 是組織的 MSP ID。 MSP ID 會做為組織的唯一標示，由渠道政策引用並包含在提交給渠道的交易中，這樣才知道這筆交易有哪些組織參與。MSPDir field是組織建立的 MSP 文件夾的路徑。 configtxgen 工具會使用這個 MSP 文件夾來建立Channel MSP。此 MSP 文件夾需要包含以下資訊，這些資訊將傳送到Channel MSP 並存儲在渠道配置中：

為組織建立信任的Root CA 憑證。 Root CA 憑證用於驗證應用程式、節點或管理員是否屬於渠道成員。
一個root cert，從 TLS CA(發行對等節點或排序節點的TLS憑證)而來的。 TLS root cert用於節點之間通訊 gossip 協定來識別組織。
如果啟用了Node OU，則 MSP 文件夾需要包含一個 config.yaml 檔案，該檔案根據其 x509 憑證的 OU 標識administrators、nodes和cleint。
如果未啟用Node OU，則 MSP 需要包含一個 admincerts 文件夾，其中包含組織管理員身份的簽署憑證。

用於建立channel MSP 的 MSP 文件夾只包含public certificates。因此，我們可以在自己的電腦中構建 MSP 文件夾，然後將 MSP 發送到建立渠道的組織。

再來是Policies的部分。這是用於定義一組引用渠道中成員的簽名政策。這篇文章有更詳細的討論到channel policies。

Capabilities

運作不同版本的 Hyperledger Fabric 的排序節點和對等節點可以加入 Fabric 渠道。 Channel capabilities允許只開啟特定功能的不同 Fabric 版本的組織參與到同一個渠道。例如，運作Fabric v1.4 的組織和運作 Fabric v2.x 的組織可以加入同一個渠道，只要渠道功能等級設置為 V1_4_X 或更低。但所有渠道成員都無法使用 Fabric v2.0 才有的功能，也就是渠道雖然能向下相容，但無法啟用新版本的功能。

如果我們看configtx.yaml這個檔案，我們會看到以下三個capabilities groups:

Application — capabilities管理對等節點使用的功能，例如 Fabric chaincode lifecycle，並設定加入渠道的對等節點可以運作的 Fabric的最低版本。
Orderer — capabilities管理排序節點使用的功能，例如 Raft consensus，並設定可以由屬於channel consenter set排序節點運行的 Fabric的最低版本。
Channel — capabilities設定可以由對等節點和排序節點運行的 Fabric 的最低版本。

現行 Fabric 測試網路的 Peer 節點和排序節點都運行 v2.x 版本，因此每個capability group都設置為 V2_0。因此，運行低於 v2.0 的 Fabric 版本的節點無法加入測試網路。

Application

應用程式部分定義了管理對等組織如何與應用程式渠道交互的政策。這些整管理需要批准chaincode的定義或簽署更新渠道配置請求的對等組織數量。這些政策還用於限制對渠道資源的訪問，例如寫入渠道帳本或查詢渠道事件的能力。

測試網路使用 Hyperledger Fabric 提供的是預設應用政策。如果我們使用得是預設的政策，所有對等組織將能夠讀取和寫入分佈式帳本資料。預設政策還要求大多數渠道成員簽署通道配置的更新，並且大多數渠道成員需要批准chaincode定義，然後才能將代碼部署到渠道。更多channel policies可以參閱本篇文件。

Orderer

每個渠道配置都包含channel consenter set中的排序節點。 Consenter set是一組排序節點，它們能夠建立新區塊並將它們分發給加入渠道的對等點。作為consenter set成員的每個排序節點的端點資訊(endpoint information)存儲在渠道配置中。

測試網路使用 configtx.yaml 檔案中的 Orderer 部分來建立單一節點 Raft Ordering service。設定如下:

OrdererType: etcdraft

Raft Ordering service由可以參與共識過程的consenter 清單決定。由於測試網路只使用單一排序節點，因此consenter 清單僅包含一個端點(如果是我們的正式環境就會有一群端點)：

EtcdRaft:
    Consenters:
    - Host: orderer.example.com
      Port: 7050
      ClientTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
      ServerTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt

Consenters 清單中的每個排序節點都由它們的端點地址(endpoint address)以及它們的client和server的 TLS 憑證來確認它們的身分。如果要部署多個節點排序服務，則需要提供每個節點的 TLS 憑證的hostname、port和path。

我們可以使用 BatchTimeout 和 BatchSize 的參數來更改每個新區塊建立的頻率以及區塊大小以來調整渠道的延遲(latency)和吞吐量(throughput)。 BatchSize 屬性包括 MaxMessageCount、AbsoluteMaxBytes 和 PreferredMaxBytes 設置。當達到 BatchTimeout 或 BatchSize 任一個設定參數時，就會產生一個新區塊。對於 AbsoluteMaxBytes，建議不要超過 49 MB，因為在 orderer 和對等節點上配置的預設 gRPC 最大訊息為 100 MB（並允許在通信期間進行訊息擴爭）。

政策設定的部分會建立管理channel consenter set的政策。測試網路使用 Fabric 提供的預設政策，要求大多數 orderer 管理員批准添加或刪除排序節點、組織或更新區塊大小的參數。

Channel

渠道的部分定義了管理最高級渠道配置的政策。對於Application Channel，這些政策管理著hashing algorithm、用於建立新區塊的data hashing structure以及channel capability level。在系統渠道(system channel)中，這些政策還管理對等組織的社群(consortiums)的建立或刪除。

測試網路使用 Fabric 提供的預設政策，這要求大多數 orderer 服務管理員需要在系統渠道中批准對這些參數的更新。在應用程序渠道中，更改需要得到大多數orderer organizations和大多數渠道成員的批准。大多數使用者不需要更改這些參數。

Profiles

configtxgen 工具會讀取在Profiles中的 channel profiles以建立渠道配置。每個profile都會使用 YAML 語法從檔案的其他部分讀取資料。 configtxgen 工具使用此配置為applications channel建立channel creation transaction，或為系統渠道產生 channel genesis block(渠道帳本中的第一個區塊)。測試網路使用的 configtx.yaml 包含兩個channel profile : TwoOrgsOrdererGenesis 和 TwoOrgsChannel。

TwoOrgsOrdererGenesis的設定

這個profile是被用來產生system channel genesis block。

TwoOrgsOrdererGenesis:
    <<: *ChannelDefaults
    Orderer:
        <<: *OrdererDefaults
        Organizations:
            - *OrdererOrg
        Capabilities:
            <<: *OrdererCapabilities
    Consortiums:
        SampleConsortium:
            Organizations:
                - *Org1
                - *Org2

系統渠道決定了排序服務的節點和作為排序服務管理員的一群組織。系統渠道還包括一組屬於區塊鏈社群的對等組織。社群中每個成員的 channel MSP都涵蓋在系統渠道(system channel)中，允許他們建立新的應用程式渠道(Application channel)並將社群成員添加到新渠道中。

Profile建立了一個名為 SampleConsortium 的社群，其中包含 configtx.yaml 檔案中的兩個對等組織 Org1 和 Org2。Profile的 Orderer 部分使用檔案的 Orderer參數設定部分定義單一節點 Raft ordering service。而Organizations參數設定部分 OrdererOrg 成為Ordering service的唯一管理員。因為我們唯一的排序節點運行的是 Fabric 2.x，所以我們可以將 orderer system channel capability設定為 V2_0。系統渠道使用渠道參數設定部分的預設政策，並啟用 V2_0 作為channel capability level。

TwoOrgsCChannel的設定

這個profile在測試網路中是被用來產生應用程式渠道的。

TwoOrgsChannel:
    Consortium: SampleConsortium
    <<: *ChannelDefaults
    Application:
        <<: *ApplicationDefaults
        Organizations:
            - *Org1
            - *Org2
        Capabilities:
            <<: *ApplicationCapabilities

Ordering servicec會用system channel作為template來建立Application channel。系統渠道中定義的排序服務節點成為新渠道預設同意者的集合，而排序服務的管理員成為渠道的ordering service administrator。渠道成員的channel MSP 從系統渠道轉移到新的渠道。建立渠道後，可以通過更新渠道配置在渠道中加入或刪除排序節點(Ordering nodes)。我們還可以更新渠道配置以便將其他組織加入為渠道成員。

TwoOrgsChannel 提供了由測試網路系統渠道託管的社群名稱: SampleConsortium。因此，TwoOrgsOrdererGenesis profile中定義的排序服務成為渠道同意者的集合。在“Application”設定的部分，來自社群的兩個組織 Org1 和 Org2 都是渠道成員。該渠道使用 V2_0 作為應用程式功能，並使用“Application”設定部分中的預設政策來管理對等組織將如何與渠道交互。Application channel還使用渠道部分的預設政策，並啟用 V2_0 作為channel capability level。

SampleAppChannelEtcdRaft的設定

SampleAppChannelEtcdRaft profile是為在沒有system channel的狀況下，用osnadmin CLI的方式來建立渠道的。主要區別在於不再需要profile中設置Consortium的參數(如下範例)。

SampleAppChannelEtcdRaft:
    <<: *ChannelDefaults
    Orderer:
        <<: *OrdererDefaults
        OrdererType: etcdraft
        Organizations:
            - <<: *SampleOrg
              Policies:
                  <<: *SampleOrgPolicies
                  Admins:
                      Type: Signature
                      Rule: "OR('SampleOrg.member')"
    Application:
        <<: *ApplicationDefaults
        Organizations:
            - <<: *SampleOrg
              Policies:
                  <<: *SampleOrgPolicies
                  Admins:
                      Type: Signature
                      Rule: "OR('SampleOrg.member')"

為簡單起見，這一段代碼假設 peers 和 orderers 都屬於同一個組織 SampleOrg。然而，對於正式環境的部署，我們需要把對等節點和排序節點分屬於不同的組織。