前回の投稿では、プラットフォームを再考するきっかけとなったいくつかの観察事項と、新しいメジャープラットフォームバージョンを定義する際に達成しようとした目標についてお話しました。この投稿では、前回の投稿で得られた知見に対応し、目標を達成するために、Corda 5の開発の一環として取り組んでいる新しいコンセプトを紹介しています。このブログシリーズでは、今後、これらの新しいコンセプトのいくつかをより深く掘り下げる機会があると思いますが、今回の投稿では、この5つのコンセプトを俯瞰してみていこうと思います。

Corda 5はまだ活発に開発が行われています。この新しいアーキテクチャでの最初のGAリリースに向けて、まだやるべきことがたくさんあります。方向性を少しずつ改善・微調整する機会もたくさんあると思いますので、皆さんのフィードバックをお待ちしています。

（１）”アプリケーションネットワーク”と新しい”アプリケーションパッケージ”の導入

（２）️新しいモジュラーAPIと開発者ツール

（３）可用性とスケーラビリティ実現のため、イベント駆動型のアーキテクチャへ移行

（４）マルチネットワークとマルチテナンシーをサポートする仮想ノードの導入

（５） パッケージング（バンドル）導入とインターオペラビリティ実現に向けた新プロトコル導入

新しい5つのコンセプトはこの5つになります。順を追って説明していきます。

前回の記事でご紹介したように、Corda4から得られた教訓として最も重要なポイントは、（他のブロックチェーンのようにまずネットワークありきのモデルではなく）アプリケーションを中心としたモデルに移行すべきだということでした。

より具体的にいうと、ノードに始まり、ビジネスネットワークを構築するという抽象化された階層構造を中心に考えるのではなく、開発者から始まりアプリケーションを構築しユーザーのフィードバックを得ていくというシステム開発の一般的な方法論に合わせてプラットフォームを最適化することを意味します。

Corda5では、開発者はビルド時にインストーラー（Installer)と呼ばれるアーティファクトを定義します。インストーラー（Installer)では、アプリケーションを実行可能な（許可性の）ネットワークを定義します。インストーラには、CorDappパッケージ（Bundleと呼ぶ）、ネットワークに関する情報、アプリケーションネットワークを管理するメンバーシップ属性を含むことができます。

インストーラー（Installer)は、分散したアプリケーションネットワークにおいて、参加者を参加させたり、バージョン管理を行うための単一のアーティファクトとなります。アプリケーションネットワークは、今のところ単なるCordaネットワークとなっています。

許可制ネットワークであることはそのままに、メンバーシップ管理の責任は、専用のサービス（CENM, Corda Enterprise Network Manager）から、ノード上で動作するシンプルで拡張可能なアプリケーションに移行しました。その結果、ネットワークを管理するために専用のインフラを実行する必要がなくなりました。

私たちは、APIをインターフェイスベースでモジュール化するように書き換えました。Corda5の新しいプラットフォームは、積み重なったレイヤーだと考えることができます。下から順に

安全なネットワークとその上でのP2Pインタラクション、位置に関わらないピア・メッセージング、安全な暗号鍵。

データに依存しない形で、分散型アプリのAPI

分散した当事者間で信頼性の高いデータを共有する（WYSIWISの実現: What you see is What I see.）

ネットワーク上の特定のエッジ（ノード）でビジネスロジックを実行する

の4つの階層が考えられます。私たちのAPIは、緩やかにこの階層に準拠していて、（詳細は次回のブログ記事で）、これは、例えば以下のような場面で役に立ちます。

・開発者は、段階に応じて適切なレイヤーと連携することで、アプリケーションを段階的に（ボトムアップで）構築することができます。このメンタルモデルはAPIを通じてより直接的に表現されます。

・開発者は、アプリケーションの特定の部分を独立してテストすることができます（例えば、ワークフローのモックなどを独立して構築できます）

・開発者は、私たちが実装している台帳モデルを使わず、独自の永続化モデルを採用することができます。これにより、プラットフォームは新しいユースケースの可能性を広げます。

さらに、私たち自身の開発速度にも大きな影響を与えます。インターフェースの背後で並行してより迅速な開発が可能になり、将来的に特定のレイヤーに新しい実装を導入することもできます。

Corda5で改善したい重要な指標の一つに、開発時間とコストの削減があります。開発者の体験は、この目標を達成するための最優先事項になります。Corda 5 Developer Previewでは、それらの取り組みの一部を導入しています。例えば

・ノードとのインタラクションにOpenAPIを採用

・ローカルマシンの開発を管理するための新しいCLIツールを導入

・CI/CDパイプラインにフックアップするためのAPIを導入

等です。是非、Developer Preview版で詳しくチェックしてみてください。

この移行はCordaの内部動作を大幅に変更するものになります。そして、みなさんが、Cordaをどこに、どのようにデプロイするか検討する際に大きな影響を与えます。

移行の目的は、再構築の主な目的の一つである、分散したミッションクリティカルなシステムを動かすために、Corda 5を高可用性とスケーラビリティを備えたものにするため、と言うことになります。

移行の内容を一言で言うと、「Cordaクライアントをイベントドリブンなシステムにする」という言葉に集約されます。

Cordaノードのランタイムは、もはや単一の JVM に限定されるものではなくなります。代わって、（特にHA構成の場合）イベントを処理するためのワーカークラスターによってCordaノードは構成されることになります。

各ワーカーはメッセージバス（Kafka）をリッスンするモジュールになり、それぞれ独立したサービスを提供します。ワーカーは、Java仮想マシンのインスタンスがデプロイされたコンテナと考えることができるようになります。

目的に応じて、複数タイプのワーカーを用意し、それぞれに特定の冗長性ポリシーを持たせることができます。例えば、同じワーカーの複数のアクティブバージョンをクラスタ内に配置することもできます。

ワーカーの冗長性は、何か問題が発生した場合に次のワーカーに即座にフェイルオーバーするという可用性の実現につながります。また、イベント処理を並列化することで、バースト的なシナリオでのスループットを向上させることができます。

このデプロイアーキテクチャはダイナミックスケーリングにも適しており、新しいワーカーをクラスターに追加し、需要に応じてクラスターを拡大・縮小することができます。まさに現代的なコンテナオーケストレーションをイメージして設計されています。

（３）で示したCordaノードの新しいアーキテクチャに対応した新機能として、仮想ノードの開発を進めています。その名の通り、仮想ノードは、Corda4のノードと論理的に同等なものを仮想で構成する機能になります。

仮想ノードは、複数のアプリケーションプロセスに対して、それぞれ「データ、アイデンティティ、鍵」をマッピングすることで実現されます。

例えば、ネットワーク1に所属するAliceがアプリA/B/Cを使用している場合を考えましょう。アリスは、共有されるクラスタを利用しつつ、自分の鍵とデータへの分離された専用アクセスを保持し、自分のアプリケーションが他の人のアプリケーションから分離して実行されることを保証することができます。Corda5はサンドボックス化可能と言うことです。

同じクラスタ上で複数の仮想ノードを独立して稼働させることができる。これにより次のような機能を実現することができるようになります。

> マネージドサービスプロバイダー、それから分散化（Decentralisation）を重視する開発者にとって重要な機能になります。

> アリスは同じ「クライアント」を使って、追加コストなしで複数のアプリケーションネットワークに参加することができます。

> 従来は複数のノードを運用していた場合に有効な機能になります。

> UATなど本番に擬したテストでは、クラスター（複数の仮想ノード）をダイナミックに構成することで、テストのセットアップや実行時間を大幅に短縮することができます。

最後に、仮想ノードは「プロセス、データ、キー」のマッピングに過ぎないため、移植が可能です。これは、例えばノードオーナーが物理的にノードを変更したい場合に、異なる「クライアント」で再構築できることを意味します。元のクラスター運営者の協力を得て、仮想ノードはそのデータを別のクライアントに移行し、鍵は新しい環境で安全に生成されるようにローテーションすることができます。

（４）で見たように、アプリケーションプロセスはサンドボックス化されます。また（１）で見た通りインストーラー（Installer)と呼ばれる考え方も導入されることも見てきました。

これらによって二つの「コンポーザビリティ（結合可能性）」に大きな改善が実現します。

アプリケーションパッケージはそれぞれのサンドボックスにロードされるので、他のアプリケーションやクライアント自体との依存関係が衝突するリスクはなくなります。

Stateコンポーザビリティとは、CorDapp間でのインターオペラビリティという説明も可能です。そして、Corda５では、Stateコンポーザビリティは、インストーラ（Installer）の境界でのみ可能になります。つまり、一つのノードに二つのアプリケーションが存在する場合にのみ、Stateコンポーザビリティは実現可能になります。これにより物事はよりシンプルになります。

開発者は、複数のアプリケーションをバンドルすると、Stateコンポーザビリティを利用できます。（勿論テストすることもできます）同時に、他のアプリケーションがそのStateを消費できないという保証も得られることになります。

さて、

・バンドル化（複数のインストーラ(Installer)を同一ノードに配置する）が適切なソリューションではない場合どうすればよいでしょう？

・既存のアプリケーションネットワーク（または他のブロックチェーンネットワーク）にアクセスしたい場合はどうすればよいでしょう？

これは、私たちにとって大きな課題です。

CordaConのセッションの一つでは、2つ以上のアプリケーションネットワークを相互運用するために、開発者が従うべき明確なプロトコルをプラットフォームに導入することを計画しているいくつかのアプローチを紹介しました。このアプローチでは、独立したアプリケーションネットワークがデータを参照したり、状態を再発行したり、アトミックなスワップを最小限の事前調整で行うことができるようになります。仮想ノードによるマルチネットワークのサポートと合わせて、ネットワークのネットワークを形成するためのより有機的なモデルとなり、私たちが目指す規制に適合した価値ある次世代インターネットを実現します。

ここで示した5つの開発重点分野によって、Cordaが今後どこへ向かうのかのヒントになればと思います。（そして、前回の投稿が、その背景の説明になればと思います）

今回、私たちはプラットフォームの多くの（非機能）要件を変更しましたが、そのDNAは変更していないということです。

・モジュラーAPI、新しいツール、パッケージングによって、Cordaでの開発をより速く、より楽しくすることを目指しています。

・新しいアーティファクトであるインストーラ（Installer)と、よりシンプルなアプリケーションネットワークを組み合わせることで、市場投入プロセス、オンボーディングプロセス、バージョン管理プロセスなどがよりシンプルになるはずです。

・ワーカークラスター間で仮想ノードの操作を移動させることができるので、企業の成長に合わせて運用モデルを柔軟に変更することができます。

・アプリベースのネットワーク管理と仮想ノードにより、関係者全員にとってCordaの運用コストが低くなるはずです。

・Cordaの新しいイベントドリブンアーキテクチャは、最も洗練された企業のマルチパーティユースケースを追求し、CBDC、グローバル決済ネットワークや、ミッションクリティカルな市場インフラを動かすのに十分な力を与えてくれるでしょう。