Cordaのデータモデルが、インターオペラビリティやスケーラビリティにどのように影響するのか。
はじめに
この記事は、Cordaデータモデルの特徴の続きです。前回ご紹介した内容を簡単にまとめると
①従来のブロックチェーンはプライバシーを確保できません。
②プライバシーを確保する為に全順序性を捨てたのがCordaのデータモデルです。
③価値の移動（2重支払い防止）のためにNotaryというノードがCordaには必要です。
というお話しでした。
プライバシーの為に全順序性を捨てたCordaでしたが、こうすることで得られるものが他にもあります。インターオペラビリティとスケーラビリティです。この記事ではこの二つについて説明してまいります。
インターオペラビリティ
Cordaのデータモデルは半順序です。図にすると例えば以下のようになります。
一つの取引が一つのトランザクションを構成し、一つのトランザクションが一つのブロックを構成するという事になります。プライバシーを確保するために、Cordaはブロック（＝トランザクション）を誰と共有するのか、P2Pベースでコントロールします。
さて、この図を見ると複数のブロックから一つのブロックを作ることができます。例えば取引２と取引３から、取引４を作ることができます。
この特徴がインターオペラビリティを実現します。
どういうことでしょうか。この図を少し改造してみましょう。
この新しい図において、上3つの取引はCordaアプリAで行われました。下２つの取引はCordaアプリBで行われました。
この時、Corda Coreから見ると、CordaアプリA上のトランザクションだろうと、CordaアプリBのトランザクションだろうと違いはありません。どちらもCordaが規定するデータ構造を持ちます。（もっと端的に言うとCordaのトランザクションを規定するJavaクラスを継承したオブジェクトです。）
つまり、アプリケーションの違いを気にすることなくブロックをつなぐことができます。Cordaが複数のブロックをインプットにできるという特徴も併せて考えると、アプリケーション間でデータや価値の移動が自然にできる事が理解できるかと思います。
前回の記事に書いた通り、2重支払いの防止はNotaryが担います。その為、CordaアプリA上で維持される価値は、CordaアプリB上でも維持されます。Notaryは単なるハッシュチェッカーなのでどのようなトランザクションであっても対応できます。
CordaアプリA上の価値（例えばドルステーブルトークンかもしれませんし、サプライチェーンマネジメントシステム上の鉄鋼部品かもしれません）を自然とCordaアプリB へ渡すことができる。これがCordaの考えるインターオペラビリティです。
これはブロックチェーン業界で今考えられ始めているインターオペラビリティと比べると、ある意味原始的、技術的にはPrimitiveなソリューションです。独自性のあるアルゴリズム・データ構造を持った複数ブロックチェーン間をつなげることを考えてはいません。データ間に半順序接続性を持たせ、オブジェクト指向が生み出した継承の概念を適用し、アプリケーション間の垣根を超えるというのがCordaの示したインターオペラビリティになります。
なぜここまでシンプルなソリューションを提供しているのでしょうか？若しくは、このシンプルなソリューションはブロックチェーン業界にとって意味があるのでしょうか？
エンタープライズという分野を考えるとき、このシンプルさは大きな意味を持ちます。
理想的には、複数の用途、アプリケーションに対して、それぞれ最適な技術、最適なブロックチェーンを用い、その上でインターオペラビリティを持つことが最高の未来なのだと思います。
しかし、エンタープライズ用途を考えると、複数のブロックチェーン技術の間でインターオペラビリティを考える事は悪夢でしかありません。アプリケーション（やそのベースになるブロックチェーン技術）のアップデート時にその地獄の蓋が開きます。一つのアプリケーションをアップデートするたびに、関連を持つすべてのアプリケーションが正しく動作するかテストする必要があります。これはエンタープライズ用途では必須のプロセスです。例えば10個のアプリケーションが独立して稼働しているなら、それぞれのアプリケーションがアップデートするたびにそれぞれにテストすればよいです。全てのアプリが年に一度アップデートするなら年に10回のテストをすればよいです。ですが、これらすべてが互いに関係を持つ、つまりインターオペラビリティを持つ場合、年に100回のテストを行わないとシステム稼働の保証は得られません。
インターオペラビリティを企業が必要とするなら（そしてその未来は確実に到来すると考えます）基盤がそのインターオペラビリティを提供しなければ実運用には到底耐えられません。基盤が提供するなら、アプリ間連携部分は基盤に任せられる（＝テストが不要になる）のです。
これがCordaが基盤上でインターオペラビリティを用意した理由、そしてできる限りシンプルなソリューションを用意した理由です。
それがCordaが寄って立つポリシーなのです。
スケーラビリティ
スケーラビリティとは何でしょうか？ここでは単純に「ビジネスのスケール拡大にシステムが追従できる事」と定義しましょう。
ビジネスのスケールが拡大すると何が起きるかというと、
①単位時間あたりに発生するトランザクションが増える
②ビジネスに参加する主体が増える
この時、システムが追従できるかどうかをブロックチェーン目線で考えると、それは
①依存関係のないトランザクションを同時並行で処理できるのか？
②参加ノードが増えても処理が遅くならないか？
という質問に置き換える事ができます。
既存のブロックチェーン技術について語るつもりは無いのですが、多くのブロックチェーン技術は①も②も答えはNoになります。Cordaについて考えてみましょう。
①依存関係のないトランザクションを同時並行で処理できるのか？
通常のブロックチェーンは、複数のトランザクションを（あるルールに従って）一つのブロックに集約します。この作業のために、すべてのノードからその時発生したトランザクションを集約する必要がありますし、同時並行でブロック生成することはできません（PoWにおいて、同時に複数作られたブロックのうち、実際に使用されるのは一つだけです）
一方、１取引＝１トランザクション＝１ブロックという考え方に立つCordaの場合、互いに独立したトランザクションはそれぞれ同時並行で処理する事ができます。有償版であるCorda Enterprise では、処理をマルチスレッドＣＰＵに同時並行で流すことで、TPSの大幅な改善を実現しています。この速度向上もまた、Cordaの持つデータモデルの特徴の一つです。
②参加ノードが増えても処理が遅くならないか？
これまでのブロックチェーン技術は、大前提として生成されたブロックを参加者全員で必ず共有するようになっています。つまり、参加者が増えれば増えるだけ通信量が増え、そこにパフォーマンスのボトルネックが発生します。一方でCordaの場合、取引＝トランザクション＝ブロックを誰が見る事ができるのかは、個別のトランザクションごとに設定されます。（下図のFlow参照）
当然ながら大概のトランザクションは参加者全員に通知する必要がありません。つまり、参加ノードが増えてもそれに比例して通信量が増えるわけではありません。スケーラビリティを確保するにあたって、これは非常に重要な論点です。Cordaのトランザクションが全員に共有されないことは、スケーラビリティを確保する上で非常に重要な決定なのです。
全員でデータを共有しない事で課題になるのは、2重支払いの防止をいかに実現するかなのですが、ここでもCordaの設計は威力を発揮します。Notaryには通常Hash値しか送付されません。つまりビジネスが複雑化しトランザクションの内容が増えたり、ビジネスが拡大してトランザクションの量が増えたとしても、Notaryが格納するのは固定サイズデータであるHash値だけなのです。技術に少し明るい人であれば、ボトルネックになりそうなＤＢへの書き込みデータが、固定サイズデータであることが、どれだけパフォーマンスにきいてくるかは想像いただけると思います。
裏側でRDBやJavaを使うCordaは（特にOpenSource版の場合）、Key-Value DBや最新の言語を使う他のブロックチェーン基盤と比較して、単純なテストで高いパフォーマンスを発揮するわけではありません。しかし、現実的なビジネススケールアップに対してリニアにパフォーマンスを改善できるようになっている。
これがCordaが採用した方針です。
おわりに
Cordaのデータモデルは単純です。ブロックを解体して依存関係だけが明確化される半順序化しただけ。しかし、そうする事で
・プライバシー
・インターオペラビリティ
・スケーラビリティ
を論理的に確保したわけです。単純に思えるCordaのデータモデルの背景にはこれだけの洞察が含まれている。それを皆さんに少しでも理解していただければ幸いです。
＜ご質問・ご要望の例＞
- Corda Portalの記事について質問したい
- ブロックチェーンを活用した新規事業を相談したい
- 企業でのブロックチェーン活用方法を教えて欲しい 等々
SBI R3 Japan エンジニアリング部長
書籍出してます：https://amzn.asia/d/c0V31Vd
趣味：サッカー、ガンプラ、ドライブ、キャンプ