What's new in Hyperledger Fabric v2.x

v1.0以来のメジャーリリースである、Hyperledger Fabric v2.0は、 ユーザーおよび運用者に重要な新機能と変更を提供します。 これは、新しいアプリケーションとプライバシーに関するパターンのサポート、スマートコントラクトの 管理の強化、ノード運用の新しいオプションなどを含んでいます。

v2.xのマイナーリリースは、v2.0に対して、小規模の機能追加・改善・バグフィックスを行ったものになります。

v2.2は、Fabric v2.xの最初の長期サポート(LTS)リリースです。 次のLTSのリリースがアナウンスされるまで、v2.2.xのストリームで修正が提供される予定です。

それでは、Fabric v2.0リリースのハイライトをいくつか見ていきましょう。

Decentralized governance for smart contracts

Fabric v2.0では、スマートコントラクトの非中央集権的な管理が導入されます。 これに伴い、チェーンコードのピアへのインストール、チャネルでの利用開始するときの手順が新しくなります。 新しいFabricのチェーンコード・ライフサイクルでは、エンドースメントポリシーといった チェーンコードのパラメータについて、複数の組織が合意することができます。 こののち、台帳とのやり取りのためにそのチェーンコードが使用できるようになります。 この新しいモデルは、以前のライフサイクルに比べると、以下のような改善点があります。

  • 複数の組織がチェーンコードのパラメータについて合意していなければならないこと: Fabricのバージョン 1.x では、一つの組織が、他の全てのチャネルのメンバーにも適用される チェーンコードのパラメータ(例えば、エンドースメントポリシー)を設定することができました。 他の組織は、チェーンコードをインストールすることを拒否して、それによって、そのチェーンコードを 呼び出すトランザクションに関与しないようにすることしかできませんでした。 新しいFabricのチェーンコード・ライフサイクルはもっと柔軟であり、中央集権的な信頼モデル (例えば、以前のライフサイクルの場合のもの)も、チェーンコードがあるチャネルで有効になる前に、 エンドースメントポリシーやそのほかの詳細について、十分な数の組織の合意を必要とする非中央集権的なモデルもサポートしています。
  • より慎重なチェーンコードのアップグレード手順: 以前のチェーンコードライフサイクルでは、アップグレードのトランザクションは、一つの組織から発行することができたため、 新しいチェーンコードをまだインストールしていないチャネルのメンバーに対するリスクがありました。 新しいモデルでは、チェーンコードのアップグレードは十分な数の組織が承認した場合にのみ行う、ということができます。
  • よりシンプルなエンドースメントポリシー・プライべートデータコレクションのアップデート: Fabricのライフサイクルでは、エンドースメントポリシーやプライベートデータコレクションの設定の変更を、 チェーンコードのパッケージ再作成や再インストールなしに行うことができます。 ユーザーは、過半数の組織からのエンドースメントを必要とする、という新しいデフォルトのエンドースメントポリシーを 活用することもできます。このポリシーは、組織が追加・削除されたときに、自動的に更新されます。
  • 検査可能なチェーンコードパッケージ: Fabricのライフサイクルでは、チェーンコードを、簡単に読むことのできるtarファイルにパッケージします。 これによってチェーンコード・パッケージの中身を検査し、複数組織間でのインストールを調整することが 容易になります。
  • 一つのチャネルで、同じパッケージを使って複数のチェーンコードを起動すること: 以前のライフサイクルでは、チェーンコードのインストール時に指定する名前とバージョンによって、 各チャネルでチェーンコードが定義されていました。 新しいライフサイクルでは、同じ一つのチェーンコードパッケージで、同じチャネルあるいは異なるチャネルで 異なる名前で複数回デプロイすることが可能になります。 例えば、異なる種類の資産のトラックを、同じチェーンコードをそれぞれの種類ごとに「コピー」して行いたいときです。
  • チェーンコードのパッケージはチャネルメンバーの中で同一である必要がないこと: 各組織は、例えば、組織の関心に応じて異なる検証を行うなど、 チェーンコードを組織のユースケースに応じて拡張することができます。 必須とされている数の組織が、チェーンコードのトランザクションと同一の結果がエンドースしていれば、 そのトランザクションは検証ののち台帳にコミットされます。 また、各組織が、自分のスケジュールで、小規模の修正を個別にロールアウトすることも可能になります。 ネットワーク全体で足並みをそろえて行う必要はありません。

Using the new chaincode lifecycle

すでにデプロイされているFabricでは、Fabric v2.xでも以前のチェーンコード・ライフサイクルを 使い続けることができます。 新しいチェーンコード・ライフサイクルは、チャネルのアプリケーション・ケーパビリティがv2.0に アップデートされたときにのみ有効になります。 新しいチェーンコード・ライフサイクルの概要については、Fabric chaincode lifecycle のトピックを参照してください。

New chaincode application patterns for collaboration and consensus

新しいチェーンコードライフサイクルを支えている合意に至るための非中央集権的な方法と同じ方法を、 チェーンコードアプリケーションでも、 組織の同意を得てからデータ・トランザクションが台帳にコミットされるよう保証するために使うこともできます。

  • 自動的なチェック: 上記でも述べたように、各組織はチェーンコードの関数に、トランザクション提案をエンドースする前に 追加の情報の検証を行う自動的なチェックを加えることができます。
  • 非中央集権的な合意: 人間による決定プロセスを、複数のトランザクションにまたがるチェーンコードのプロセスにモデル化することができます。 そのようなチェーンコードは、様々な組織のアクターに対して、合意の契約条件を台帳へのトランザクションで 示すことを要求するかもしれません。 そして、最後のチェーンコード提案で、各トランザクション発行者の条件を満たしていることを確かめ、 チャネルのメンバー間での商取引の最終的な「解決」とすることができるでしょう。 非公開で契約条件を示す例については、Private data のドキュメントの資産移動のシナリオを 参照してください。

Private data enhancements

Fabric v2.0は、トランザクションが関与する全てのチャネルメンバーの組み合わせのプライベートデータ・コレクションを 作る必要なく、プライベートデータを扱い共有する新しいパターンを可能にします。 具体的には、プライベートデータを、複数のメンバーからなる一つのコレクションの中で共有するのではなく、 一つの組織や、あるいは一つの組織と規制機関や監査機関からなるような複数のコレクションにわたって 共有することができます。

この新しいプライベートデータのパターンは、Fabric v2.xでの以下の機能強化によって可能になっています。

  • プライベートデータの共有と確認: プライベートデータが、コレクションのメンバーではないチャネルメンバーと共有されるとき、 もしくは、一つまたは複数のチャネルメンバーを含むプライベートデータコレクションとで (そのコレクションのキーに書き込むことで)共有されるとき、 受け取った側は、チェーンコードAPIである GetPrivateDataHash() を使うことで、 プライベートデータが、チェーン上に存在している、過去のトランザクションでプライベートデータから作られたハッシュ値と 一致することを確認することができます。
  • コレクションレベルのエンドースメントポリシー: プライベートデータ・コレクションは、コレクション内のキーに対して、チェーンコードレベルのエンドースメントポリシーを オーバーライドするエンドースメントポリシーを新たに定義することができます。 この機能は、コレクションに対して書き込む組織を制限するのに使うことができ、上記で述べたチェーンコードライフサイクルや チェーンコードアプリケーションのパターンを可能にするものでもあります。 例えば、チェーンコードレベルのエンドースメントポリシーでは、過半数の組織によるエンドースを必要としつつ、 あるトランザクションについては、プライベートデータコレクションでの合意についてそれぞれがエンドースするように、 二つの関係する組織を必要とすることもできます。
  • 暗黙的な組織ごとのコレクション: もし組織ごとのプライベートデータのパターンを使いたいのであれば、 チェーンコードのデプロイ時にコレクションを定義する必要すらありません。 暗黙的な組織独自のコレクションは、特に前もって定義する必要なく使うことができます。

プライベートデータのパターンについて知りたいときは、Private data (概念の解説ドキュメント) を参照してください。 プライベートデータ・コレクションの設定や暗黙的なコレクションについては、Private Data (リファレンス) を参照してください。

External chaincode launcher

外部チェーンコード・ランチャーの機能は、運用者が、好きな技術を使ってチェーンコードをビルド・起動できるように するものです。 デフォルトの挙動は、以前のリリースと同様に、Docker APIを用いてチェーンコードをビルド・起動するもので、 外部ビルダーとランチャーは必須ではありません。

  • Dockerデーモンへの依存の削除: 以前のFabricリリースは、チェーンコードのビルドと起動のために、ピアがDockerデーモンに対して アクセス可能である必要がありました。 これは、ピアプロセスに対して特権を与えることが必要になり、本番環境では好ましくないかもしれません。
  • コンテナに対する代替: チェーンコードは、Dockerコンテナとして起動する必要がなくなり、運用者の都合のよい環境 (コンテナを含む) で動かすことができるようになりました。
  • 外部ビルダー実行可能ファイル: 運用者は、外部ビルダー実行可能ファイル群を与えることで、 ピアがチェーンコードをビルドし起動する方法をオーバーライドすることができます。
  • 外部チェーンコードサービス: 従来は、チェーンコードはピアによって起動され、チェーンコードがピアに接続を行うするというものでした。 このリリースで、チェーンコードを外部サービスとして起動することが可能となりました。 例えば、ピアから接続しチェーンコードの実行に利用できるKubernetesのpodなどです。 より詳細は、Chaincode as an external service を参照してください。

外部チェーンコードランチャーの機能の詳細については、External Builders and Launchers を参照してください。

State database cache for improved performance on CouchDB

  • CouchDB を外部ステートデータベースとして利用するとき、エンドースメントや検証のフェーズでの 読み込みの際の遅延(delay)は以前から性能のボトルネックとなっていました。
  • Fabric v2.0では、新しいピアのキャッシュによって、処理の重い参照の多くを、高速なローカルキャッシュからの読み込みに 置き換えます。キャッシュのサイズは、core.yamlのプロパティである``cacheSize``で設定することができます。

Alpine-based docker images

v2.0から、Hyperledger FabricのDockerイメージは、セキュリティを重視した軽量なLinuxディストリビューションである Alpine Linuxを使用します。 これにより、Dockerイメージがよりはるかに小さくなるため、ダウンロードと起動速度が向上し、ホストのディスク使用量も 削減されます。 Alpine Linuxは、最初からセキュリティを考慮してデザインされており、Alpineディストリビューションの ミニマリストな性質は、セキュリティ脆弱性のリスクを大幅に減らします。

Sample test network

新しいFabricのテストネットワークが、fabric-samplesのレポジトリに含まれるようになります。 このネットワークは、アプリケーションやスマートコントラクトを簡単にテストすることができる モジュール化され、かつ、ユーザーフレンドリーなFabricのサンプルネットワークとなるように 作られています。 また、このネットワークは、cryptogenに加えて、認証局(CA)を用いたデプロイもサポートしています。

このテストネットワークについての詳細は、 Using the Fabric test network を参照してください。

Upgrading to Fabric v2.x

新しいメジャーリリースでは、新たにいくつかアップグレード時に注意すべき点があります。 でも大丈夫です。v1.4.xからv2.0へのローリングアップグレードはサポートされていますので、 ネットワーク内のコンポーネントはダウンタイムなしに順次アップグレードすることができます。

アップグレードに関するドキュメントは、大幅に書き直され拡充されており、Upgrading to the latest release に一か所にまとめられています。 ここでは、Upgrading your componentsUpdating the capability level of a channel 、 また、特に各v2.xへのアップグレード時の注意すべき点 Considerations for getting to v2.x といったドキュメントを見ることができます。

Release notes

リリースノートには、ユーザーが新しいリリースに移行する際の詳細な情報があります。 特に、各v2.xのリリースにおける変更点や非推奨となった項目のアナウンスには目を通しておきましょう。