Amazon マネージドブロックチェーンのハイパーレジャーファブリックチャネルに新しいメンバーを追加する

このシリーズの前の記事では、Amazon Managed Blockchain を使用してハイパーレジャーファブリックネットワークを構築する方法を学びました。ネットワークを作成した後、ファブリックチェーンコード、RESTful API、およびユーザーインターフェイスアプリケーションからなる 3 層アプリケーションをデプロイしました。作成したネットワークはシングルメンバーネットワークであり、ハイパーレジャーファブリックの基礎を実験および学習するのに適しています。

ただし、より堅牢なテストまたは本番シナリオでは、マルチメンバー分散ネットワークが必要になる場合があります。ネットワークのメンバーは、一般的なビジネスプロセスに参加し、データを共有したり互いに協力したりすることで利益を得る実際の組織を表す場合があります。

この記事では、パート 1 で作成したファブリックネットワークに新しいメンバーを追加します。新しいメンバーを作成し、新しいメンバーのピアノードをプロビジョニングして、ピアを既存のチャネルに参加させます。新しいメンバーを別の AWS アカウント、またはパート 1 ネットワークと同じ AWS アカウントで作成できます。この記事では異なる AWS アカウントを使用していますが、どちらの方法でも機能します。新しいピアノードがチャネルに参加したら、ブロックが新しいピアに複製されているかどうかを確認してから、チェーンコードをインストールしてトランザクションを呼び出します。ピアノードは、ファブリックネットワーク内で完全に機能するノードになり、ファブリックレジャーの独自のコピーを維持しながらトランザクションを保証および検証することができます。

アーキテクチャの概要

この記事の手順に従うと、2 人のメンバーがいるマルチメンバーネットワークになり、各メンバーは異なる AWS アカウントが所有します。各アカウントが所有するメンバーにアクセスするには、そのアカウントの VPC で実行されているファブリックのクライアントノードまたはファブリックのクライアントアプリケーションを使用します。

次の図に示すように、ハイパーレジャーファブリックの順序サービス、メンバーの認証局 (CA)、およびメンバーのピアは、マネージドブロックチェーンが管理します。VPC エンドポイントを使用して、それらのエンドポイントを顧客の VPC に公開します。顧客の VPC とマネージドファブリックネットワーク間のすべてのネットワークトラフィックは AWS バックボーンを介して発生し、パブリックインターネットには公開されません。

前提条件: マネージドブロックチェーン上に既存のハイパーレジャーファブリックネットワークがあること

前のブログ投稿と同じ Git リポジトリで、既存のファブリックネットワークに新しいメンバーを追加する手順を見つけることができます。前回の記事はパート 5 で更新されました。パート 5 を開始する前に、少なくとも 1 人のメンバーでハイパーレジャーファブリックネットワークを実行しておく必要があります。これを行うには、前の投稿のパート 1 を完了してください。パート 1 から 4 を完了しても良いですが、パート 2 から 4 はパート 5 を完了する前提条件ではありません。

ハイパーレジャーファブリックチャネル

新しいメンバーをプロビジョニングする前に、ハイパーレジャーファブリックチャネルの目的を確認しましょう。チャネルは、ファブリックネットワーク内のメンバーが通信するためのメカニズムです。ネットワーク内の複数のメンバーがチャネルに参加します。これらのメンバーは、同じネットワーク内の他のメンバーとレジャーを共有することなく、チャネル上で個人的にトランザクションを行えます。したがって、チャネルでは、メンバーのさまざまな組み合わせでさまざまな種類の情報を共有できます。

前のブログ記事で述べたように、ハイパーレジャーファブリックのレジャーは、暗号的にイミュータブル (不変) なトランザクションログ (または「ブロックチェーン」) を保持するジャーナルと、レジャーの現在の状態を保持するワールドステートとして知られているキーバリューストアの 2 つの部分から構成されています。レジャーは、チェーンコードをチャネルにバインドすることによって作成され、チャネルに参加している各ピアノードに物理的に存在します。つまり、2 つのチャネルに参加するピアノードが 2 つの独立したレジャーをホストすることになります。

パート 5: マネージドブロックチェーンのファブリックネットワークに新しいメンバーを追加する

既存のファブリックネットワークに新しいメンバーを追加するとき、次の 2 つのシナリオが考えられます。

新しいメンバーが、既存のメンバーがすでにコラボレーションおよびトランザクションを行っている既存のチャネルに参加するシナリオ。既存のメンバーはすでにこのチャネルの独自のレジャーを維持しているシナリオ。
新しいメンバーは、既存のメンバーと協力して、コラボレーションやトランザクションを行う新しいチャネルを作成します。

この記事の残りの部分では、上記のシナリオ 1 に焦点を当てます。シナリオ 2 は Git リポジトリのパート 5 の readme ファイルで扱います。これは、マネージドブロックチェーンのドキュメントでも説明しています。シナリオ 1 は、既存のチャネル設定を更新して新しいメンバーを含める必要があるため、より複雑です。

既存のファブリックネットワークに新しいメンバーを追加するには、いくつかの手順があります。新しいメンバーは別の AWS アカウントにあります。そのため、手順には、ファブリックネットワークが最初に作成された既存のアカウントと、新しいメンバーが作成された新しいアカウントのファブリック管理者間の協力も必要です。既存のアカウントをアカウント A、新しいアカウントをアカウント B と呼びましょう。手順は次のとおりです。

アカウント A がファブリックネットワークに参加するようアカウント B を招待します。
アカウント B がファブリックネットワークにメンバーを作成します。
アカウント B がピアノードを作成します。
アカウント B がファブリックのクライアントノードを作成します。
アカウント B がファブリックのクライアントノードを準備し、ID を登録します。
アカウント B が、そのメンバーのパブリックキーをアカウント A と共有します。
アカウント A が、新しいアカウント B のメンバーのために MSP フォルダを作成します。
アカウント A が、新しいアカウント B のメンバーを含む configtx.yaml ファイルを作成します。
アカウント A がチャネル設定を生成します。
保証ピアが新しいチャネル設定に署名します。
アカウント A が新しい設定でチャネルを更新します。
アカウント A が、アカウント B とチャネルのジェネシスブロックを共有します。
アカウント B がピアノードを起動し、チャネルに参加します。
アカウント B がチェーンコードをインストールします。
アカウント B がチェーンコードをクエリします。
アカウント B がトランザクションを呼び出します。
アカウント A が、チャネル上のチェーンコードの保証ポリシーを更新します。
アカウント B が最新バージョンのチェーンコードをインストールします。

各ステップの目的を詳しく見ていき、詳細をつかみましょう。各ステップの実行方法に関する詳細は Git リポジトリにあります。ここにリストされている各ステップは、Git リポジトリにそれと合致するステップがあります。

ステップ 1: アカウント A がファブリックネットワークに参加するようアカウント B を招待する

マネージドブロックチェーンのプレビューでは、他の AWS アカウントの新しいメンバーをファブリックネットワークへ参加するよう招待する必要があります。他の AWS アカウントもマネージドブロックチェーンプレビューの一部である必要があります。アカウント A のファブリック管理者は、ファブリックネットワークに参加するよう別の AWS アカウントを招待します。マネージドブロックチェーンコンソールで、ファブリックネットワークを選択し、[アカウントの招待] ボタンをクリックします。招待するアカウントの 12 桁の AWS アカウント番号を入力します。招待状が正常に送信されたことを示す確認メッセージが表示されます。

ステップ 2: アカウント B がファブリックネットワークでメンバーを作成する

アカウント B にログインしたユーザーは、マネージドブロックチェーンコンソールで招待状を閲覧できます。ネットワーク名をクリックすると、アカウント B が参加の招待を受けたネットワークの詳細が表示されます。ネットワークにメンバーを作成するには [メンバーの作成] を選択し、メンバーの固有のメンバー名、管理者ユーザー名、およびパスワードを入力します。後で必要になるので、管理者のユーザー名とパスワードを書き留めておいてください。

この時点で、マネージドブロックチェーンは新しいメンバーに可用性の高いファブリック CA をプロビジョニングします。

ステップ 3: アカウント B がピアノードを作成する

ファブリックネットワークとメンバーのステータスがアクティブになったら、ファブリックピアノードを作成します。ネットワーク上の各メンバーは独自のピアノードを作成するために、上記で作成したメンバーを選択し、リンクをクリックして、ピアノードを作成します。インスタンスタイプ、ノードのストレージ容量を選択し、ピアノードを作成します。順序サービスおよび CA と同様に、各メンバーのピアノードはマネージドブロックチェーンが管理し、VPC エンドポイントを使用して VPC からアクセスできます。

この段階では、高可用性の順序サービスを備えたハイパーレジャーファブリックネットワークがあります。ネットワークには 2 人のメンバーがいて、それぞれが独自の CA を持ち、それぞれが単一のピアを含みます。

これで、チャネルの作成、チェーンコードのインストール、トランザクションの呼び出しを行えるように、ファブリックネットワークの新しいメンバーと対話する方法が必要になりました。これを行うには、VPC にファブリックのクライアントノードを作成します。

ステップ 4: アカウント B がファブリックのクライアントノードを作成します

これらの手順は、ファブリックネットワークが最初に作成されたときにアカウント A が実行した手順と同じです。前述のアーキテクチャ図に示すように、マネージドブロックチェーンが管理するファブリックコンポーネントには、アカウントの VPC でプロビジョニングしたファブリックのクライアントノードを介してアクセスします。ファブリックのクライアントノードはオープンソースのファブリック CLI をホストし、VPC エンドポイントを使用してファブリックネットワークと対話できるようにします。

3 つのアイテムをプロビジョニングするには AWS CloudFormation を使用します。3 つのアイテムは、アカウント B の新しい VPC、ファブリックのクライアントノードとして設定された EC2 インスタンス、およびファブリックネットワークと通信するための VPC エンドポイントです。

Git リポジトリで指定されているアカウント B の前提条件を完了していることを確認してください。次に、ステップ 4 に従って、ファブリックのクライアントノードをプロビジョニングします。

ステップ 5: アカウント B がファブリックのクライアントノードを準備し、ID を登録する

ステップ 2 でメンバーを作成したときに管理者 ID が自動的に作成されました。このステップで管理者ユーザーを登録するために使用する管理者ユーザー名とパスワードも保存しました。ファブリックへの登録は、Membership Service Provider (MSP) フォルダを生成するプロセスです。このフォルダには、登録証明書、プライベートキー、および CA が署名したルート証明書と中間証明書が含まれています。MSP のプライベートキーですべての操作に署名することによって、マネージドブロックチェーンに認証するためにこれらを使います。管理者 ID を使用してファブリックネットワークを管理し、チャネルの作成やチェーンコードのインスタンス化などのタスクを実行します。

ステップ 6: アカウント B が、そのメンバーのパブリックキーをアカウント A と共有する

すべてのファブリック操作 (トランザクション提案保証要求と応答、オーダラーからのブロックなど) は、メンバーのプライベートキーで署名します。このため、他の関係者は、操作の発信者を認証してメッセージを復号化するために、そのメンバーのパブリックキーのコピーが必要です。そのため、アカウント A には、新しいメンバーの公開証明書のコピーが必要です。アカウント A には 2 つの証明書が必要です。管理者のロールを持つユーザーを認証するための「admincert」と、メンバーのロールを持つユーザーを認証するための「cacert」です。

ステップ 7: アカウント A が新しいアカウント B のメンバーのために MSP フォルダを作成する

アカウント A は MSP フォルダを作成し、新しいメンバーに属する admincert と cacert を保存します。この MSP は、新しいメンバーが署名した操作について新しいメンバーの身元を確認するために使用します。

ステップ 8: アカウント A が、新しいアカウント B のメンバーを含む configtx.yaml ファイルを作成する

チャネル設定ファイル (configtx.yaml) には、プロファイルとしてのチャネル定義と、ファブリックネットワークを構成するメンバーの詳細が含まれています。この段階では、configtx.yaml には、ネットワーク作成者が作成したアカウント A の単一メンバーの詳細のみが含まれています。新しいメンバーをこのファイルのさまざまなセクションに追加する必要があります。各チャネル設定はプロファイルを使用して生成されるので、新しいメンバーはプロファイルセクションの適切なプロファイルにも追加する必要があります。

Git リポジトリのステップ 8 の readme ファイルには、2 人のメンバーをサポートする configtx.yaml ファイルのテンプレートと実用例が記載されています。

ステップ 9: アカウント A がチャネル設定を生成する

このステップは、アカウント B に属する新規メンバーを含む新規チャネル設定ブロックを生成します。設定ブロックは、チャネルのメンバーおよびポリシーを定義するジェネシスブロックに似ています。実際、設定ブロックは、ジェネシスブロックに、チャネルの作成以降に発生した設定変更のデルタを加えたものと見なすことができます。

興味深いことに、「ジェネシスブロック」はファブリックの次の 2 つの場所に現れます。

オーダラーは、オーダラーシステムチャネルの作成に使用するジェネシスブロックを使用してブートストラップされます。ジェネシスブロックは、コマンド configtxgen -outputBlock を使用して作成します。通常、起動時に ENV 変数またはパラメータ (GenesisFile という名前を付けて) を使用してオーダラーに渡されます。マネージドブロックチェーンがこれを処理します。
アプリケーションチャネルは、チャネル設定ブロックを使用して作成します。これらのうちの最初のものは、チャネルのためのジェネシスブロックになります。これは、コマンド configtxgen -outputCreateChannelTx を使用して作成します。

新しいチャネル設定ブロックを作成するには、まずチャネルから最新の設定ブロックを取得します。次に、新しいメンバーを含む新しいチャネル設定を生成し、次に古い設定と新しい設定を比較して差分を生成します。

新しいチャネル設定を生成するには、readme のステップ 9 に詳述されているいくつかのステップが必要です。

ステップ 10: 保証ピアが新しいチャネル設定に署名する

差分は既存のネットワークメンバーが署名しなければなりません。つまり、ネットワークメンバーはチャネル設定への変更を保証し、新しいメンバーがチャネルに参加することを承認する必要があります。チャネル設定の更新は、実際にはファブリックのもう 1 つのトランザクションであり、設定トランザクションと呼ばれます。このように、更新はチャネルのための変更ポリシーに従ってネットワークメンバーが保証しなければなりません。チャネルアプリケーショングループのデフォルトの変更ポリシーは MAJORITY です。これは、大多数のメンバーがチャネル設定の更新に署名する必要があることを意味します。

現在のネットワークには 1 人のメンバーとネットワーク作成者しか含まれていないので、ネットワーク作成者だけがパッケージに署名する必要があるため、この手順は厳密には必要ありません。ただし、ファブリックネットワークが 2 人以上のメンバーに成長するときに必要になるため、手順として明示しました。

異なるメンバーに属する管理者がチャネル設定に署名できるようにするには、チャネル設定の差分ファイルをネットワーク内の各メンバーに渡す必要があります。各メンバーにそれをひとつひとつに渡し、メンバーにチャネル設定を署名させます。各メンバーの署名を順番に適用する必要があるので、すべての保証メンバーの署名があるパッケージになります。あるいは、チャネル設定を全メンバーに同時に送信し、署名付きの応答を受信するのを待つこともできます。ただし、その場合は個々の応答から署名を抽出し、設定の更新と必要なすべての署名を含む単一のパッケージを作成する必要があります。

署名付きチャネル設定を行った後は、それをチャネルに適用できます。

ステップ 11: アカウント A が新しい設定でチャネルを更新する

このステップでは、新しいチャネル設定でチャネルを更新します。新しいチャネル設定に新しいメンバーの詳細が含まれるようになったので、これにより新しいメンバーはチャネルに参加できます。

ステップ 12: アカウント A がアカウント B とチャネルのジェネシスブロックを共有する

アカウント B のピアノードがチャネルに参加する前に、マネージドブロックチェーンが管理する順序サービスに接続できなければなりません。チャネルジェネシスブロックから順序サービスのエンドポイントを取得します。チャネルジェネシスブロックの設定はファイル mychannel.block に保存されています。ここで、mychannel はチャネル名を表し、チャネル名を変更した場合は異なる場合があります。この設定は、アカウント A が最初にチャネルを作成したときに作成されました。アカウント A はファイル mychannel.block をアカウント B と共有します。

ステップ 13: アカウント B がピアノードを起動し、チャネルに参加する

次のステップは、新しいメンバーに属するピアノードをチャネルに参加させることです。ピアがチャネルに正常に参加した後、ピアはトランザクションのブロックの受信を開始します。ピアはレジャーの独自のコピーを作成し、ブロックチェーンを作成し、ワールドステートのキーバリューストアを生成します。

ステップ 14: アカウント B がチェーンコードをインストールする

アカウント B のピアノードがチャネルでブロックを受信していることを確認するには、チェーンコードをインストールします。その後、ピアのローカルレジャーに対してクエリを実行します。チェーンコードをインストールした後、アカウント B のピアノードは自身のワールドステートデータベースに対してクエリを実行できます。

ステップ 15: アカウント B がチェーンコードをクエリする

このステップでは、ピアノードが独自のレジャーを管理していることを確認するためにクエリを実行します。

ステップ 16: アカウント B がトランザクションを呼び出す

ピアノードがワールドステートデータベースに対してクエリを実行することができるけれども、トランザクションを首尾よく呼び出すことができないことを発見して驚くかもしれません。

アカウント B のピアノードは現在、コミットしているピアです。これは、ピアが順序サービスから受け取ったブロックを検証し、独自のレジャーを維持できることを意味します。しかし、それはまだ保証ピアではなく、保証するトランザクションに参加することはできません。ステップ 16では、保証のためにトランザクションをアカウント B のピアノードに明示的に送信します。アカウント B のピアがトランザクションを保証し、デジタル署名します。ただし、このチャネルのチェーンコードの保証ポリシーを満たしていないため、トランザクションはファブリック検証ステップに失敗します。

アカウント B のピアノードが保証要求を受信すると、トランザクションをシミュレートして保証する標準のファブリックプロセスに従います。このプロセスには、アカウント B のメンバーの ID を使用して保証に署名することが含まれます。その後、保証されたトランザクションは順序サービスに送信され、順序サービスはトランザクションをブロックにグループ化し、そのブロックをピアノードに送信します。その後、各ピアノードはブロック内のトランザクションを検証します。検証ステップに失敗したトランザクションは、無効なトランザクションとして各ピアのブロックチェーンに書き込まれ、ワールドステートは更新されません。

保証ポリシーは通常、チェーンコードがチャネル上でインスタンス化されるときに指定されます。パート 1 を振り返ると、インスタンス化中に保証ポリシーを提供しなかったことがわかります。そのため、ファブリックはデフォルトの保証ポリシーを適用します。この場合、それは「OR ( ‘Org1.member’)」です。つまり、トランザクションは作成者組織のみが保証できます。

無効なトランザクションを解決するには、次の 2 つの方法があります。

アカウント A とアカウント B のピアノードにトランザクション提案を送信する方法。アカウント A はトランザクションを保証できるため、トランザクション提案は有効なエンドーサーと無効なエンドーサーの両方が署名します。つまり、アカウント A とアカウント B のピアからの保証が含まれています。検証ステップで保証ポリシーを確認すると、トランザクションにはそのポリシーに含まれているメンバーの保証が含まれているため成功します。
新しいメンバーを保証ポリシーに追加する方法。これを行うには、チャネルのチェーンコードを、新しいメンバーを含む新しい保証ポリシーで更新する必要があります。

次の手順では、新しいメンバーを保証ポリシーに追加します。

ステップ 17: アカウント A がチャネル上のチェーンコードの保証ポリシーを更新する

保証ポリシーは、チェーンコードがチャネル上でインスタンス化またはアップグレードされるときに定義されます。この場合は、ファブリックチャネルのチェーンコードをアップグレードします。これにより、アカウント A のチェーンノードのバージョンをアップグレードし、新しいバージョンのチェーンコードをピアノードにインストールする必要があります。チェーンコード自体は変更されません。このチャネルでは、バージョン番号とそれに適用される保証ポリシーのみが変更されます。

チェーンコードのアップグレードはインスタンス化と非常によく似ており、完了までに約 30 秒かかります。このプロセス中に、ファブリックは新しい Docker チェーンコードコンテナを作成し、チェーンコードをインストールして init 関数を呼び出します。自身のチェーンコードを設計するときのため、これを覚えておいてください。チェーンコードがアップグレードされるたびに init 関数が実行されるので、init 関数でステートが初期化されるというファブリックのサンプルと見間違えないでください。これにより、チェーンコードがアップグレードされるたびに、現在のワールドステートが init 関数で定義された値にリセットされます。つまり、現在のワールドステートを消去して、init 関数で指定されたデフォルト値で上書きすることができます。ファブリックのベストプラクティスは、ステートを初期化し、チェーンコードのインスタンス化中に一度だけ呼び出すための別の機能を持つことです。

ステップ 18: アカウント B が最新バージョンのチェーンコードをインストールする

新しいバージョンのチェーンコードをアカウント B のピアノードにインストールする必要があります。チェーンコードをインストールした後、トランザクションを呼び出してクエリを再実行すると、アカウント B のピアノードがトランザクションを保証できるようになったことを確認できます。各ピアノードで実行した検証チェックは、アカウント B によって保証されたトランザクションが有効であることを確認し、各ピアのワールドステートが更新されます。これを再確認するには、まずアカウント A またはアカウント B のピアノードでトランザクションを呼び出します。次に、アカウント A とアカウント B のピアノードで同じクエリを実行します。両方のピアで同じ結果が表示されるはずです。

結論

この記事では、パート 1 で作成したファブリックネットワークに、別の AWS アカウントが所有する新しいメンバーを追加しました。次に、新しいメンバーのピアノードをプロビジョニングし、新しいメンバーを既存のチャネルのチャネル設定に追加しました。次に、新しいメンバーが所有するピアノードをチャネルに参加させました。最後に、新しい AWS アカウントと元の AWS アカウントの両方のメンバーがチャネル上のトランザクションを保証できるように、チャネルの保証ポリシーを更新しました。

プレビューにサインアップして、マネージドブロックチェーンをお試しください。

著者について

Michael Edge は、AWS プロフェッショナルサービスのシニアクラウドアーキテクトで、ブロックチェーン、コンテナ、およびマイクロサービスを専門としています。

Amazon Web Services ブログ