Using configtx.yaml to build a channel configuration¶

チャネルは、チャネルの初期設定を指定するチャネル作成トランザクションアーティファクトをビルドすることによって作成されます。チャネル設定( channel configuration )は台帳に格納され、チャネルに追加されるすべての後続のブロックを管理します。チャネル設定は、どの組織がチャネルメンバーであるか、新しいブロックを追加できるオーダリングノード、チャネルの更新を管理するポリシーなどを指定します。ジェネシスブロックに格納されている初期チャネル設定は、チャネル設定の更新によって更新することができます。十分な数の組織がチャネル更新を承認すると、新しいチャネル設定ブロックはチャネルにコミットされた後に、チャネルを管理するようになります。

チャネル作成トランザクションファイルを手動でビルドすることは可能ですが、 configtx.yaml ファイルと configtxgen ツールを使用してチャネルを作成する方が簡単です。 configtx.yaml ファイルには、チャネル設定をビルドするために必要とされる情報が、人間が簡単に読み込み編集できる形式で記述されています。 configtxgen ツールは、 configtx.yaml ファイル内の情報を読み取り、Fabricが読めるプロトコルバッファフォーマット protobuf format に書き込みます。

Overview¶

このチュートリアルを使用して、ジェネシスブロックに格納されている初期チャネル設定をビルドするするための configtx.yaml ファイルの使用方法を学習することができます。チュートリアルでは、ファイルの各セクションによってビルドされるチャネル設定の部分について説明します。

Organizations
Capabilities
Application
Orderer
Channel
Profiles

ファイルのさまざまなセクションが連携して、チャネルを管理するためのポリシーが作成されるため、チャネルポリシーについてはチュートリアルごとに説明します。

Creating a channel tutorial のビルドでは、例としてFabricテストネットワークをデプロイするに使用される configtx.yaml ファイルを使用します。ローカルマシンのコマンドターミナルを開き、Fabricサンプルのローカルクローンにある test-network ディレクトリに移動します。:

cd fabric-samples/test-network

テストネットワークが使用する configtx.yaml ファイルは、 configtx フォルダにあります。ファイルをテキストエディタで開きます。チュートリアルで各セクションを進む際に、このファイルを参照することができます。Fabricサンプル設定 Fabric sample configuration に詳細なバージョンの configtx.yaml ファイルがあります。

Organizations¶

チャネル設定に含まれる最も重要な情報は、チャネルメンバである組織です。各組織は、MSP IDとチャネルMSP channel MSP によって識別されます。チャネルMSPはチャネル設定に格納され、組織のノード、アプリケーション、および管理者を識別する際に使用する証明書が含まれます。 configtx.yaml ファイルの Organizations セクションは、チャネルの各メンバーのチャネルMSPと付随するMSP IDを作成するために使用されます。

テストネットワークによって使用される configtx.yaml ファイルには、3つの組織が含まれています。2つは、アプリケーションチャネルに追加することができるOrg1およびOrg2のピア組織です。あと1つは、OrdererOrgというオーダリングサービスの管理者の組織です。ピアノードとオーダリングノードをデプロイするのに別の認証局を使用することがベストプラクティスであるため、実際には同じ企業が運用していても、組織はピア組織またはオーダリング組織として参照されます。

テストネットワークの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')"

Name フィールドは、組織を識別するのに使用される非公式の名前です。
ID フィールドは組織のMSP IDです。MSP IDは、組織のユニークな識別子として機能し、チャネルポリシーによって参照され、チャネルに送信されるトランザクションに含まれます。
MSPDir は組織によって作られたMSPフォルダへのパスです。 configtxgen ツールは、チャネルMSPを作成するためにこのMSPフォルダを使用します。このMSPフォルダには次の情報を含める必要があります。そしてそれらはチャネルMSPに転送され、チャネル設定に格納されます。:
- 組織への信頼のルートを設定するCAルート証明書。CAルート証明書は、アプリケーション、ノード、または管理者がチャネルメンバーに属しているかどうかを確認するために使用されます。
- ピアまたはオーダリングノードのTLS証明書を発行したTLS CAからのルート証明書。TLSルート証明書は、ゴシッププロトコルによって組織を識別するするために使用されます。
- Node OUが有効になっている場合、MSPフォルダは、x509証明書のOUに基づいた管理者、ノード、およびクライアントを識別する config.yaml ファイルを含む必要があります。
- Node OUが有効になっていない場合、MSPには、組織管理者のアイデンティティの署名証明書を含むadmincertsフォルダを含める必要があります。
チャネルMSPの作成に使用されるMSPフォルダには、公開証明書のみが含まれます。その結果、MSPフォルダをローカルにビルドし、チャネルを作成している組織にMSPを送信することができます。
Policy セクションは、チャネルメンバを参照するSignatureポリシーのセットを定義するために使用されます。 channel policies について説明するときに、これらのポリシーについて詳しく説明します。

Capabilities¶

Fabricチャネルは、Hyperledger Fabricの異なるバージョンを実行しているordererとピアノードを追加させることができます。チャネルケイパビリティは、特定の機能のみを有効にすることによって、異なるFabricバイナリを実行している組織を同じチャネルに参加するのを許可します。たとえば、Fabric v1.4を実行している組織とFabric v2.xを実行している組織は、チャネルケイパビリティレベルがV1_4_X以下に設定されている限り、同じチャネルに参加できます。どのチャネルメンバーもFabric v2.0で導入された機能は使用できません。

configtx.yaml ファイルを調べると、次の3つのケーパビリティグループがあります。:

Application ケーパビリティは、Fabricチェーンコードライフサイクルなどのようなピアノードによって使用される機能を管理し、チャネルに接続されたピアによって実行可能なFabricバイナリの最小バージョンを設定します。
Orderer ケーパビリティは、Raft合意形成などのようなオーダリングノードで使用される機能を管理し、チャネル同意者セットに属するオーダリングノードで実行可能なFabricバイナリの最小バージョンを設定します。
Channel ケーパビリティは、ピアとオーダリングノードが実行できるFabricの最小バージョンを設定します。

Fabricテストネットワークのピアとオーダリングノードの両方がバージョンv2.xを実行するため、すべてのケーパビリティグループは v2_0 に設定されます。結果として、テストネットワークは、v2.0よりも低いFabricのバージョンを実行するノードが参加することができません。詳細については、 capabilities コンセプトトピックを参照してください。

Application¶

アプリケーションセクションでは、ピア組織がアプリケーションチャネルとどのようにやりとりすることができるかを管理するポリシーを定義しています。これらのポリシーは、チェーンコード定義を承認するのに必要なピア組織の数、またはチャネル設定の更新に署名する必要のあるピア組織の数を管理します。これらのポリシーは、チャネル台帳への書き込みまたはチャネルイベントのクエリのような、チャネルリソースへのアクセスを制限するためにも使用されます。

テストネットワークはHyperledger Fabricが提供するデフォルトアプリケーションポリシーを利用しています。デフォルトポリシーを使用する場合、すべてのピア組織は台帳のデータを読み書きすることができます。また、デフォルトポリシーでは、チャネルメンバーの過半数がチャネル設定の更新を署名し、チェーンコードがチャネルにデプロイされる前にチャネルメンバーの過半数がチェーンコード定義を承認することが必要です。このセクションの内容については、 channel policies チュートリアルで詳しく説明しています。

Orderer¶

各チャネル設定には、チャネル同意者セットのオーダリングノードが含まれます。同意者セットは、新しいブロックを作成し、それをチャネルに参加しているピアへ配布する能力を持つオーダリングノードのグループです。同意者セットのメンバーである各オーダリングノードのエンドポイント情報は、チャネル設定に格納されます。

テストネットワークは configtx.yaml ファイルの Orderer セクションを使用して、単一ノードRaftオーダリングサービスを作成します。

-OrdererType フィールドは、合意形成タイプとしてRaftを選択するために使用されます。:

OrdererType: etcdraft

Raftオーダリングサービスは、合意形成プロセスに参加できる同意者のリストによって定義されます。テストネットワークはオーダリングノードを1つだけ使用するので、同意者リストはエンドポイントを1つだけ含みます。:

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
    Addresses:
    - orderer.example.com:7050

同意者リストの各オーダリングノードは、エンドポイントのアドレスとクライアントおよびサーバーのTLS証明書によって識別されます。マルチノードオーダリングサービスをデプロイする場合は、ホスト名、ポート、および各ノードで使用されるTLS証明書へのパスを指定する必要があります。また、各オーダリングノードのエンドポイントアドレスを Addresses のリストに追加する必要があります。

BatchTimeout フィールドと BatchSize フィールドを使用して、各ブロックの最大サイズと新しいブロックが作成される頻度を変更することにより、チャネルのレイテンシとスループットを調整できます。
Policies セクションは、チャネル同意者セットを管理するポリシーを作成します。テストネットワークは、Fabricによって提供されたデフォルトポリシーを使用します。このポリシーでは、orderer管理者の過半数が、オーダリングノードや組織の追加や削除、またはブロック作成パラメータに対する更新について、承認する必要があります。

テストネットワークは開発とテストに使用されるため、単一のオーダリングノードで構成されるオーダリングサービスを使用します。本番でデプロイされるネットワークは、セキュリティと可用性のためにマルチノードオーダリングサービスを使用する必要があります。詳細については、 Configuring and operating a Raft ordering service を参照してください。

Channel¶

チャネルセクションでは、チャネル設定の最高レベルを管理するポリシーを定義しています。アプリケーションチャネルの場合、これらのポリシーはハッシュ・アルゴリズム、新しいブロックの作成に使用されるデータ・ハッシュ構造、およびチャネルケイパビリティレベルを管理します。システム・チャネルでは、これらのポリシーはピア組織のコンソーシアムの作成または削除も管理します。

テストネットワークは、Fabricによって提供されるデフォルトポリシーを使用します。このポリシーでは、過半数のordererのサービス管理者が、システムチャネル内のこれらの値の更新について承認する必要があります。アプリケーションチャネルでは、変更はorderer組織の過半数とチャネルメンバーの過半数によって承認される必要があります。ほとんどのユーザは、これらの値を変更する必要はありません。

Profiles¶

configtxgen ツールは、 Profiles セクションのチャネルプロファイルを読み取って、チャネル設定をビルドします。各プロファイルはYAML構文を使用して、ファイルの他のセクションからデータを収集します。 configtxgen ツールはこの設定を使用して、アプリケーションチャネルに対してチャネル作成トランザクションを作成したり、システムチャネルに対してチャネルジェネシスブロックを書き込みます。YAML構文についてさらに学ぶために、最初は Wikipedia を参考にするのがいいでしょう。

テストネットワークで使用される configtx.yaml には、 TwoOrgsOrdererGenesis と TwoOrgsChannel という2つのチャネルプロファイルが含まれています。:

TwoOrgsOrdererGenesis¶

TwoOrgOrdererGenesis プロファイルは、システムチャネルジェネシスブロックを作成するために使用されます。:

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

システムチャネルは、オーダリングサービスのノードと、オーダリングサービス管理者である組織のセットを定義します。システムチャネルには、ブロックチェーンコンソーシアム consortium に属するピア組織セットも含まれます。コンソーシアムの各メンバーのチャネルMSPはシステムチャネルに含まれているため、新しいアプリケーションチャネルを作成し、新しいチャネルにコンソーシアムメンバーを追加することができます。

プロファイルは、 configtx.yaml ファイル内の2つのピア組織(Org1とOrg2)を含む SampleConsortium という名前のコンソーシアムを作成します。プロファイルの Orderer セクションは、ファイルの Orderer: セクションで定義された単一ノードRaftオーダリングサービスを使用します。 Organizations: セクションのOrdererOrgは、オーダリングサービスの唯一の管理者となります。唯一のオーダリングノードがFabric 2.xを運用しているため、ordererシステムチャネルケーパビリティを V2_0 に設定することができます。システムチャネルは、 Channel セクションのデフォルトポリシーを使用し、チャネルケーパビリティレベルとして V2_0 を有効にします。

TwoOrgsChannel¶

TwoOrgsChannel プロファイルは、アプリケーションチャネルを作成するためにテストネットワークによって使用されます。:

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

システムチャネルは、オーダリングサービスによってアプリケーションチャネルを作成するためのテンプレートとして使用されます。システムチャネルで定義されたオーダリングサービスのノードは、新しいチャネルのデフォルト同意者セットになり、オーダリングサービスの管理者は、チャネルのorderer管理者になります。チャネルメンバのチャネルMSPは、システムチャネルから新しいチャネルに転送されます。チャネルが作成された後、チャネル設定を更新することによって、オーダリングノードを追加したりチャネルから削除したりすることができます。他の組織をチャネルメンバーとして追加するために、チャネル設定を更新することもできます。

TwoOrgsChannel は、テストネットワークシステムチャネルがホストする SampleConsortium というコンソーシアムの名前を提供しています。その結果、 TwoOrgsOrdererGenesis プロファイルで定義されたオーダリングサービスはチャネル同意者セットとなります。 Application セクションでは、両方のコンソーシアムの組織(Org1とOrg2)がチャネルメンバーとして含まれます。チャネルは V2_0 をアプリケーションケーパビリティとして使用し、ピア組織がチャネルとどのようにやりとりするかを管理するために、 Application セクションのデフォルトポリシーを使用します。また、アプリケーションチャネルは Channel セクションのデフォルトポリシーを使用し、チャネルケーパビリティレベルとして V2_0 を有効にします。