3か月Hyperledger Fabricを使用してみてわかったこと

PS/SLの佐々木です。

私のSLでは今年度から新しい技術開発に関する取り組みを行っており、私は3か月間Hyperledger Fabricについて、技術やユースケースの調査を行ってきました。

昨年まではEthereumやPolygonというパブリックチェーンを扱っていたため、これらのチェーンとの違いについてもご紹介できればと思います。（Hyperledgerの技術的な細かい話はしません）

Hyperledger Fabricとは

Hyperledger Fabricは、Linux Foundationが主導するHyperledgerプロジェクトの一環として開発された、エンタープライズ向けのオープンソースブロックチェーンフレームワークです。

Hyperledger Fabricの最大の特徴は、ネットワークへの参加が許可制であるという点です（パーミッション型ブロックチェーン）。

「ネットワークに参加する」というのは、ブロックチェーンノードを立てたり、スマートコントラクトをデプロイすることを指します。

例えば、Ethereumであれば、Gethを使うことで誰でもEthereumノードを立て、Ethereumネットワークのトランザクションを閲覧したり、トランザクションを発行してEthereumのワールドステートを変更することができます。

一方、Hyperledger Fabricではネットワーク参加に許可が必要なため、誰でもネットワーク内のトランザクションを閲覧したり、データを見ることはできません。

さらにもう1つの特徴は、ブロックチェーン上にデプロイされているアプリケーション（Chaincodeと呼びます）がGo、Java、Node.jsといった複数のプログラミング言語をサポートしている点です。これは、エンジニアにとって学習コストが低く、非常に嬉しいポイントです。

Hyperledger Fabricのユースケース

• サプライチェーン管理

  サプライチェーンにおける製品や原材料の追跡が容易になり、取引の透明性を確保するために使用されます。例えば、食品業界や製造業における物流プロセスで、各段階の情報をリアルタイムで追跡し、データを一元管理することが可能です。

• 金融業界

  金融機関間での取引をスムーズかつセキュアに実行するため、Hyperledger Fabricが活用されています。従来のシステムでは確認作業や取引処理に時間がかかりますが、分散型台帳を活用することでリアルタイムかつ正確に記録が残り、信頼性の高い取引が可能になります。

• ヘルスケア

  医療記録の管理や患者データのセキュアな共有にも利用されます。Hyperledger Fabricのパーミッション型ネットワークは、医療データのプライバシーを確保しつつ、必要な医療機関や関係者が適切なアクセス権を持って情報を参照できる環境を提供します。

• トレーサビリティ

  製品の起源や移動履歴の追跡に利用されます。特に農業や飲料業界において、製品の品質管理や法的要件への準拠に役立っています。

このように、Hyperledger Fabricはエンタープライズ領域で広く利用されています。ブランド企業が自社製品の品質保証を強化し、付加価値をつけるためにトレーサビリティ管理を行うケースや、カーボンクレジットの算出をサポートする目的で活用されている事例もあります。

EthereumやPolygonとの違い

• ネットワークモデル

  Hyperledger Fabricはパーミッション型ブロックチェーンで、ネットワークに参加するノードは許可制です。一方、EthereumやPolygonはパブリックブロックチェーンであり、誰でも参加できるオープンなネットワークです。

• コンセンサスメカニズム

  Fabricはさまざまなコンセンサスアルゴリズムをサポートし、ネットワークに応じた柔軟な合意形成が可能です。対して、EthereumやPolygonはProof of Stake（PoS）やProof of Work（PoW）といった公開型コンセンサスメカニズムに依存しています。

• スマートコントラクト

  Fabricではスマートコントラクトを「チェーンコード」と呼び、Go、Java、Node.jsなど複数の言語をサポートしていますが、Ethereumでは基本的にSolidityを使用します。PolygonはEthereumのスマートコントラクト処理速度を向上させるLayer 2ソリューションとしての役割が強調されています。

• トークンのサポート

  PolygonはEthereumと同様にネイティブトークンの発行が容易です。しかし、Hyperledger Fabricはトークン発行を基本機能としておらず、主に企業内取引やデータ管理に焦点を当てています。

EthereumやPolygonのようなパブリックチェーンでは、既存のネットワークのルールに従い、開発を行っていく形になりますが、Hyperledger Fabricは自分たちの要件に合わせてネットワークの設計が可能です。これは柔軟性を提供する一方で、設計にあたっては慎重な検討が必要になります。

Hyperledger Fabricのメリット

Hyperledger Fabricを使う最大の理由は、ネットワーク参加者を限定できる点です。エンタープライズ環境では、許可なしにすべてのトランザクションデータが公開されることは受け入れがたい場合があります。また、有事の際にネットワークを制御できる可能性を残している点も大きなメリットです。

さらに、コンソーシアム内でもデータの公開範囲を制限したり、MSP（Membership Service Provider）を用いてユーザーの権限を詳細に管理することができ、エンタープライズソリューションに必要な機能が充実しています。

また、パブリックチェーンよりもトランザクション処理能力が高く、スケーラビリティが優れているため、より高い非機能要件を満たすことができます。

Hyperledger Fabricのデメリット

1つ目のデメリットは、ネットワーク構築の複雑さです。柔軟なアーキテクチャを持つ一方で、導入や構築には専門的な知識が必要です。また、管理者が存在しない前提で設計するため、設計初期の判断が非常に重要であり、不確実性が高くなります。

2つ目は費用です。コンソーシアムチェーンの場合、最低2ノード以上が必要であり、これにはサーバーコストや運用コストがかかります。（Amazon Managed Blockchainの試算では、商用利用の場合、最低20万円以上かかるケースが多いです）

さらに、真の分散型を目指すパブリックチェーン界隈からは、2ノード程度のネットワークをブロックチェーンと呼べるのか、という意見もあるのが現状です。

Hyperledger Fabricの開発方法

Hyperledger Fabricを開発で使用する場合にはネットワークレイヤーの設計をするメンバーとアプリケーションレイヤーの設計をする人に分けるべきかと思います。

私はアプリケーションレイヤーの人間なので今回はアプリケーションレイヤーの開発方法を紹介します。

パブリックチェーンで開発を行う場合にはローカルにブロックチェーンネットワークを展開できるライブラリが用意されていたり、testnetと呼ばれる検証用のチェーンをEthereum Polygonそれぞれ用意していることが多いためそれらを使用します。

Hyperledger Fabricの場合には簡易的なネットワークを構築するシェルスクリプトが用意されているためネットワークはそちらを利用させていただきます。

Chaincodeや認証のための秘密鍵などはチーム開発の場面では自分たちのリポジトリに切り出したいことが多いと思いますので、私たちのチームでは以下のようなリポジトリを作成して開発を行いました。

サンプルは公開されているので興味のある方は触ってみてください。

https://tech-lab.sios.jp/archives/42794

https://github.com/atomic-kanta-sasaki/hyperledger-fabric-application

コンソーシアムチェーンの難しさ

コンソーシアムチェーンを運用している実例ではどこかの企業が複数ノード運営しているケースや開発ベンダーがネットワーク内のノードを面倒見ているケースも多いようで真に分散しているネットワークを目指すうえではまだまだ課題があります。

このような課題からブロックチェーンではないといった意見や、なぜブロックチェーンを使用しているのかという疑問が発生しています。(実際に私自身もこの疑問に対しては日々考えさせられています)

一方でネットワークに参加するためには自分でノードを運営する必要があり、ブロックチェーンはたまたITに明るくない人たちが参加してくるにはかなりの障壁があることも確かです。

また技術的な問題だけではなく、ブロックチェーン領域ではコミュニティも非常に大切です。

お互いネットワークを維持していくメンバーであるためどのようにネットワークに貢献していくのか、どのようなネットワークにしていきたいのかという点についても会話をして意識をすり合わせていく必要がある点が今までのシステムと大きく異なる点かと思います。

終わりに

Hyperledger Fabricの調査を3か月ほど行ってきた結果見えてきたことをざっとまとめてみました。

一般的に紹介されているユースケースは確かに有効ではあるが、実現するにはかなりの障壁があるというのも見えてきました。

現在はキラーユースケースも多くないためとりあえずユースケースを増やすこと優先で様々な事例で使用していくことが大切なフェーズだと思います。

最後の方ネガティブな話題が多くなりましたが、それ以上に現在のWebでは難しい信頼性のあるデータを作って行けたり、コンソーシアム内でデータの共有が行われることにより新しいビジネスの創出やデータの利活用が進んでいく可能性を秘めた技術になっています。