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

[星暁雄，キーマンズネット]

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のアーキテクチャ

　まず、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プロジェクトに寄せられた声の中には「中央集権の考え方の是非」に関する意見もあるとのことだ。

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