「エンドースメントポリシー」「チャネル」「組織」を詳細解説
佐中 晋
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
コグニティブ・ソリューション
先進インダストリー・ソリューション
アドバイザリーITスペシャリスト
新しい合意形成の仕組み
エンドースメントポリシー
Hyperledger Fabric v1.0（以下、v1.0）では合意形成のアルゴリズムが大きく変更されている。v0.6で使用されていた合意形成のアルゴリズム「PBFT」（Practical Byzantine Fault Tolerance）では、更新処理が適正なものであるかを確認するためにネットワーク上のすべての検証ノードで検証を行い、その後、全体の (2n+1)/3ノード以上から適正と判断された処理をコミットする仕組みとなっていた。
一方、v1.0では「エンドースメントポリシー」（Endorsement Policy）と呼ばれるポリシーベースの検証が導入されている。検証はポリシーで設定された台数の検証ノード（Endorser）でのみ実施され、ポリシーに適合する支持が得られた処理をコミットする仕組みとなった。
検証がネットワーク上で局所的に実行されるので検証処理の並列化が可能で、v0.6と比較してネットワーク全体のスケーラビリティが向上している。また、ネットワーク内で局所的に行われる検証処理の整合性を保つため、「Ordering Service」という更新処理の順序づけを行う新しいコンポーネントがv1.0では追加されている。
以下、v1.0における台帳更新の流れを紹介する。
① Proposal
台帳の更新を希望するクライアントは、SDKを介してPeer（Endorser）に対しトランザクションProposalを送信する。トランザクションProposalにはSDKによりクライアントの署名が添付されている。Proposalの対象となるPeerは、エンドースメントポリシーに従う。エンドースメントポリシーについての詳細は後述するが、ポリシーは「組織」と呼ぶv1.0から導入されたPeerの管理単位を使用してルール化される（図表1ではOrg0、Org1、Org2の3つの組織からの署名が必要というポリシーを想定しており、E0、E1、E2というEndorserがそれぞれOrg0、Org1、Org2に属している状態とする）。
【図表1】Proposal
② Endorse
Endorserは、トランザクションProposalのフォーマットや、2重実行がなされていないか、署名やクライアントが権限をもっているかをチェックし、問題なければ更新を仮実行する。仮実行時のread値・write値のセット（RWset）にEndorserは署名を付け、仮実行結果（Proposalレスポンス）としてクライアントに返す。この段階では各Peerの台帳は更新されない（図表2）。
【図表2】Endorse
③ Submit
クライアントはすべてのEndorserからのレスポンスを待ち、エンドースメントポリシーを満たす署名が集まったかを確認する。必要な数のレスポンスが集まったら、クライアントは各EndorserからのProposalレスポンスが同一であるかをチェックし、ProposalレスポンスをOrdering Serviceにトランザクションとして送付する。Ordering Serviceは、Channelごとにトランザクションを時系列整列しブロックとしてまとめる（図表3。Channelとは、v1.0から導入された、台帳を共有するノードの管理単位。詳細は後述）。
【図表3】Submit
④ Broadcast
Ordering Serviceからトランザクションのブロックが同一ChannelのすべてのPeerに送付される（図表4）。
【図表4】 Broadcast
⑤ Commit
各PeerでProposal間での矛盾がないかや必要な署名が揃っているかをチェックし、エンドースメントポリシーを満たしていることが確認できればトランザクションのブロックをチェーンに追加し、仮実行値をステートDBに書き込む。Eventが発行され、クライアントにブロックの追加とトランザクション結果が通知される（図表5）。
【図表5】Commit
時系列で見るv0.6とv1.0の
トランザクション
図表6と図表7は、時系列で見た場合のトランザクションの流れである。
v0.6では、検証・コミットのステップにおいて、すべての検証ノード間で相互に通信を行うので、ノードの台数増加に伴いネットワークを流れる処理量が増大する仕組みであった（図表6）。一方、v1.0では検証が決められた台数で局所的に行われるため、Peerの増加によるトランザクション量の増加は限定的であるのがわかる（図表7）。
【図表6】v0.6のトランザクション推移
【図表7】v1.0のトランザクション推移
ここで、v1.0のエンドースメントポリシーで設定可能なポリシーの例を挙げてみよう。組織の集合を、E = {OrgA、 OrgB、 OrgC、 OrgD、OrgE、 OrgF、 OrgG} とすると、次のようなポリシーが考えられる。
・例1：Eに含まれるすべての組織からの署名が必要
・例2：Eに含まれる任意の1組織からの署名が必要
・例3：(OrgAまたはOrgB) と (OrgC、OrgD、OrgE、OrgF、OrgGのうち2つ) の3つの署名
・例4：5つ（一般的には2n+1/3）以上の組織からの署名が必要
つまりv1.0では、アプリケーションやネットワークが必要とするEndorserの不具合・不正行為への耐性度合いに応じて、ポリシーを柔軟に細かく設定可能ということである。
セキュリティを高める管理単位
「チャネル」「組織」
v1.0には「チャネル」（Channel）および「組織」（Organization）という新しい管理単位が導入されている。
チャネルとは、一言で言えば、台帳・チェーンコード（Chaincode）を共有するPeerの集合である。v1.0以前のネットワークでは、合意形成の検証がすべてのノード（検証ノード）で実行されていたので、ネットワークに所属するすべてのPeerで同一の台帳が共有されていた。
これに対してv1.0の合意形成はチャネル単位で行われるため、ネットワーク基盤のリソースを共有しながら、必要なノード間でのみ台帳・チェーンコードの共有が可能となった。つまりチャネルの実装によって、必要な関係者だけでデータを共有できるのだ。このことは、ビジネス上の理由や、プライバシー保護・個人情報保護の観点からデータの秘匿性が強く求められる現在、意味のある仕組みと言えるだろう。
チャネルは、組織および組織ごとの「Anchor Peer」（異なる組織間の通信を担うPeer）によって構成される。チェーンコードはチャネルを指定してデプロイされ、エンドースメントポリシーを指定する。またチャネルごとに使用するOrdering Serviceのノード（Orderer）が決定されている（図表8）。
【図表8】マルチチャネルで構成されるv1.0ブロックチェーンの例
前述したが、エンドースメントポリシーの定義は組織という単位を利用してルール化されている。組織は、組織に属するノードおよび認証局（Membership Service Provider。以下、MSP）によって構成されている。
また、Ordering Serviceは、Peerの所属する組織とは別の独自組織に属しており、複数の組織のリクエストを受け付けることが可能になっている。
連携する業務ごとに
「チャネル」を区切る
チャネル・組織の例を挙げてみよう。
図表9では、A商社・B商社・C工場・D企業の4つの組織間でネットワークが構成されている。それぞれに、Org1、Org2、Org3、Org4という「組織」が割り当てられ、「業務A」はA商社・B商社・C工場・D企業が連携するので、「チャネル1」にはすべての組織が参加している。「業務B」はB商社・C工場・D企業のみに関連する業務なので、「チャネル2」には3つの組織のみが参加する。「チャネル3」も関連する3つの組織で構成される。
【図表9】チャネルを区切ることにより、必要な組織に必要なデータのアクセス権を割り当てる
このように、組織間で連携する業務ごとにチャネルを区切ることで、ネットワーク基盤を共有しながら、必要な組織に必要なデータのアクセス権を割り当てることが可能になる。
････････
著者プロフィール
佐中 晋 氏
2010年、日本IBMシステムズ・エンジニアリング入社。IAサーバー仮想化、クラウド基盤関連のプロジェクトを担当。その後、クラウドを利用したアプリケーション開発に携わり、現在はブロックチェーン、WatsonAPI、BPMといったクラウドを取り巻く技術に関して幅広く活動している。現在、日本IBMのビジネス・オートメーション所属。
････････
IS magazine No.18（2018年1月）掲載
