本記事では，新しい Corda 5 アーキテクチャの基盤の 1 つである仮想ノードについて掘り下げ、このアーキテクチャが与える影響に焦点を当てています。まず、アーキテクチャの変更によって我々が求めたこと、Corda 5で実現したいことを、グラフを使って具体的に整理してみましょう。

始めに、今までにない数のIDをオンボーディングすることで、アプリケーション ネットワークの拡大の際に生じる問題に対処したいと考えました。上図に示す通り、Corda 4では、アプリケーションネットワークに新しい IDが追加されるたびにオーバーヘッドが線形的に増加します。この原因として、後述する様々な要因がありますが、Cordaを既に活用されている企業の方は、この問題をよくご存じだと思います。 したがって、Corda 5では参加しているIDの増加に伴う、オーバヘッドの増加を削減したいと考えています。(訳注：上図の左Operating Load参照)

次に、アプリケーションネットワークにIDを登録した後、他のネットワークメンバーとの取引可能な状態を維持するために必要となるオーバーヘッドについてはどうでしょうか？Corda 4 以下のバージョンでは、オーバヘッドは一定のレベルに保たれます。これは、特定のIDについて（取引できない状態にするような）状態変化を起こす機能は存在せず、常に一定の状態でしか維持できないためです。さらに、IDは単一のコンピューターインスタンス上に置かねばならないという制限があるため、（あらたに、より大きなコンピュータへ移行する場合を除けば）ある時点で処理能力不足に陥ります。したがって、単一の物理的または仮想的なリソースの性能不足によりボトルネックが生じます。

Corda 5のクラスタ化されたサービス指向のアーキテクチャは、前述したオーバヘッドの線形増加という欠点を克服しました。IDは、トランザクションが完了のするまでの一時的なものとすることができます。現在、アクティブでないノードは、必要とされるまでリソースをほぼ消費せず、より高い負荷に対応するために以前にコミットされたリソースが解放されます。 負荷の種類には次のようなものがあります。

Corda 5はどのように仮想ノードを実装するのでしょうか？仮想ノードとシンプルな名前ですが、実際は名前以上に複雑です。仮想ノードはCorda 4とCorda 5の違いを明確に示した言葉であるといっても過言ではありません。つまり、ここがCorda 5の鍵となる部分なので、次のトピックにて深掘りしたいと思います。

ノード！これまでCordaの主役だった存在です。私たちは皆「それが何であるか」知っていると思っていますが、先に進む前に、まずはその立ち位置を再度確認しましょう。Corda Whitepaper（改訂版）にある定義を検証してみます。

原文: “The node acts as an application server which loads JARs containing CorDapps and provides them with access to the peer-to-peer network, signing keys, a relational database that may be used for any purpose, and a ‘vault’ that stores states.”– Mike Hearn, Richard Gendal Brown — August 20, 2019

訳: “Cordaのノードは、CorDappを含むJARをロードし、P2Pネットワークへのアクセス、署名鍵、あらゆる用途に利用できるRDB、状態を保存する「Vault」を提供するアプリケーションサーバとして動作します。”

– Mike Hearn, Richard Gendal Brown — 2019年8月20日

(訳注：Mike Hearn：当時のR3のチーフエンジニア, Richard Gendal Brown：R3のCTO)

なぜノードという名前なのでしょうか？実際、考えたこともなかったですが、Wikipediaを見ると以下の定義が書かれています。

”物理ネットワークノードとは、ネットワークに接続され、通信路を介して情報を作成、受信、送信することができる電子機器である。”

さらに、Bitcoinにおける「フルノード」といったブロックチェーンならではの概念は、Cordaがノードという言葉で表現したかった「ネットワーク上のルールに基づき、ネットワーク内で取引を行う主権的なエンティティ」と合致します。

ノードはどのような概念を含んでいるのでしょうか？

これは最大限包括的な理解です。一つ一つの概念が、私たちが実体として考えることのできる全体像に対する一側面を包括的に捉えようとしています。

Cordaのこれまでのノード中心のネットワークビューの現実的な問題は、スケーリングが線形であり、したがってコストも線形であることです。例えば、単一のIDが一つのノードだとすると、100のIDは100のノード、1000のIDは1000のノードとなります。

上図に示すように、線形に増加した場合、全てのIDを管理するにはあまりに多すぎることが分かると思います。実際、Cordaの初期バージョンでは、技術的な構築の問題により、スケーラビリティに焦点を当てることを断念しました。そうした背景もあって、Corda 5にてこの課題に取り組んでいます。かつて、我々は分散化に対して“最大限包括的“な理解をしていました。全てのエンティティが自分自身でノードを実行すると仮定し、ノードが現実世界での法的アイデンティティと結びつくモデルを想定しました。

当初はスケーラビリティを考慮しませんでしたが、Cordaにおいてスケーラビリティを増大させることが難しいというわけではありません。Cordaが選択してきたアーキテクチャーの根本的な採用理由を理解するためには、分散台帳というコンセプトが根源的に抱える脅威モデルを理解する必要があります。究極的に、Cordaは次の問いに答えようとしていました。

”複数の当事者間で共有されるデータベースを構築する際、悪意がないとは言い切れない当事者がいる場合、どのようにすればよいのか？”

当時は信頼できる第三者がいれば、その人を介して標準的なデータベースにDLTの制約を導入することで生じる複雑さやオーバーヘッドを回避できるという解決策を考えていました。

今思えば、この考えにはいくつかの点で疑問が残ります。

第一に、産業は分散的なシステムにより発展してきたわけではありません。ソリューションプロバイダーは、システムの側面や参加者リストなどのメタ情報の所有権を保持することを明確に要求しています。同様に、これらのサービスのユーザーは、一般的にサービスを利用するために独自のインフラを運用できるほど高度な知識を持っていません。したがって、ほとんどの企業が現在のニーズを可能な限り満たすために、完全分散型モデルの採用という選択肢を除外しています。

第二に、データベースを他の台帳と安全に切り離すことができるかどうかという観点と、個別のIDに提供されているデータに対して、純粋な意味で主権がないという観点を明確に区別できていませんでした。各IDが（あたかも切り離して）保有していると理解しているデータは、単一の信頼ゾーンの中でお互いに絡み合ったデータなので、本質的にデータに対する主権があるということはできないのです。Cordaの各参加者（ID)が持つデータとは、アプリケーションネットワークに含まれるデータを各参加者のプライベートビューとして取り出したものと言えます。また、以下の図に示すようなキーやスキーマを通して細分化された（各ID用の）データセットにたいして、各IDから見たコンテキスト情報を畳み込んで再構成したものとみなすことができます。

現在の暗号鍵の安全性は、これまで何度となくその安全性が破られてきたからこそ実現できているのと同じように、データに対しても同じような安全性を考えることができます。誰でもアクセスできるシステムからデータを取り出すことは、従来のシステムとは根本的に異なった問題が生じます。中央集権的なデータベースは、参加者のアカウントを作りますが、その参加者にインフラを移転し、運営できるほどの権限を与えることはありません。しかし、非中央集権的つまり分散型のデータベースでは、これらの権限が参加者に付与されることが求められます。漸進的な非中央集権化は、この技術を調査している人たちからの明確な要求なのです。

第三に、サンドボックスや暗号化など、信頼できない第三者がインフラをホストできるようにする技術的な解決策はあるものの、当時はソリューションに組み込めるほど成熟したものではないと考えられていました。しかし、しかし、Corda独自のサンドボックス技術(詳しくはこちらの記事をご覧ください)に取り組むこと、このビジョンの実現に着実に近づいており、それに応じて（分散台帳基盤が対峙すべき）脅威モデルも変化しつつあります。

最後に、上図に示したように、強力なユースケースを持つ最大主義者は、Corda 5をCorda 4と同じ方法でデプロイし使用することができます。重要な点は、Corda 5を使えば、多くのIDを一つの環境に展開できるからといって、必ずしもそうする必要はないということです。Corda 5は、有望なネットワークメンバーに選択肢を提案するオプション性を導入していますが、強制ではありません。

ノードそれ自体は、それほど面白いものではないです。Cordaをより広い世界で役立つものにするには、ノードがどのようにアプリケーションによってどのように接続され、それらの間でトランザクションが行われるかが重要となります。Cordaの価値は、ノードがネットワークにオンボードされて取引を行うことで初めて現れるのです。

勿論、ネットワークが生まれた経緯から、アプリケーションネットワークの管理者がインフラを集中管理する一方で、ユーザー（下図の例ではAlice）にはデジタルな主権(権利)を提供する必要があることを我々は理解しています。一般的にCordaとDLTプラットフォームは、このモデルを実現するのに適しており、将来的には、より簡単に実現されるであろうIDの移行技術の実現により、さらなる分散化が容易に実現できると考えます。

Corda 4においては、各IDの管理コストは、処理負荷の多寡にかかわらず一定程度必要なため、前述のモデルの実装には適していません。

ここまで議論してきた課題の根本的な課題は何なのかというと、それは、現在の（Corda 4の）ノードに関する実装が、最初のバージョンのCordaの時から何も変わっていないことを忘れてしまっていることにあります。根本に立ち返り、大切なのはパッケージングではなく、コンセプトそのものであり、「それによって何ができるようになるのか」ということなのです。ノードというのは、私たちが使っている便利な省略記法の域を出ないので、それほど重要ではありません。重要なのは、ネットワークへのIDの登録、取引の実行、そしてDLTソリューションの価値を証明することです。

ここまで時間をかけて議論してきた理由は、「仮想ノード」の仮想という言葉を聞くと、ごく自然に、同じ計算インスタンス内で並列処理を可能にし、1つの「Cordaノード」が複数のIDに関する処理を実行できると考えてしまいがちだからです。

私たちは、仮想化技術や、仮想化された物理インスタンスの上に重なる抽象化についてよく知っています。しかしながら、これはCordaにおける仮想ノードとは異なる「仮想化」であり、我々の考える「仮想ノード」というコンセプトは、はるかに革新的で広範囲に及ぶものです。

仮想ノードを理解するためには、まずFlowについて知る必要があります。

Flowとは、トランザクションの当事者がある提案について合意に至るメカニズムです。これは、分散型台帳の更新が成功し、すべての当事者がその更新が有効であると判断し、合意する形で行われることが多いです。これはrun to completionプロセス（実行から完了までのプロセス）であり、CorDappを作成を通して簡単に実現できます。内部では、CordaはFlowを適切に分割し、関係するIDがそれぞれ提案されたFlowの適切な部分を処理していきます。

上図の例では、実装にCorda 4を使用しており、各IDとそのステップがCorda ノードによって配置されています。これはグローバルネットワークでの実行が、どのように当事者間で細分化されるかを強調するために行っています。

さらに深く掘り下げると、以下の図で、各ノードが各ステップごとに様々な処理をスケジュールしており、それらはすべてステートマシンを通じて制御されていることがわかります。

Cordaが複数のFlowを同時に実行できるのは、このステートマシンのおかげです。どのFlowの処理を開始し、実行するかについては、通常のOSが提供するスケジューラーと同じような動作をします。

実際、Flowフレームワークはコンセンサスプロトコルのステップをスケジューリングするために設計された分散ステートマシンと考えることもできます。Flowは中断された時点で再開するためにチェックポイントが保存されます。これにより中断された時点から実行が開始できるようにスケジュールされます。

さてここまで多くの説明がありましたが、未だにこの疑問だけは残っています。”仮想ノードとは何か？”。 私たちは、Flowを理解することで、その答えを導き出します。

Corda 5はFlowのプロセスステップの実行を仮想化し、複数のIDのFlowや複数のアプリのFlowを同じ環境内で同時に実行することを可能にします。仮想ノードのインスタンスは、必要な実行ステップを処理する際だけ生成され、処理が終わった後は消失します

つまり、仮想ノードとは、ユーザーのコンテキストとトランザクション実行に必要な一時的な計算リソースの組み合わせを、特定のIDのために用意したもの、ということになります。

上図の時間軸のどの時点でも、仮想ノードのインスタンスが多数実行されている可能性があり、インスタンスの個数の上限は、演算ユニット（Flowワーカ）を幾つ用意しているかに依存します。さらに他の仮想ノードインスタンスがチェックポイントストアに停止した状態で待機している場合も存在します。