Corda5のオープンソース化の記事（ここ、日本語訳）に続いて、開発方針を導く哲学について、掘り下げてみましょう。完全に異なる場所、そして異なる国、地域にいる2人が何かに同意し、その結果が２人に同時に展開されていく世界を想像してみてください。そこには手間のかかる再確認作業や、いつまで立っても送信が終わらない1980年代のFaxを使うようなビジネスプロセスはありません。

もしくは、データを所有しつつ、誰かに共有できる世界を想像してみてください。業界で共有された一つのデータベースがある世界を。そこでは、包括的な制御と支配権を持つ中央の企業を通じてライセンスを取得する必要はありません。

これがCordaの創設ビジョンでした。

あれから5年後、私たちはどんな障害を乗り越え、何を学んできたのでしょうか？

Cordaは、 最初のホワイトペーパーに示された単一のビジョンに基づいて構築されました。このホワイトペーパーは、単なる技術的な説明でなく、Corda開発者に対する、”世界へ飛び出し破壊的な変化を起こせ！”という叫びでもありました。

あれから５年、この創設のビジョンを再検討する時が来ました。学んだ教訓を取り入れ、サービスを提供している業界の変化を理解した上で、この先何を実現できるのかについて、改めて、再宣言したいと思います。

最初のホワイトペーパを覗き込みましょう。：

当初のビジョンの核となる部分は、「 単一の グローバルデータベース」というフレーズに要約されています。CordaとCordaを利用する業界において、様々な情報が飛び交い、その情報が変化していく様子を頭に思い浮かべてください。

このとき、アプリケーションは、この世界の重要な”イネーブラー”として存在しますが、その中心にはありません。そう、確かに、上記の声明には情報の変化に対する言及はあっても、その変化を起こすために必要な協力、協業に対する言及はないのです。

時とともに、私たちはコミュニティから、”Corda とは何か”という質問の中心に”ワークフローをカプセル化するビジネスロジック”があると教えられてきました。

Corda上のチェーンはそれぞれ、何らかのビジネスコンテキストによって制約され、グローバルデータベース内で個別のスキーマとして動作しています。

更に、DLTの使用が拡大するにつれて、ビジネスが規定するこのスキーマを、同じ基盤上に展開する必然性は何もないこともあきらかになります。

インターオペラビリティという言葉は再定義されるべきです。つまりインターオペラビリティとは、プラットフォーム間の相互乗り入れという意味ではなく、特定のビジネススキーマからプラットフォームのセマンティクスを削除することであるべきです。重要なのは、データそのものであり、そのデータがEthereumの上にあること、Cordaの上にあることは重要ではないのです。

異なるコンテクスト（技術基盤）をまたいだチェーンの操作は、2つのコンテキストの両方にIDを持つ同一の主体による、２つのアクションとして構築されます。主体、人、組織は、取引や交流を行っているコンテクストに応じたアイデンティティを持っているはずです。

この考え方によって、各ネットワークもしくはチェーンは、誰が参加して誰と対話できるか、そして、他のネットワークが誰とどのように対話できるかという、ガバナンスに関する独自のルールを設定できます。

新しいビジョンのCordaネットワークは、アプリケーション有りきで構築される必要があります。

チェーンは孤島ではありませんし、孤島にすべきでもありません。もちろん、分離されていることは重要です（そして、重要な規制要件であることも多いです）ただ、分離は選択肢の一つにしかないこと、そして可逆的なものである必要があります。

ただし、異なるネットワークの相互接続の容量には注意が必要です。一方の側に他方の操作の詳細を過度に負担させたり、一方のネットワークの範囲内にとどまる必要のある情報を公開したりすることなく、その相互接続について議論できるように提供する必要があります。

今日の世界では、インターオペラビリティが最も重要です。なぜなら、単一のベンダーやテクノロジーの選択に「捕らえられる」リスクを誰も冒したくないからです。特に、支配的な技術の変更ができないとか、あとになって問題解決に立たない技術であることがわかるような場合にはなおさらです。一部のユースケースでは、パブリックブロックチェーンが完全に理にかなっていることもあります。

グローバルデータベースの概念に戻ると、アプリケーションの開発当初であれ、追加された機能であれ、各スキーマは、ドメイン内で信頼されるIDを使って安全に情報を変化できるように構築する必要があります。第三者が「根回し」して、目に見えないルールを破らないことを願うことに意味はありません。

Corda Architectureの次のイテレーション（訳注：Corda５を指す）では、この構成可能性の問題を設計の中心に据えています。CordaからCorda、Cordaから他のプラットフォームであっても、プラットフォーム間の相互作用について一般化した形で想定し、明確に定義されたAPIを使って両方の世界を行き来できるアプリケーションを構成する能力が鍵となります。

例えば、デジタル通貨で競走馬を購入するタスクを例に、Cordaアーキテクチャの既存バージョンと今後リリースされるバージョンでどのように実現されるかを対比してみましょう。

アリスとボブ、私たちの大好きな暗号のカップルは、アリスの「素晴らしい牝馬」をボブに売ることにしている。もちろん、アリスの牝馬が将来のダービー馬なのか、それとも年寄りの小娘なのかは、DLTではボブに確認することができませんよ。

アリスとボブは単一のネットワークに属しています（実際、ネットワークのインターオペラビリティの概念は存在しません）。アリスは、いくらかのKatCoins（Fungible State）と「馬」（LinearState）の交換という取引をボブに提案します。

ネットワークにはKatCoinの発行者がいて、他の開発者がContractを用意して使用できるようにしていると想定しています（もちろん、そのコードのライフサイクルの統合と管理はインテグレーターに残された課題です）

アリスとボブは、馬とコインを交換できるアプリケーションを発見するか、あるいは自分たちでアプリケーションを作成し、ボブはアリスが自分（たち）の馬をトークンとして自己発行することに同意します。

ボブは、グローバルにホワイトリストに登録されたNotaryの署名によって（馬とKatCoinを交換する）アトミックなトランザクションを受け入れ、その結果がすべての参加者に伝達されます。

アトミック性によって、この契約トランザクションは単純な成功または失敗をもたらします。更に、このやり取りは、本質的に、異なる2つのブロックチェーンを絡み合わせることになります。

概念的には、これは非常に単純で推論が容易ですが、多くの問題が発生します。

第一に、このグローバルネットワークは、一つのペルソナが複数のIDを持つ可能性を考慮していません。そして、個々のチェーンがどう変化するのかを支配するルールを（Notary、コンセンサスパラメーターなどの観点から）指定することもできません。

さらに、２つのブロックチェーンが絡みあうことにより、スケール拡大時のBlockchain検証が非常に困難になっています。そして、より実用的なレベルでは、さまざまなベンダーが構築したJavaコードが混在することを意味しています。これは、アプリケーションのライフサイクルと品質保証に致命的な問題を惹起します。

Corda 5は、バックチェーンを混在させる必要はないと考えています。そうすると、単一のチェーンは、独自のルールを備えた独自のアプリケーションレベルのネットワークと考えることができます。

あるStateを別のStateと交換することは、APIと一つのアプリケーションネットワーク内に定義される「代用信頼 “vicarious trust” 」の概念によって可能になるクロスネットワークスワップになります。「代用信頼 “vicarious trust” 」とは、もし私が多くのチェーンでアイデンティティを持っているならば、プラットフォームが提供するAPIを通じて、他のチェーンにいる自分に何かをするように指示することができることを意味します。

この考えのもとで構築されるCorda5では、強力なバージョニング、シンプルなライフサイクル管理、展開可能なID認証、および簡単なバックチェーン検証が可能になることになります。

その一方、クロスネットワークスワップ実現のために、複数のチェーン上での複雑な非アトミック操作を複数行う必要が発生します。ただし、この複雑な操作の実現はプラットフォームの課題になります。つまり、プラットフォームのCordaが、アプリケーションベンダーの代わりに手間のかかる作業を行うことになります。プラットフォームの複雑さがエンドユーザーエクスペリエンスの簡素化を可能にするというケースの一つです。

これは、最終的にプラットフォームが存在し、採用される理由になります。

上記の例を続けると、アリスとボブはそれぞれ2つのID、Alice-HorseとAlice-Cashを持ち、各ネットワークに参加し、自分のIDと現実世界の実体が一致していることを証明する十分な資料をオペレータに提供しているものとします。

取引は、”馬ネットワーク”内でトランザクションが提案され、ボブは”現金ネットワーク”でアリスに支払うように指示します。

”馬ネットワーク”は現金を理解する必要もなければ、モデル化して取り扱う必要もありません。ただ”現金ネットワーク”と対話するだけになります。

事実上、ボブのアイデンティティは、明確に定義されたAPIを通じて、他のエンティティと相互作用するために自分自身に指示を発行することができるようになります。（Bob-HorseがBob-Cash西路を出すことになります）そして、互いからの指示を代理的に信頼することができるようになります。

グローバルデータベースに追加される各スキーマは、偶然に追加されるのではなく、あるエンティティによって特定の目的のために置かれます。その目的は「アプリケーション」として表現されます。

アプリケーションは、ワークフローを通じて参加者が変更できる一連の状態を定義することで具現化されます。アプリケーションは、このとき、相互作用する相手のIDを定義することで、メンバーIDが相互作用できるルールを設定する事もできます。

アプリケーションが、CorDappとはどのようなものになっていくのかを規定します。また、アプリケーションは、分散であれ集中であれ、何らかの目的を解決する方法を提供し、その目的に賛同する人々によって使用されることになります。

Corda 5は、小規模から始めて、必要に応じてスケーリングし、必要に応じて配布と分権化を容易にできることを目的としています。

Corda Architectureバージョン1.0の最大の欠点は、すべてのエンティティが真の分散化を一夜にして受け入れるという推定でした。Corda Nodeの設計は、ネットワークの各メンバーが自分の参加を管理したいと考えており、重要なことに、技術的およびロジスティック的に管理できるという考えに基づいて構築されています。

Cordaの上にアプリケーションネットワークを構築する初期の採用者は、ここでの考え方の誤りを浮き彫りにしました。彼ら自身の顧客は、彼ら自身のインフラストラクチャをホストすることに挑戦する準備ができていませんでした。さらに、従来のビジネスでは、DLTテクノロジーがプロセス内の調整または「仲介者」の削除からもたらす大きなメリットを確認しながら、顧客への制御を分散化する準備が同様に整っていませんでした。

Corda 5は、 ”プログレッシブ分散化”の概念を取り入れています。クラスター化されたアーキテクチャにより、単一のエンティティが単一の論理的なコンピューティング環境内で多くのIDを管理できると同時に、それらのIDが後で独自の環境に移行するのを妨げることはありません。

ユーザーや業界の準備が整ったときにはじめて、追加の技術的なソリューション（独自環境への移行）が提供されることになり、それまでの間は、DLTが何を提供できるのか探すという目的に完璧に合致したものになります。

このことは、プロジェクトのリスクを軽減し、他の方法では実現できなかったようなことを可能にするという意味で、非常に強力なことなのです。

技術スタックにおけるID部分の独立化P2Pレイヤーの独立化を通じて、アプリケーションをシームレスに移行する機能が存在します。

自己ホスト型なのか、リモートホスト型なのか、集中型なのか、マネージドサービスなのか、分権化された自己署名型なのか、こうした課題は、チェーンの存続期間を通じる基本的で根本的な選択肢なのではなく、単なるシステム配置の問題になります。

小規模から始め、ローカルから始め、集中化から始め、時間の経過とともに、必要に応じて外に向かって流れていくことができます。各ステップでビジネスの問題を再発明して解決するという制限はもはや有りません。それでも、そのソリューションは依然としてR3 DLTテクノロジーを活用して、業界の問題に対するDLTに裏打ちされたソリューションとなっていくことでしょう。Cordaは依然としてCordaなのです。

最後に、Corda 4のアーキテクチャは、純粋に分散化された焦点で、ネットワーク内のすべてのエンティティの参加がほぼ等しいと想定していました。

ネットワークの「中に」あり、 Cordaノードを実行することに関連する固定費 は、参入障壁が非常に高いことを意味します。特に、IDのインフラストラクチャの管理が、ホストされた方法で単一のエンティティによって行われている場合。

Corda 5の仮想ノードとスケーラブルなワーカーアーキテクチャにより、数千のIDを単一の論理コンピューティングスタックでホストできますが、それらのIDによる実際のアクティビティが発生しない場合、スタックはゼロに縮小できます。Corda 4は、起動と停止の必要性を想定していませんでした。Corda5は、これをアーキテクチャの本質的な部分として提供します。これにより、個々のIDが高速で処理されない場合に、TCOが大幅に削減され、コンピューティングリソースの効率的な共有が可能になります。