The Linux Foundationによるブロックチェーンのオープンソースソフトウエア（OSS）開発プロジェクト「Hyperledger Project」は2017年3月末～4月初頭に、ブロックチェーンソフト「Hyperledger Fabric v1.0」をリリースする。
「業務用ブロックチェーンのLinux」を目指すFabricの正式版リリースで、ブロックチェーンを決済、証券取引、製造業や流通のトレーサビリティといった領域に応用する実証実験が加速しそうだ。ただし、Fabric v1.0は実運用に向けた課題がいくつか残っており、実験と並行してFabric自身の改良も求められる。
IT、金融、製造の大手企業がプロジェクトに参画
Hyperledger Projectは、企業の業務システム並みの安定性・信頼性を持つ分散台帳（distributed ledger）技術のOSSを開発するプロジェクト。分散台帳とは、耐改ざん性の高い同一の台帳を複数のプレイヤーが共有する仕組みである。仮想通貨ビットコインから派生したブロックチェーンは分散台帳技術の一種で、その本命という位置づけだ。Hyperledger Projectのプレミア会員として米IBM、米インテル、米アクセンチュア、日立製作所、富士通などのIT企業、米JPモルガンや米CMEグループなどの金融機関、仏エアバスや独ダイムラーなどの製造業が名を連ねる。
Hyperledgerは複数のOSSプロジェクトから成り、現在は米IBMが主導する「Fabric」のほか、米インテルが主導する「Sawtooth Lake」、日本のスタートアップ企業であるソラミツが主導する「Iroha（いろは）」の開発が進むほか、米R3が主導する「Corda」も加わる見込み。当初からプロジェクトの中核的存在だったFabricが、まずは正式版として名乗りを挙げた格好だ。
ブロックチェーンソフトとしてのFabricの特徴は、台帳データを操作するプログラム（スマートコントラクト）の実行基盤が、Go言語やJava言語といった汎用言語に対応し、業務システムの開発者がアプリケーションを開発しやすい点だ。Eclipseなどの開発環境も使える。
日本では、日本取引所グループ（JPX）と国内金融機関6社（SBI証券、証券保管振替機構、野村証券、マネックス証券、みずほ証券、三菱東京UFJ銀行）は2016年4～6月にかけて、開発中のFabricを使った実験を日本IBMと共同で実施している。JPXは2017年春にも、新たな実験をFabric v1.0を使って始める見通しだ。
IBMを始め、Hyperledgerに参加するIT企業にとって、「v1.0」として仕様が固まることの意義は大きい。ブロックチェーンソフトを使った実験環境を構築するサービスを提案しやすくなるためだ。世界各国でPOC（概念検証）が相次ぐブロックチェーンは、金融機関や流通企業、製造業の大手との取引を開拓するうえで、格好の商材になり得る。
Fabricの開発をリードする米IBMは、v1.0のリリース前から動き出した。2017年3月20日（現地時間）、Fabric v1.0をベースとした業務用ブロックチェーンのクラウドサービス「IBM Blockchain」の提供を発表した。現在はβ版を提供しているが、v1.0のリリース次第、正式版に切り替える。
処理速度不足の課題はアルゴリズム変更で対応
Fabricの前バージョン（v0.6）と比較した最大の違いは、ノード（ブロックチェーンの取り引きに参加するコンピュータ）間で合意を形成するアルゴリズムを変更することで、トランザクション（取引）処理性能を高めた点にある。
Fabric v0.6が採用していた合意アルゴリズム「PBFT（Practical Byzantine Fault Tolelance）」は、参加ノード台数の約3分の1が故障などで応答しない（クラッシュ障害）、あるいは悪意を持って偽のデータを発信した（ビザンチン障害）場合でも、正常なノード間で合意を形成し、分散台帳としてのブロックチェーンの一貫性を保つことができる。ビットコインが採用する合意アルゴリズム「Proof of Work（PoW）」よりも計算力を浪費せずに済む。合意をもって取引を確定できる利点もある。
一方、PBFTには欠点もあった。参加ノード間で複雑な通信が必要になるため、トランザクション処理性能が数十件/秒と低い点だ。ビットコインの6～7件/秒よりは高速だが、決済や証券取引、製品のトレーサビリティといった業務に使うには性能不足だ。
Fabric v1.0では合意アルゴリズムを一新。以前は互いに対等だったノードに「コードの検証」「取引順序の確定」などの役割分担を与え、処理の一部を並列実行できるようにした。
これにより、トランザクション処理性能は数百件/秒、IBM試算では1000件超/秒になったという。「これらの施策により処理性能が向上し、Fabricを適用可能な業務範囲が拡大することで、実用に近づいたと考えている」（Hyperledger Projectに参加する日立製作所 研究開発グループ システムイノベーションセンタの山田仁志夫氏）。
このほかv1.0では、限られたメンバーのみデータにアクセスできるセキュリティ機能、プライバシー保護機能の強化が図られた。
実用化への高いハードル、残された課題は多い
ただし、Hyperledger Fabric v1.0は、実際の業務に適用するうえで、改善を要する課題がいくつも残っている。v1.0リリース後は、様々な実証実験を行いながら課題を抽出し、Fabricの修正、改善を進める必要がありそうだ。
2017年3月16日に国内で初めて開催された「第1回 Hyperledger Tokyo Meetup」での議論や各社への取材をベースに、現時点で浮上している課題を4つにまとめる。
（1）トランザクション処理性能の不足
v1.0によって処理性能が数百件～1000件/秒に高まり、応用できる用途は広がったものの、本命である金融業務に使うにはまだ力不足、との声が多い。
例えば証券取引のポストトレード処理などにブロックチェーンを使う場合、一般に数千件/秒の処理性能を求められる。
数百件/秒という性能も、ノード数が最低数の4で、ノード間の通信遅延がほとんどなく、スマートコントラクトの処理もシンプル、という理想的な環境での値とみられる。今後は、実運用を見据えた性能評価も求められるだろう。
（2）スマートコントラクトを使ったアプリケーションの品質確保
Fabricでは、スマートコントラクトのコードをGo言語やJava言語で記述できる。Java開発者がアプリケーションを開発しやすいのは利点といえる一方、アプリケーションの品質担保が課題になる。開発ツールの整備、検証済みサンプルコードの拡充などが求められそうだ。
金融取引においてスマートコントラクトのコードにバグがあると、契約者が想定した通りの取引が行われず、金融取引の健全性が損なわれる。Ethereum上のスマートコントラクトで発生した「The DAO事件」は、その典型だろう。
（3）ビザンチン障害に非対応
Fabric v1.0は、高速性を重視して合意アルゴリズムの標準モジュールを変更した。この標準モジュール（Kafka）は、ノードが故障のため正常に応答しなくなる「クラッシュ障害」には引き続き対応する一方、悪意を持ったノードが偽りのデータを配信する「ビザンチン障害」には対応しない。
＊こうした特性は、分散データベースにおいてデータの整合性を保つ「Paxos」などの合意アルゴリズムに近い。
つまり、参加ノードを管理する組織にブロックチェーンの一貫性をゆがめるような悪意がないことが、運用の前提になる。この点では、お互いの信頼に依存しないというブロックチェーンとしての特性は、v1.0ではやや薄れることになる。
（4）認証局が「単一信頼点」になる
Fabricでは、認証局の機能を持つサーバーが認可したノードのみが、ブロックチェーンネットワークに参加できる。v0.6の実装では、認証局サーバーが単一障害点（single point of failure）になり、サーバーが故障するとブロックチェーンの運用が停止しかねない課題があった。
v1.0では認証局サーバーを分散運用できるようになり、単一障害点としての弱点は改善された。
その一方、認証局サーバーの運用主体まで分散させるのは難しく、ブロックチェーンの参加者は引き続き認証局の運営者を「信頼」するほかない。つまり、認証局はFabricブロックチェーンの「単一信頼点」になっており、その点で中央集権的な性質が残っている、というわけだ。
これらの観点から、現状ではFabric v1.0は実証実験向けソフトウエアの域を明確に離脱したとは言いにくい。今後は、実証実験や追加開発を通じてこれらの課題を克服するか、あるいは運用上の妥協点を見出せるかが、実用化の可否を決めることになりそうだ。
出典 http:/