みずほ銀らが検証「Hyperledger」は取引システムに使えるか？（1/4 ページ）

信用やトレーサビリティーを圧倒的に低コストで手に入れられると期待の新技術に国内外の企業が本気。企業間取引も通貨交換も、資本にものをいわせるだけではない世界がもうすぐそこに。その真価は？

　ブロックチェーン／分散型台帳技術のオープンソースソフトウェアを開発する取り組みである「Hyperledgerプロジェクト」が、2017年3月16日にイベント「第1回 Hyperledger Tokyo Meetup」を開催した。

　本稿では、間もなく登場する「Hyperledger Fabric v1.0」の動向や、開発ツールの動向、日本企業による実際の検証結果、モバイルアプリやIoTへの適用を視野に入れた別の分散台帳技術の動向などを見ていく。

α版が公開されたばかりの「Hyperledger Fabric v1.0」

　今回、多くの参加者が関心を寄せていたのは「Hyperledger Fabric v1.0（以降、Fabric v1.0）」の内容だろう。Meetupでは、Fabric v1.0の詳細情報を日立製作所の山田仁志夫氏が紹介した。Fabric v1.0では、v0.6と比べて重要な変更点が幾つもある。Fabricに関する知識は大幅にアップデートする必要がありそうだ。

　大きな変更は、合意形成アルゴリズムの変更とChaincodeの並列／分散実行の仕組みである。Fabric v0.6では全ノードが参加して一斉に合意形成を行う仕組みであることから、スマートコントラクト（Chaincode）を順次処理をすることに基づくボトルネックがあった。

　Fabric v1.0でこれをあらためて「ノード群を分割し、それぞれ並列に合意形成とプログラム実行を進める」仕組みに変わった。並列・分散処理が可能になり、スループット向上（性能向上）が期待できる。ただし、並列・分散処理の設計という新たな課題が発生したともいえる。

　山田氏によれば、Hyperledger Fabric v0.6では、合意形成アルゴリズムとして「PBFT（Practical Byzantine Fault Tolerance：実用的ビザンチン・フォールトトレラント・アルゴリズム）」を用いることに関連して2点の課題があった。

　1点目の課題はプライバシーである。全ノードが合意形成に参加することから、全ノードが全Chaincodeを閲覧可能であった。v1.0では特定のノードだけで合意形成を行うようにした。

　2点目の課題はスケーラビリティである。PBFTでは、全ノードがPBFTの合意形成とChaincode実行の全てを担うので、CPU負荷が高くなる。v1.0ではブロックチェーンのノードの役割を分割し、Chaincodeの実行元帳を管理する「Peer」と、トランザクションの順序を整列させる「Orderer」に分けた。

　全ノードで1つのトランザクションに対して合意形成とChaincode実行をする設計をあらためて、ノードのグループを複数作り、トランザクションを並列／分散処理できるようにした。「PBFTは全員参加だったが、それを切り出した」（山田氏）。この2点が、Fabricv1.0の大きな変更点である。

　Hyperledger Fabricにおけるスケーラビリティの課題については以前から指摘があった。日本取引所グループが2016年8月30日に公開したワーキングペーパー『金融市場インフラに対する分散型台帳技術の適用可能性について』では、スマートコントラクト（Chaincode）を順次実行することが性能上のネックとなる、との指摘がある。このネックはFabric v1.0で解消されることが期待できる。

イベントレポートアーカイブ

この連載の記事をもっと見る

この記事の著者