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

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