はじめに

ブロックチェーンスタジオでは、アップデートの早いブロックチェーンの基盤に関する情報収集に積極的に取り組んでいます。今回は、その一環として2/19に開催されたHyperledger Tokyo Meetupに参加してきました！

前回のHyperledger Tokyoから約半年経っており、Hyperledgerプロジェクトの中で注目されているHyperleger Fabricのバージョンもv1.2からv1.4に上がっていたため、今回は、バージョンアップによる機能追加の情報や、研究内容の紹介、および事例紹介と面白かったです。また、ブロックチェーンの勉強会にしては、顔ぶれが大きく違っており、大手の方中心だったのも印象的でした。

今回は、全セッションのうち、Hyperledger Fabric Weather Reportについて簡単に紹介していきたいと思います。

Hyperledger Weather Report 2019/02/19

このセッションでは、Hitachi America, Ltd. で実際にHyperledger Fabricの開発に携わっている方から、Hyperleger Communityの変遷とHyperleger Fabricのアップデートによる機能追加に関する紹介がありました。この内容については、3つに分けて紹介したいと思います。

Hyperledger Communityの状況

まず、Hyperledger Communityについてですが、この半年で組織変更とプロジェクトの追加、およびカンファレンスの体制変更があったそうです。

特に、組織変更による影響でTSCがIntelへ移った影響なのか、Intel主導のブロックチェーンサービスをHyperledger Projectで開発するというのは個人的に驚きました。ちなみに、追加されるプロジェクトは以下の2つです。

• Hyperledger Grid:
  Intel主導のHyperledger Sawtoothを利用したWebAssemblyベースのサービス開発プロジェクト
• Hyperledger URSA:
  富士通主導のHyperledgerプロジェクト全体で利用できる暗号化ライブラリの開発プロジェクト

Hyperledgerプロジェクトについては、Irohaのように他のブロックチェーンとは違って日本企業が主導権を握っているところが面白いですね。

Hyperledger Fabricの現状

Hyperledger Fabricの現状で、一番大きいニュースは、LTSをサポートしたことですね！ただし、1年間限定な上、プロジェクトに張り付いたメンテナーではなく、有志が修正するらしいですが・・・
また、v1.2からv1.4へアップデートしたことにより、大きく以下の機能が追加(一部予定)されたそうです。

• 運用管理用プロトコルの追加：
  運用管理用の機能として、ノードの稼働監視をするためにPrometheusプロトコル対応の監視ツールを用いてヘルスケア等の情報を取得することができる機能が追加されたそうです。Hyperledger Fabric自体、組織を跨った運用等を想定されること、ノードが死ぬと復旧とネットワーク維持が難しいことが課題にあったので、少しでも監視機能が実装されるとありがたいですね。ちなみに、Hyperledger Explorerとの関係はどうなるのだろうか・・・と少し疑問もあります。
• High Level APIの追加：
  こちらは、Hyperleger Composerが提供する予定だったWallet等の機能が活用できるHigh Level APIを利用してアプリケーションを開発できるようになるそうです。これにより、Ethereumのようにトークンを用いるようなアプリケーション開発のコストの削減が見込めるようになります。また、既存のKVS用のLow Level APIについても今まで通りサポートされるそうです。トークンを使う場合と使わない場合で利用するAPIの選択肢や簡易化がされるのはありがたいですね。
• Side DB(Enhancements in Private Data)の追加
  このSideDBについては、Hyperledger Fabric特有の機能や問題を知っておかないと理解が難しいのですが、チェーンの中に運用に応じて動的に値を書き換えることができる機能が追加されたという点です。Hyperledger Fabricは、ネットワーク内でコンソーシアムを組めるチャンネルという機能があり、このチャンネルごとにノード内のKVSの値をテーブルに分けて保存しています。このため、他のチャンネルに流れないようにブロック情報を他のノードへ転送したりする処理の実装が遅れていたのですが、この機能の追加により、後から参加したノードであっても自動的にブロックを追従できるようになったとのことです。また、KVSの容量を圧迫するためブロックの削除を実施する機能もあるのですが、こちらについは時間区分で削除されるので、未だに使い物にならないそうです。
• Ordererの冗長化(v1.4.1で追加予定)
  Ordererの運用や冗長化については、Kafkaクラスタを組んで、Ordererを運営する組織が冗長化対策をして維持する必要があったのですが、Raftを用いてクラスタ内で冗長化を行うことができるようになるそうです。Raftについては、このWikiのアニメーションが分かりやすいので参照してください。

Hyperledger Fabric2.0のWeather Report

これについては、開発者の完全な予測らしいですが、JIRAに上がっているチケットから、4月にリリース予定の2.0で実装されそうな内容についてピックアップして紹介していただけました。内容については、以下の通りです。

• Chaincodeのデプロイサイクルの変更
• 運用管理用プロトコルの拡充
• Chaincodeのプログラミングモデルの変更
• UTXOの採用
• 互換性を削除

このうち、Chaincodeのプログラミングモデルの変更については、High Level APIでのプログラミングモデルで可能なことを増やしていくということらしいです。ただ、基盤がGoで記述されているため、Low Level APIについても再利用して利用できるだろうと予想しているとも説明していました。また、プログラミングモデルの変更を主導している人たちの影響により、対応言語がNode.js、Java、Goの順になっていくと予想していました。また、互換性についてですが、2.0は完全に1.xとは互換性を切るらしく、1.xで運用していると変更点が多くてアップデートできずになくなってしまうサービスもありそうですね。

おわりに

個人的には、久しぶりにHyperleger Fabricの情報を知ることができて楽しかったです。ただ、Hyperledger Fabricは、パブリックブロックチェーンとは異なり、分散台帳的な利用シーンでの適用を考えるのに向いていたので、Ethereumと似ていくような方向性への変化は残念だなと思いました。

また、今回紹介しなかったセッションも一部資料が上がっており、技術的に面白い内容もあったので他の記事で紹介できると良いかなと思います。