見出し画像

複数のブロックチェーンを連携させる技術課題を考えてみる

はじめまして。サイバーエージェントでブロックチェーンエンジニアを名乗り始めたおしょさんです。2018年11月から所属が変わったので、これを機にnoteで個人的な技術ブログを書いていこうと思います(以前はQiitaで書いてました)
本記事は、BlockChain Advent Calendar 2018 - Qiitaの19日目の記事です。

1. 概要

2018年に入り、弊社含めてブロックチェーンを利用したサービスを作る!という企業が増えてきました(LINE、メルペイ、ソフトバンク、...etc)。こういったサービスを作る中で後回しにされる内容として、サービス同士を連携させる話、話のレイヤーを技術寄りに落とすと異なるブロックチェーン間で価値を移転させる話があります。本記事では、この内容について、既存技術や必要となってくる課題を振り返ってみたいと思います。

2. ブロックチェーンで管理される価値とは?

そもそもの話として、ブロックチェーンで管理されている「価値」とは何でしょうか?現在、ブロックチェーンの基盤として、BitcoinやEthereum、Hyperleger Fabric等が有名ですが、その中で管理されている「価値」とは、いわゆる台帳やレジャーと呼ばれるブロックの中やトランザクションの中に保存されている「情報」と定義したいと思います。この情報について、先ほど基盤だと、(諸説あるのは承知の上ですが)それぞれ以下のように定義できると考えています。

Bitcoin: 各アドレスのBTCの保有量の変化
Ethereum: 
各アドレスのETHやトークンの保有量の変化 
各アドレスにおけるサービスごとのステート
Hyperledger Fabric: 共有されているKey-Value Storeのデータ変化

3. 既存の価値移転技術について

既存技術として、価値移転を実現しているのは、BitcoinやEthereumにおけるコインやトークンの移転です。この技術については、現状、3つの方式に分類されています。

DEX: 
Ethereumのように、基盤内で複数のトークンが定義できる場合等において、トークン同士に値段を付けて交換する分散方式。基盤間では不可能ですが、サービス同士という観点で見ると、移転可能。
Escrow: 
Interledger Protocolに代表されるような、価値を交換したいもの同士が信頼できる第三者を仲介役に置いて、価値を交換する仕組み。第三者が交換された基盤の台帳に対して交換を行ったことを追記する。
中央仲介型: 
Cosmosのように、接続する台帳を予め保持しているサービスを用いて当事者同士が価値交換を行う方式。

4. 連携する際の課題を考えてみる

ブロックチェーンで展開されたサービスを連携させていくことを考えてみると、既存のWebサービスを構築する時と同じように、他サービス連携(認証にOAuthのような個人認証サービスを利用する、情報履歴として動いているネットワークと情報流通サービスを連携させる等)することが考えられます。しかし、ブロックチェーンの基盤は1つの共通基盤を最初から利用する可能性は少なく、それぞれのサービスにあった基盤を利用し、サービス間でそれぞれのブロックチェーンに保存した価値(情報)を交換していくことになる可能性が大きいと考えられます。このため、ブロックチェーン間での価値交換の必要はあるのですが、既存の価値交換だけでなく、以下のような課題もあると考えられます。

課題1: トークン等の値段がない場合の価値交換ってどうするのか?
Hyperledger Fabricを用いようとするモチベーションの1つに、情報単体では価値を生まないが、他の情報と紐付けることで全体のコスト削減が見込まれるような情報管理的な単体のサービスでの利用シーンは考えられている(サプライチェーン等)。しかし、こういった情報履歴と連携するサービスを考えた際、情報単体の価値を提供者に還元しながらどう情報を移転するのかといった課題がある。

課題2: プライバシーデータの取り扱い方法
サービス同士の連携という部分で考えると、コインやトークンのやり取りだけでなく、例えば、OAuthのように、第3機関がブロックチェーンのアカウントの信頼性を保証するようなサービスで認証連携することを考えられます。この場合、情報の保証を行ったという確証を各サービスのネットワーク間でどう取るのか、という部分での問題があります。例えば、Facebookが扱っている氏名を他のサービスに渡した結果、そのデータがパブリックなチェーン全体に公開されてしまう可能性もあり、サービスのデータの扱い方の明確性を保証する必要がある。

課題3: 情報の追跡性をどう保証するのか?
これは、同じブロックチェーン内のサービスでも起こりうる話ですが、もともと管理していたブロックチェーン外へ情報が移転された際の情報の追跡性をどう保証するのか?という問題があります。例えば、あるブロックチェーン基盤のゲームのアバターを他のブロックチェーン基盤のゲームに移転して遊べるようにした際に、移した後では、複製したり、別の人がリアルでは利用している(なりすまし)等の問題にどう対応するのか?といった問題も考えられます。

5. 解決策は?

上記のように、ブロックチェーンサービス間での連携を考えると、既存のInterledgr ProtocolやCosmosのように互いの分散台帳に交換結果を書き合うだけでは解決できない問題が発生すると考えられます。この際、連携サービス同士でまずはインターフェイス仕様やデータの扱い方に関して合意を取っていき、標準化をしていく必要があるのは確かですが、互いの分散台帳を監視し合えるプロトコルやデータ標準化が必要になっていくと考えられます。
こういったことを考えていくと、まず最初に大きめのコンソーシアムを構築して、最初に実装したものが勝ってしまうプラットフォーマー的な思想で勝敗がついてしまいそうで怖いですね・・・。

6. おわりに

今年は、ブロックチェーン同士を接続し、その間で価値を移転する技術を勉強したり、実装する機会があったので、知見を記事にまとめてみました。
トークンエコノミーによって情報を扱うというサービスもありますが、今後、サービスを実装していこうとすると、Hyperledger Fabricのような共有KVSとしてブロックチェーンを利用し、その外のサービスで価値を与えることも考えられるので、価値交換における価値の付け方をどうするのかは、結構難しいのかなーとも思う一方で、そこにビジネスの糸口も見えるのかもなーと考えています。
ただし、その前提にあるのが、ブロックチェーンを活用したビジネス(特にB2CやC2C的なもの)の浸透性が必要なので、ブロックチェーン業界を盛り上がって行って欲しいなーとも思います。

7. 参考資料:

繋がる台帳の話
世界で一番分かりやすいInterledger Protocol

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