エンタープライズブロックチェーン基盤の比較

●背景:

・エンタープライズ領域でブロックチェーンで何かを実現したいとき、必ずブロックチェーン基盤の選定に迫られる。
・RDBの場合であれば、OSSであればPostgresql,Mysql, sqliteあたりになるが、どれかを選択して致命的な失敗になることはない(ブロックチェーン基盤と比較して)。
・ブロックチェーン基盤の場合、基盤選定をミスると致命的になり得る(性能が出ない、致命的に生産性が落ちる、業務要件を満たせない 等)
・ブロックチェーンセミナーなどでは、言い切ることを避けて、あやふやな言い方になっていていまいち腹落ちしない。
・よくある比較表は、技術特性の比較であり、もう一歩踏み込んだ「こういう技術特性を持っているのでこういうユースケースにはこの基盤」を説明できる状態になっておきたい。

●エンタープライズブロックチェーン基盤:

ユースケース数、製品の更新状況を考慮し、エンタープライズブロックチェーン基盤でよく選択肢に上がるのは、以下。
・HyperLedger Fabric
・Corda
・Quorum
・HyperLedger Besu
#上3つがリードしており、最近HyperLedger Besuが注目されてきているという理解。今回はHyperLedger Besuは比較対象から外す。

技術的特徴の比較は以下のようなブログで既に比較をしていただいています。

各リンクより、特に重要だと思ったコメントは以下。

いずれも現状では得意なところも不得意なところもあり、ユースケースごとにノックアウトとなるファクターがないのであれば、現状の技術的なケーパビリティだけでなく基盤の将来性なども考えて総合的に検討すべし、ということになるのかとも思います。

●ユースケース毎の基盤選択:

・コンセンサスアルゴリズムのビザンチン耐性の有無:
 ・HyperLedger Fabric:EOV,Raft/BFT(共にBF耐性なし)
 ・Corda:Raft(BF耐性なし)、BFT Smart(BF耐性あり)
 ・Quorum:Raft-based Consensus(BF耐性なし)、Istanbul BFT(BF耐性あり)
HyperLedger Fabricのみ、BF耐性ありオプションのコンセンサスアルゴリズムを選択できない。
だが、そもそもエンタープライズ領域で参加者が限られているネットワークにおいて、BF耐性は必要なのか?逆にブロックチェーンの価値を落としてししまっているかもしれないが、エンタープライズにおいて会社間で結託して悪事を働くようなことは考え辛く、ビザンチン耐性の有無はあまり選定影響は及ぼさないように思う。
ただ、ビザンチン耐性については、イマイチ現時点で理解しきれていないので、別途調査・理解をした上で、必要に応じて本ブログも書き直す。(宿題)

・ゼロ知識証明
 ・HyperLedger Fabric:あり
 ・Corda:なし
 ・Quorum:あり
ゼロ知識証明については、以下の記事の説明がわかりやすいです。

また、ブロックチェーンにおける「ゼロ知識証明」のユースケースは、以下でまとめられていました。

上記から分かったこととしては、ゼロ知識証明のブロックチェーンにおけるユースケース自体研究中のものがあるということです。
ある程度自明なゼロ知識証明のユースケースは、「検証または証明のためのゼロ知識証明」かと思います。

ゼロ知識証明を用いることで、データの選択的開示が可能になります。ゼロ知識証明では、「秘密」が何であるかを開示することなく、秘密の存在を証明できるのです。簡単な例としては、ゼロ知識証明を使うことで、成人であることを年齢を明かさなくても証明できるサービスが実現します。
また、情報が特定の範囲に収まっていることや、別のデータセットと一致するかどうかも証明できるため、例えば、特定のアドレスがホワイトリストに含まれていることを、個人情報の開示無しに証明できるのです。
この特徴は金融システムなどに応用できると考えられており、例えば「QEDIT」という企業は、あるユーザーがKYC済みであることを個人情報の開示なしに複数機関でシェアする基盤「Collaborative KYC」を開発しています。
参考:Privacy-Enhanced Collaborative KYC

・性能
パブリックブロックチェーンの欠点として有名なのは、性能です。仮想通貨バブルの際にビットコインの送金が完了するのに数十分かかったのは有名な話です。
一方エンタープライズブロックチェーンは、エンタープライズ適用するためにパブリックの欠点を埋めてきたという経緯もあり、各製品それぞれ数千TPSを実現可能(ただし構成による)となっており、滅多なユースケース以外はどの製品でも満たせそうです。

・システム構成
以下参照。

HyperLedger 及びCordaは、管理サーバーを立てる必要がある。一方、Quorumは等しい権限のノードでのみ構成され、より分散管理よりである。
これは、最終的なシステム管理モデルに大きく影響すると思われる。HyperLedger及びCordaは中央集権的な管理サーバーの管理ルール・管理者について決める必要があるが、Quorumは各企業が自身のノードさえ管理すれば良いというより分散管理モデルでシステム管理も実施することができ、コンソーシアムの推進も容易になると思われる。

・データ共有の範囲
以下参照。

・HyperLedger Fabricは、Channelというグループを定義し、Channel単位での情報共有モデルとなる。
・Cordaは、基本は1対1のトランザクションをベースとしており、必要に応じてトランザクション毎に公開範囲を設定することができる。
・Quorumは、特定ノードにのみ共有するトランザクションと、全体に共有するトランザクションを区別することができる。

Fabricは高パフォーマンスで特定グループ内での情報を共有したい場合に、Cordaは情報連携先が頻繁に変化する中で証券や取引などを転々流通させたい場合などへの活用が考えられます。ただし、中央集権的な機能が存在するので、それを誰が運用するかが注意点となります。Quorumは公開情報と個別のやり取りを行うSNSのような使い方が想定できますが、完全な分散システムであるため、運用やガバナンスの制御が課題となります。

確かに、Fabricは、グループが固定されていて、そのグループ内で情報を共有したい場合(かつ、共有範囲を全ノードではなく、ある程度のグループ内に収めたい場合)は向いていそうです。
Cordaは、2社間のやりとりがベースとなっているので、契約関連の書類の電子化など、EmailやEDIの代替として向いていそうです。
Quorumは、フラットなネットワークが形成できるため、競合会社間の情報共有などに向いていそうです。

この記事が気に入ったらサポートをしてみませんか?