Hyperledger Fabric 2.0 新機能まとめ

Hyperledger Fabric 2.0 新機能まとめ

はじめに

「Hyperledger Fabric」は、もっとも利用されているパーミッション型のブロックチェーンフレームワークです。Fabricの開発初期からIBMが主導的に関わっており、同社の提供するBaaS「IBM Blockchain Platform」をはじめとして、AWS(Amazon)やAzure(Microsoft)、Alibaba、Oracleといった主要なクラウドベンダーが、Fabricをサポートしています。

2020年1月30日、Hyperledger Fabric 2.0がリリースされました。Fabricはすでに数年以上の改善が続けられており、今回のv2.0でもより柔軟な開発ができるような新機能が追加されています。本記事は、Fabric 2.0の主な新機能をピックアップしたものです。

なお、Fabricの概要については別の記事でまとめていますので、そちらをご覧ください。

Hyperledger Fabric 2.0の新機能まとめ

Hyperledger Fabric 2.0へのアップグレードによる大きな変更点としては、チェーンコード(スマートコントラクト)の分散ガバナンスが導入された点です(アーキテクチャの変更はほとんど無い)。その他にも、プライバシーやパフォーマンスの向上など、エンタープライズ向けのフレームワークとして、ニーズに応じた柔軟な開発が可能になっています。

なお、Fabric 2.0へのアップグレードは強制ではなく、従来のバージョンを使い続けることも可能ですし、Fabricをサポートしている主要クラウドも、2020年2月末時点ではv2.0をサポートしていません。

ただ、将来的にサポートされると考えられるため、要点はチェックしておいて損はないでしょう。

スマートコントラクトの分散ガバナンス

v2.0の大きな特徴は、スマートコントラクト向けの分散型ガバナンスが導入されている点です。ポイントを紹介していきましょう。

複数組織によるチェーンコードのパラメータへの合意を必須にできる

Fabric v1.xでは、チャネルに複数の組織が存在する場合でも、ひとつの組織のみがチェーンコードのパラメータを設定する仕様になっていました。ほかの組織は、チェーンコードのパラメータ(Endorsement Policyやプライベートデータコレクションなど)を検証し、その妥当性について判断することができなかったのです。

一方で、v2.0ではチェーンコードがチャネルでアクティブになる前に、充分な数のメンバーからの承認を必要とするようなEndorsement Policyを設定できるようになりました。なお、従来通りの集中型ガバナンスを採用するか、分散型ガバナンスを採用するかは任意です。

チェーンコードのアップグレードプロセスにも複数組織による合意を必須にできる

以前のライフサイクルでは、権限のある組織がチェーンコードのアップグレードを行うモデルでしたが、v2.0ではアップグレードに複数の組織による合意を必要とする設定も可能になっています。

Endorsement Policyとプライベートデータコレクションの設定更新がシンプルに

v2.0ではチェーンコードを再インストール(または再パッケージ化)せずに、Endorsement Policyやプライベートデータコレクションの構成を変更できるようになりました。また、特に設定を行わない場合、デフォルトのEndorsement Policy(チャネル上に存在する組織の過半数)が適用されることになり、組織が追加(削除)された場合の再定義が不要になっています。

検査可能なチェーンコードパッケージ

チェーンコードがtarファイルにパッケージ化されたため、チェーンコードパッケージの検査と複数の組織にわたるインストールの調整コストが削減されます。

ひとつのパッケージで複数のチェーンコードをスタートできるように

従来のライフサイクルでは、各チェーンコードはチャネルメンバー間で同一のパッケージをインストールしている必要がありました。一方でv2.0では、ひとつのチェーンコードパッケージのみを使用して、別名のチェーンコードを複数デプロイできるようになっています。

チェーンコードの拡張性

v2.0では、ユーザーは自社独自のユースケースに応じてチェーンコードを拡張することができます。例えば、組織は独自の検証用チェーンコードを実装可能です。ゆえに、ネットワーク全体をリスクにさらすことなく、事業者が独自のスケジュールでチェーンコードのマイナーアップデートをデプロイできます。

新たなチェーンコードアプリケーションパターン

v2.0では分散台帳にコミットする前に、組織がトランザクションを検証するように設定可能です。

プライベートデータの機能強化

プライベートデータの共有と検証

プライベートデータが、コレクションのメンバーではないチャネルメンバーに共有された場合や、別のチャネルのコレクションデータが共有された場合、受信者がGetPrivateDataHashというチェーンコードAPIを叩くと、当該データが分散台帳上のデータと一致するかどうかを確認できます。

Collection-Level Endorsement Policy

v2.0では、プライベートデータコレクション単位でEndorsement Policyの設定ができるようになりました。これによって例えば、「チェーンコードの場合は全組織の過半数の合意が必要だが、プライベートデータコレクションの変更には、組織AとBの両方の同意が必要」といった設定が可能になります。

暗黙のper-organization collections

v2.0では、組織単独のプライベートデータの場合、デプロイするときにコレクションを事前定義しなくても良くなりました。

外部のチェーンコードランチャー

v2.0からは、Dockerコンテナ以外の稼働環境も選べるようになっています(Docker daemonの依存関係の排除)。また、コンテナ以外でチェーンコードを実行できるようになり、従来ピアによってローンチされていましたチェーンコードが、外部サービスとして実行できるようになりました。

Raftコンセンサス

v2.0ではOrdering Serviceのうち、SoloとKafkaコンセンサスは非推奨となっています。したがって、Raftの利用が推奨されています。

そのほかの詳細については、ドキュメントをご覧ください。

参考:What’s new in Hyperledger Fabric v2.0

まとめ:チェーンコードの分散ガバナンスやプライバシー強化が特徴のv2.0

従来のバージョンでは、チェーンコードのパラメータ設定に関する権限がひとつの組織にのみ集中していました。それに対して、v2.0ではチェーンコードがチャネル上で有効になる前に、複数の組織による合意が必須となる設定が可能になるなど、分散ガバナンスの機能が強化されました。

また、データプライバシーに関しても強化、あるいは柔軟性が向上しています。

v2.0へのアップグレードによって、エンタープライズ向けのフレームワークとして必要不可欠な安全性とプライバシーが向上したと言えるでしょう。

建設業におけるブロックチェーン活用方法とは?

CTA-IMAGE 【ホワイトペーパー】建設業における業務変革をテーマに、業界の課題に対してブロックチェーンを活用する方法を紹介します。

ブロックチェーンカテゴリの最新記事