Corda4の技術的特徴
--
____________________________________________________
＜お知らせ＞
SBI R3 Japanブログは、MediumからSBI R3 Japanのポータルサイトに引っ越ししました。引っ越し先で、mediumの過去記事も閲覧可能です。今までとは異なる新しいコンテンツも発信してまいりますので、お気に入り登録をぜひお願いします！
____________________________________________________
2月にCorda4がリリースされました。今回のアップデートの中で、特に重要な3つの新機能について説明します。
１．Reference States（参照ステート）
２．トランザクションにおけるネットワークパラメータ設定
３．署名制約（Signature Constraints）
これらの機能は、いずれも、ブロックチェーンアプリケーションを永続的に使用する（＝将来の更新に耐えうる）ために必要な機能です。本当の意味で商用化を目指すならば、データ更新、システム更新、ネットワーク更新といったものへの配慮が不可欠なのです。（WindowsとMicrosoft officeがなぜ使われ続けているのか、その理由を考えてみてください。）
ここでは、Cordaに関する最低限の知識があることを前提としています。最低限の知識は例えばこちら https://docs.corda.net/key-concepts.htmlをご覧ください。(日本語字幕付きの動画がございます）
１．Reference States（参照ステート）
「参照しているデータが最新のものである場合に限って、このトランザクションを承認します。」 実務上こういった要件が出てくることはないでしょうか？
Cordaは取引を安全に実現するために、”what I see is what you see（あなたと私が同じものを見ている事）”を保証します。私の保有するノードが「あなたは私にお金を借りている」と表示しているなら、同じものをあなたも見ていることを保証したい。これがCordaのやりたいことです。
だからこそ、R3社はコンセンサス、決定性、契約検証などに多くの時間を費やしています。しかし、単一の事実に同意することですべてが完結するわけではありません。時には、ある事実だけではなく、その事実の基礎となるデータに対しても合意する必要がある場合もあります。
この状況を理解するために、ブロックチェーンを使用した保険契約を例にとりましょう。
ここではまず、何かしら保険請求があって、その支払いを行おうとしている時点から考えましょう。
私は一つのトランザクションを作成し、CordaSettlerを利用した支払い履行を何らかの支払い手段へ指示すると同時に、保険請求に対して支払い済みであることを記録するでしょう。
そして、私はこのトランザクションに署名し、まもなく保険金があなたの銀行口座に着金し、保険請求に対する支払いが完了することをあなたに通知することになります。
…ところが、あなたがこの請求プロセスの途中、あなたは銀行を変えました！私の保持している支払先のデータは古くなっていました。
他にも、あなたが上司の承認なしに決済してしまうかもしれないという問題も考えられます。例え支払いが分散台帳上で行われたとしても同じです。あなたの承認は得られているのですから。ただ、今日、あなたに権限があるかどうかを確認しなくてはならない。
この問題に対する解決策は単純です。 「実行したいトランザクションと比較するための参照データ（reference state)があります。参照データが最新のものである場合にのみ、トランザクションを確認してください。」
上記の保険の例であれば、分散台帳上に「あなたの銀行口座」を示すデータがあればいいのです。それは事実上あなたから世界への通知です「こちらが、私への支払いに使用する方法です。」あなたがもし銀行を変えるならば、あなたは「あなたの銀行口座」を更新することになります。
さて、Corda 4では最新の「あなたの銀行口座」を参照することで、支払いを指示する前に変更を発見できる機能を提供します。
「データが最新のものである場合にのみトランザクションを処理する」という考えは、スマートコントラクトの世界で非常に重要な概念になると考えています。
より詳細については、こちらを参照ください。
https://docs.corda.net/api-states.html#reference-states
２．トランザクションにおけるネットワークパラメータ設定
「過去にこの取引が確認されたときのネットワーク（のルール）はどんなものでしたか？」
さて…これは退屈で些細な話に思えます。しかし、それはCorda Networkを拡大するうえで非常に重要なテーマです。
Cordaの壮大なビジョンを思い出してください。
（https://medium.com/corda/universal-interoperability-why-enterprise-blockchain-applications-should-be-deployed-to-shared-3d4daff97754）
我々は、数多ある単一目的ブロックチェーンネットワークをはるかに超えたところを目指しています。もちろん、特定の規制や地理的、もしくはビジネス上の要件によっては、誰がそのネットワークに参加し、誰がコントロールしているかが重要な場合でも、Cordaはうまく機能します。たくさんのこうしたネットワークが育っているのを目にしています。
しかし、一つのコンテキストで作成されたステート（State）を他のコンテキストで再利用するユーザが多いことも確かです。Cordaノードによって構成された「インターネット」上で、ステートは予期せぬ方法で使用され、分割され、そして再結合していく事も可能です。そして、こうした状況は、未来の（まだコードを書いたこともない）開発者の想像力次第でどこまでも広がりえるのです。
そして、こうしたビジョンを現実のものとするために、我々はいくつかの準備が必要です。
例えば、Corda Networkのようなネットワークは長い間存在し続けるでしょう。
(Corda Networkについては https://medium.com/corda/the-birth-of-the-corda-network-foundation-55f346304780 に詳述しています。）
当然、Corda Networkはアップグレードを経験するはずです。ノータリープールが追加されたり、古いノータリーが廃止されたり。Cordaの新しい機能は標準的なものになっていく一行で、古い機能は非推奨になっていくでしょう。誰もが使うことになるような一般的な暗号化手法が新たに追加されていくでしょう。
さて、ここで疑問が生じます。
ネットワークに新たに参加した人が、過去のトランザクションが有効なものだったかどうかを確認すべきかどうか？過去のトランザクションは、どのようなルールにのっとっていたのか？そのルールをどのようにして知ればいいのか？
たとえば、Bitcoinでは、その答えを（ソフトウェア的に）ハードコーディングすることで解決しています。しかし、こうしたルール（これを我々はネットワークパラメータと呼んでいますが）は、サブネットワークごとに、あるいは時期によって異なる可能性があります。
こうしたパラメータも含めてハードコーディングすることは非常に面倒です。
そこで、(バージョン4以降の）Cordaでは、ネットワークパラメータへの参照をすべてのトランザクションに含めることにしました。あるノードが過去のトランザクションの有効性を検証する際、どのようなバージョンのネットワークパラメータが有効であるかを正確に知ることができます。
一見マイナーな機能に思えるかもしれません。しかし、この機能は、the Corda Network (https://medium.com/inside-r3/top-5-facts-about-corda-network-e5ced4287123)
のような、大規模なネットワークを採用し、そのネットワーク上へシステムを移行する事を検討する際には重要なカギとなります。
3. 署名の制約
「アプリをアップグレードするにはどうすればいいですか？」
これは明らかに重要な課題です。
当初我々が想定していたよりも困難な課題であり、同時にCorda4に
よってこの課題を実現することの困難さも明らかになりました。
しかし、解決を待つだけの価値はありました。
署名制約という新機能とCordaのシリアライゼーションフレームワーク
を活用することで、Cordaは画期的な能力を獲得しました。
次のような状況を考えましょう。
あなたたちはコンソーシアムを作って、ビジネスの一部を自動化するために、ブロックチェーンアプリケーションを構築しました。
ここではそのアプリはあるソフトウェアベンダーによって書かれたとしましょう。
コンソーシアムではそれぞれにCorda 4（もしくは相互運用可能なCorda Enterprise 4）をインストールし、アプリをインストールし、コンソーシアムに参加した人々はアプリ上で取引を開始しました。
さて、アプリケーションをアップグレードするとき何が起きるのでしょう？
事前に何も考えていなければ、DAO問題（https://en.wikipedia.org/wiki/The_DAO_%28organization%29）や、Code is law問題（https://www.coindesk.com/parity-floats-fix-160-million-ether-fund-freeze）を前に、あなたはにっちもさっちもいかなくなるでしょう。
たとえ考えていたとしても、分散アプリ内に個別にアップグレード機能を実装することは困難であり、エラーとバグの温床になりえます。
そこで、Corda 3では、アプリケーションのアップグレードを可能にするためのやや強引な方法を用意していました。
それは、ネットワーク内で使用可能なアプリケーションの「ホワイトリスト」を用意し、リストのアップデートをネットワークの管理者に許可するという方法でした。短期的な措置とはいえ、中央集権的であり、決してスマートではなかった。しかし、うまくいきました。
Corda 4ではここから大きく踏み出しました。
Corda4では、「ソーシャル」なアプリケーションアップグレードシステムを選択できます。例えば
「次に示す一つの署名（例えばビジネスネットワークを主催する主体の署名）もしくは、次に示すN個の署名のうちM個の署名が付与された(n-of-m)アプリは、このState（CordaのUTXOモデルにおける未使用アウトプットの事）を消費することが可能。」
というスマートコントラクトを記述できます。
これは大した変化ではないようにも思えます。しかし、Cordaのシリアライゼーション・フレームワークと組み合わせると、ブロックチェーンシステムに、画期的な新機能をもたらすのです。つまり、アプリのローリングアップグレードです。
ビジネスネットワークに参加するすべての参加者にアプリをアップグレードさせるその具体的な手順を考えれば、ローリングアップグレードの重要さが理解できると思います。
参加者全員が同じ日にアップグレードを完了させる必要がある等という考えが妄想に過ぎないことはご理解いただけると思います。
さて、非中央集権的なアップグレードロジックを提供し、個別のノード管理者にアプリアップグレードに関するある程度の自由を与える署名制約という機能。そして、データ構造とそのやり取りに関して、バージョン間の互換性を保証するCordaのシリアライゼーション機能。これらによって、Corda4は参加メンバーにアプリアップグレードに関する自由を与え、場合によっては過去のバージョンを使用する事を可能にしたのです。
この機能は非常に高度なものです。実運用に関して、今後数か月の間により多くのことを我々は理解することになるでしょう。注目していただきたいと思います。
それまでに署名制約とCordaシリアライザがどのように機能するのか理解するために時間を割いてください。最初はうまくいかないでしょうし、頭痛がするような経験になるでしょう。しかし頑張ってください。Corda4で導入したこの機能は本当に画期的なものです。どのように機能し、なぜそのようになっているのか、時間をかける価値はあります。
その他にもたくさんの機能が追加されています。さらなる情報については以下をご覧ください。（すべて英語です。）
https://docs.corda.net/release-notes.html
https://docs.corda.net/app-upgrade-notes.html
https://docs.corda.net/changelog.html
この文章は、こちら（https://medium.com/corda/introducing-corda-4-18e3b588b71c）とこちら（https://medium.com/corda/lets-all-welcome-corda-4-into-the-world-88bde4b86345）の内容を一部抜粋して翻訳したものです。内容については保証いたしかねます。
