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 Foundation のオープンソース組織は 2015 年 12 月に Hyperledger という名前のオープンソースプロジェクトを開始しました。これは、さまざまな関係者が協力して、ブロックチェーン技術の企業向けアプリケーションプラットフォームを共同で構築し、業界を超えたブロックチェーンの発展を促進することを目的としています。

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

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

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

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

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（ソフトウェアガード拡張）機能をサポートする必要があります。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 運用サービスは、製造オペレーターに対して、ピアノードとコンセンサスサービスノードの運用を監視および管理するための 3 つのサービスを提供します。最初のサービスはログ記録 /logspec エンドポイントを使用し、オペレーターがピアノードとコンセンサスサービスノードのログ記録レベルを動的に取得および設定できるようにします。2 番目のサービスは健康チェック /healthz エンドポイントを使用し、オペレーターとビジネスプロセスコンテナがピアノードとコンセンサスサービスノードのアクティビティと健康状態を確認できるようにします。3 番目のサービスは運用指標 /metrics エンドポイントを使用し、オペレーターが Prometheus を利用してピアノードとコンセンサスサービスノードからの運用指標を記録できるようにします。

• アンカーノード

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

• アクセス制御リスト

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

• ブロック

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

• ブロックチェーン

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

• スマートコントラクト

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

• チャネル

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

• コミット

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

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

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

• 構成ブロック

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

• コンセンサス

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

• 合意集合

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

• コンソーシアム

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

• 世界状態

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

• 動的メンバー管理

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

• 創世ブロック

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

• Gossip プロトコル

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

• 台帳

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

• フォロワー

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

• リーダー

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

• 主要ピアノード

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

• ログ記録

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

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

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

• メンバー管理サービス

  メンバー管理サービスは、許可されたブロックチェーン上で身分を認証、承認、管理します。ピアノードと順序サービスノードの中でメンバー管理サービスの代理が実行されます。

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

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

• 組織

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

• ノード

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

• ポリシー

  • ポリシーは、デジタル ID（digital identity）の属性で構成される式であり、Org.Peer や Org2.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 体系と非許可ブロックチェーンを組み合わせて、非許可ブロックチェーンを許可ブロックチェーンに変えます。非許可ブロックチェーンでは、エンティティは承認を受ける必要がなく、ネットワーク内のすべてのノードには役割の違いがなく、すべてが同等のピアエンティティであり、取引の提出と記帳の権利を平等に持っています。しかし、許可ブロックチェーンでは、エンティティは長期的な身分証明書（例えば登録証明書）を取得するために登録する必要があります。この身分証明書はエンティティのタイプに基づいて区別されます。ユーザーにとって、登録時に取引証明書発行機関（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）、およびコンセンサスサービスノード（Ordering Service Node または Orderer）です。

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

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

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

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

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

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

• コンセンサスサービス

  ネットワーク内の Orderer ノードが集まり、コンセンサスサービスを形成します。これは配信保証を提供する通信組織と見なすことができます。コンセンサスサービスはクライアントとピアノードに共有の通信チャネルを提供し、取引を含むメッセージにブロードキャストサービス機能を提供します。クライアントがチャネルに接続すると、コンセンサスサービスを介してメッセージをブロードキャストし、すべてのピアノードにメッセージを送信できます。コンセンサスサービスはすべてのメッセージに原子的な配信保証を提供します。つまり、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 ノードから台帳状態データベースを取得し、台帳の事前コミット状態数を送信します。プライベートデータの読み取りと書き込みを行う場合は、GetPrivateDate()およびPutPrivateDate()メソッドを使用します。

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

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

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

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