IBM Blockchain Platform を Hyperledger Fabric コンポーネントに接続する

IBM Blockchain Platform と Hyperledger Fabric のコンポーネントを接続する

ブロックチェーン・ネットワークを運用するには、さまざまな組織が連携する必要があります。こうしたネットワークのメンバーがそれぞれに異なるクラウド・プラットフォームを使用してデータとアプリケーションをホストすることはよくありますが、IBM Blockchain Platform では、さまざまなクラウドにわたってコンポーネントをデプロイし、接続できるようになっています。ただし、組織がオープンソースの Hyperledger Fabric や別のサービス・プロバイダーを使ってデプロイしたノードから IBM Blockchain Platform ネットワークに参加しなければならない場合もあります。IBM Blockchain Platform で信条としている基本原則の 1 つは、Hyperledger Fabric のコア・コンポーネントを変更することなく相互運用性を維持することです。したがって、IBM Blockchain Platform を利用してデプロイしてブロックチェーン・ノードを運用しているお客様でも、他の Fabric ネットワークに接続することが可能です。

このチュートリアルは、IBM Blockchain Platform を利用してデプロイされたノードを、Hyperledger Fabric のツールを使用して IBM Blockchain Platform 以外のネットワークに接続する方法を焦点としたシリーズの第 1 回です。このチュートリアルではオープンソースのツールを使用するため、ここで説明する手順に従えば、IBM Blockchain Platform 上のピアを、オープンソース Hyperledger Fabric ネットワークや他のクラウド・プロバイダーによってデプロイされた Hyperledger Fabric ネットワークに接続することができます。ただしその前提として、ネットワーク内のすべてのノードは、Linux Foundation の Hyperledger Fabric プロジェクトが提供しているコードをそのままベースとしているものとします。

IBM Blockchain Platform から Hyperledger Fabric ネットワークに参加する

組織が IBM Blockchain Platform 上にピアをデプロイしている場合、組織は、他の Hyperledger Fabric ネットワークを使用して作成されたチャネルにも参加できます。このチュートリアルでは、ピア組織を Hyperledger Fabric 上の順序付けサービスでホストされているシステム・チャネルや Hyperledger Fabric チャネルに追加するために必要な一連の手順を説明します。これらの手順を完了すると、IBM Blockchain Platform 上のピア組織が既存の Hyperledger Fabric チャネル上でデータを照会したり、トランザクションを承認したりできるようになります。また、Hyperledger Fabric ネットワーク上に作成された任意の新しいチャネルに参加することもできます。

ここでは、Hyperledger Fabric ネットワークは、単一の順序付けサービス組織が実行している順序付けサービスと、別の複数のピア組織によってデプロイされたピアで構成されていることを前提とします。また、IBM Blockchain Platform 上の組織は、ピアをデプロイしている一方、順序付けサービス・ノードを実行していない組織という前提です。

IBM Blockchain Platform ネットワークを示す図

このチュートリアルの手順では、Org2 が IBM Blockchain Platform 上で実行しているピアを、Org1 と順序付けサービス組織によって作成されたチャネルに参加させる方法を説明します。ピア Org1 ノードと順序付けサービス・ノードはどちらもオープンソース Hyperledger Fabric を使用してデプロイされました。

IBM Blockchain Platform 上の組織を Hyperledger Fabric ネットワークに追加するプロセスには、Hyperledger Fabric ネットワークの順序付けサービス組織とピア組織のそれぞれが行わなければならない手順が伴います。また、このプロセスでは IBM Blockchain Platform 上のピア組織も、Hyperledger Fabric のツールを使用する必要があります。このチュートリアルでは、それぞれの組織で必要となる以下の手順を説明します。

分散型 Hyperledger Fabric ネットワークを実行している場合、プロセスに関わるすべての組織がこのチュートリアルを使用して、それぞれの組織に関連する手順に従うことができます。このチュートリアルを開発および教育目的で使用する場合でも、各手順を行ってプロセスをテストできます。

考慮事項

Hyperledger Fabric のツールを使用してノードを管理するのは、IBM Blockchain コンソールを使用する場合よりも遥かに難易度が高い作業です。このトピックは経験を積んだ Hyperledger Fabric のユーザーを対象としています。

前提条件

  • 順序付けサービスと少なくとも 1 つのアプリケーション・チャネルが含まれる、既存の Hyperledger Fabric ネットワーク。
  • IBM Blockchain Platform 上のピア組織。IBM Blockchain Platform ネットワークをデプロイしていない場合、開発やテストの目的でこのチュートリアルに従うには、あらかじめ「手順 1: ピア組織とピアを作成する」に従って CA、組織の MSP 定義、ピア・ノードを作成しておく必要があります。
  • 互換性の問題を回避するために、両方のネットワークで同じバージョンの Hyperledger Fabric を使用することをお勧めします。ノードで使用している Hyperledger Fabric バージョンを調べるには、IBM Blockchain Platform コンソールを使用できます。Hyperledger Fabric チャネルに参加させるピア・ノードの左上隅に示されている数値を確認してください。

    IBM Blockchain Platform コンソールに表示されたバージョンのスクリーン・キャプチャー

  • Hyperledger Fabric の前提条件がインストールされていること。

  • IBM Blockchain Platform は 2 つのオファリングで利用できます。1 つは IBM Cloud のオファリング、もう 1 つはオープンソースの Kubernetes、OpenShift Container Platform、IBM Cloud Private 上にブロックチェーン・コンポーネントをデプロイするために使用できるオファリングです。このチュートリアルの手順は、どちらのオファリングにも有効です。
  • jq ツールがインストールされていること。

制限事項

  • サポート: IBM Blockchain Platform ネットワークに接続されているとしても、オープンソース Hyperledger Fabric のコンポーネントは IBM のサポート対象外です。独自の Hyperledger Fabric ネットワークを実行する場合、IBM からのサポートを受けるには、IBM Blockchain Platform イメージ・オファリングを購入してください。

  • ノード管理: コンソールで Hyperledger Fabric のノードと通信するには、IBM Blockchain Platform で提供している gRPC Web プロキシーが必要です。オープンソース Hyperledger Fabric には gRPC Web プロキシーが同梱されていないため、オープンソース Hyperledger Fabric のツールを使用してノードを管理する必要があります。以下の手順は、コンソールではなく Hyperledger Fabric のツールを使用して行ってください。

    • ノードと組織の追跡: ユーザーは他のメンバーのノードと組織を、アウト・オブ・バンド・プロセスを通じて追跡する必要があります。

    • 署名の管理: ユーザーは Hyperledger Fabric のツールを使用してチャネル更新に対する署名リクエストを送信すべき組織を把握する必要があることがあります。Org1 と Org2 が署名しなければならないもの、これらの組織に署名の必要を通知する方法、順序付けサービス組織がコンソーシアム更新に署名する必要があるかどうか、その必要がどのようにして生じるのか、リクエストを送信するのに十分な署名が収集されたことを知る方法、そのロジックはどこにコーディングされているのか、アプリケーション・レベルでコーディングされているのか、それとも他のところにコーディングされているのかを把握してください。

組織の MSP 定義をエクスポートする

ピア組織が Hyperledger Fabric ネットワークに参加するには、その前に、組織の MSP 定義をアウト・オブ・バンド操作で Hyperledger Fabric 管理者に渡す必要があります。他の Hyperledger Fabric ノードは、組織の MSP 定義に含まれる証明書に基づいて、その組織を特定するからです。IBM Blockchain Platform で使用している組織の MSP 定義を Hyperledger Fabric 管理者に送信すると、管理者がその MSP 定義に含まれる証明書を使用して、ネットワーク内のチャネルに組織を追加できるようになります。

IBM Blockchain コンソールにログインします。「Organizations (組織)」タブを表示して、組織の MSP 定義をクリックします。コンソール内の「Export (エクスポート)」アイコン (以下の図を参照) をクリックし、MSP 定義をダウンロードします。

MSP 定義をエクスポートする画面のスクリーン・キャプチャー

ブラウザーに、以下のような内容の JSON ファイルがダウンロードされます。

    json
    {
      "display_name": "Org1 MSP",
    "msp_id": "org1msp",
    "type": "msp",
    "admins": [
        "LS0tLS1CR...LS0tLQo="
    ],
    "root_certs": [
        "LS0tL...LS0K"
    ],
    "tls_root_certs": [
        " LS0tLS1CR...LS0tLQo= "
    ],
    "fabric_node_ous": {
        "admin_ou_identifier": {
            "certificate": " LS0tL...LS0K ",
            "organizational_unit_identifier": "admin"
        },
        "client_ou_identifier": {
            "certificate": " LS0tL...LS0K ",
            "organizational_unit_identifier": "client"
        },
        "enable": true,
        "orderer_ou_identifier": {
            "certificate": " LS0tL...LS0K ",
            "organizational_unit_identifier": "orderer"
        },
        "peer_ou_identifier": {
            "certificate": " LS0tL...LS0K ",
            "organizational_unit_identifier": "peer"
        }
    },
    "host_url": "https://sw0317-ibpconsole-console.ibp20openshifttestcluster-a1-0001.us-south.containers.appdomain.cloud:443"
}

組織の MSP JSON ファイルを、アウト・オブ・バンド操作で Hyperledger Fabric ネットワークの管理者に送信します。このファイルは、順序付けサービスの 1 名以上の管理者と、参加する各チャネルの 1 名以上のピア組織管理者に送信する必要があります。

ピアをチャネルに参加させるには、組織管理者の ID を使用する必要もあります。組織の MSP 定義をダウンロードしたら、「Wallet (ウォレット)」タブにナビゲートして、組織管理者 ID をエクスポートします。

組織管理者 ID をエクスポートする画面のスクリーン・キャプチャー

コンソールから、次のような内容の JSON ID ファイルがエクスポートされます。

    json
    {
      "name": "Org1 MSP Admin",
    "type": "identity",
    "private_key": "LS0tLS1CR...LS0tLQ0K",
    "cert": "LS0d1CR...LS0tLQo="
}

IBM Blockchain コンソールからエクスポートされる管理者 ID には、証明書と秘密鍵が含まれています。秘密鍵は、ピアを操作するために必要です。このファイルに含まれる秘密鍵を使用すればネットワークを操作できるため、ファイルを安全な場所に保管してください。

Hyperledger Fabric のツールをセットアップする

プロセスを開始する前に、このプロセスに関与するすべての組織が Hyperledger Fabric のツールをダウンロードする必要があります。このチュートリアルでは、Hyperledger Fabric CLI のバイナリーをインストールして、任意のマシンからネットワークを操作できるようにする方法を説明します。別の方法として、組織は独自のクラスター上に Hyperledger Fabric のツール・コンテナーをデプロイして、そのコンテナー内からこのチュートリアルの手順に従うこともできます。

ローカル・マシン上にまだ Hyperledger Fabric CLI のバイナリーが準備されていない場合は、以下の手順に従って CLI バイナリーをダウンロードして、その場所を CLI パスに追加できます。単純にするために、チュートリアルでは以降、このセクションで作成するセットアップを使用します。

Hyperledger Fabric バイナリーを格納するディレクトリーを新しく作成します。このディレクトリーには、MSP 素材と、このチュートリアルを完了するために使用するアーティファクトのすべても格納します。以下のコマンドを使用して、新しいディレクトリーを作成し、カレント・ディレクトリーをそのディレクトリーに変更します。

mkdir interop
cd interop

Hyperledger Fabric のドキュメントに、バイナリーをダウンロードするためのコマンドが記載されています。作業を楽にするために、このチュートリアルで使用するコマンドを以下に記載します。コマンドを実行する前に、cURL をインストールする必要があります。その上で、interop ディレクトリーから、このコマンドを実行します。

curl -sSL https://bit.ly/2ysbOFE | bash -s -- 1.4.6 -d -s

上記の cURL コマンドは、interop ディレクトリー内に作成された bin フォルダー内にバイナリーをインストールします。このコマンドは、peer CLI を使用する際に必要となる構成ファイルが格納された config ディレクトリーもダウンロードします。

以下の 2 つの環境変数を設定し、bin フォルダー内のバイナリーの場所をパスに追加して、FABRIC_CFG_PATH の値を構成ファイルに設定します。

export PATH=${PWD}/bin:${PWD}:$PATH
export FABRIC_CFG_PATH=${PWD}/config/

以下の peer バージョンのコマンドを実行すると、バイナリーがダウンロードされて正常にパスに追加されたことを確認できます。このコマンドにより、Hyperledger Fabric ネットワークと同じバージョンを使用していることも確認できます。

Usage:
  peer [command]

Available Commands:
  chaincode   Operate a chaincode: install|instantiate|invoke|package|query|signpackage|upgrade|list.
  channel     Operate a channel: create|fetch|join|list|update|signconfigtx|getinfo.
  help        Help about any command
  logging     Logging configuration: getlevel|setlevel|getlogspec|setlogspec|revertlevels.
  node        Operate a peer node: start|status|reset|rollback.
  version     Print fabric peer version.

Flags:
  -h, --help   help for peer

Use "peer [command] --help" for more information about a command.

新しい組織をシステム・チャネルに追加する

IBM Blockchain Platform のピア組織をネットワークに追加する際は、順序付けサービス・システム・チャネルでホストされているピア組織のコンソーシアムに新しい組織を追加することもできます。このようにしなくてもアプリケーション・チャネルに参加することはできますが、コンソーシアムに参加すると、新しいチャネルが作成されたときに、ピア組織がそのチャネルのメンバーになれます。また、コンソーシアムに参加した新しい組織は、Hyperledger Fabric のツールを使用してネットワーク上に新しいチャネルを作成できるようにもなります。

このセクションの手順を順序付けサービスの管理者として行うことで、順序付けサービス・システム・チャネルを更新できます。前のセクションでは Hyperledger Fabric のツールをセットアップする手順に従い、カレント・ディレクトリーを interop ディレクトリーに変更しました。システム・チャネルを更新するには、順序付けサービス組織の MSP フォルダーと順序付けサービス・ノードの TLS 証明書を使用する必要があります。interop ディレクトリー内で以下のコマンドを実行して、MSP フォルダーおよび TLS 証明書用のディレクトリーを作成します。

mkdir -p organizations/ordererOrganizations/ordererOrg/admin/
mkdir -p organizations/ordererOrganizations/ordererOrg/orderer/tls

admin ディレクトリー内に、順序付けサービス組織管理者 ID の MSP フォルダーをコピーします。orderer/tls フォルダー内には、順序付けサービス・ノードの TLS 証明書を移動します。これで、順序付けサービス・システム・チャネルを更新するために必要な暗号素材が揃います。

新しいピア組織用の MSP フォルダーを作成する

システム・チャネルに追加するピア組織用に MSP フォルダーを作成する必要があります。IBM Blockchain Platform 用の MSP 定義を使用して、Hyperledger Fabric で使用する MSP フォルダーを作成できます。新しい組織の管理者から、IBM Blockchain Platform コンソールを使ってエクスポートした MSP JSON ファイルを受け取っていることを確認してください。その上で、同じく interop フォルダーから以下のコマンドを実行して、MSP フォルダーを作成するためのディレクトリーを作成し、カレント・ディレクトリーをそのディレクトリーに変更します。

mkdir -p organizations/peerOrganizations/ibporg
cd organizations/peerOrganizations/ibporg

新しく作成されたディレクトリー内に IBM Blockchain Platform 用の MSP 定義をコピーし、ファイル名を msp.json に変更して簡単に特定できるようにします。ibporg ディレクトリーから以下のコマンドを実行して、MSP フォルダー構造を作成します。

mkdir -p msp/admincerts
mkdir -p msp/cacerts
mkdir -p msp/tlscacerts

これで、作成された MSP フォルダー構造に、msp.json ファイルに含まれる証明書をコピーできるようになりました。ibporg ディレクトリーから以下のコマンドを実行して、証明書のコピー、証明書のデコードを行って、MSP フォルダー内に配置します。

export root_cert=$(cat msp.json | jq --raw-output '.root_certs[]')
export tls_root_cert=$(cat msp.json | jq --raw-output '.tls_root_certs[]')
export admin_certs=$(cat msp.json | jq --raw-output '.admins[]')
export FLAG=$(if [ "$(uname -s)" == "Linux" ]; then echo "-w 0"; else echo "-b 0"; fi)
echo $root_cert | base64 --decode $FLAG > msp/cacerts/cacert.pem
echo $tls_root_cert | base64 --decode $FLAG > msp/tlscacerts/tlscacert.pem
echo $admin_certs  | base64 --decode $FLAG > msp/admincerts/cert.pem

ネットワークで管理者 ID のノード OU を有効にしている場合、以下の yaml ファイルを msp ディレクトリー内にコピーして、コピーしたファイルに config.yaml という名前を付けます。

NodeOUs:
Enable: true
ClientOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: client
PeerOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: peer
AdminOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: admin
OrdererOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: orderer

MSP フォルダーの作成が完了したら、tree コマンドを使用して MSP フォルダーが正しく作成されていることを確認できます。

tree msp/
msp/
├── admincerts
│   └── cert.pem
├── cacerts
│   └── cacert.pem
├── config.yaml
└── tlscacerts
    └── tlscacert.pem

次は、チャネル MSP を作成して、チャネル構成に組織を追加する際に使用できるようにします。interop ディレクトリーに戻り、以下のファイルを configtx.yaml として保存します。

yaml
Organizations:

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

        # ID to load the MSP definition as
        ID: <IBP_MSP_ID>

        MSPDir: organizations/peerOrganizations/ibporg/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('<IBP_MSP_ID>.admin', '<IBP_MSP_ID>.peer', '<IBP_MSP_ID>.client')"
            Writers:
                Type: Signature
                Rule: "OR('<IBP_MSP_ID>.admin', '<IBP_MSP_ID>.client')"
            Admins:
                Type: Signature
                Rule: "OR('<IBP_MSP_ID>.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('<IBP_MSP_ID>.peer')"

<IBP_MSP_ID> の部分は、IBM Blockchain Platform 上のピア組織の MSP ID で置き換えます。MSP ID を調べるには、コンソールからエクスポートした MSP JSON ファイル内で msp_id フィールドを確認してください。

これで、編集後の configtx.yamlconfigtxgen ツールを使用してチャネル MSP を作成できます。<IBP_MSP_ID> をピア組織の MSP ID で置き換えた上で、以下のコマンドを interop ディレクトリーから実行します。

export FABRIC_CFG_PATH=${PWD}
configtxgen -printOrg <IBP_MSP_ID> > ibporg.json

システム・チャネル構成をフェッチする

次は、peer CLI を使用して、最新のシステム・チャネル構成ブロックをフェッチし、新しい組織をチャネルに追加します。peer CLI を操作するために、以下の環境変数を設定します。<OrdererMSP> の部分は組織の MSP ID で置き換え、<orderer_address> の部分は順序付けサービス・ノードのアドレスで置き換えてください。

export FABRIC_CFG_PATH=${PWD}/config/
export CORE_PEER_LOCALMSPID="<OrdererMSP>"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/ordererOrganizations/ordererOrg/orderer/tls/cert.pem
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/ordererOrganizations/ordererOrg/admin/msp
export CORE_PEER_ADDRESS=<orderer_address>

これで、peer channel fetch コマンドを使用してシステム・チャネル構成を取得できます。<system-channel-name> の部分はシステム・チャネルの名前で置き換えてください。

peer channel fetch config config_block.pb -o $CORE_PEER_ADDRESS -c <system-channel-name> --tls --cafile $CORE_PEER_TLS_ROOTCERT_FILE

コマンドが正常に実行されると、チャネル構成ブロックを受信したことを通知するメッセージが表示されます。

2017-11-07 17:17:57.383 UTC [channelCmd] readBlock -> DEBU 011 Received block: 4

ローカル・ファイル・システム上では、チャネル構成ブロックに config_block.pb という名前が付けられます。

システム・チャネル構成を更新する

これで、新しい組織をシステム・チャネル・コンソーシアムに追加するために、configtxlator Hyperledger Fabric CLI ツールと jq ツールを使用してチャネル構成を更新できます。このチュートリアルでは、「Updating a channel configuration」チュートリアルで詳しく説明されているチャネル構成の更新プロセスに従いますが、jq を使用してシステム・チャネルでホストされているコンソーシアムの組織リストにチャネル MSP を追加するコマンドは、このチュートリアルに固有のものです。

最初のステップは、チャネル構成ブロックをデコードして、Hyperledger Fabric で使用されている protobuf 形式から、人間が理解して編集できる JSON 形式に変換することです。また、更新には関連しない不要なメタデータをチャネル構成から削除します。

configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
jq .data.data[0].payload.data.config config_block.json > config.json

上記のコマンドによって、不要なものが削除された JSON オブジェクト (config.json) が返されます。このオブジェクトが、構成更新のベースラインとしての役割を果たします。このファイルをコピーし、そのコピーを使ってチャネルを更新しましょう。オリジナルのチャネル構成は、後のステップで使用します。

cp config.json config_copy.json

jq ツールを使用して、IBM Blockchain Platform 上のピア組織のチャネル MSP をコンソーシアムに追加します。

jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"<consortium-name>":{"groups": {"<IBP_MSP_ID>":.[1]}}}}}}}' config_copy.json ./ibporg.json > modified_config.json

<IBP_MSP_ID> の部分は、ピア組織の MSP ID で置き換えます。"<consortium-name>" の部分は、コンソーシアムの名前で置き換えます。コンソーシアムの名前を調べるには、以下のコマンドを使用します。

cat config.json | jq '.channel_group.groups.Consortiums.groups | keys'

このコマンドにより、コンソーシアムの名前が出力されます。

[
  "SampleConsortium"
]

このステップが完了すると、modified_config.json ファイル内に、更新されたチャネル構成が JSON 形式で格納された状態になります。オリジナルと更新後の両方のチャネル構成を protobuf 形式に戻せば、その差分を計算できます。<system-channel-name> の部分をシステム・チャネルの名前に置き換えた上で、以下のコマンドを実行してください。

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 <system-channel-name> --original config.pb --updated modified_config.pb --output system_channel_update.pb

新しい system_channel_update.pb という名前の protobuf 形式のファイルには、システム・チャネルの更新が protobuf 形式で含まれています。この更新をチャネル構成に適用する必要があります。前に削除したメタデータを追加して、新しいチャネル構成ブロックを作成します。ここでも <system-channel-name> の部分はシステム・チャネルの名前で置き換えてください。

configtxlator proto_decode --input system_channel_update.pb --type common.ConfigUpdate --output system_channel_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"'<system-channel-name>'", "type":2}},"data":{"config_update":'$(cat system_channel_update.json)'}}}' | jq . > system_channel_update_in_envelope.json
configtxlator proto_encode --input system_channel_update_in_envelope.json --type common.Envelope --output system_channel_update_in_envelope.pb

必要なアーティファクトの残り 1 つは、システム・チャネルを更新するために使用する system_channel_update_in_envelope.pb です。

システム・チャネル更新を署名付きで送信する

システム・チャネルを更新するには、新しく作成したチャネル構成ブロックに署名を付けて、それを順序付けサービスに送信する必要があります。Hyperledger Fabric に用意されているデフォルト・ポリシーを使用した場合、チャネル更新には順序付けサービス管理者の過半数による署名が必要です。以下の peer CLI は、必ず順序付けサービス管理者として操作してください。

env | grep CORE

上記のコマンドにより、ネットワークに接続する際に使用される環境変数が出力されます。

CORE_PEER_TLS_ROOTCERT_FILE=/usr/interop/organizations/ordererOrganizations/ordererOrg/orderer/tls/cert.pem
CORE_PEER_LOCALMSPID=OrdererMSP
CORE_PEER_MSPCONFIGPATH=/usr/interop/organizations/ordererOrganizations/ordererOrg/admin/msp
CORE_PEER_ADDRESS=169.55.231.137:30732

チャネル更新に署名するには、以下の peer CLI を使用することができます。

export FABRIC_CFG_PATH=${PWD}/config/
peer channel signconfigtx -f system_channel_update_in_envelope.pb

チャネル更新に複数の組織による署名が必要な場合は、署名付き system_channel_update_in_envelope.pb オブジェクトをアウト・オブ・バンドで他の管理者に渡します。アウト・オブ・バンドとは、Fabric を使用せずに手作業で (例えば e-メールを使用して) 他の組織にオブジェクトを送信する必要があることを意味します。更新に署名する必要がある最後の組織も、peer channel update を使用して新しいチャネル構成を送信できます。

peer channel update -f system_channel_update_in_envelope.pb -c <system-channel-name> -o <orderer_address> --tls --cafile <orderer_tls_certificate>

<orderer_address><orderer_tls_certificate> の部分はそれぞれ、順序付けサービス・ノードのエンドポイントと TLS 証明書で置き換えます。<system-channel-name> の部分は、システム・チャネルの名前で置き換えます。チャネルが正常に更新されると、ログに以下のようなメッセージが記録されます。

2020-01-09 21:30:45.791 UTC [channelCmd] update -> INFO 002 Successfully submitted channel update

新しい組織をアプリケーション・チャネルに追加する

Hyperledger Fabric ネットワーク上のピア組織は、既存のアプリケーション・チャネルに IBM Blockchain Platform 上のピア組織を追加できます。チャネルのメンバーになった新しい組織は、IBM Blockchain Platform 上のピアからチャネルのレジャーにアクセスし、新しいトランザクションを検証できます。前のセクションの手順を完了している場合、ピア組織をアプリケーション・チャネルに追加する手順は、そのときに行った組織をシステム・チャネルに追加するために必要な手順と同様です。このセクションの手順は、組織が参加するチャネルごとに繰り返してください。

新しいメンバーをチャネルに追加するには、そのチャネルの管理者であるピア組織がチャネルを更新する必要があります。Hyperledger Fabric のツールをセットアップする手順に従って、カレント・ディレクトリーを interop ディレクトリーに変更してください。システム・チャネルを更新するには、組織管理者の MSP フォルダー、ピア・ノードの TLS 証明書、順序付けサービス・ノードの TLS 証明書を使用する必要があります。interop ディレクトリー内で以下のコマンドを実行して、MSP フォルダーおよび TLS 証明書用のディレクトリーを作成します。

mkdir -p organizations/peerOrganizations/fabricPeerOrg/admin/
mkdir -p organizations/peerOrganizations/fabricPeerOrg/peer/tls
mkdir -p organizations/ordererOrganizations/ordererOrg/orderer/tls

admin ディレクトリー内に、組織管理者 ID の MSP フォルダーを移動します。peer/tls フォルダー内に、ピア・ノードの TLS 証明書を移動します。orderer/tls フォルダー内に、順序付けサービス・ノードの TLS 証明書を移動します。これで、チャネルを更新するために必要な暗号素材が揃います。

新しいチャネル・メンバー用の MSP フォルダーを作成する

チャネルに追加するピア組織用に MSP フォルダーを作成する必要があります。順序付けサービスの管理者が組織をシステム・チャネルに追加する手順をすでに完了した場合、以下の手順もすでに完了しているはずです。その場合は、作成済みの ibporg.json という名前のチャネル MSP を使用して、チャネル構成をフェッチする手順に進むことができます。また、ibporg.json にチャネル MSP を含めてアウト・オブ・バンドで送信してもらうよう、順序付けサービス管理者に依頼することもできます。

IBM Blockchain Platform 用の MSP 定義を使用して、Hyperledger Fabric で使用する MSP フォルダーを作成できます。新しい組織の管理者から、IBM Blockchain Platform コンソールを使ってエクスポートした MSP JSON ファイルを受け取っていることを確認してください。その上で、MSP フォルダーの作成に使用できるディレクトリーを作成し、カレント・ディレクトリーをそのディレクトリーに変更します。

mkdir -p organizations/peerOrganizations/ibporg
cd organizations/peerOrganizations/ibporg

新しく作成されたディレクトリー内に IBM Blockchain Platform 用の MSP 定義をコピーし、ファイル名を msp.json に変更して簡単に特定できるようにします。ibporg ディレクトリーから以下のコマンドを実行して、MSP フォルダー構造を作成します。

mkdir -p msp/admincerts
mkdir -p msp/cacerts
mkdir -p msp/tlscacerts

これで、作成された MSP フォルダー構造に、msp.json ファイルに含まれる証明書をコピーできるようになりました。ibporg ディレクトリーから以下のコマンドを実行して、証明書のコピー、証明書のデコードを行って、MSP フォルダー内に配置します。

export root_cert=$(cat msp.json | jq --raw-output '.root_certs[]')
export tls_root_cert=$(cat msp.json | jq --raw-output '.tls_root_certs[]')
export admin_certs=$(cat msp.json | jq --raw-output '.admins[]')
export FLAG=$(if [ "$(uname -s)" == "Linux" ]; then echo "-w 0"; else echo "-b 0"; fi)
echo $root_cert | base64 --decode $FLAG > msp/cacerts/cacert.pem
echo $tls_root_cert | base64 --decode $FLAG > msp/tlscacerts/tlscacert.pem
echo $admin_certs  | base64 --decode $FLAG > msp/admincerts/cert.pem

ネットワークで管理者 ID のノード OU を有効にしている場合、以下の yaml ファイルを msp ディレクトリー内にコピーして、コピーしたファイルに config.yaml という名前を付けます。

yaml
echo 'NodeOUs:
Enable: true
ClientOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: client
PeerOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: peer
AdminOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: admin
OrdererOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: orderer'

MSP フォルダーの作成が完了したら、tree コマンドを使用して MSP フォルダーが正しく作成されていることを確認できます。

tree msp/
msp/
├── admincerts
│   └── cert.pem
├── cacerts
│   └── cacert.pem
├── config.yaml
└── tlscacerts
    └── tlscacert.pem

次は、チャネル MSP を作成して、チャネル構成に組織を追加する際に使用できるようにします。interop ディレクトリーに戻り、以下のファイルを configtx.yaml として保存します。

yaml
Organizations:

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

        # ID to load the MSP definition as
        ID: <IBP_MSP_ID>

        MSPDir: organizations/peerOrganizations/ibporg/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('<IBP_MSP_ID>.admin', '<IBP_MSP_ID>.peer', '<IBP_MSP_ID>.client')"
            Writers:
                Type: Signature
                Rule: "OR('<IBP_MSP_ID>.admin', '<IBP_MSP_ID>.client')"
            Admins:
                Type: Signature
                Rule: "OR('<IBP_MSP_ID>.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('<IBP_MSP_ID>.peer')"

<IBP_MSP_ID> の部分は、IBM Blockchain Platform 上のピア組織の MSP ID で置き換えます。MSP ID を調べるには、コンソールからエクスポートした MSP JSON ファイル内で msp_id フィールドを確認してください。

これで、編集後の configtx.yamlconfigtxgen ツールを使用してチャネル MSP を作成できます。<IBP_MSP_ID> をピア組織の MSP ID で置き換えた上で、以下のコマンドを interop ディレクトリーから実行します。

export FABRIC_CFG_PATH=${PWD}
configtxgen -printOrg <IBP_MSP_ID> > ibporg.json

チャネル構成をフェッチする

次は、peer CLI を使用して、最新のチャネル構成ブロックをフェッチし、新しい組織をチャネルに追加します。peer CLI を操作するために、組織管理者として以下の環境変数を設定します。<peerOrgMSP> の部分は組織の MSP ID で置き換え、<peer_address> の部分はピアのアドレスで置き換えてください。ここでは、TLS 証明書の名前が cert.pem であると想定しています。

export FABRIC_CFG_PATH=${PWD}/config/
export CORE_PEER_LOCALMSPID="<peerOrgMSP>"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/fabricPeerOrg/peer/tls/cert.pem
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/fabricPeerOrg/admin/msp
export CORE_PEER_ADDRESS=<peer_address>

これで、peer channel fetch コマンドを使用してチャネル構成を取得できます。<channel_name> の部分は、アプリケーション・チャネルの名前で置き換えます。

peer channel fetch config config_block.pb -o <orderer_address> -c <channel_name> --tls --cafile ${PWD}/organizations/ordererOrganizations/ordererOrg/orderer/tls/cert.pem

コマンドが正常に実行されると、チャネル構成ブロックを受信したことを通知するメッセージが表示されます。

2017-11-07 17:17:57.383 UTC [channelCmd] readBlock -> DEBU 011 Received block: 6

ローカル・ファイル・システム上では、チャネル構成ブロックに config_block.pb という名前が付けられます。

チャネル構成を更新する

新しい組織をチャネルのメンバーにするために、configtxlator Hyperledger Fabric CLI ツールと jq ツールを使用してチャネル構成を更新します。このチュートリアルでは、「Updating a channel configuration」チュートリアルで詳しく説明されているチャネル構成の更新プロセスに従いますが、jq を使用してチャネル・メンバーのリストにチャネル MSP を追加するコマンドは、このチュートリアルに固有のものです。

最初のステップは、チャネル構成ブロックをデコードして、Hyperledger Fabric で使用されている protobuf 形式から、人間が理解して編集できる JSON 形式に変換することです。また、ここで行っている更新には関連しない不要なメタデータをチャネル構成から削除します。

configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
jq .data.data[0].payload.data.config config_block.json > config.json

上記のコマンドによって、不要なものが削除された JSON オブジェクト (config.json) が返されます。このオブジェクトが、構成更新のベースラインとしての役割を果たします。このファイルをコピーし、そのコピーを使ってチャネルを更新しましょう。オリジナルのチャネル構成は、後のステップで使用します。

cp config.json config_copy.json

jq ツールを使用して、IBM Blockchain Platform 上のピア組織のチャネル MSP をコンソーシアムに追加します。<IBP_MSP_ID> の部分は、IBM Blockchain Platform 上のピア組織の MSP ID で置き換えます。

jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"<IBP_MSP_ID>":.[1]}}}}}' config_copy.json ./ibporg.json > modified_config.json

ここでは、Hyperledger Fabric に用意されているデフォルト・ポリシーをチャネルで使用していると想定しています。デフォルト・ポリシーを使用する場合、新しい組織は自動的にチャネル上の管理者兼書き込み組織として追加されます。チャネル用のカスタム・ポリシーを作成した場合は、新しい組織を追加するようにポリシーを更新しなければならない可能性があります。チャネルのジェネシス・ブロックをフェッチしてピアをチャネルに参加させるためには、新しいピア組織をチャネル上の書き込み組織にする必要があります。詳細については、Hyperledger Fabric ドキュメントの「Policies」を参照してください。

このステップが完了すると、modified_config.json ファイル内に、更新されたチャネル構成が JSON 形式で格納された状態になります。オリジナルと更新後の両方のチャネル構成を protobuf 形式に戻せば、その差分を計算できます。<channel_name> の部分をアプリケーション・チャネルの名前に置き換えた上で、以下のコマンドを実行してください。

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 <channel_name> --original config.pb --updated modified_config.pb --output config_update.pb

新しい channel_update.pb という名前の protobuf 形式のファイルには、チャネルの更新が protobuf 形式で含まれています。この更新をチャネル構成に適用する必要があります。前に削除したメタデータを追加して、新しいチャネル構成ブロックを作成します。ここでも <channel_name> の部分はチャネルの名前に置き換えてください。

configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"<channel_name>", "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

必要なアーティファクトの残り 1 つは、チャネルを更新するために使用する config_update_in_envelope.pb です。

チャネル更新を署名付きで送信する

チャネルを更新するには、新しく作成したチャネル構成ブロックに署名を付けて、それを順序付けサービスに送信する必要があります。Hyperledger Fabric に用意されているデフォルト・ポリシーを使用した場合、チャネル更新にはチャネル・メンバーの過半数による署名が必要です。以下の peer CLI は、必ずピア組織の管理者として操作してください。

env | grep CORE

上記のコマンドにより、ネットワークに接続する際に使用される主な環境変数が出力されます。

CORE_PEER_TLS_ROOTCERT_FILE=/usr/interop/organizations/peerOrganizations/fabricPeerOrg/peer/tls/cert.pem
CORE_PEER_LOCALMSPID=FabricPeerMSP
CORE_PEER_MSPCONFIGPATH=/usr/interop/organizations/peerOrganizations/fabricPeerOrg/admin/msp
CORE_PEER_ADDRESS=169.55.231.137:30420

チャネル更新に署名するには、以下の peer CLI を使用することができます。

export FABRIC_CFG_PATH=${PWD}/config/
peer channel signconfigtx -f config_update_in_envelope.pb

チャネル更新に複数の組織による署名が必要な場合は、署名付き config_update_in_envelope.pb オブジェクトをアウト・オブ・バンドで他の管理者に渡します。更新に署名する必要がある最後の組織も、peer channel update を使用して新しいチャネル構成を送信できます。

peer channel update -f config_update_in_envelope.pb -c <channel_name> -o <orderer_address> --tls --cafile ${PWD}/organizations/ordererOrganizations/ordererOrg/orderer/tls/cert.pem

<orderer_address><orderer_tls_certificate> の部分はそれぞれ、順序付けサービス・ノードのエンドポイントと TLS 証明書で置き換えます。<channel_name> の部分は、システム・チャネルの名前で置き換えます。チャネルが正常に更新されると、ログに以下のようなメッセージが記録されます。

2020-03-31 21:33:32.267 EDT [channelCmd] InitCmdFactory -> INFO 004 Endorser and orderer connections initialized
2020-03-31 21:33:32.615 EDT [channelCmd] update -> INFO 005 Successfully submitted channel update

ピアをチャネルに参加させる

組織がアプリケーション・チャネルに追加された後は、Fabric のツールを使用して IBM Blockchain Platform 上のピアをチャネルに参加させることができます。IBM Blockchain コンソールを使用してピアを管理することもできますが、Hyperledger Fabric の順序付けサービスには、コンソールと通信するために必要となる gRPC Web プロキシーが含まれていません。したがって、ピアをチャネルに参加させるには Fabric peer CLI を使用する必要があります。

組織管理者用の MSP フォルダーを作成する

peer CLI を操作するには、組織管理者 ID を使用する必要があります。そのためには、IBM Blockchain コンソールで使用している JSON 形式の管理者 ID を、Hyperledger Fabric で使用する MSP フォルダー構造に変換しなければなりません。Hyperledger Fabric のツールをセットアップする手順に従って、カレント・ディレクトリーを interop ディレクトリーに変更してください。以下のコマンドを実行して、MSP フォルダーを作成するために使用するフォルダーを作成し、カレント・ディレクトリーをそのディレクトリーに変更します。

mkdir -p organizations/peerOrganizations/ibporg/admin
cd organizations/peerOrganizations/ibporg/admin

admin フォルダー内に、コンソールからエクスポートした MSP 定義と管理者 ID をコピーします。ファイルの名前をそれぞれ msp.jsonadmin.json に変更して特定しやすくします。管理者 ID に証明書と秘密鍵が含まれていますが、peer CLI を操作するためには MSP ファイルに含まれている証明書が必要です。admin ディレクトリーから以下のコマンドを実行して、MSP フォルダーを作成します。

mkdir -p msp/admincerts
mkdir -p msp/cacerts
mkdir -p msp/tlscacerts
mkdir -p msp/keystore
mkdir -p msp/signcerts

作成された MSP フォルダー構造に、msp.json および admin.json ファイルに含まれている証明書と鍵をコピーします。admin ディレクトリーから以下のコマンドを実行して、証明書のコピー、証明書のデコードを行って、MSP フォルダー内に配置します。

export root_cert=$(cat msp.json | jq --raw-output '.root_certs[]')
export tls_root_cert=$(cat msp.json | jq --raw-output '.tls_root_certs[]')
export admin_certs=$(cat msp.json | jq --raw-output '.admins[]')
export privateKey=$(cat admin.json | jq --raw-output '.private_key')
export cert=$(cat admin.json | jq --raw-output '.cert')
export FLAG=$(if [ "$(uname -s)" == "Linux" ]; then echo "-w 0"; else echo "-b 0"; fi)
echo $root_cert | base64 --decode $FLAG > msp/cacerts/cacert.pem
echo $tls_root_cert | base64 --decode $FLAG > msp/tlscacerts/cert.pem
echo $admin_certs  | base64 --decode $FLAG > msp/admincerts/cert.pem
echo $privateKey | base64 --decode $FLAG > msp/keystore/key.pem
echo $cert | base64 --decode $FLAG > msp/signcerts/cert.pem

ネットワークで管理者 ID のノード OU を有効にしている場合、以下の yaml ファイルを msp ディレクトリー内にコピーして、コピーしたファイルに config.yaml という名前を付けます。

echo 'NodeOUs:
Enable: true
ClientOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: client
PeerOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: peer
AdminOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: admin
OrdererOUIdentifier:
    Certificate: cacerts/cacert.pem
    OrganizationalUnitIdentifier: orderer'

MSP フォルダーの作成が完了したら、tree コマンドを使用して MSP フォルダーが正しく作成されていることを確認できます。

$ tree msp/
msp/
├── admincerts
│   └── cert.pem
├── cacerts
│   └── cacert.pem
├── config.yaml
├── keystore
│   └── key.pem
├── signcerts
│   └── cert.pem
└── tlscacerts
    └── cert.pem

これで、peer CLI を操作するために使用できる管理者 MSP を入手できました。interop フォルダーに戻って、以下の環境変数を設定します。

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="<IBP_MSP_ID>"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/ibporg/admin/msp/tlscacerts/cert.pem
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/ibporg/admin/msp
export CORE_PEER_ADDRESS=<peer_address>
  1. <IBP_MSP_ID> の部分は、組織の MSP ID で置き換えます。
  2. <peer_address> の部分は、チャネルに参加させるピアの URL で置き換えます。ピアのエンドポイントを調べるには、IBM Blockchain コンソールにログインしてください。「Nodes (ノード)」タブを表示して、ピアの情報をエクスポートします。peer CLI でターゲットにする必要があるピアの URL とポートは、api_url フィールド内に示されています。URL の先頭にある grpcs:// は省いてください。
  3. TLS ハンドシェークを行うにはルート証明書を使用する必要があるため、ピアとの通信には組織の MSP のルート TLS 証明書を使用します。ピア情報の tls_cert フィールドに格納されている TLS 証明書を使用することもできます。

チャネルに参加するには、Hyperledger Fabric 順序付けサービスからチャネルのジェネシス・ブロックをフェッチして、そのジェネシス・ブロックをピアに渡す必要があります。ジェネシス・ブロックを受け取ったピアは、Hyperledger Fabric の順序付けサービスから、チャネル内の他のブロックを取得します。

チャネルのジェネシス・ブロックを取得するには、peer channel fetch コマンドを使用できます。<channel_name> の部分はアプリケーション・チャネルの名前で置き換え、<orderer_address> の部分は Hyperledger Fabric 順序付けサービス・ノードのアドレスで置き換えます。--cafile で、順序付けサービス・ノードの TLS 証明書を指してください。

peer channel fetch 0 genesis.block -c <channel_name> -o <orderer_address> --tls --cafile ${PWD}/organizations/ordererOrganizations/ordererOrg/orderer/tls/cert.pem

コマンドが正常に実行されると、ジェネシス・ブロックが genesis.block という名前のファイルとして返されます。このブロックを peer channel join コマンドに渡すと、ピアをチャネルに参加させることができます。

peer channel join -b genesis.block

複数のピアをチャネルに参加させるには、ピアごとに CORE_PEER_ADDRESSCORE_PEER_TLS_ROOTCERT_FILE の 1 組を設定してコマンドを実行する必要があります。ピアがチャネルに参加すると、コンソール内でそのチャネルを表示できるようになります。

正常に参加したチャネルを示す画面のスクリーン・キャプチャー

アンカー・ピアを設定する

ピアをチャネルに参加させた後、アンカー・ピアにするピアを 1 つ選択する必要があります。アンカー・ピアは、ゴシップ・プロトコルを使用して、チャネル上の他のピアとの通信を先導します。アンカー・ピアを使用すると、サービス・ディスカバリーやプライベート・データなどといった Hyperledger Fabric の重要な機能を活用できます。

アンカー・ピアを選択するには、チャネル構成を更新する必要があります。ここでは、「Updating a channel configuration」チュートリアルで説明されている手順に従って組織のアンカー・ピアを作成します。ただし、このプロセスは組織をチャネルに追加する際のプロセスと同様なので、このセクションでは概要を押さえるだけにとどめます。ピアをチャネルに参加させるときに設定した環境変数がまだそのまま設定されていることを前提とします。

peer channel fetch コマンドを使用して、最新のチャネル構成を取得する必要があります。<channel_name> の部分は、チャネルの名前で置き換えてください。

peer channel fetch config config_block.pb -o <orderer_address> -c <channel_name> --tls --cafile ${PWD}/organizations/ordererOrganizations/ordererOrg/orderer/tls/cert.pem

取得した構成ブロックをデコードしてコピーします。

configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
jq .data.data[0].payload.data.config config_block.json > config.json
cp config.json config_copy.json

jq を使用してアンカー・ピアをチャネル構成に追加できます。<peer_url><peer_port> の部分はそれぞれ、アンカー・ピアにするピアの URL とポートで置き換えます。<MSP_ID> の部分は、MSP ID の値で置き換えます。

jq '.channel_group.groups.Application.groups.<MSP_ID>.values += {"AnchorPeers":{"mod_policy": "Admins","value":{"anchor_peers": [{"host": "<peer_url>","port": <peer_port>}]},"version": "0"}}' config_copy.json > modified_config.json

チャネル構成を更新したので、オリジナルと更新後の両方のチャネル構成を protobuf 形式に戻して、その差分を計算できます。<channel_name> の部分をアプリケーション・チャネルの名前に置き換えた上で、以下のコマンドを実行してください。

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 <channel_name> --original config.pb --updated modified_config.pb --output config_update.pb

新しい channel_update.pb という名前の protobuf 形式のファイルには、アンカー・ピアの更新が含まれています。この更新をチャネル構成に適用する必要があります。最終的な構成ブロックを作成し、その構成ブロックを使用してチャネルを更新できます。

configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"<channel_name>", "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

更新をチャネルに送信すると、アンカー・ピアを設定できます。この更新は IBM Blockchain Platform 上の自組織にのみ適用されるため、チャネルの他のメンバーが更新に署名する必要はありません。--cafile で、順序付けサービス・ノードの TLS 証明書を指してください。

peer channel update -f config_update_in_envelope.pb -c <channel_name> -o <orderer_address> --tls --cafile ${PWD}/organizations/ordererOrganizations/ordererOrg/orderer/tls/cert.pem

次のステップ

アプリケーション・チャネルに参加した後は、Hyperledger Fabric ネットワークの他のメンバーとのトランザクションを開始できます。チャネル上でインスタンス化するチェーンコードをインストールするには、IBM Blockchain コンソールと peer CLI のどちらでも使用できます。ただし、コンソールを使用してチャネル上のチェーンコードをインスタンス化したりアップグレードしたりすることはできません。

クライアント・アプリケーションがトランザクションをチャネルに送信するために使用する接続プロファイルをダウンロードするには、コンソールを使用できます。ダウンロードした接続プロファイルにアクセスするには、「Smart contracts (スマート・コントラクト)」タブで、Hyperledger Fabric チャネル上でインスタンス化されたチェーンコードの横にあるオーバーフロー・メニューを使用します。Hyperledger Fabric チャネルのチェーンコードはコンソールの UI 内で表示できます。ただし、サービス・ディスカバリーが有効にされていない場合は、チャネルに参加している順序付けサービス・ノードとピア・ノードのノード・エンドポイント情報ならびに TLS 証明書を収集する必要があります。

まとめ

このチュートリアルでは、IBM Blockchain Platform 上のピアを Hyperledger Fabric ネットワーク上のアプリケーション・チャネルに接続するプロセスを説明しました。IBP コンソールでピアを作成し、作成したピアを、Hyperledger Fabric CLI インターフェースを使って既存の Hyperledger Fabric チャネルに参加させるという方法で、2 つのブロックチェーン・ネットワーク間の相互運用性を構成するために必要な手順を説明しました。