What's new in Hyperledger Fabric v2.x¶

What's New in Hyperledger Fabric v2.5¶

Purge history of private data¶

ステートデータからプライベートデータを削除することは以前から可能でしたが、この新機能により、ブロックチェーン上に不変の証拠としてプライベートデータのハッシュを保存しつつ、ピアからプライベートデータの履歴を「パージ」(消去)することができるようになります。

プライバシー上の理由や政府の規制を遵守するために、プライベートデータを必要に応じて消去したい場合に便利です。
ブロックイベントや他のピアからプライベートデータを照会できないように、ステートデータとピアのプライベートデータ履歴からプライベートデータを削除します。
新しいchaincode API PurgePrivateData() として利用可能です。
本機能を利用するには、チャネルのコンフィギュレーションにて、Applicationケイパビリティを V2_5 に設定する必要があります。

詳細については、Private data を参照してください。

Multi-architecture binaries and docker images are now available¶

リリースバイナリおよび Docker イメージが以下のようにアップデートされました:

amd64 および arm64 をサポート。
リリースバイナリは移植性を高めるために静的にリンクされています。
Dockerイメージは動的にリンクされたバイナリを使用し、（Alpineではなく）Ubuntuをベースにすることで、一般的な本番環境との整合性を高めています（本番環境は一般的にglibcをベースとしており、HSMモジュールの動的リンクを必要とすることがよくあります）。

注釈

Fabric v2.5.x は最新の長期サポート(LTS)リリースです。以前のLTS (Fabric v2.2.x) リリースからの単純なインプレースアップグレードが可能です。

What's New in Hyperledger Fabric v2.4¶

Fabric Gateway¶

Fabric Gatewayはピアノード上で動作する新しいサービスで、クライアントアプリケーションのトランザクション送信および処理を代行します。次のような利点があります:

クライアントアプリケーションとSDKの簡素化 - クライアントアプリケーションは、信頼できるピアにトランザクションの送信を委任するだけでよく、他組織のピアノードやOrdererノードへの接続を行う必要はありません。
Fabric Gatewayは、クライアントアプリケーションに代わって、他組織に対しトランザクションの承認を依頼し、Ordererサービスへの送信を実行します。
Fabric Gatewayは、あなたのソリューションがチェーンコードレベルのエンドースメントポリシー、プライベートデータ収集エンドースメントポリシー、ステートベースのエンドースメントポリシーを組み合わせて利用する場合でも、与えられたトランザクションに必要なエンドースメントを決定するインテリジェンスを持っています。

Node、Java、Go用の新しい軽量な Gateway SDK（v1.0.0）が利用可能です。SDKは柔軟なアプリケーションパターンをサポートします:

以前のバージョンのSDKと同様、高レベルプログラミングモデルを利用でき、アプリケーションは SubmitTransaction() 関数のみを呼び出せばよいだけです。
より高度なアプリケーションは、Gatewayに対しトランザクション送信のための Endorse、Submit、CommitStatus 各サービスと、クエリのための Evaluate サービスを個別に実行できます。
トランザクションのエンドースメントを完全にゲートウェイに委任することもできるほか、必要であればエンドースする組織を指定すると、Gatewayは指定された組織のピアを利用します。

詳細については、Fabric Gateway を参照してください。

Peer node unjoin¶

チャネルが不要になった際に、ピアをチャネルから除外できるようになりました。全てのチャネルリソースがピアから削除され、ピアはチャネルからのブロックを処理しなくなります。

詳細については、 peer node unjoin command reference topic を参照してください。

Calculate package ID of a packaged chaincode¶

新しい`peer lifecycle chaincode calculatepackageid`コマンドを使えば、ピアにチェーンコードをインストールすることなく、パッケージ化されたチェーンコードからパッケージIDを計算することができます。このコマンドは例えば以下のような場面で役に立ちます:

同じラベル名の複数のチェーンコードパッケージがインストールされている場合、どの ID がどのパッケージに対応するかを後で識別できます。
特定のチェーンコードパッケージがインストールされているかどうかを、そのパッケージをインストールすることなくチェックできます。

詳細については、 peer lifecycle chaincode calculatepackageid command reference topic を参照してください。

What's New in Hyperledger Fabric v2.3¶

Hyperledger Fabric v2.3では、Ordererとピアの操作を改善する2つの新機能が導入されました。

Orderer channel management without a system channel¶

チャネル作成プロセスを簡素化し、チャネルのプライバシーとスケーラビリティを強化するため、 Ordererサービスによって管理される「システムチャネル」を最初に作成することなく、アプリケーションチャネルを作成できるようになりました。このプロセスによりOrdererは、ピアが複数のチャネルに参加できるのと同様に、必要に応じて任意の数のチャネルに参加（または離脱）することができます。

新プロセスの利点:

プライバシーの向上: すべてのOrdererノードはシステムチャネルに参加していたため、ネットワーク上のすべてのOrdererノードは、そのOrdererサービス上のすべてのチャネルの存在を知っていました、今後は、Ordererノードが知っているのは自分が参加しているチャネルのみとなります。
スケーラビリティ: Ordererノードとチャネルがシステムチャネルに多数定義されている場合、 Ordererノードがすべてのチャネルのメンバーシップについてコンセンサスを得るのに長い時間がかかることがあります。今後は、OrdererサービスがOrdererノードを特定のチャネルに独立して参加させることで、分散化された方法で横展開することができます。
運用上の利点
- Ordererノードをチャネルに参加させるためのプロセスを簡易化します。
- Ordererノードが同意者であるチャネルをリストアップできます。
- Ordererノードからチャネルを削除し、そのチャネルに関連するブロックを自動的にクリーンアップするプロセスを簡易化します。
- ピア組織は、MSPを作成または更新するために、システムチャネルの管理者と調整する必要はありません。

詳細については、 Create a channel を参照してください。

Ledger snapshot¶

ステートデータベースを含むピアのチャネル情報のスナップショットを取得し、スナップショットに基づいて新しいピア（同じ組織または異なる組織）をチャネルに参加させることが可能になりました。

台帳スナップショットを使うことには、次のような利点があります:

ピアはジェネシスブロック以降の全ブロックの処理が不要: ピアは、ジェネシスブロック以降の過去のブロックをすべて処理することなくチャネルに参加できるため、既存のチャネルにピアを参加させるのに要する時間が大幅に短縮されます。
ピアは最新のチャネル設定を使用してチャネルに参加可能: スナップショットには最新のチャネル構成が含まれているため、ピアは最新のチャネル構成を使用してチャネルに参加できるようになりました。これは、OrdererエンドポイントやTLS CA証明書のような重要なチャネル構成が、ジェネシスブロック生成以降に更新された場合に特に重要です。
ストレージコストの削減: スナップショットを用いて参加するピアは、ジェネシスブロック以降のすべてのブロックを維持するためのストレージコストが発生しません。
ステートチェックポイント: ピア管理者は現在のチャネルのステートをスナップショットし、同じ組織内または異なる組織内の他のピアと比較することで、各ピアの台帳の一貫性と整合性を検証できます。合意されたスナップショットは、新たに参加するピアのチェックポイントおよび起点として使用できます。

詳細については、 Taking ledger snapshots and using them to join channels を参照してください。

注釈

Fabric v2.3.0 は新機能を導入していますが、次のLTSリリースが発表されるまでは、 Fabric v2.2.x が現在の長期サポートリリースとなります。

What's New in Hyperledger Fabric v2.0, v2.1, v2.2¶

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

v2.1およびv2.2は、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ファイルにパッケージします。これによってチェーンコード・パッケージの中身を検査し、複数組織間でのインストールを調整することが容易になります。
一つのチャネルで、同じパッケージを使って複数のチェーンコードを起動すること: 以前のライフサイクルでは、チェーンコードのインストール時に指定する名前とバージョンによって、各チャネルでチェーンコードが定義されていました。新しいライフサイクルでは、同じ一つのチェーンコードパッケージで、同じチャネルあるいは異なるチャネルで異なる名前で複数回デプロイすることが可能になります。例えば、異なる種類の資産のトラックを、同じチェーンコードをそれぞれの種類ごとに「コピー」して行いたいときです。
チェーンコードのパッケージはチャネルメンバーの中で同一である必要がないこと: 各組織は、例えば、組織の関心に応じて異なる検証を行うなど、チェーンコードを組織のユースケースに応じて拡張することができます。必須とされている数の組織が、チェーンコードのトランザクションと同一の結果がエンドースしていれば、そのトランザクションは検証ののち台帳にコミットされます。また、各組織が、自分のスケジュールで、小規模の修正を個別にロールアウトすることも可能になります。ネットワーク全体で足並みをそろえて行う必要はありません。

すでにデプロイされている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へのローリングアップグレードはサポートされていますので、ネットワーク内のコンポーネントはダウンタイムなしに順次アップグレードすることができます。また、v1.4.x LTS リリースから v2.2.x LTS リリースまたは v2.5.x LTS リリースに直接アップグレードすることもできます。

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

Release notes¶

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