目次


Hyperledger Fabric 入門, 第 2 回

Peer/チャネル/Endorsement Policy の解説

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Hyperledger Fabric 入門, 第 2 回

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Hyperledger Fabric 入門, 第 2 回

このシリーズの続きに乞うご期待。

今回は第 1 回でも取り上げた Peer について詳しく紹介します。また Peer と関係性のあるチャネル、Endorsement Policy についてもあわせて紹介します。

1

はじめに

Hyperledger Fabric のネットワークに参加しているノードのことを Peer と言います。 Peer は Hyperledger Fabric を理解する上で重要な構成要素であり、チャネルや Endorsement Policy 等、Hyperledger Fabric を支える他の構成要素とも関わりが多くあります。

今回は Peer に加え、Hyperledger Fabric のプライバシーを強化する仕組みであるチャネルとネットワーク内の合意形成 (コンセンサス) の鍵である Endorsement Policy についても紹介します。

2

Peer

Peer は Hyperledger Fabric の構成の中で最も重要な構成要素の 1 つです。 Peer には主に 2 種類の役割があり、Hyperledger Fabric のネットワークを構築する時にはそれぞれの役割を Peer に定義します。 1 つの Peer に複数の役割を定義することも可能です。

  • Endorsement Peer
    Endorsement Peer は、台帳とチェーンコードを保有します。クライアントから送られてきたトランザクションをEndorsement Policy を基にトランザクションを検証し、結果に自身の署名をしてクライアントに返信します。 (Endorsement Policy については後述)
  • Committing Peer
    Endorsement Peer のような検証作業はせず、Orderer から送られてきたブロックを自身の台帳へ書き込みます。
「Hyperledger FabricにおけるPeerの役割」を示したフロー図
「Hyperledger FabricにおけるPeerの役割」を示したフロー図

 

Peer のそれぞれの機能について紹介します。

クライアントアプリケーションとの接続

台帳の更新や参照をする際、SDK (Software Development Kit) が提供されており、クライアントと Hyperledger Fabric 間の通信を行います。 通信の手順は大きく 2 種類に分かれ、1 つ目は台帳のデータを参照する (Query) 時。2 つ目は台帳のデータを更新する (Invoke) 時です。

まず、1 つ目の台帳のデータを Query する時の手順について説明します。

(1) クライアントから Peer に対して通信を開始します。
(2) 通信の確認後、台帳のデータを参照するためのトランザクションを Peer に送信します。
(3) Peer は Endorsement Policy を基にトランザクションを検証し、
(4) 承認した時のみ、チェーンコードを実行して
(5) 結果をクライアントに返します。Query の場合はこの結果にクライアントが参照したい情報が含まれています。

次に 2 つ目の Invoke の時の手順について説明します。

トランザクションが承認され、チェーンコードの実行結果を受け取るまでは Query の時と同様です。

(6) Peer からチェーンコードの実行結果を受け取ると、クライアントはトランザクションを Orderer に送信しましす。
(7) Orderer は受け取ったトランザクションの順序付けをしてブロックを作成します。
(8) Orderer は作成したブロックを送付します。
(9) Peer はブロックを受け取り、検証時とトランザクションの結果が変わっていないかを確認した上で、台帳に書き込みます。 この時の検証を MVCC 検証 (MultiVersion Concurrency Control) と言います。 MVCC 検証は複数のリクエスト (Query/Invoke) を並列処理する際に、情報の一貫性を保証する仕組みです。
(10) 最後に Peer は結果をイベントとしてクライアントに送信します。

「クライアントHyperledger Fabricとの接続」を示したフロー図
「クライアントHyperledger Fabricとの接続」を示したフロー図

 

台帳の保有

Hyperledger Fabric の台帳はブロックチェーンとステート DB が含まれています。 チェーンコードの実行履歴をブロックチェーンに書き込み、トランザクションを実行した最新の結果をステート DB に書き込みます。 チェーンコードを実行することで、ステート DB のデータを参照/書込をすることができますが、ブロックチェーンはそれぞれのブロックヘッダのハッシュ値がチェーン状に繋がっており、改ざんできないようになっています。

ステート DB はトランザクションを実行した結果の状態を保存しています。ステート DB で利用できる DB にはいくつか種類があり、デフォルトでは Level DB という KVS (Key-Value Store) 形式の DB が設定されています。 KVS とは保存したいデータ (Value) を一意なデータ (Key) と紐づけて保存する (Store) 仕組みのことを言います。 Hyperledger Fabric V1.0 から CouchDB が利用できるようになりました。

CouchDB はデータベースのスキーマが不要で、保存するデータ構造が自由なドキュメント型データベースです。 1 件分のデータをドキュメントと呼び、JSON や XML 等の形式で書かれたデータが保存されます。 フィールドの値を文字列や日付等、自由に指定することができ、文字列のパターンマッチや数値の範囲指定等、より柔軟に検索条件を指定することが可能です。

台帳の情報は同じネットワーク内で整合性を取るため、同期されます。チャネル単位で同期を取るため、必要最低限の範囲で情報の共有を行うことが可能です。Orderer が Peer にブロックを送信する際は該当するチャネル内の Peer に送付されます。 Orderer からブロックを受け取ると Peer はそのブロックが正しいブロックかどうかを検証します。

各 Peer はチェーンコードを実行した時の結果が他のチェーンコードの実行結果と競合していないかをステート DB の値を確認して検証し、競合が発生した場合は、そのトランザクションを無効にして、クライアントにその旨をイベントで送信します。

チェーンコードの実行

チェーンコードはビジネス上の条件や契約をビジネスロジックとして実装したプログラムです。 主に GO 言語を用いて記述されますが、Hyperledger Fabric V1.1 から JavaScript でも記述が可能になりました。

ブロックチェーンネットワーク内の参加者間で合意されたビジネスロジックをチェーンコードに記述して、処理を自動化します。 ステート DB にあるデータを参照/書込等をする際は、クライアントからトランザクションを送信して、該当するチェーンコードを実行することで、データの参照/書込をすることができます。

1 つのネットワーク内に複数のチェーンコードを配置することが可能で、それぞれのチェーンコードは ID で識別されます。 クライアントがトランザクションを送信する際には対象のチェーンコードの ID を指定します。

Peer には Endorsement Peer と Committing Peer の他に 2 つの役割があります。 それぞれの役割について紹介します。

  • Anchor Peer
    Anchor Peer はブロックチェーンネットワーク上の他の組織の Peer との通信の窓口となる Peer のことを言います。 各組織の Anchor Peer のアドレスはブロックチェーンネットワークの起動時に受け取ることができるので、Anchor Peer を通じて各組織の持つ Peer の情報を知ることができます。
  • Leader Peer
    Leader Peer は Orderer と通信する Peer です。LeaderPeer は 1 つの組織内で 1 ノード選出され、Leader Peer が Orderer から新しいブロックを受け取ると、同じ組織内の他の Peer に新しいブロックを伝播します。 Leader Peer により、全ての Peer が Orderer から直接ブロックを受け取る必要がなくなるため、Peer と Orderer 間の通信の負荷を軽減することができます。
3

チャネル

Hyperledger Fabric では Peer の持つ台帳の共有する範囲をチャネルという機能を使って制御することで情報のプライバシーを保護します。 チャネルはブロックチェーンネットワーク内に作られた仮想ネットワークです。ネットワーク内の特定の参加者間だけで、台帳の共有や、利用できるクライアントアプリケーションを制御することができます。

チャネルは 1 つのビジネスネットワーク上に仮想的なネットワーク (= チャネル) を作り、そのチャネル内で限られた参加者で台帳やチェーンコードを共有することができる仕組みです。 チャネルの機能により情報の公開範囲を柔軟に変えることができ、情報のプライバシーを保護することができます。

Peer は複数のチャネルに参加することができます。台帳はチャネルごとに管理されるので、台帳も複数管理することができます。 Peer 内に複数の台帳があっても、別のチャネルの台帳にアクセスすることはできないようコントロールされています。

図の Hyperledger Fabric のチャネル構成例では CompanyB が 3 つのチェーンコードと台帳を持っています。 チャネル 2 の参加者の CompanyC と D がチャネル 3 のチェーンコードと台帳にアクセスすることはできません。 そのためクライアントがトランザクションを送信する際はチェーンコードの ID だけでなく、チャネル名も指定する必要があります。

「Hyperledger Fabricにおけるチャネルの構成例」を示したフロー図
「Hyperledger Fabricにおけるチャネルの構成例」を示したフロー図

 

4

Endorsement Policy

Endorsement Policy は Hyperledger Fabric のネットワークで台帳の整合性を担保するための条件のことを言います。 Peer にチェーンコードを保存する時に Endorsement Policy を設定します。 Endorsement Peer はクライアントからトランザクションが送られると、Endorsement Policy を基にそのトランザクションを検証し、結果に自身の署名をして、クライアントに返信します。

例えば、複数の組織で構成されるブロックチェーンネットワークの場合、台帳の閲覧だけであれば、各組織のうちどちらかの Endorsement Peer の承認が取れれば、トランザクションが実行されますが、台帳を更新する時は、全ての組織の Endorsement Peer の承認を得られないと、トランザクションが実行できない等、Endorsement Policy を使って、悪意を持った参加者が不正に台帳を操作することを防ぐことができます。

クライアントは Endorsement Peer からのレスポンスを受け取り、Endorsement Policy を満たしているかどうかを確認します。 満たしている場合は、トランザクションを Orderer に送付します。Orderer は各クライアントから受け取ったトランザクションをブロックにパッケージングして、Peer に送信します。Peer は自身のブロックに書き込む前にトランザクションの値が検証時から変更されていないか。Endorsement Policy を満たしているかを確認した上で、自身の台帳に書き込みます。

「Hyperledger FabricにおけるEndorsement Policyの構成例」を示したフロー図
「Hyperledger FabricにおけるEndorsement Policyの構成例」を示したフロー図

 

5

まとめ

今回は Peer の詳細やチャネル、Endorsement Policy について学びました。Hyperledger Fabric はこれらの機能を活用してトランザクションの一貫性を担保したり、台帳のプライバシー保護を実現しています。 次回以降も Hyperledger Fabric の構成要素について紹介していきたいと思います。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=1060932
ArticleTitle=Hyperledger Fabric 入門, 第 2 回: Peer/チャネル/Endorsement Policy の解説
publish-date=05172018