みずほ銀らが検証「Hyperledger」は取引に使えるか

この記事をtweetする このエントリーをはてなブックマークに追加


みずほ銀らが検証「Hyperledger」は取引システムに使えるか?

基幹系システム 2017/05/08

 ブロックチェーン/分散型台帳技術のオープンソースソフトウェアを開発する取り組みである「Hyperledgerプロジェクト」が、2017年3月16日にイベント「第1回 Hyperledger Tokyo Meetup」 を開催した。前の記事「日本企業も注目する『Hyperledger Fabric』とは何か」では、Hyperledgerプロジェクトの最新状況、そして注目が集まる「Hyperledger Fabric」のブロックチェーン技術としての位置付けを紹介した。

 本稿では、間もなく登場する「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で解消されることが期待できる。

Fabric v1.0では数百トランザクション/秒が期待できる

 気になる性能についての情報もあった。

 講演後の質疑応答では「Fabric v0.6では30〜40tps(トランザクション/秒)程度だったが、v1.0では4ノードで100tpsは出せる。ただ、『どのようなユースケースをどのように設計したのか』の意味付けが伴わない性能に意味があるのか、という疑問がある」とのコメントがあった。なお、IBMのプレスリリースではFabric v1.0を活用して1000tps以上の性能が見込まれるとの記述もあり、性能の上限は大幅に上がると考えていい。ただし性能を得るためには、ユースケースごとに異なる前提条件に対応した分散処理の設計が必要となる。並列/分散処理による性能向上を議論するには、前提条件をしっかり定義しないと意味がないというわけである。

 ざっくりいえば、性能は上がると考えてよいが、その分「どのような処理を切り出し、どのように並列/分散実行するのか」という設計をよく考えなければいけなくなった。

Fabric v1.0はアーキテクチャを大幅変更、PeerとOrdererにノードを分ける

 並列/分散処理を取り入れるため、Fabric v1.0ではアーキテクチャが大幅に変わる。役割が異なる複数のコンポーネントが連携し、トランザクションの処理を進める枠組みを取り入れた(図)。

Fabric v1.0のアーキテクチャ

図をご覧いただくには・・・
会員登録いただくと自動的にこの記事に戻り、図がご覧いただけます。

会員登録(無料)・ログイン

Fabric v1.0のアーキテクチャ
(山田氏の発表資料より)

 まず、v0.6のように全員参加ではなく特定のPeerのグループにより合意形成するようになったので、「どのPeerどうしで合意形成するか」をユーザーが決める必要がある。これを決めるのが「エンドースメントポリシー」である。

 エンドースメントポリシーについては、次のような例を出して説明した。日立製作所はシンガポールで小切手に関するブロックチェーン実証実験を行っているが、このような複数の銀行を結ぶコンソーシアム型ブロックチェーンで処理を実行する場合「どの銀行のPeerどうしで合意形成ができれば正しい結果とするのか」をクライアント側で決める必要がある。例えば合意形成するPeerとして「当局」や、第三者機関による「監査」のPeerを加えることもできる。このようなポリシーはユーザー側で決める必要がある。

 以上の並列/分散処理の取り入れに伴い、合意形成アルゴリズムがFabric v0.6のPBFTから、Fabric v1.0では「エンドースメントとオーダリング」(承認と整列)に変わる。ノードの役割は処理を実行する"Peer"と、トランザクションを整列させる"Orderer"に分かれる。Peerは、いったんChaincodeを実行してその結果が正しいことを承認する(そのためにPeerはEndorserと呼ぶコンポーネントを組み込んでいる)。各Peerが実行したトランザクションの順序を決めるのがOrdererである。Ordererの現状の実装はKafka(pub-sub型メッセージングシステム)を利用している。

 v1.0の大きな変更点の1つとして、認証局を複数持てるようにした。従来、ノードを認証する認証局が「単一障害点」になるとの指摘があったのだが(認証局がダウンするとブロックチェーン全体が機能しなくなるため)、その懸念を解消した。ただし、認証局が「単一信頼点」となるとの指摘があり、引き続き検討課題となっていると説明した。Hyperledgerプロジェクトに寄せられた声の中には「中央集権の考え方の是非」に関する意見もあるとのことだ。

 ここで補足すると、一般にブロックチェーン技術では単一障害点が存在しないだけでなく、特定のノード(コンピュータ)、組織、人間を信用しなくて済むこと、すなわち単一信頼点を持たない点が評価されている。この立場からは「認証局を信用しなければならないなら、従来の情報システムを信頼していたのと同じではないか?」との疑問も出てくるのだ。

開発ツール「Composer」「Fabric-Java SDK」の整備も進む

 日本アイ・ビー・エムの紫関昭光氏は開発ツール「Fabric Composer」を紹介した。現時点ではHyperledger Fabric向けの開発ツールだが、将来は他のブロックチェーン技術にも対応するかもしれないとのことだ。

 Composerの前提となる問題意識は次の4つが挙げられる。

(1)スマートコントラクトの可視化。現状のHyperledger FabricではGo言語でスマートコントラクト(Chaincode)を実装する(なお、Java言語も利用可能)。Go言語が読めないビジネスマンにも理解できるようなスマートコントラクトの記述手法が必要

(2)より迅速なアプリケーション開発

(3)テスト自動化による信頼性の向上

(4)高いレベルでアプリケーションの変更が可能な柔軟性を実現するためのさらなる抽象化

 これらの問題意識に対応するツールがComposerということになる。その内容は「簡単に扱えるモデリング言語」「JavaScriptツール」「Webのクライアントライブラリ」「エディタ」「ユーティリティー」「コード生成ツール」などの組み合わせである。


 アプリケーションの成果物は“Business Network Archive”と呼ぶ1つのzipファイルにまとめ、デプロイできる。既にBluemixのWebサイト上で動くComposerの実物を試すことができる。Hyperledger Fabricの実環境がなくても、Composer内部でアプリケーションをシミュレート実行してテストすることができる。

 なお、現状のComposerはオープンソースではあるが、Hyperledgerの正式なメンバーではない。インキュベータプロジェクトとして採用するための審査を受けている最中である。

 もう1つの開発ツールが、富士通が開発中の「Fabric-Java SDK」である。

 Fabric v1.0では、それまで提供していたREST APIをセキュリティ上の問題から廃止する予定であり、その代替としてFabric-Java SDKの開発が進められている。Fabric v1.0では分散処理が高度になったので、ノードが増えたり減ったりする状況が発生する。REST APIではこの状況でサーバ(ノード)を追跡し続けることが不可能との事情もある。

富士通とみずほ銀による「証券ポストトレード」の技術検証

 富士通/富士通北陸システムズ 滝口成人氏は、富士通とみずほ銀行が共同で開発した「証券ポストトレード」への技術検証について説明した。国際的な証券取引の分野では、「約定したものの、伝言ゲームの内容が食い違い無効になる取引」が一定比率存在するが、ブロックチェーンで約定内容を共有することで失敗を低減しようという取り組みである。

 この取り組みは、まずビットコインのパブリックブロックチェーンを活用する「OpenAsset」プロトコルによりいったん実装した。その後、内容が公開されるパブリックブロックチェーンではなく、当事者の会社だけが参加できるコンソーシアム型ブロックチェーンに移行することにし、Hyperledger Fabricを使って再度実装している。

 今回のイベントで、滝口氏は双方の特性が分かるデモを披露した。Fabricの場合、ビットコインのブロックチェーンとOpenAssetの組み合わせに比べ、「ワールドステート」と呼ぶ一種のデータベースをデータ管理に利用できること、Chaincodeを汎用プログラミング言語で開発できることから「より簡単に開発できた」としている。なお、「証券ポストトレード」に関する発表内容の中核部分は、日本銀行が開催した第3回FinTechフォーラム資料としても公開されている

 発表では、開発経験を踏まえて「Chaincodeの品質担保が極めて重要」と指摘した。特に、合意形成のため「時刻や乱数のようにノードごとに異なる情報を利用せず、各ノードの実行結果が必ず同じになるようにする(決定論的なプログラムコードを書く)」ことが大事だと指摘した。

 前述したようにブロックチェーンは信頼できる台帳である点に価値があるのだが、スマートコントラクト(Chaincode)にバグや脆弱性があればこの特性は台無しになってしまう。また、Chaincodeの実行結果がノードごとに異なる場合、正常に動作しない。例えば参照する時計の時刻がノードごとに異なっていたり、プログラム内で乱数を使うと、同じプログラムコードでも実行結果が異なる現象が起こり得る。Fabricをシステム構築に活用する場合はChaincodeのプログラム開発が必ず伴うと考えてよいので「Chaincodeの品質担保が重要」との指摘は重い意味を持つといえる。

Fabricとは異なる分散型台帳技術「Iroha」

 今回のイベントではFabric関連の発表が多い中で、Fabricとは別の分散型台帳技術Irohaについて、開発元であるソラミツの武宮誠氏が紹介した。

 FabricはB2B向けだが、IrohaはB2Cを意識し、特にモバイルアプリ開発ライブラリを充実させている。データ構造にはブロックチェーンで用いられるハッシュチェーンではなく「マークル木」を用いる(つまりIrohaは厳密にはブロックチェーン技術ではないが、分散型台帳技術ではある)。

 「スメラギ」と呼ぶPBFTを拡張した確定的な合意形成アルゴリズム、高速な動作(秒間3000トランザクションを目指すとしている)、「天地(あめつち)」と呼ぶビッグデータ対応可能なデータベースなど、Fabricとは異なる特徴を備える。イベント内仮想通貨「萌貨」に使われた実績があるほか、IoT(Internet of Things)向けの応用などが検討されている。IoT(Internet of Things)向けの応用などが検討されている。このMeetupの後、カンボジア国立銀行とIrohaおよび次世代決済システムの共同開発に乗り出すとの発表もあった。


 以上、Hyperledger Meetupの内容を駆け足で紹介した。ブロックチェーン/分散型台帳技術に関する取り組みは各方面で進んでおり、大手ITベンダーやメガバンクも積極的だ。Hyperledger Fabricの新バージョンv1.0は大幅にアーキテクチャが強化されるし、Irohaも説明を聞く限り非常に意欲的な内容だ。このような取り組みによりブロックチェーン/分散型台帳技術への知見の蓄積、知識やノウハウの普及が進み、次の世代の情報システムに結びついていくことを期待したい。

                      (文/写真:星 暁雄、ITジャーナリスト)

…この記事の続きは、会員限定です。  会員登録はこちら(無料)

続きを読むには…
会員登録いただくと自動的にこの記事に戻り、続きが読めます。

会員登録(無料)・ログイン

このページの先頭へ

文書管理/みずほ銀らが検証「Hyperledger」は取引に使えるか」関連の情報を、チョイスしてお届けします

※キーマンズネット内の「文書管理」関連情報をランダムに表示しています。

文書管理」関連の製品

システム設計専用ツール「Verasym System Designer(VSSD)」 【第一コンピュータリソース】 ATOK、一太郎で培われた言語処理技術を集結 校正支援ツールの劇的な効果 【ジャストシステム】 InterSafe IRM(インターセーフ アイアールエム) 【アルプス システム インテグレーション】
開発ツール 文書管理 暗号化
システム開発における要件定義、外部・内部設計などシステムの設計を行う専用ツール。ドキュメントごとに専用インタフェースが用意されており効率よく設計作業を行える。 ATOK、一太郎で培われた言語処理技術を集結 校正支援ツールの劇的な効果 ファイルを保存時に自動で暗号化する情報漏洩対策ソフト。パスワードが不要で、暗号化忘れを防止できるほか、利用権限設定も可能。

文書管理」関連の特集


まだ導入してないのっ!?“月150円スタート”やプロジェクト単位での導入も増加中!安く、手軽に始める…



机に放置された財務データ満載の帳票。そんな日常にこそ情報漏洩の危険が‥。日本版SOX法対策としても注…



納期もコストも圧縮、なのに品質は担保しろなんて・・・プロマネに愚痴をこぼす前に考えたい、開発効率化に…


文書管理」関連のセミナー

【大阪】基本がわかる!機能体験セミナー 【主催:ネオジャパン/共催:三谷商事】 注目 

開催日 11月24日(金)   開催地 大阪府   参加費 無料

1社1台のパソコン環境でご体験いただきながら、グループウェア「desknet's NEO(デスクネッツネオ)」の各機能をご紹介するセミナーです。徹底した「現場主…

【名古屋】desknet's NEOじっくり触れる!ハンズオンセミナー 【【主催】日立システムズ/【共催】ネオジャパン】 注目 

開催日 12月7日(木)   開催地 愛知県   参加費 無料

1社1台のパソコン環境でご体験いただきながら、グループウェア「desknet's NEO(デスクネッツネオ)」の各機能をご紹介するセミナーです。徹底した「現場主…

ペーパーレス化で働き方改革 【ウイングアーク1st】 注目 

開催日 12月12日(火)   開催地 東京都   参加費 無料

電子帳票活用ソリューションの紹介の実例をベースに業務に即した操作を体験いただき、ソリューション導入後の活用をイメージいただきます。利用する際の基本的な操作をご理…

「基幹系システム」関連 製品レポート一覧

このページの先頭へ

文書管理/ みずほ銀らが検証「Hyperledger」は取引に使えるか」の記事を一部ご紹介しました。
会員登録を行い、ログインすると、「文書管理/ みずほ銀らが検証「Hyperledger」は取引に使えるか」の記事の続きがお読みいただけます。


Myリストへ

この記事をtweetする このエントリーをはてなブックマークに追加


この記事に掲載している情報は、掲載日時点のものです。変更となる場合がございますのでご了承下さい。


30009654


IT・IT製品TOP > 基幹系システム > その他基幹系システム関連 > その他基幹系システム関連のIT特集 > 特集詳細

このページの先頭へ

キーマンズネットとは

ページトップへ