Corda5のNotaryアーキテクチャの大きな変更があった点をCorda4と比較して説明しています。
Notaryとは？
Notaryとは、Cordaのアーキテクチャの中で中核的な存在の一つです。ブロックチェーンに共通する特徴に「ネットワーク内の価値を保存できる」というものがありますが、Cordaネットワーク内での価値の保存に必要なコンポーネントがNotaryになります。この記事ではNotaryの内部実装についてご説明します。Notaryの果たす機能（二重支払いの防止）については、Corda４の公式ドキュメントや、弊社のNotary関連の記事をご覧ください。
UTXOモデル
CordaはUTXOモデルを採用したブロックチェーン実装です。UTXOとはUnspent Transaction Outputの略で、Bitcoinが採用しているデータモデルになります。Cordaでは、（価値の移転を含めた）情報のやりとりはUTXOモデルの実装としてTransactionと呼ばれる形式でデータを作成し、関係者の間で送受信されます。Transactionの例として「10ドルをAさんからBさんへ渡す」という情報を一つのTransactionとして作ってみましょう。以下のようになります。
このTransactionには二つの情報が含まれます。すなわち 「Aさんの持つ10ドルを使用する」ことと、「Bさんの持つ10ドルが生まれる」ことの二つです。 Cordaにおいて、前者をInput State, 後者をOutput Stateと呼びます。
二重支払いの防止とNotary
さて、Aさんを悪いことをしたい人だと仮定しましょう。「Aさんの持つ10ドルを使用する」という情報（Input State）は先ほどのTransactionに含めて使われましたが、このTransactionの存在はAさんと Bさんしか知りません。Aさんは考えます。「10ドルをAさんからCさんへ渡す」という別のTransactionにも同じInput Stateを使えば、自分はあたかも20ドル持っていたかのような取引を実現できるのではないだろうか・・・
この課題を解決するのがNotaryです。
Notaryは、同じInput Stateを2度使えないような制御を行います。上の絵では、「Aさんの持つ十ドル」がすでに使われていないかどうかを確認するのがNotaryの役割になります。つまり、価値の移転を実現する取引には、かならずNotaryによる確認が必要ということになります。
Input StateとOutput Stateの関係
さて、Input State（Aさんの持つ10ドル）はどこから来たのでしょうか？ 単純に想定することができるのは二つです。①AさんはZさんから10ドル受け取った。②Aさんはドルの発行体（銀行、もしくは中央銀行でしょうか）から10ドルを受け取った。この二つのどちらかでしょう。
さて、以降、パターン②の方を想定してお話を続けます。（議論はどちらを使っても同じです）
ここで示した、Input StateとOutput Stateはどちらも「Asaが十ドル持っている」状態を指していて、情報としては全く同じ中身になります。しかし、その使用状況については、必ずNotaryが管理しなければいけないということになります。
Notaryの実装
さて、Notaryの役割がはっきりしたところで、実際にNotaryがどのように情報を管理するかについて考えましょう。実は大きく分けて二つの方法が存在します。そして、一つ目の（よりシンプルな）パターンをCorda4が採用しており、二つ目の（より網羅的で真正性の高まる）パターンをCorda5で採用しています。しています。
二つの仕組みの１番の差は、Notaryに記録をするタイミングになります。Corda4は、「消費した時」で、Corda5は、「情報が発生した時」になります。詳しくみていきましょう。
Corda4 Notaryの実装
Notaryは、一つのStateを２回Input Stateに入ることを防ぐことができればOKです。なので、シンプル＆ミニマムな実装は、「一度使ったInput Stateを記録していく」事になります。
この時、Notaryが記録するのは、使用済みStateの一覧と言う事になります。Cordaの場合は、Stateは必ずTransactionに含まれます。そこで、Notaryは使用済みStateを管理するために、Transactionのハッシュ値とTransactionの中で何番目のStateであったか、を記録します（Transaction HashとTransaction Indexという言い方をします）
Corda４のNotaryのデータは以下のような表になります。
Notaryは、新しいチェック依頼が来るたびに、このデータと照合し、もし一致するデータがあれば（すでに他で使われていたら）NGを返し、一致するデータがなければ、そのデータを記録した上で、新しいデータが初めて使用されることを認めるという意味を込めて、Notaryの署名を返します。（実際は、新しく届くTransactionのハッシュ値に対して署名を作成して返送します）この時Notaryは、当該データの内容について知ることはありません。あくまでTransactionのHashとIndexだけを用いて判断をする事になります。このように、取引内容を知ることなく、価値の管理に必要な情報だけをやり取りする仕組みのことをNon Validating Notaryといいます。
Corda5 Notaryの実装
さて、Corda5では、上記とは異なる形でチェックを行います。（こちらがこのBlogのメインの内容になります。）
Corda5のNotaryは、もう少し広い範囲でデータの管理を行います。なぜシンプルなCorda4のNotaryの仕組みから変えたのかについては、続きを読んでいただくとして、まずはその仕組みを解説いたします。
Corda5のNotaryは、一つのStateに関して、２回記録を取ります。一度目はStateがOutputStateとしてネットワーク上で構築された時、二度目が（Corda4と同じく）Input Stateとして使用された時です。
Corda5においても、Non Validating Notaryは引き続き取引内容を知らない状態です。ただし、ネットワーク参加者からOutput Stateを作った時と、そのStateをInput Stateとして使った時の二つの状態を記録する必要があります。そのため、Corda5のNotaryは以下のような情報を保存します。最初に(Output Stateとして）登録される時には「未消費」で登録され、Input Stateとして使われると、「消費済み」になります。
なお、Corda4は、「未消費」状態の時にはNotaryに登録されることはなかったという事になります。
さて、この変更により、ネットワークに参加しているノードがNotaryにあるStateを登録する方法が変わる事になります。
Corda4では、TransactionのHashとそのIndexだけを飛ばせば十分でした（登録する＝消費したい）。一方、Corda5は、飛んでくるStateは未消費に登録したい場合もあれば、消費済みに登録したい場合もあります。そして、リクエストを受けとるNotary側の状態のパターンも異なります。Corda4では、特定のStateに関して「知らない＝未消費」場合と、「登録済＝消費済」の場合の２パターンでしたが、Corda5では「知らない」場合、「未消費」の場合、「消費済」の場合の３パターンがある事になります。このようなパターンをまとめると、以下のような表になります。
まとめ
この変更をアプリケーションネットワークレベルで”引いて”みると、次のようなことがわかります。
Corda4のNotaryは、アプリケーションネットワークに存在するStateのうち、消費済みのStateの存在しか認識していませんでした。
一方、Corda5のNotaryはアプリケーションネットワークに存在するすべてのStateの存在を認知していることになります。網羅性があがっていることは（なんとなく）いいことのような気がしますが、それと引き換えにNodeもNotaryも抱える処理が複雑化しています。ともすると複雑化しただけに見える新しいCorda5のNotary。なぜこのような実装を選んだのか。その点については、次回の記事で詳しく解説します。次回記事も併せてご覧ください。
＜ご質問・ご要望の例＞
- Corda Portalの記事について質問したい
- ブロックチェーンを活用した新規事業を相談したい
- 企業でのブロックチェーン活用方法を教えて欲しい 等々
SBI R3 Japan エンジニアリング部長
書籍出してます：https://amzn.asia/d/c0V31Vd
趣味：サッカー、ガンプラ、ドライブ、キャンプ