異なるブロックチェーン間の接続の困難さと、それを克服するための可能性
はじめに
①異なるブロックチェーン間を繋げる — How
現状、異なるブロックチェーン間を技術的に”繋げる”のは非常に困難です。例えばFabricとCordaは、シームレスかつダイレクトにデータを受け渡すことが出来ません。これは両者が技術的に未熟ではなく、また発展途上という話でもなく、そもそもデータにファイナリティーを与えるための合意形成の方法が異なるため、当たり前に繋がらないのです。Fabricは、CA、Peer(Endorcer)、Ordererと呼ばれるコンポーネントによりネットワークが構築されます。一方Cordaも似たような仕組みでCA、Node、Notaryといったコンポーネントにより構成されます。OrdererとNotaryは同じく二重支払い防止の役割を果たしますが、似て非なるものなので取り換え不可です。また、異なるブロックチェーン間では、異なるPKI基盤、異なる秘密鍵・公開鍵が使われるため、ブロックチェーン間を跨いでデータの改ざんチェックも出来ません。
②同じブロックチェーン間を繋げる — How
では同じブロックチェーン間の接続の場合はどうでしょう。私はCordaを専門としているため、Corda間の接続に絞って説明します。これは結論からすると繋がります。なぜ接続可能かというと、異なるアプリケーション間でも同じ合意形成のインフラを利用できるからです。具体的には、Cordaで開発された異なるアプリケーションが、同じPKI基盤上で、共通のノータリーを利用する形になります。
異なるブロックチェーン間を”頑張って繋げる”
以上を踏まえると、技術的にブロックチェーンを繋げるためには、世の中のブロックチェーンを全て一つに統一しなければならないのか、といった結論になってしまいます。そうではありません。異なるネットワークは異なる目的のために、分散して共存する世界を私たちは想像しています。なので、やはり異なるブロックチェーンはどうにかして繋げるたいのです。そこで、技術的には不可能であるものの、ある意味”割り切り”で繋げてしまおうじゃないか、という考え方があります。つまり、”繋がる”の要件を若干満たさないものの、エンドユーザーにメリットがあるのであれば、ビジネス的にルールを決めて”繋がる”の要件を緩和しましょうということです。
そういう意味では、所謂プライベート・ブロックチェーンも、パブリック・ブロックチェーンにある意味”割り切り”を加えたプラットフォームと言えます。パブリック・ブロックチェーンであれば、完全なる分散型ネットワークを構築出来ますが、プライバシーの要件が充足出来ません。そこで、理論上は第三者ではあるものの、現実的にはこの第三者が単一障害点とならないよう冗長性を担保することで、事実上の分散型ネットワークを構築する、プライベート・ブロックチェーンをこう呼ぶこともできます。コチラの世界ではこれで良いのです。なぜなら分散化自体が目的ではなく、ビジネスを効率化するのが目的だからです。
ブロックチェーンに”第三者”を置く
さて、異なるブロックチェーン間を頑張って繋げるにはどうしたら良いでしょうか。一つの方法は、異なるブロックチェーンそれぞれに、信頼の置ける第三者（下記図のX）を置き、そこをブリッジにしてデータを介す方法です。はい、”第三者を置く”と言っています。
例えば、Xはどの参加者からも信頼が置けるプレイヤーだと仮定します。まずは連携元となるネットワーク内でデータをXに渡します。この渡しはブロックチェーン上なのでシームレスかつダイレクトです。Xは社内でデータ変換し、連携先のネットワークで利用できる形にします。連携先ネットワークでXからAにデータを戻します。こうすることで、Aがブロックチェーンを跨ってデータを利用する際の不正（改ざん、二重利用）を防止します。
このやり方は言うまでもなく、第三者の信頼に依存しており、「そもそもブロックチェーンいるか？」問題が発生します。また、このブリッジを運営するインセンティブは？という問題も発生します。
それでもなお、この方法が検討に値すべきなのは、第三者が完全中立な非営利団体等であれば成り立つ可能性があるからです。その組織が”原価”でサービス提供してくれれば、少なくともローコストの要件はクリア出来そうです。
自社の信頼を活用
もしくは、第三者を置かずに社内でブロックチェーン間をAPIで相互接続するというアイデアもあります。これは第三者ではなく、自社の信頼に依存させるやり方です。
このやり方はブロックチェーンの良さを完全に失い意味不明です。ブロックチェーンを跨いで”価値”は移転出来ませんので、お勧めしません。しかし、これを使えないと切り捨ててしまわず、少し観点を変え、連携する人の信頼に加え、連携するデータの質も考慮した上で、”あり”にしても良い場面があるかもしれません。
ブリッジとなるAが業界トップ３の大手企業であった場合、データを不正利用するインセンティブは何でしょう？そんなことをすれば信頼失墜です。また連携するデータが財務データではなく、非財務データであれば、どうでしょう？ブロックチェーンを跨いで価値を運びたいのではなく、単にデータを”転記”したいというニーズであれば、Aの信頼に基づいて、オフチェーンで処理する場面は検討に値するでしょう。むしろ、Aにとっての差別化サービスとなるかもしれません。
インターオペラビリティーを検討するための方向性
と、ここまでインターオペラビリティーを実現する方法について議論してきましたが、現状、技術的には色々と課題があることが分かりました。一方、技術的には完璧ではないものの、実利優先で、ユーザーが違和感なくブロックチェーンを使える環境を整えるという考え方もあります。以上を踏まえると、私たちは次の方向性で具体策を検討していかなければなりません。
①何を繋げたいか？なぜ繋げたいか？
まずはいきなり「インターオペラビリティーが重要だ！」と叫ばず、具体的なユースケースを想定し、どのようなプレイヤーがどんなデータをなぜ繋げたいのか、を明確化しましょう。
②どう繋げるか？
さらに、Howを検討する上で、技術的に”繋がる” 、”繋がらない”と白黒付けるだけでなく、ビジネス的な観点で目的に照らし合わせ、妥協点を探ってみましょう。完全にシームレスかつダイレクトなインターオペラビリティーが実現できなくとも、エンドユーザーにとって単一のポータルとして機能するプラットフォームを構築できれば、業務上のメリットがあります。ブロックチェーンが分断されることによるオペレーション・リスクを最小化する観点で、インターオペラビリティーの実装を検討しましょう。
③標準化は？
加えて、データモデルの標準化も議論の必要があります。ここは戦うところではありません。非競争領域として捉え、競合するネットワークが協力し合って進めていく必要があるでしょう。分散型ネットワークが主流となる未来はデファクト・スタンダード・プレイではありません。
”脱線”します
さて、個別具体的なユースケースの検討に入る前に、身近な例え話で頭の体操をしておきます。
渋谷駅から東急東横線で元町・中華街方面に向かって乗車すると、横浜駅から自動的にみなとみらい線へ接続します。乗客はわざわざ乗り換える必要はなく、座っていれば次は新高島に到着し、そのまま終点、元町・中華街まで運んでくれます。行き先がそこからさらに離れていると（例えば三渓園）、横浜市営バスに乗り換える必要が出てくるでしょう。冒険心を失った大人にとっては、知らない土地でのバス利用は難易度高です。中華街入口バス停に向かって歩くと、先に山下町バス停に辿り着き困惑するでしょう。そのままバスに乗ると横浜駅へ逆戻りです。
東急東横線は東急電鉄、みなとみらい線は横浜高速鉄道が運営しています。異なる会社が同じ旅客輸送という目的で電車を運行しており、運行計画を揃え、標準化された線路を使っているため、その電車は繋がります。しかし、電車がそのまま道路を走る訳にはいかないので、元町・中華街駅からはバスに乗り換えです。ただ、交通系ICカード（Suica, PASMO等）が使えるので乗り換え自体は非常にスムーズです。
このように当たり前ですが、別々に作られた仕組み（電車とバス）は簡単には繋がりませんが、利便性を高める手段として交通系ICカードの共通利用は実現しています。ここにインターオペラビリティーを考える上でのヒントがありそうです。
①何を繋げたいか？なぜ繋げたいか？
乗客をスムーズに目的地まで運びたい。なぜなら、乗り換えは乗客にとって面倒だから。繋げることで利便性を上げたい。
②どう繋げるか？
鉄道会社間は線路で繋げる。鉄道会社-バス間は繋げられないので、少なくともSuica、Pasmo等を共通利用出来るようにしておいて、線路と道路が仮につながった場合に備えて利便性を確保しておく。
③標準化は？
鉄道会社間で線路の規格を統一する。交通系ICカードの規格も統一しておく。
さて、ブロックチェーンの話に戻りましょう。
後編へ続く
＜ご質問・ご要望の例＞
- Corda Portalの記事について質問したい
- ブロックチェーンを活用した新規事業を相談したい
- 企業でのブロックチェーン活用方法を教えて欲しい 等々