leaf

ビットコインはブロックチェーン技術 1.0 時代の代表的なプラットフォームと見なされており、スマートコントラクトを主要な特徴とするイーサリアムプラットフォームの誕生により、ブロックチェーン技術は 2.0 時代に突入しました。そして、オープンソースプロジェクトである Hyperledger Fabric プラットフォームは、ブロックチェーン技術 3.0 時代の到来を示しています。最新の Fabric v1.4.1（LTS）では、多くの新しい設計コンセプトが提案され、多くの新機能が追加され、高度にモジュール化され、構成可能なアーキテクチャが提供され、一般的なプログラミング言語（Java、Go、Node.js など）を使用してスマートコントラクトを記述することができ、プラグイン可能なコンセンサスプロトコルをサポートしています。このプラットフォームに基づいて企業向けアプリケーションを開発することが現実のものとなり、プラットフォームへの関心も高まっています。本章では、読者を Hyperledger Fabric の世界に導き、基本的な動作原理を探求し、このプラットフォームへの理解を深め、Fabric に基づくアプリケーション開発技術の学習に向けた基礎を築きます。

Hyperledger プロジェクトは、ブロックチェーンデジタル技術と取引検証を推進することを目的としたオープンソースプロジェクトであり、オープンソースコミュニティのメンバーが協力して、さまざまな業界のユーザーのニーズを満たし、ビジネスプロセスを簡素化するためのオープンプラットフォームを構築することを目指しています。このプロジェクトは、分散台帳の公開標準を作成することによって、仮想およびデジタル形式の価値交換を実現します。

ブロックチェーン技術の支えにより、ビットコインなどの「デジタル暗号通貨」は注目を集めており、そのアクティブユーザー数と取引量は日々増加しており、発展速度は人々の予想をはるかに超えています。多くの起業家、企業、金融機関は次第にブロックチェーン技術の価値に気づき、それが「デジタル暗号通貨」分野にとどまらず、より大きな応用の可能性を持つと広く認識されています。

そのため、Vitalik は Ethereum プロジェクトを設立し、ブロックチェーン愛好者がより良く、より簡単にブロックチェーンアプリケーションを構築できるように、チューリング完全なスマートコントラクトプログラミングプラットフォームを作ることを期待しました。その後、市場には資産登録、予測市場、アイデンティティ認証などの新しいタイプのブロックチェーンアプリケーションが次々と登場しました。しかし、当時のブロックチェーン技術自体には克服できないいくつかの問題が残っていました。例えば、まず取引効率が低く、ビットコイン全体のネットワークは 1 秒あたり約 7 件の取引しかサポートできませんでした。次に、取引の確定性が十分に保証されていませんでした。最後に、コンセンサスを達成するために使用されるマイニングメカニズムは、大きなリソースの浪費を引き起こす可能性があります。これらの問題により、当時のブロックチェーン技術はほとんどの商業アプリケーションのニーズを満たすことができませんでした。

したがって、商業ニーズを満たすブロックチェーンプラットフォームを設計し実装することが、当時のブロックチェーンの発展における重要な課題となりました。社会各界からの強い要望を受けて、Linux 財団のオープンソース組織は 2015 年 12 月に Hyperledger という名前のオープンソースプロジェクトを開始し、さまざまな関係者が協力してブロックチェーン技術の企業向けアプリケーションプラットフォームを共同で構築し、業界を超えたブロックチェーンの発展を促進することを目指しています。

Hyperledger は設立当初から、IBM、シスコ、インテルなどの著名な企業を多数引き付けており、富国銀行や JP モルガンなどの金融業界の巨頭も最初のメンバーとなりました。その開発コミュニティは現在、270 以上の組織に成長しています。特筆すべきは、プロジェクトメンバーの 4 分の 1 以上が中国の企業から来ていることで、趣链科技、小蚁、布比などの新興ブロックチェーン企業や、万達、華為、招商銀行などの著名企業も参加しています。メンバーの構成から見ると、Hyperledger オープンソースプロジェクトは非常に大規模で、さまざまな業界の企業エリートが集まり、共同で解決策を探求し、企業向けブロックチェーンプラットフォームの発展を推進しています。

Hyperledger プロジェクトは、完全なメンバー権限管理、革新的なコンセンサスアルゴリズム、プラグイン可能なフレームワークを初めて提案し実現しました。これにより、ブロックチェーン関連技術と産業の発展に深遠な影響を与えることになります。実際、これはブロックチェーン技術が単なるオープンソース技術ではなく、他の業界の主流機関や市場に正式に認識されていることを示しています。

Hyperledger プロジェクトは、大規模なオープンソースプロジェクトであり、さまざまな関係者が協力してブロックチェーン技術の商業アプリケーションの発展を促進し推進することを目指しています。構成には多くの関連する具体的なサブプロジェクトが含まれています。これらのサブプロジェクトは独立したプロジェクトであることもあれば、他のプロジェクトと関連するプロジェクトであることもあります。例えば、構築ツール、ブロックチェーンブラウザなどです。Hyperledger はサブプロジェクトの形式に対して大きな制約を設けておらず、関連する良いアイデアがあれば、Hyperledger 委員会に提案を提出することができます。

プロジェクトの公式アドレスは Linux 財団のウェブサイトにホスティングされており、コードは Gerrit にホスティングされ、GitHub を通じてコードミラーが提供されています。サブプロジェクトをより良く管理し、プロジェクトを発展させるために、Hyperledger プロジェクトは技術指導委員会（Technical Steering Committee、TSC）という機関を設立しました。これは Hyperledger プロジェクトの最高権力機関であり、サブプロジェクトの管理やプロジェクトエコシステムの発展に関する重要な決定が実行されます。Hyperledger プロジェクトは、所属するサブプロジェクトを管理する際にライフサイクル形式を採用し、各プロジェクトにライフサイクルを付与して、プロジェクトの運営と管理を容易にします。全体のライフサイクルは 5 つの段階に分かれており、それぞれ提案（proposal）段階、孵化（incubation）段階、活発（active）段階、廃止（deprecated）段階、そして最終的な終了（end of Life）段階です。各プロジェクトは開発運営の過程で、ある時点で 1 つの段階にのみ対応します。もちろん、プロジェクトは必ずしも上記の段階の順序で発展するわけではなく、特定の理由により複数の段階の間で変化することもあります。すべてのプロジェクトは、取引、契約、一貫性、アイデンティティ、ストレージなどの技術シナリオを含むモジュール設計を重視し、新機能やモジュールが簡単に追加および拡張できるようにコードの可読性を実現し、ますます深刻化する商業ニーズや徐々に豊かになるアプリケーションシナリオに応じて新しいプロジェクトを継続的に追加および進化させる必要があります。

Fabric はブロックチェーン技術の実装であり、取引呼び出しとデジタルイベントに基づく分散型共有台帳技術です。他のブロックチェーン技術の実装と比べて、モジュール化されたアーキテクチャ設計を採用し、プラグイン可能なコンポーネントの開発と使用をサポートしています。その総勘定元帳のデータは複数の参加ノードによって共同で維持され、一度記録されると、台帳上の取引情報は永久に改ざんされることはなく、タイムスタンプによる追跡調査がサポートされています。他のパブリックチェーンに対して、Fabric はメンバー管理サービスを導入しているため、各参加者は対応する証明書を提供して身分を証明しなければ Fabric システムにアクセスできません。また、マルチチャネル・マルチ台帳の設計を導入してシステムのセキュリティとプライバシーを強化しています。イーサリアムと比較して、Fabric は強力な Docker コンテナ技術を使用してサービスを実行し、イーサリアムよりも便利で強力なスマートコントラクトサービスをサポートします。イーサリアムは提供された Solidity 言語を使用して契約を記述することしかできませんが、Fabric は Go、Java、Node.js などの多言語による契約の記述をサポートしています。さらに、Fabric は多言語の SDK 開発インターフェースを提供し、開発者が提供されるブロックチェーンサービスを自由に便利に使用できるようにしています。本章の後半では、Fabric のアーキテクチャと動作について詳しく分析します。

Iroha は Fabric アーキテクチャに触発された分散型台帳プロジェクトであり、2016 年 10 月 13 日に技術指導委員会の承認を受けて孵化段階に入り、2017 年 5 月 18 日に孵化区を出ました。このプロジェクトは C++ およびモバイルアプリケーション開発者に Hyperledger プロジェクトの開発環境を提供することを目指しています。このプロジェクトは C++ を使用して Fabric、Sawtooth Lake、その他の潜在的なブロックチェーンプロジェクトの再利用可能なコンポーネントを実現し、これらのコンポーネントは Go 言語で呼び出すことができます。つまり、Iroha は既存のプロジェクトの補完であり、その長期的な目標は、Hyperledger 技術プロジェクトが分散型台帳を運営する際に、これらの再利用可能な要素を自由に選択し使用できる健全な再利用可能なコンポーネントライブラリを実現することです。

Sawtooth Lake は 2016 年 4 月 14 日に TSC の承認を受け、2017 年 5 月 18 日に孵化区を出た、インテルが発起したモジュール型分散型台帳プラットフォームの実験プロジェクトであり、多機能性と拡張性を考慮して設計されています。Sawtooth Lake は分散型台帳を構築、展開、運用するためのモジュール型プラットフォームを提供し、許可されたチェーンと非許可のチェーンの展開をサポートします。新しいコンセンサスアルゴリズム PoET が含まれています。PoET はビットコインが採用しているプルーフ・オブ・ワークアルゴリズムと同様に、一定のルールに従ってランダムにノードを選択し、そのノードがブロックの記帳者となり、他のノードがそのブロックと実行結果を検証します。異なる点は、PoET は大量の計算能力とエネルギーを消費する必要がなく、CPU ハードウェアが SGX（Software Guard Extensions）機能をサポートする必要があります。PoET アルゴリズムのハードウェア制限により、現在は生産環境での PoET アルゴリズムの使用が適しているのは一時的です。

Blockchain Explorer プロジェクトは、Hyperledger のユーザーフレンドリーな Web アプリケーションを作成し、Hyperledger ブロックチェーン上の情報を照会することを目的としています。これには、ブロック情報、取引関連データ、ネットワーク情報、契約コード、分散型台帳に保存されている関連情報が含まれます。プロジェクトは 2016 年 8 月 11 日に TSC の承認を受け、その後孵化段階に入りました。

Cello プロジェクトは 2017 年 1 月 5 日に TSC の承認を受け、孵化状態に入りました。Cello プロジェクトは、ブロックチェーンをサービスとして提供する（blockchain as a service、BaaS）ことを目指し、ブロックチェーンの手動操作（作成と廃止）の作業量を削減します。Cello を通じて、オペレーターはダッシュボードを使用して簡単にブロックチェーンを作成および管理でき、ユーザー（契約コード開発者）は単一のリクエストでブロックチェーン情報を即座に取得できます。つまり、オペレーターに簡単で便利なブロックチェーン操作プラットフォームを提供します。

Hyperledger Fabric は分散型台帳技術（DLT）の独自の実装であり、モジュール型のブロックチェーンアーキテクチャに基づいて企業向けのネットワークセキュリティ、拡張性、機密性、高性能を提供します。現在の Fabric の最新バージョンは v1.4.1（LTS）であり、以前の v0.6 バージョンと比較して、v1.4 バージョンはセキュリティ、機密性、展開、保守、実際のビジネスシナリオのニーズなどの面で多くの改善が行われています。例えば、アーキテクチャ設計における Peer ノードの機能分離、マルチチャネルのプライバシー隔離、コンセンサスのプラグイン実装などが含まれています。機能面では、Raft 障害耐性コンセンサスサービスが導入され、保守性と操作性が改善され、プライベートデータのサポートが追加されるなど、Fabric により良いサービスサポートが提供されています。したがって、本書の後半での Fabric に関する内容はすべて v1.4 バージョンに基づいて説明されます。

Hyperledger Fabric v1.4 には以下の特徴があります。

• 身分管理（identity management）。Fabric ブロックチェーンは許可されたチェーンネットワークであるため、Fabric はメンバーサービス（member service）を提供し、ユーザー ID を管理し、ネットワーク上のすべての参加者を認証します。Hyperledger Fabric ブロックチェーンネットワーク内では、メンバーは身分情報を通じて互いに認識できますが、彼らは互いに何をしているかは知りません。これが Fabric が提供する機密性とプライバシーです。

• プライバシーと機密性（privacy and confidentiality）。Hyperledger Fabric は、競合する商業組織や取引情報にプライバシーと機密性のニーズを持つ他の任意の団体が同じ許可されたチェーンネットワーク内で共存できるようにします。メッセージの伝播経路を制限するためにチャネルを通じて、ネットワークメンバーに取引のプライバシーと機密性の保護を提供します。チャネル内のすべてのデータ、取引、メンバー、およびチャネル情報は不可視であり、そのチャネルに未登録のネットワークエンティティはアクセスできません。

• 効率的なパフォーマンス（efficient processing）。Hyperledger Fabric はノードタイプに基づいてネットワークロールを割り当てます。より良いネットワークの同時実行性と並行性を提供するために、Fabric はトランザクションの実行、トランザクションの順序付け、トランザクションのコミットを効果的に分離しました。順序付けの前にトランザクションを実行することで、各 Peer ノードは同時に複数のトランザクションを処理でき、この同時実行は Peer ノードの処理効率を大幅に向上させ、取引からコンセンサスサービスへの配信プロセスを加速します。

• 関数型契約コードプログラミング（chaincode functionality）。契約コードはチャネル内の取引呼び出しのコーディングロジックであり、資産所有権を変更するためのパラメータを定義し、デジタル資産所有権の移転に関するすべての取引が同じルールと要件に従うことを保証します。

• モジュール化設計（modular design）。Hyperledger Fabric が実現したモジュール型アーキテクチャは、ネットワーク設計者に機能選択を提供します。特定の身分認識、コンセンサス、暗号化アルゴリズムは、Fabric ネットワークにプラグイン可能なコンポーネントとして挿入でき、これに基づいて、あらゆる業界や公共領域で一般的なブロックチェーンアーキテクチャを採用し、ネットワークが市場、規制、地理的境界を超えて相互運用できることを保証します。

• 保守性と操作性（serviceability and operations）。ログ記録の改善、健康チェックメカニズム、運用指標の追加により、v1.4 バージョンは保守性と操作性において大きな飛躍を遂げました。新しい RESTful 運用サービスは、生産オペレーターに対して、Peer ノードとコンセンサスサービスノードの運用を監視および管理するための 3 つのサービスを提供します。最初のサービスは、ログ記録 /logspec エンドポイントを使用し、オペレーターが Peer ノードとコンセンサスサービスノードのログ記録レベルを動的に取得および設定できるようにします。2 番目のサービスは、健康チェック /healthz エンドポイントを使用し、オペレーターとビジネスプロセスコンテナが Peer ノードとコンセンサスサービスノードのアクティビティと健康状態を確認できるようにします。3 番目のサービスは、運用指標 /metrics エンドポイントを使用し、オペレーターが Prometheus を利用して Peer ノードとコンセンサスサービスノードからの運用指標を記録できるようにします。

• アンカーノード

  Gossip プロトコルは、異なる組織の Peer ノードが互いに認識できるようにアンカーノードを使用します。アンカーノードの更新を含む構成ブロックが提出されると、Peer ノードはアンカーノードを検出し、アンカーノードが知っているすべての Peer ノードを知ることができます。組織間は Gossip 通信を通じて接続されているため、チャネル構成には少なくとも 1 つのアンカーノードを定義する必要があります。各組織が一組のアンカーノードを提供することで、高可用性と冗長性の削減が実現されます。

• アクセス制御リスト

  アクセス制御リスト（ACL）は、特定の Peer ノードリソース（システム契約コード API やトランザクションサービスなど）へのアクセスをポリシー（必要な組織または役割の数とタイプを指定）に関連付けます。ACL はチャネル構成の一部であり、標準構成更新メカニズムを使用して更新できます。

• ブロック

  ブロックは、コンセンサスシステムによって作成された順序付けられた取引のセットを含み、Peer ノードによって検証されます。チャネル内では暗号化された方法で前のブロックにリンクされ、その後のブロックに接続されます。最初のブロックは創世ブロックと呼ばれます。

• ブロックチェーン

  ブロックチェーンは取引ログであり、取引ブロックがハッシュで接続されて構造化されています。Peer ノードはコンセンサスサービスから取引ブロックを受け取った後、背書ポリシーと並行性の衝突に基づいてブロックの取引を有効または無効としてマークし、ブロックを Peer ノードファイルシステムのハッシュチェーンに追加します。

• スマートコントラクト

  スマートコントラクトは、ブロックチェーンネットワーク外部のクライアントによって呼び出されるコードであり、世界状態のキーと値のペアへのアクセスと変更を管理するために使用され、Peer ノードにインストールされ、チャネル上でインスタンス化されます。スマートコントラクトは契約コードとも呼ばれます。

• チャネル

  チャネルは Fabric ネットワーク上に構築されたプライベートブロックチェーンであり、構成ブロックによって定義され、データの隔離とプライバシーを保証します。すべての Peer ノードはチャネル内の特定の台帳を共有し、取引者と台帳の相互作用はチャネルの正当性検証を通じて行われる必要があります。

• コミット

  チャネル内の各 Peer ノードは取引ブロックの順序を検証し、その後ブロックをチャネルの台帳の各コピーにコミット（書き込みまたは追加）します。Peer ノードは取引が有効かどうかもマークします。

• 並行制御バージョンチェック

  並行制御バージョンチェック（CCVC）は、チャネル内の Peer ノードの状態を同期させることができます。Peer ノードは並行して取引を実行し、取引が台帳にコミットされる前に、Peer ノードは実行中に読み取ったデータが変更されていないかを確認します。変更されている場合、CCVC の衝突が発生し、その取引は台帳内で無効としてマークされ、その値は状態データベースに更新されません。

• 構成ブロック

  システムチェーン（コンセンサスサービス）またはチャネル定義メンバーとポリシーの構成データを含みます。特定のチャネルまたはネットワーク全体の構成変更（例えば、メンバーの離脱または参加）は、新しい構成ブロックを生成し、適切なチェーンに追加されます。この構成ブロックには創始ブロックの内容と増分が含まれます。

• コンセンサス

  コンセンサスは取引の順序を確認し、取引セット自体の正当性を確認するために使用されます。

• 合意セット

  Raft コンセンサスサービスにおいて、合意セットはチャネル上で積極的にコンセンサスメカニズムに参加している順序付けノードです。システムチャネル上に他の順序付けノードが存在しても、それがチャネルの一部でない場合、これらの順序付けノードはチャネルの順序付けセットには含まれません。

• コンソーシアム

  コンソーシアムはブロックチェーンネットワーク上の無秩序な組織の集合です。これらの集合はチャネルを構成し、独自の Peer ノードを持ちます。ブロックチェーンネットワークは複数のコンソーシアムを持つことができますが、ほとんどのネットワークには 1 つのコンソーシアムしかありません。チャネルが作成されると、チャネルに参加するすべての組織はコンソーシアムの一部である必要があります。コンソーシアムに定義されていない組織は、既存のチャネルに追加される可能性があります。

• 世界状態

  世界状態は台帳の現在の状態とも呼ばれ、ブロックチェーン取引ログ内のすべてのキーの最新の値を示します。Peer ノードは最近処理した各取引に対応する変更された値を台帳の世界状態に更新します。世界状態は、キーの最新の値に直接アクセスできるため、全体の取引ログを通じてではなく、契約コードは最初にキーと値の世界状態を知り、その世界状態に基づいて取引提案を実行する必要があります。

• 動的メンバー管理

  Fabric は、ネットワークの操作性に影響を与えることなく、メンバー、Peer ノード、およびコンセンサスサービスノードを動的に追加または削除することをサポートします。動的メンバー管理は、ビジネス関係の調整やさまざまな理由でエンティティを追加または削除する必要がある場合に重要です。

• 創世ブロック

  創世ブロックはブロックチェーンネットワークまたはチャネルの初期化ブロックであり、ブロックチェーン上の最初のブロックでもあります。

• Gossip プロトコル

  Gossip データ転送プロトコルには 3 つの機能があります：Peer ノードの管理、チャネル上のメンバーの発見；チャネル上のすべての Peer ノード間での台帳データのブロードキャスト；チャネル上のすべての Peer ノード間での台帳データの同期。

• 台帳

  台帳はブロックチェーンと世界状態で構成されています。ブロックチェーンは不変であり、一度ブロックがチェーンに追加されると変更できません。一方、世界状態はデータベースであり、ブロックチェーンで検証され、提出されたトランザクションセットによって追加、変更、または削除されたキーと値の集合の現在の値を含みます。ネットワーク内の各チャネルには論理的な台帳があり、実際にはチャネル内の各 Peer ノードが自身の台帳のコピーを維持しており、これらのコピーはコンセンサスプロセスを通じて他の Peer ノードのコピーと一致します。論理的には単一ですが、ネットワークノード（Peer ノードとコンセンサスサービス）グループ内に多くの同じコピーが分散しています。分散型台帳技術（DLT）という用語は通常、この台帳に関連付けられます。

• フォロワー

  リーダーベースのコンセンサスプロトコル（Raft など）では、フォロワーはリーダーによって生成されたログエントリのコピーを取るノードです。Raft では、フォロワーはリーダーの「ハートビート」メッセージも受け取ります。リーダーが設定された時間内にこれらのメッセージの送信を停止すると、フォロワーはリーダー選挙を開始し、フォロワーの 1 つがリーダーとして選出されます。

• リーダー

  リーダーベースのコンセンサスプロトコル（Raft など）では、リーダーは新しいログエントリを取得し、それをフォローノードにコピーし、いつそれがコミットされたと見なされるかを管理します。

• 主要 Peer ノード

  各組織は、サブスクライブしているチャネル上に複数の Peer ノードを持つことができ、その中の少なくとも 1 つが主要 Peer ノードとして機能し、その組織を代表してネットワークのコンセンサスサービスと通信します。コンセンサスサービスは、チャネル上の主要 Peer ノードにブロックを提供し、その後、同じ組織内の他の Peer ノードに配布します。

• ログ記録

  ログ記録は Raft コンセンサスサービスの主要な作業単位であり、リーダーからフォロワーに配布されます。これらの記録の完全なシーケンスは「ログ」と呼ばれます。すべてのメンバーが記録とその順序に合意すれば、そのログは一貫性があると見なされます。

• メンバーサービス提供コンポーネント

  メンバーサービス提供コンポーネント（MSP）は、クライアントノードと Peer ノードに証明書を提供するシステム抽象コンポーネントを指します。クライアントノードは証明書を使用して取引を認証します。Peer ノードは証明書を使用してその取引（背書）を認証します。このインターフェースはシステムの取引処理コンポーネントと密接に関連しており、定義されたメンバーシップサービスコンポーネントがこの方法でスムーズに挿入されることを目的としており、システムの取引処理コンポーネントのコアを変更することはありません。

• メンバー管理サービス

  メンバー管理サービスは、許可されたブロックチェーン上で身分を認証、承認、管理します。Peer ノードと順序付けサービスノード内でメンバー管理サービスのエージェントが実行されます。

• 順序付けサービスまたはコンセンサスサービス

  取引をブロックに順序付けるノードの集合です。順序付けサービスは Peer ノードプロセスとは独立しており、先着順でネットワーク上のすべてのチャネルの取引を順序付けます。順序付けサービスはプラグイン可能な実装をサポートしており、現在は Solo と Kafka がデフォルトで実装されています。

• 組織

  組織は「メンバー」とも呼ばれ、ブロックチェーンサービスプロバイダーによってブロックチェーンネットワークに招待されます。組織はその MSP をネットワークに追加することによってネットワークに参加します。組織の取引エンドポイントは Peer ノードであり、一群の組織がコンソーシアムを形成します。ネットワーク上のすべての組織はメンバーですが、すべての組織が連合の一部になるわけではありません。

• ノード

  台帳を維持し、契約コンテナを実行して台帳に対して読み書き操作を行うネットワークエンティティです。ノードはメンバーによって所有および維持されます。

• ポリシー

  • ポリシーは、Org.Peer や Org2.Peer のようなデジタルアイデンティティの属性で構成される式であり、ブロックチェーンネットワーク上のリソースへのアクセスを制限します。ポリシーはコンセンサスサービスを起動する前やチャネルを作成する前に定義することができ、またはチャネル上の契約コードをインスタンス化する際に指定することができます。

  • プライベートデータ

    プライベートデータは、各許可された Peer ノードのプライベートデータベースに保存される機密データであり、論理的にはチャネルの台帳データとは分離されています。プライベートデータへのアクセスは、プライベートデータセットで定義された組織に制限されています。無許可の組織は、プライベートデータのハッシュ値をチャネルの台帳上に持つことができ、取引データの証拠として使用されます。さらに、プライベートデータのハッシュ値はプライベートデータ自体ではなく、コンセンサスサービスを通じて伝達されるため、プライベートデータはコンセンサスサービスノードに対して機密性を保ちます。

  • プライベートデータセット

    プライベートデータセットは、チャネル上で他の組織とプライバシーを保ちたい 2 つ以上の組織を管理するために使用され、チャネル上でプライベートデータを保存する権限を持つ組織のサブセットを記述します。これらの組織のみがプライベートデータと取引できます。

  • Raft

    Raft は v1.4.1 で新たに追加された機能で、Raft プロトコル etcd ライブラリに基づく障害耐性（CFT）コンセンサスサービスの実装です。Raft は「リーダーとフォロワー」モデルに従います。Kafka ベースのコンセンサスサービスと比較して、Raft コンセンサスサービスは設定と管理が容易であり、組織が分散型コンセンサスサービスにノードを提供することを許可します。

Hyperledger は現在業界で広く認識されているコンソーシアムチェーンの実装であり、その最も重要なサブプロジェクトである Fabric は特に注目されています。孵化から現在まで、Fabric のアーキテクチャ設計も進化の過程で徐々に改善され、完成度が高まっています。前述の通り、Fabric の基本的な内容と機能について紹介しました。次に、Fabric の最新の全体アーキテクチャを分析し、過去のアーキテクチャとの比較を通じて Fabric 新アーキテクチャの特徴と利点を探ります。

Fabric はアーキテクチャ設計においてモジュール化の設計理念を採用しており、図 4.1 に示す全体の論理アーキテクチャでは、Fabric は主に 3 つのサービスモジュールから構成されています。それぞれ、メンバーサービス（membership service）、ブロックチェーンサービス（Blockchain service）、契約コードサービス（Chaincode service）です。メンバーサービスはメンバー登録、身分管理、認証サービスを提供し、プラットフォームへのアクセスをより安全にし、権限管理に役立ちます。ブロックチェーンサービスはノード間のコンセンサス管理、台帳の分散計算、P2P ネットワークプロトコルの実装、台帳のストレージを担当し、ブロックチェーンのコアコンポーネントとして、ブロックチェーンの主要機能に対する基盤サービスを提供します。契約コードサービスは、Fabric の契約コード（スマートコントラクト）プログラムのデプロイ実行環境を提供するスマートコントラクトの実行エンジンを提供します。同時に、論理アーキテクチャ図には、イベントストリーム（event stream）が 3 つのサービスコンポーネント間を貫通していることが見えます。その機能は、各コンポーネントの非同期通信を技術的にサポートすることです。Fabric のインターフェース部分では、API、SDK、CLI の 3 種類のインターフェースが提供されており、ユーザーはこれらを使用して Fabric を操作管理できます。

Fabric の実行アーキテクチャを示しています。v0.6 バージョンの構造は非常にシンプルで、アプリケーション - メンバー管理 - Peer の三角関係を呈しています。システムのすべてのビジネス機能は Peer ノードによって完了します。しかし、Peer ノードはあまりにも多くのビジネス機能を担っており、拡張性、保守性、安全性、ビジネスの隔離などの多くの問題が露呈しました。したがって、v1.4 バージョンでは、公式にアーキテクチャが改善され再構築され、コンセンサスサービス部分が Peer ノードから完全に分離され、独立した新しいノードが形成され、コンセンサスサービスとブロードキャストサービスを提供します。v1.4 バージョンでは、チャネルの概念も導入され、マルチチャネル構造とマルチチェーンネットワークが実現され、より柔軟なビジネス適応性がもたらされました。また、より強力な構成機能とポリシー管理機能をサポートし、システムの柔軟性をさらに強化しました。

実行時アーキテクチャ（v1.4）

v0.6 バージョンと比較して、新しいアーキテクチャにより、システムは多くの面で大きな向上を遂げました。主な利点は以下の通りです。

• 契約コードの信頼の柔軟性（chaincode trust flexibility）。v1.4 バージョンでは、アーキテクチャ上で契約コードの信頼仮定（trust assumptions）とコンセンサスサービス（ordering service）の信頼仮定が分離されました。新しいバージョンのコンセンサスサービスは、単独のノードのグループ（orderer）によって提供され、故障ノードや悪意のあるノードが存在することも許可されます。一方、契約コードプログラムは異なる背書ノードを指定でき、契約コードの柔軟性が大幅に向上しました。

• 拡張性（scalability）。新しいアーキテクチャでは、指定された契約コードの背書を担当する背書ノードとコンセンサスノードは直交関係にあるため、v0.6 アーキテクチャのすべてのビジネス機能が Peer ノード上で実行されるのに対し、v1.4 バージョンのアーキテクチャは拡張性が大幅に向上しました。特に、異なる契約コードが指定する背書ノードに交差がない場合、システムは同時に複数の契約コードプログラムの背書操作を行うことができ、システムの処理効率が大幅に向上します。

• 機密性（confidentiality）。マルチチャネルの設計により、内容と実行状態の更新に機密性のニーズがある契約コードのデプロイが容易になりました。また、プライベートデータのサポートが追加され、今後利用可能なゼロ知識証明（ZKP）が開発中です。

• コンセンサスのモジュール性（consensus modularity）。v1.4 アーキテクチャでは、コンセンサスサービスが Peer ノードから分離され、独自のコンセンサスノードとなりました。コンセンサスサービスはプラグイン可能なモジュール型コンポーネントとして設計され、さまざまなビジネスシナリオに適用できる異なるコンセンサスアルゴリズムの実装を許可します。

メンバーサービスは Fabric の参加者にネットワーク上の身分管理、プライバシー、機密性、認証サービスを提供できます。以下では PKI システムに関連する内容とユーザーの登録プロセスについて重点的に紹介します。

1. PKI システム

   PKI（public key infrastructure、公的鍵基盤）の目標は、異なるメンバーが顔を合わせずに安全に通信できるようにすることです。Fabric が現在採用しているモデルは、信頼できる第三者機関、すなわち証明書発行機関（certification authority、CA）によって発行された証明書に基づいています。CA は申請者の身分を確認した後、証明書を発行し、オンラインで発行した証明書の最新の取り消し情報を提供します。これにより、使用者は証明書がまだ有効であるかどうかを検証できます。証明書は公的鍵、申請者に関連する情報、およびデジタル署名を含むファイルです。デジタル署名は、証明書の内容が攻撃者によって改ざんされないことを保証し、検証アルゴリズムは偽造されたデジタル署名を発見できます。このようにして、公的鍵と身分が結びつけられ、改ざんや偽造ができなくなり、メンバー管理が実現されます。

   メンバーサービスは PKI システムと分散型コンセンサスプロトコルを組み合わせ、非許可ブロックチェーンを許可ブロックチェーンに変えました。非許可ブロックチェーンでは、エンティティは認可を受ける必要がなく、ネットワーク内のすべてのノードには役割の違いがなく、すべてが均一な Peer エンティティであり、取引を提出し、記帳する権利が平等にあります。一方、許可ブロックチェーンでは、エンティティは長期的な身分証明書（例えば、登録証明書）を取得するために登録する必要があります。この身分証明書はエンティティのタイプに応じて区別されます。ユーザーにとって、登録時に取引証明書発行機関（transaction certificate authority、TCA）が登録ユーザーに匿名の証明書を発行します。一方、取引には取引証明書の認証を通過する必要があり、取引証明書はブロックチェーン上に保存され、認証サービスが取引を追跡するために使用されます。実際、メンバーサービスは認証センターであり、ユーザーに証明書認証と権限管理機能を提供し、ブロックチェーンネットワーク内のノードと取引を管理および認証します。

   Fabric のシステム実装では、メンバーサービスはユーザーの身分とプライバシーを管理するために協力するいくつかの基本的なエンティティで構成されています。これらのエンティティの中には、ユーザーの身分を検証するもの、システム内でユーザーの身分を登録するもの、ネットワークに入る際や取引を呼び出す際に必要な証明書の証拠を提供するものがあります。PKI は公的鍵暗号に基づくフレームワークであり、ネットワーク上のデータの安全な交換を確保するだけでなく、相手の身分を確認するためにも使用されます。同時に、Fabric システム内では、PKI は鍵とデジタル証明書の生成、配布、取り消しの管理にも使用されます。

   通常、PKI システムは証明書発行機関（CA）、登録機関（RA）、証明書データベース、および証明書ストレージエンティティを含みます。RA は信頼できるエンティティであり、ユーザーの身分を検証し、データ、証明書、またはユーザーのリクエストをサポートするための他の材料の合法性を確認する責任があります。また、登録に必要な登録証明書を作成する責任も負います。CA は RA の提案に基づいて、指定されたユーザーにデジタル証明書を発行します。これらの証明書は、ルート CA によって直接または階層的に認証されます。

図中のエンティティについてさらに説明します。

• ルート証明書機関：ルート CA は PKI システム内の信頼できるエンティティを代表し、PKI システムアーキテクチャ内の最上位の認証機関です。

• 登録 CA（ECA）：ユーザーが提供する登録証明書を検証した後、ECA は登録証明書（ECerts）を発行します。

• 取引 CA（TCA）：ユーザーが提供する登録証明書を検証した後、TCA は取引証明書（TCerts）を発行します。

• TLS CA：ユーザーがネットワークを使用できるように TLS（transport layer security、伝送層セキュリティプロトコル）証明書と証明書を発行します。

• ECerts（enrollment certificates）：ECerts は長期証明書であり、すべての役割に発行されます。

• TCerts（transaction certificates）：TCerts は各取引の短期証明書であり、TCA によって認可されたユーザーのリクエストに基づいて発行されます。ユーザーは TCerts をユーザーの身分情報を持たないように構成し、匿名でシステムに参加することができ、取引のリンク可能性を防ぐこともできます。

• TLS-Certs（TLS-Certificates）：TLS-Certs はその所有者の身分を持ち、システムとコンポーネント間で通信し、ネットワークレベルのセキュリティを維持するために使用されます。

• CodeSignerCerts（Code Signer Certificates）：ソフトウェアコードにデジタル署名を行い、ソフトウェアの出所とソフトウェア開発者の真の身分を識別し、署名後にコードが悪意を持って改ざんされないことを保証します。

金融 IC カードシステムでも PKI システムが使用されており、そのアーキテクチャは図 4.5 に示されています。Fabric の PKI システムと比較すると、TCert は存在せず、各取引は ECert を使用して完了するため、このシステム内の取引は匿名ではありません。

** 前述のように、** メンバーサービスの PKI システムのエンティティと基本機能について紹介しました。次に、具体的なユーザー登録プロセスについて簡単に紹介します。図はユーザー登録プロセスの高レベルの説明を示しており、オフラインプロセスとオンラインプロセスの 2 つの段階に分かれています。

ユーザー登録プロセス

• オフラインプロセス

  (1) 各ユーザーまたは Peer ノードは、RA 登録機関に身分証明書（ID 証明）を提供する必要があります。このプロセスは、RA がユーザーのアカウントを作成（および保存）するために必要な証拠を提供するために、アウトオブバンド（out-of-band、OOB）で伝送される必要があります。

  (2) RA 登録機関は、ユーザーに関連するユーザー名とパスワード、および信頼のアンカー（TLS-CA Cert を含む）を返します。ユーザーがローカルクライアントにアクセスできる場合、クライアントは TLS-CA 証明書を信頼のアンカーの一種として使用できます。

• オンラインプロセス

  (1) ユーザーはクライアントに接続してシステムにログインをリクエストし、このプロセスでユーザーはユーザー名とパスワードをクライアントに送信します。

  (2) ユーザー端末はユーザーを代表してメンバーサービスにリクエストを送信し、メンバーサービスはリクエストを受け入れます。

  (3) メンバーサービスは、複数の証明書を含むパッケージをクライアントに送信します。

  (4) クライアントがすべての暗号材料が正しく有効であることを検証すると、証明書はローカルデータベースに保存され、ユーザーに通知され、これでユーザー登録が完了します。

ブロックチェーンサービスは 4 つのモジュールで構成されています：コンセンサス管理、分散型台帳、台帳ストレージ、および P2P ネットワークプロトコル。コンセンサス管理は、複数のノードの分散型複雑ネットワーク内でメッセージが合意に達するのを助け、分散型台帳と台帳ストレージはブロックチェーンシステム内のすべてのデータストレージを担当します。これには、取引情報、世界状態、プライベートデータなどが含まれます。P2P ネットワークプロトコルは、ネットワーク内のノード間の通信方法であり、Fabric 内の各ノード間の通信と相互作用を担当します。

1. P2P ネットワーク

   P2P ネットワークは、対等な計算モデルがアプリケーション層で形成した分散型アプリケーションアーキテクチャであり、対等なエンティティ間でタスクと作業負荷を分配するために使用されます。相互に接続された複数のコンピュータは、P2P ネットワーク環境内で対等な地位にあり、同じ機能を持ち、主従の区別はありません。1 台のコンピュータはサーバーとして機能し、ネットワーク内の他のコンピュータが使用する共有リソースを設定し、ワークステーションとしてサービスを要求することもできます。一般的に、全体のネットワークは専用の集中サーバーに依存せず、専用のワークステーションもありません。ブロックチェーンが存在する分散型環境では、各ノードは本来平等であり、P2P ネットワークプロトコルに自然に適しています。

   Fabric のネットワーク環境では、ノードはブロックチェーンの通信エンティティです。3 種類の異なるノードが存在し、それぞれクライアントノード（Client）、Peer ノード（Peer）、およびコンセンサスサービスノード（Ordering Service Node または Orderer）です。

   クライアントノードはエンドユーザーエンティティを表します。クライアントノードは Peer ノードに接続して初めてブロックチェーンと通信できます。また、クライアントノードは自分の選択に基づいて任意の Peer ノードに接続し、取引を作成し、取引を呼び出すことができます。実際のシステム運用環境では、クライアントは Peer ノードと通信して実際の取引呼び出しを提出し、コンセンサスサービスと通信して取引のブロードキャストタスクを要求します。

   Peer ノードは、コンセンサスサービスノードと通信して世界状態を維持および更新します。彼らはコンセンサスサービスからのメッセージを受け取り、ブロックの形式で順序付けられた取引情報を受け取り、その後、ローカルの世界状態と台帳を更新および維持します。同時に、Peer ノードは追加で背書ノードの役割を担うことができ、取引の背書を担当します。背書ノードの特別な機能は、特定の取引に対して設定されており、提出前にその取引を背書する操作を行います。各契約コードプログラムは、複数の背書ノードの集合を含む背書ポリシーを指定できます。このポリシーは、有効な取引の背書（通常は背書ノードの署名の集合）の充足条件を定義します。特に注意すべきは、新しい契約コードのデプロイ取引において、（デプロイ）背書ポリシーはシステム契約コードの背書ポリシーによって指定され、自己指定はできないという特別な状況が存在します。

   コンセンサスサービスノード Orderer は、コンセンサスサービスの構成要素です。コンセンサスサービスは、配信保証を提供する通信組織と見なすことができます。コンセンサスサービスノードの責任は、取引を順序付け、最終的にすべての取引が同じシーケンスで出力され、配信保証サービスのブロードキャスト通信サービスを提供することです。コンセンサスサービスのノードタイプを見てみましょう。v0.6 バージョンでは、全体のネットワークは 2 種類のノードで構成されています：VP（validating Peer）検証ノードと NVP 非検証ノード。図に示すように、ネットワークには 4 つの検証ノードが含まれており、各ノードは 2 つの非検証ノードに接続しています。全体のネットワークのコンセンサスは 4 つの検証ノードによって構成されています。v1.4 バージョンでは、ネットワークトポロジーがノードタイプの変化に伴い大きく変化し、コンセンサスサービスノードがコンセンサスサービスを構成し、コンセンサスサービスが分離され、Peer ノードは背書ノードまたはコミット Peer ノードに分けられ、グループ化することもできます。そして、全体のコンセンサスサービスと Peer ノードで構成されるグループが新しい完成したネットワークを形成します。

v1.0 以降のバージョンでは、Fabric は新しいチャネルの概念を導入し、コンセンサスサービス上のメッセージ伝達がマルチチャネルをサポートし、Peer ノードがアプリケーションアクセス制御ポリシーに基づいて任意の数のチャネルをサブスクライブできるようにしました。Peer ノードのサブセットは、アプリケーションによって関連チャネルを指定して設置され、同じチャネルの Peer ノードが集合を構成し、そのチャネルの取引を提出し、これらの Peer ノードのみが関連取引ブロックを受信でき、他の取引とは完全に隔離されます。Fabric はマルチチェーンとマルチチャネルをサポートしており、システム内には複数のチャネルと複数のチェーンが存在することができます。図に示すように、アプリケーションはビジネスロジックに基づいて各取引を指定された 1 つまたは複数のチャネルに送信し、異なるチャネル上の取引は一切の関係を持ちません。

• v1.2 以降、Fabric は台帳内にプライベートデータセットを作成できるようになり、チャネル上の組織のサブセットがプライベートデータを認可、提出、または照会できるようになり、別のチャネルを作成することなく、チャネル上の一群の組織のデータを他の組織に対して秘密にする機能を実現しました。実際のプライベートデータは、許可された組織の Peer ノード上のプライベート状態データベースに保存され（時にはサイドデータベースまたは SideDB と呼ばれます）、許可されたノード上の契約コードが Gossip プロトコルを通じてアクセスできます。コンセンサスサービスはその中に関与せず、プライベートデータを見ることもできません。Gossip プロトコルは許可された組織内でプライベートデータを対等に配布するため、チャネル内にアンカーノードを設立し、各ノードに CORE_PEER_GOSSIP_EXTERNALENDPOINT を設定して、組織間通信を導く必要があります。プライベートデータのハッシュ値は、認可、順序付け、各 Peer の台帳に書き込まれ、取引の証拠として使用され、状態検証に役立ち、監査にも使用されます。

全体として、Fabric のノードとネットワークに関する再構築と新機能により、Fabric の取引処理能力が向上し、プライバシー隔離がうまく実現されました。

• コンセンサスサービス

  ネットワーク内の Orderer ノードが集まり、コンセンサスサービスを形成します。これは配信保証を提供する通信組織と見なすことができます。コンセンサスサービスはクライアントと Peer ノードに共有の通信チャネルを提供し、取引を含むメッセージにブロードキャストサービス機能を提供します。クライアントがチャネルに接続すると、コンセンサスサービスを通じてメッセージをブロードキャストし、すべての Peer ノードにメッセージを送信できます。コンセンサスサービスはすべてのメッセージに原子的な配信保証を提供します。つまり、Fabric 内のコンセンサスサービスはメッセージ通信が直列化され、信頼できることを保証します。言い換えれば、コンセンサスサービスは、すべての接続された Peer ノードに同じメッセージを出力し、出力の論理的順序も同じです。

  コンセンサスサービスは異なる実装方法を持つことができ、v1.4 バージョンでは、Fabric はコンセンサスサービスをプラグイン可能なモジュールとして設計し、異なるアプリケーションシナリオに応じて異なるコンセンサスオプションを構成できるようにしました。現在、Fabric は 3 つのモードの実装を提供しています：Solo、Kafka、Raft。

  Solo は、単一ノードに展開されるシンプルな時系列サービスであり、主に開発テストに使用され、単一のチェーンと単一のチャネルのみをサポートします。Kafka は、マルチチャネルのパーティションをサポートするクラスタコンセンサスサービスであり、CFT（crash faults tolerance）をサポートします。部分的なノードのクラッシュを許容しますが、悪意のあるノードには耐性がありません。基本的な実装は Zookeeper サービスに基づいており、使用される分散環境では、ノードの総数と失敗したノードの数がn≥2f+1 を満たす必要があります。Raft は「リーダーとフォロワー」モデルに従い、各チャネルは「リーダー」を選出し、その決定が「フォロワー」に複製され、CFT をサポートします。ノードの総数と失敗したノードの数がn≥2f+1 を満たす限り、リーダーを含む部分的なノードのクラッシュを許可します。Kafka ベースのコンセンサスサービスと比較して、Raft は設定と管理が容易であり、設計により組織が分散型コンセンサスサービスにノードを提供することを許可します。

• ブロックチェーン技術はその基盤構造から分析すると、共有台帳技術と見なすことができます。台帳はブロックチェーンのコアコンポーネントであり、ブロックチェーンの台帳にはすべての歴史的取引と状態変更の記録が保存されています。Fabric では、各チャネルは共有台帳に対応しており、共有台帳に接続されている各 Peer ノードはネットワークに参加し、台帳情報を表示できます。つまり、ネットワーク内のすべてのノードが台帳情報に参加し、表示することが許可されています。台帳上の情報は公開されており、各 Peer ノード上で台帳のコピーが維持されています。図 4.9 は Fabric の台帳の構造を示しています。

共有台帳構造

図からわかるように、共有台帳はローカルにファイルシステムの形式で保存されています。共有台帳は 2 つの部分で構成されています：図中のチェーン部分と右側の状態データを保存する部分です。チェーン部分はすべての取引情報を保存しており、追加と照会のみ可能で、削除や変更はできません。状態部分は取引ログ内のすべての変数の最新の値を保存しており、これはチャネル内のすべての変数のキーと値のペアの最新の値を示すため、「世界状態」とも呼ばれます。

契約コードは現在の状態データを変更するために取引を呼び出して実行します。これらの契約コードが効率的に相互作用するために、最新のキーと値のペアデータを状態データベースに保存するように設計されています。デフォルトの状態データベースは Level DB を使用していますが、構成を通じて Couch DB や他のデータベースに切り替えることができます。

契約コードサービスは、サンドボックスでノード上の契約コードの実行を検証する安全で軽量な方法を提供し、安全なコンテナサービスと安全な契約コード登録サービスを提供します。その実行環境は「ロック」され、安全なコンテナであり、契約コードは最初に独立したアプリケーションとしてコンパイルされ、隔離された Docker コンテナ内で実行されます。契約コードがデプロイされると、自動的に署名されたスマートコントラクトの Docker 基本イメージのセットが生成されます。Docker コンテナ内での契約コードと Peer ノードの相互作用プロセスは図に示されています。

手順は次のとおりです。

(1) Peer ノードはクライアントからの契約コード実行リクエストを受け取ると、gRPC を介して契約コードと相互作用し、契約コードメッセージオブジェクトを対応する契約コードに送信します。

(2) 契約コードはInvoke()メソッドを呼び出し、GetState()操作とPutState()操作を実行して、Peer ノードから台帳状態データベースを取得し、台帳の事前提出状態数を送信します。プライベートデータを読み書きする場合は、GetPrivateData()およびPutPrivateData()メソッドを使用します。

(3) 契約コードが成功裏に実行されると、出力結果が Peer ノードに送信され、背書ノードは入力と出力情報に対して背書署名を行い、完了後にクライアントに応答します。

アーキテクチャの解読から、契約コードサービスは Fabric アーキテクチャのコアコンポーネントであることがわかります。本節では、契約コードサービスで実行される契約コードをさらに研究し、具体的な契約コードの作成、デプロイ、および呼び出し方法を紹介します。

契約コードはブロックチェーン上で実行されるコードの一部であり、Fabric におけるスマートコントラクトの実装方法です。また、Fabric において、契約コードは取引生成の唯一のソースでもあります。共有台帳はブロックで接続されたハッシュチェーンで構成されており、ブロックには Merkle ツリーのデータ構造で表されたすべての取引情報が含まれています。取引はブロックチェーン上で最も基本的なエンティティ単位と見なされます。では、取引はどのように生成されるのでしょうか？取引は契約コードの呼び出し操作によってのみ生成されるため、契約コードは Fabric のコアコンポーネントであり、共有台帳と相互作用する唯一のチャネルです。

現在、Fabric は Java、Go、Node.js 言語を使用してインターフェースを実装する方法で契約コードを作成することをサポートしています。Fabric の設計に従い、/core/chaincode ディレクトリ内の shim パッケージは契約コード開発の SDK を提供しており、理論的には独立して使用できますが、現在は他の依存モジュールを呼び出す必要があるため、まだ完全に独立していないかもしれません。

Fabric 内の契約コードは Peer ノード上で実行され、契約コードに関連する操作（デプロイ、インストール、呼び出しなど）も Peer ノード上で行われます。契約コードは SDK または CLI を介して Fabric ネットワークの Peer ノード上でインストールおよび初期化され、ユーザーと Fabric ネットワークの