ブロックチェーンの弱点と言われるデータ量の増大。Cordaにこの弱点は存在しません。データ量増大を回避する仕組みであるアーカイブに関する新機能、Notaryのデータアーカイブについて解説しています。
はじめに
こちらの記事では、Notaryのデータアーカイブの実現にあたって必要な技術課題を紹介し、それをCorda5でどのように解決したかを説明いたします。Corda5のNotaryとTimewindowの仕様については簡単にしか紹介いたしません。それぞれのご紹介については別記事（Notary解説記事、Timewindow解説記事）をご参照ください。
NotaryとTimewindowの仕様変更
Corda5のNotaryは、Corda４から比べると、だいぶ複雑になりました。この仕様変更により、Notaryはアプリケーションネットワークに存在するすべてのStateの存在を認識しています。
Timewindowもまた仕様が変更されています。こちらは必須設定項目となり、また設定可能パターンが減っています。アプリケーション構築に一手間追加されたような印象です。
さて、このような（細かい）仕様変更を行なった理由をこれから説明しましょう。データアーカイブという非機能要件をより高いレベルで実現するために必要な変更です。
Cordaにおけるデータアーカイブ
Cordaの著しい特徴の一つに、ネットワーク全体での改竄耐性を持ちつつ、不要になったデータの削除が可能であるというものがあります。
アーカイブ機能は、データストレージの容量節約に役立ちます。Corda4のアーカイブ機能は主に実データを保持する各ノードに焦点を当てていました。その一方、取引データのハッシュ値のみを管理するNotaryは、原則アーカイブサービスのスコープ外で、過去データを全て保持することを想定していました。Notaryの持つデータ量はノードと比べると小さなものです。一般的なTransactionのサイズは通常数十キロバイトに対して、Notaryが持つ１Transactionあたりのデータは大体数十バイト。サイズはざっくり１０００分の１程度になります。その為、ストレージ容量という観点ではアーカイブできないことの影響は小さかったのです。
ただし、ストレージ容量とは異なる観点でアーカイブの必要性は出てくる可能性がありました。それは、Notaryの検索性能という問題です。Notaryは２重支払いチェックを行うにあたって、必ずDBの全数チェックが走ります。もちろん検索対象がハッシュ値（十分にランダム化された固定サイズ文字列）なので、不均質な性能劣化が発生する余地はほぼないものの、過去データが膨大になればなるほどその検索には負荷がかかります。この問題を見越して、Corda5では、Notaryのアーカイブもできるようにアーキテクチャが変更されました。
Notaryとアーカイブ
さて、まずはアーカイブ機能とNotaryの関係について詳しくみていきます。
一つの例を参考に検討します。
この例は、Aさん宛にStatble Coin（十ドル）が発行され、Aさんはその十ドルでそのままBさんへのなんらかの支払いをこなったというものになります。ここで二つのTransactionが存在しますが、このうち最初に作ったTransactionをアーカイブしたいとしましょう。しかし、アーカイブした後もこの十ドルを使って２重支払いさせたくは（当然ながら）ありません。
ここから先は、「Aさん」が悪意を持ったノードオーナーだとして検討していきます。さまざまなパターンでアーカイブ（データの削除）を行なった場合に、Aさんが果たして二重支払いを行えるのか（Bさんに支払ったはずの十ドルで、Cさんという別の人にも支払いができる？）という点を検討します。
シナリオ準備
Aさんが「悪意のある人」だとは、当然ながらBさん、Cさん、それからNotaryの管理者は知りません。また、Aさん、Bさん、Cさん、そしてNotaryはそれぞれ異なる情報を持っています。そこで、まずはどんな情報を持っているのかを確認しましょう。わかりやすくする為に、二つのTransactionにTX-1とTX-2と名前をつけておきます。（Notaryは情報の中身は知らず、TX-1とTX-2をTransaction Hashとして認識します）
また、比較のために、Corda4とCorda5のNotaryが何を知っているのかも同時に考えてみましょう。Aさんは、Bさんに十ドル払い終わったタイミングです。
- AさんはBさんに十ドル払ってます。この情報はAさんもBさんも確認済みです。
- Bさんは、ブロックチェーンの特性を活かしてTX-2の検証及びそのひとつ前の取引であるTX-1のスマートコントラクト検証も実施済みです。
- Cさんはこの取引に関わっていないので、なにも知りません。
- Corda4の場合だと、Notaryは、消費済みなのはTX-1-0というStateだけなので、このStateだけを知っている（＝消費済）状態です。
- Corda5の場合だと、Notaryは、TX-1-0を消費済として知っていて、他にTX-2-0が未消費であることも知っていることになります。
シナリオ① Corda4（Notaryアーカイブせず）
さて、Corda４におけるアーカイブは、ノードのデータが対象でした。まずはノードのデータをアーカイブした場合に二重消費を起こせないかどうかを確認しましょう。 ノードBはデータをアーカイブしています。一方、ノードAは悪意を持っているのでアーカイブしたフリをして、削除したと言ったデータを元に全く別のトランザクションを（Cに支払いをする）構築し、ネットワークに流します。
すると、この取引（図のTX-3）は、ノードAとノードCのチェックは通過するものの、Corda4のNotaryが拒否することがわかります。
シナリオ② Corda4（Notaryの情報を誤ってアーカイブした場合）
では、Corda4が対応していない「Notaryのアーカイブ」を誤って行なった場合どうなるか考えてみましょう。上の図においてC4Notaryが知っている情報をアーカイブ（システムから削除）すると何が起きるでしょうか？
当然ながら、Corda4のNotaryはTX-1-0のStateを自分のデータベースに持たない状態になります。（Bとの取引を知らない）ノードCは、ノードAとの取引情報（TX-3及びTX-1）を確認しますが、そこに怪しい点はありません。NotaryもTX-2のことを（アーカイブして）忘れているので、ノードAが悪意を持って構築したTX-３は、このネットワークの中で認められてしまうことになります。
こうした状況を避けるためには、Corda4のNotaryはアーカイブすることができませんでした。
シナリオ③ Corda5の場合（Notaryのアーカイブをしていない状況）
さて、シナリオは同じです。ノードBはデータをアーカイブしています。一方、ノードAは悪意を持っているのでアーカイブしたフリをして、削除したと言ったデータを元に全く別のトランザクションを（Cに支払いをする）構築し、ネットワークに流そうとしているという状況です。シナリオ①と同様、この取引（図のTX-3）は、ノードAとノードCのチェックは通過するものの、Notaryが拒否することがわかります。 この時、C5Notaryの内部は以下のような状況になります。
シナリオ④ Corda5の場合（Notaryのアーカイブした場合）
シナリオ④-1 アーカイブ直後
まずは、Notaryのアーカイブ（及びノードBのアーカイブ）した直後の状況を見てみましょう。この時、NotaryはTX-1-0をアーカイブすることを想定します。（どのStateをアーカイブできるかについての検討は最後に行います）
Corda4と異なり、Corda5のNotaryはアプリケーションネットワークに含まれるすべてのStateの状況（内容を知らないまま）を管理しているという整理をしています。その為、Corda5のNotaryがアーカイブしたStateは、ネットワークに存在しない、という理解になります。詳しくみていきましょう。
シナリオ④-2 ノードA（悪意有り）がTX-3を構築
さて、この状況で悪意を持ったノードAがTX-3を構築したとします。このTX-3は果たしてNotaryのチェックを通るのでしょうか？
結論から言えば通りません。こちらの表をご覧ください。この表の見方はCorda5のNotaryの解説記事をご覧いただければと思いますが、簡単にいうと、Stateの登録・更新依頼に対して、Notaryがどのような反応をするかについて説明した表になります。
こちらに、今回問題となっているTX-1-0（最初に発行した十ドル）を当てはめるとどうなるかというと、以下の図のようになります。すなわち、アーカイブ前は”消費済State”だったものが、アーカイブ後は”Notaryの知らないState”になります。
さて、アーカイブ後にTX-3をNotaryに流した場合何が起きるのでしょうか？TX-3の中で、TX-1-0をInput Stateとして登録をかけます。アーカイブ後なので、Notaryの反応は「❌エラー（未登録）」となり、Notaryの署名に失敗します。結果として、アーカイブ後もTX-3はネットワークで承認されないということになります。
さて、これで安心。かというともう一つだけ塞がなければならない抜け穴があります。これが最後のシナリオです。
真正性を保つ最後の砦＝Timewindow
上の表を見てお気づきになった方もいらっしゃるのではないでしょうか？アーカイブ後のTX-1-0は、Notaryにとって未知のStateになります。なので、TX-1-0を「未消費のState」として登録すれば２重消費ができるのではないか？という問題です。つまり、TX-1をもうひとつ新しく登録する（TX-4）という抜け道があるのではないか？というお話になります。
シナリオ⑤ ノードA（悪意有り）がTX-1を複製
このシナリオを図にしたのが下の図になります。
さて、詳しく見ていきましょう。
シナリオ⑤−１TX-1を複製（Notaryのアーカイブ前）