Introduction¶

一般的に、ブロックチェーンはイミュータブルなトランザクションの台帳であり、複数の_ピアノード_からなる分散ネットワークで管理されるものです。トランザクションは、ある 合意形成プロトコル に従って検証され、ブロックにまとめられます。各ノードは、それぞれが持つ台帳のコピーに対して、これらのトランザクションを適用していくことで管理しています。なお、各ブロックは、直前のブロックと紐づけるためにハッシュ値を含んでいます。

ブロックチェーンアプリケーションの中で、最初でかつ最もよく知られているものは、暗号資産(暗号通貨)であるBitcoin です。他の例もこれの後を継いでいますが、暗号資産のEthereumは異なるアプローチをとっており、新しく スマートコントラクト と、Bitcoin同様の特徴をあわせもつことで、分散アプリケーションのプラットフォームとなりました。 BitcoinとEthereumは、 パブリック・パーミッションレス ブロックチェーン技術というカテゴリに分類されます。これらは、誰でもアクセスできる、パブリックなネットワークで、参加者が匿名でやりとりすることができます。

BitcoinやEthereum、またそこから派生した技術が発展するに従って、その元となる技術であるブロックチェーン、分散台帳、分散アプリケーションプラットフォームの技術をより革新的な エンタープライズ 向けに適用しようという動きもでてきました。しかし、多くのエンタープライズ向けのユースケースでは、(今のところ)満たすことが不可能な性能特性が要件になっています。さらに、多くのユースケースでは、参加者の素性が明らかであることが強い要件となることがあります。例えば、”Know Your Customer" (KYC) やアンチマネーロンダリング (AML) といった規制に従わなければならない金融系のトランザクションです。

エンタープライズでの利用にあっては、下記の要件について考慮しなければなりません。

参加者が特定されている/特定可能であること
ネットワークが 許可型 であること
高いトランザクション・スループット性能
低レイテンシでトランザクションが確定すること
実際の商取引にかかわるトランザクションとデータのプライバシーと機密性の保持

初期のブロックチェーンプラットフォームの多くが、現在エンタープライズ向けに それに適応するように変更 されているところであるのに対し、 Hyperledger Fabricはエンタープライズ向けに最初から設計されています。以下の節では、Hyperledger Fabric (Fabric) と他のブロックチェーンとの違いを説明し、そのアーキテクチャを決定する上での動機づけについて述べていきます。

Hyperledger Fabric¶

Hyperledger Fabricは、オープンソースで、エンタープライズグレードで、許可型の分散台帳技術(DLT)のプラットフォームです。Fabricは、エンタープライズ向けに設計されており、よく使われている他の分散台帳やブロックチェーンプラットフォームとは大きく異なる特性を持っています。

一つは、HyperledgerがLinux Foundationの傘下で設立されたことです。Linux Foundationは、 オープンガバナンス の考え方で、オープンソースプロジェクトを育てることに成功してきた長い歴史があります。コミュニティを持続しエコシステムを育むことで、これらのプロジェクトは立派に成長することができました。 Hyperledgerは、多様性のあるテクニカル・ステアリング・コミッティ (TSC)によって運営されており、 Hyperledger Fabricは、複数の組織からの多様性のあるメンテナによって運営されています。最初のコミット以来、Fabricの開発者コミュニティは、組織数は35以上、開発者の数は200人近くにまで成長しました。

Fabricは、高度に モジュール化され、構成変更可能な アーキテクチャを採用しており、銀行業務や金融、保険、ヘルスケア、人材、サプライチェーン、さらには音楽のデジタル配信といった幅広い産業のユースケースに対するイノベーション、汎用化、最適化を可能としています。

Fabricは、ドメイン固有言語(DSL)ではなく、JavaやGoやNode.jsといった 汎用プログラミング言語によって書かれたスマートコントラクト をサポートした最初の分散台帳プラットフォームです。つまり、ほとんどの企業は、スマートコントラクトを開発するのに必要なスキルをすでに持っているということであり、新しい言語やDSLを学ぶための追加のトレーニングは必要ないということです。

Fabricのプラットフォームは 許可型 でもあります。これは、匿名で互いに信用を全く信用しないパブリック・パーミッションレスとは異なり、参加者は互いを知っているというものです。つまり、参加者は互いを 完全には信用していない かもしれませんが(例えば、同じ産業の競合同士)、例えば法的な合意や紛争解決の枠組みといった、参加者間に 何らかの形で存在する 信頼をもとに、ネットワークを運営することができるということです。

Fabricと他のプラットフォームの違いのうちで、最も重要なものの一つは、 プラグ可能な合意形成プロトコル のサポートです。これにより、特定のユースケースや信頼モデルに合うように、効率よくカスタマイズすることができます。例えば、一つの企業内で利用する場合や、信頼できる機関により運営される場合などでは、完全なビザンチン故障耐性のある合意形成アルゴリズムは不要であり、性能やスループットを必要以上に損なうと考えられるかもしれません。そのような場合、クラッシュ故障耐性 (CFT)をもつ合意形成プロトコルのほうがはるかに適切でしょうし、複数の参加者による非中央集権型のユースケースでは、従来のビザンチン故障耐性 (BFT)をもつ合意形成プロトコルが必要になるでしょう。

Fabricは、ネイティブな暗号資産を必要としない合意形成プロトコルを利用することができます。他のプラットフォームでは、暗号資産は、コストのかかるマイニングやスマートコントラクトの実行に対するインセンティブとして使われています。暗号資産の利用を避けることによって、いくつかの大きなリスクや攻撃ベクタを減らすことができ、また、マイニング処理を必要としないことで、他の分散システムとほぼ同様の運用コストでプラットフォームをデプロイすることができます。

これらの特徴的な設計の組み合わせにより、Fabricは、トランザクション処理性能とトランザクションの確定レイテンシの両方において、今日利用できる高い性能のプラットフォームの一つであり、トランザクションとスマートコントラクト(Fabricではチェーンコードと呼びます) の実装によってプライバシーと機密性を実現することができます。

では、これらの特徴的な機能について詳細に見ていきましょう。

Modularity¶

Hyperledger Fabricは、モジュール化されたアーキテクチャとなるように特に注意を払って設計されています。 Fabricは、合意形成プロトコルのプラグイン、LDAPやOpenID Connectといったアイデンティティ管理のプラグイン、鍵管理のプロトコルや暗号ライブラリなど、エンタープライズのユースケースにおける要件に合うように、コアが設定可能となるように設計されています。

Fabricは、大まかにいうと、次のモジュール化されたコンポーネントからなっています。

プラグ可能な オーダリングサービス: トランザクションの順番に対する合意形成を行い、ピアにブロックをブロードキャストします。
プラグ可能な メンバーシップサービスプロバイダ: ネットワーク上の実体と暗号的なアイデンティティを紐づけます。
P2Pのゴシップサービス (オプショナル): オーダリングサービスから出力されたブロックを他のピアに配布します。
スマートコントラクト ("チェーンコード"): 隔離のためにDockerなどのコンテナ環境で動作します。標準的なプログラム言語で書くことができますが、台帳のステートに直接アクセスできるわけではありません。
台帳: 様々なDBMSをサポートできます。
プラグ可能なエンドースメントおよび検証ポリシー: アプリケーションごとによって、強制する設定を変更することができます。

ブロックチェーン業界においては、「全てを統べるブロックチェーンは存在しない」というのが、ひとまずの合意となっています。 Hyperledger Fabricは、多くの産業のユースケースの様々な要件を満たせるようにいろいろな形で設定変更が可能になっています。

Permissioned vs Permissionless Blockchains¶

パーミッションレスなブロックチェーンには、事実上誰でも参加することができ、各参加者は匿名となります。そこでは、ある程度以上の過去のブロックについてはイミュータブルである、という以外の信頼は必要ありません。信頼をおかない代わりに、"Proof of Work" (PoW)をもとにした、ビザンチン故障耐性をもつ合意形成を行い、それに参加する膨大なコストを打ち消す経済的なインセンティブとして、典型的なパーミッションレスブロックチェーンでは、"マイニング"によって得られるネイティブな暗号通貨やトランザクション手数料を導入しています。

これに対して、許可型 のブロックチェーンは、既に知っていて素性のわかっている(多くの場合、深く吟味された)参加者によって、ある程度の信頼をおく管理モデルで運用されます。許可型のブロックチェーンは、共通する目標をもちつつ、完全には互いを信用していないグループの中でのセキュアなやりとりを行う場を提供します。参加者の素性が明らかであることで、許可型ブロックチェーンでは、コストのかかるマイニングを必要としない、クラッシュ故障耐性(CFT)やビザンチン故障耐性(BFT)をもつ、従来から存在する合意形成プロトコルを使用することができます。

くわえて、許可型のブロックチェーンでは、参加者が、意図的にスマートコントラクトに悪意のあるコードをもたらすリスクも低くなります。まず第一に、参加者は互いを知っています。そして、アプリケーショントランザクションの発行、ネットワークの設定変更、スマートコントラクトのデプロイといった全ての行動は、ネットワークとトランザクションの種類ごとに設定されたエンドースメントポリシーに従って、ブロックチェーンに記録されます。このため、完全な匿名の場合と異なり、問題ある参加者は簡単に特定され、管理モデルの規定に従ってそのインシデントが処理されることになります。

Smart Contracts¶

Fabricでは「チェーンコード」と呼ばれるスマートコントラクトは、信頼された分散アプリケーションとして動作します。ブロックチェーンとそこで行われるピア間での合意形成によって、チェーンコードのセキュリティや信頼が保たれます。チェーンコードは、ブロックチェーンのアプリケーションのビジネスロジックとなります。

ブロックチェーンプラットフォームでのスマートコントラクトについては、次の三つの重要な点があります。

ネットワーク上では、多くのスマートコントラクトが同時に動作すること
スマートコントラクトは、動的にデプロイされる可能性があること（そして多くの場合では、誰でもデプロイできること）
アプリケーションのコードは、信頼できないもの、場合によっては悪意のあるものとして扱うべきこと

スマートコントラクトに対応している既存のほとんどのブロックチェーンプラットフォームでは、 order-execute (順序付け→実行) アーキテクチャを採用しています。このアーキテクチャでは、合意形成プロトコルは、下記のようになります:

最初に、トランザクションを検証し順序を決定し、それを全てのピアに対して伝播させます
各ピアは、そのトランザクションを逐次的に実行します

この order-execute アーキテクチャは、 Etheruem(PoWベースの合意形成を使用) のようなパブリック・パーミッションレスなプラットフォームから Tendermint・Chain・Quorumのような許可型のプラットフォームに至るまで、既存のほとんど全てのブロックチェーンシステムで使われています。

order-executeアーキテクチャのブロックチェーンで実行されるスマートコントラクトの動作は、決定的(deterministic)でなければなりません。そうでなければ、合意に至ることは不可能であるからです。非決定的動作(non-determinism)の問題に対応するため、多くのプラットフォームでは、スマートコントラクトを書くのに、非決定的操作を排除するために、標準的ではない、あるいはドメイン固有のプログラミング言語 (例: Solidity)を使う必要があります。一方、これによって、スマートコントラクトの開発者はこれらの新しい言語を学ぶ必要があり、プログラムのミスも引き起こす可能性もあり、普及の妨げとなっているという問題があります。

さらには、全てのトランザクションが全てのノードで逐次的に実行されるため、性能もスケーラビリティも限界があります。システム上の全てのノードでスマートコントラクトが実行されるということは、悪意あるスマートコントラクトが実行される可能性を考えて、システム全体を保護するために複雑な対策を必要とすることでもあります。それがなければ、システム全体のレジリエンスを担保することができません。

A New Approach¶

Fabricでは、execute-order-validate (実行→順序付け→検証)と呼ばれる新しいアーキテクチャを導入しました。このアーキテクチャは、order-executeモデルで問題となったレジリエンス、柔軟性、スケーラビリティ、性能と機密性に対応するため、トランザクションのフローを次の3ステップに分割しています。

実行 (execute): トランザクションを実行し、その正しさをチェックし、エンドースを行う
順序付け (order): トランザクションを(プラグ可能な)合意形成プロトコルによって順序を決定する
検証 (validate): トランザクションをアプリケーションごとのエンドースメントポリシーを用いて検証し、台帳にコミットする

Fabricでは、順序が最終的に合意される前にトランザクションを実行します。この設計は、order-executeのパラダイムからは大きく異なるものです。

Fabricでは、スマートコントラクトの実行結果が正しいことを証明するのに、どのピア・ノード、あるいは、いくつのピアが必要であるかを、アプリケーションごとのエンドースメントポリシーで規定します。そのため、各トランザクションの実行は、エンドースメントポリシーを満たすようなピアの部分集合で行われるだけで十分となります。これにより、並列実行が可能となり、システム全体の性能やスケーラビリティを向上させることができます。この最初のフェーズでは、結果が一貫しないものを取り除くことができるため、 非決定的動作を排除 することもできます。

非決定的動作を排除することによって、Fabricは 標準的なプログラミング言語を利用することができる 最初のブロックチェーン技術となりました。

Privacy and Confidentiality¶

前述したように、合意形成モデルにPoWを利用するパブリック・パーミッションレスなブロックチェーンのネットワークでは、トランザクションは各ノードで実行されます。これでは、スマートコントラクトそのものの機密性も、処理するトランザクションのデータの機密性も実現することができません。各トランザクションとそれを実装するコードは、ネットワーク上のすべてのノードから見ることができます。すなわち、PoWによるビザンチン故障耐性の合意形成の代わりに、スマートコントラクトとデータの機密性を失ったということです。

多くのビジネスやエンタープライズのユースケースでは、機密性が保てないことは問題となりえます。例えば、サプライチェーンのパートナーのネットワークにおいては、ある消費者に対して優遇価格を提示することで、関係を強化したりさらなる売上を上げようとすることがあります。もし、全ての参加者が全てのスマートコントラクトやトランザクションを見ることができたら、つまり、完全に透明性のあるネットワークにおいては、そのようなビジネスの関係を維持することは不可能になるでしょう。なぜなら、みなその優遇価格で取引したいと思うからです。

もう一つの例として、証券業界を考えます。あるトレーダーが、ポジションを持とうとする(あるいは処分しようとする)にあたり、そのことを他の同業者に知られたいとは思わないでしょう。さもなければ、同業者がその流れに加わってしまい、そのトレーダーの旨味が損なわれてしまうでしょう。

このエンタープライズのユースケースで要件となるプライバシーと機密性の問題に対応するため、ブロックチェーンプラットフォームは様々なアプローチをとってきました。それぞれのアプローチにはトレードオフがあります。

機密性を保持するための一つのアプローチに、データの暗号化があります。しかし、合意形成にPoWを用いるパーミッションレスのネットワークにおいては、暗号されたデータはすべてのノードに存在することになってしまいます。十分な時間と計算資源があれば、この暗号は解くことができるかもしれません。多くのエンタープライズのユースケースにおいて、情報が漏洩してしまうかもしれないというリスクは受け入れられるものではありません。

この問題に対する別の研究として、ゼロ知識証明(ZKP)があります。 ZKPのトレードオフは、現在のところは、ZKPの計算には相当の時間と計算資源が必要となることです。つまり、ZKPのトレードオフは、機密性と性能、ということになります。

PoW以外の合意形成を用いることのできる許可型においては、許可された(authorized)ノードにのみ機密情報を配布するアプローチを考えることができるかもしれません。

許可型のプラットフォームであるHyperledger Fabricでは、チャネル・アーキテクチャとプライベートデータの機能によって、機密性を実現できます。チャネルを利用することで、Fabricのネットワークの参加者は、サブネットワークを作成することができます。このサブネットワークでは、参加者は特定のトランザクションのみ見ることができます。そのため、チャネルに参加しているノードだけがスマートコントラクト(チェーンコード)とトランザクションのデータにアクセスすることができるため、この二つのプライバシーと機密性を守ることができます。プライベートデータの機能では、チャネルのメンバーの間でコレクションを作成することができ、別のチャネルの作成・維持の管理のオーバヘッドをかけることなく、チャネルの場合とかなり近い保護を実現することができます。

Pluggable Consensus¶

トランザクションのオーダリング(順序付け)は、トランザクションを実行し台帳を管理するピアとは論理的に切り離されている、モジュール化された合意形成コンポーネント、具体的にはオーダリングサービスの役割です。合意形成はモジュール化されているため、それぞれの構成やソリューションに応じた実装を使うことができます。このモジュール化アーキテクチャによって、CFT(クラッシュ故障耐性)やBFT(ビザンチン故障耐性)のオーダリングに既に確立されているツールキットを用いることができます。

Fabricは現在のところ、 Raft プロトコルの etcd ライブラリをベースとしたCFTのオーダリングサービス実装を提供しています。現在利用できるオーダリングサービスについては、オーダリングの概念についてのドキュメントを参照してください。

なお、これらは排他的ではないことに注意してください。一つのFabricのネットワークは、異なるアプリケーションや要件に対応する複数のオーダリングサービスをもつことができます。

Performance and Scalability¶

ブロックチェーンプラットフォームの性能は、トランザクションのサイズ、ブロックのサイズ、ネットワークのサイズ、ハードウェアの制約といった多くの変数によって影響を受けます。 Hyperledger Fabricの Performance and Scale working group は、 Hyperledger Caliper というベンチマークのためのフレームワークに現在取り組んでいます。

Hyperledge Fabricの性能について調査、測定を行った研究論文がいくつかあります。最新のものには、Fabricを毎秒20,000トランザクションまでスケールさせたものがあります。

Conclusion¶

ブロックチェーンプラットフォームに関するまともな評価には、必ずHyperledger Fabricを加えるべきです。

Fabricは、これらの特徴によって、許可型ブロックチェーンのための高いスケーラビリティをもつシステムとなりました。 Fabricは信頼の仮定について柔軟に変更可能であり、それにより、政府から金融、サプライチェーン、ヘルスケア、そのほか多くの幅広い産業のユースケースに対応することができるようになりました。

Hyperledger Fabricは、Hyperledgerのプロジェクトの中で最も活発なものです。このプラットフォームをとりまくコミュニティは着実に成長しており、各リリースによってもたらされるイノベーションは、他のエンタープライズ向けブロックチェーンプラットフォームを凌駕しています。

Acknowledgement¶

この内容は、査読された下記の論文によります。

"Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains" - Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukolic, Sharon Weed Cocco, Jason Yellick