ブロックチェーンの弱点と言われるデータ量の増大。Cordaにこの弱点は存在しません。データ量増大を回避する仕組みであるアーカイブに関する新機能、Notaryのデータアーカイブについて解説しています。
- はじめに
- NotaryとTimewindowの仕様変更
- Cordaにおけるデータアーカイブ
- Notaryとアーカイブ
- シナリオ準備
- シナリオ① Corda4（Notaryアーカイブせず）
- シナリオ② Corda4（Notaryの情報を誤ってアーカイブした場合）
- シナリオ③ Corda5の場合（Notaryのアーカイブをしていない状況）
- シナリオ④ Corda5の場合（Notaryのアーカイブした場合）
- 真正性を保つ最後の砦＝Timewindow
- シナリオ⑤ ノードA（悪意有り）がTX-1を複製
- Timewindow登場
- シナリオ再検討
- シナリオ⑤’−1 TX-1を複製（Notaryのアーカイブ前）
- シナリオ⑤’-3 TX-1を複製（Timewindowの制限時間後にNotaryをアーカイブ）
- シナリオ⑤’-2 TX-1を複製（ちょっとだけTimewindowのデータを変える）
- シナリオ⑤まとめ
- まとめ
はじめに
こちらの記事では、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のアーカイブ前）
まずはアーカイブ前の状態を確認しましょう。
TX-1には必ず相手がいるはずです。Stable Coinの発行であれば、当然ながらStable Coinの発行体がこのTransactionには署名するはず。しかし、このTX-1の情報を全て持っているノードAは、Stable Coinの発行体が認知することなく、このTransactionは構築可能です。（単なるデータコピーです）しかし、当然このTransactionはNotaryによって否定されます。この状況を示したのが以下の図になります。
シナリオ⑤-2 TX-1を複製（ちょっとだけデータを変える）
もちろん、TX-1から少しだけデータの中身を変えたTX-4を作ることが可能です。しかし、Transactionの内容を少しでも変えると、Transaction Hashが変わってしまいます。このTransactionは署名検証に失敗するので、次に受け取るノードCが受け取りを拒否します。 よって、このデータを用いて取引を行うことができません。
シナリオ⑤-3 TX-1を複製（Notaryのアーカイブ後）
お気付きの読者もいらっしゃると思います。さて、Notaryでアーカイブするとこの問題はどのように変化するでしょう？アーカイブされると、すでに登録されたTX-1は存在しないので、新しい登録として、TX-4は受け入れられてしまいます。このシナリオについて考えると、Notaryのアーカイブは不可能ということになってしまします。
ここで登場するのがTimewindowになります。
Timewindow登場
Timewindowがなんなのか、またそのCorda5での仕様については、別記事をご覧いただくとして、ここではこのケースにおいてTimewindowがどのような役割を果たしているのかを見ていきます。Timewindowとは、あるTransactionのNotaryへの登録に関しての時間制約を設ける役割を果たしています。Corda5では、Timewindowを特定時間より前という形で必ず設定しなければいけません。（下図参照）
この制約には他にも理由がありますが、一番重要な理由はNotaryアーカイブの実現に必須の機能だからということになります。詳しく説明していきましょう。
Corda5のTransactionは、必ずNotaryが署名可能な時間の最大値が設定されます。（上の図の①であっても、②であっても、特定時間を過ぎるとNGとするという制約がかかることが見て取れるかと思います）
先ほどの例に戻りましょう。TX-1にも、当然TimeWindowが設定されています。これまで表現していませんでしたが、明示的に書くとすると以下のよう表現ができると思います。この時刻情報はTransactionの一部の情報として記録されています。
また、NotaryにTimewindowの情報は渡されます。（これはCorda4でもCorda5でも同じです）
Corda5のNotaryはこの情報をDBで管理します。なので、これまで提示していたNotaryのDBには、実はもう１列列があって、以下のような情報を管理しています。
ということで、先ほどのシナリオに戻りましょう。
3つのシナリオがありました。
シナリオ⑤−1 TX-1を複製（Notaryのアーカイブ前）
シナリオ⑤-2 TX-1を複製（ちょっとだけデータを変える）
シナリオ⑤-3 TX-1を複製（Notaryのアーカイブ後）
この三つのシナリオに、Timewindowを組み合わせるとどうなるのか考えます。
シナリオ再検討
シナリオ⑤’−1 TX-1を複製（Notaryのアーカイブ前）
Notaryのアーカイブ前にTransactionの複製を作ると当然ながらNotaryはそのTransactionを否定します。
シナリオ⑤’-3 TX-1を複製（Timewindowの制限時間後にNotaryをアーカイブ）
しかし、アーカイブされた場合を考えると、TX-1の複製が登録できてしまうという課題がありました。しかしアーカイブするタイミングを、Timewindowで指定された時間以降に実施するとどうなるでしょう？この時、新規登録されるTX-4は、Timewindow制約に違反することから、Notaryは登録を拒否します。
シナリオ⑤’-2 TX-1を複製（ちょっとだけTimewindowのデータを変える）
もちろん、Timewindowの設定を変更したTransactionを構築することでこの制約は回避可能ですが、Transactionに含まれるデータであるTimewindowは、その値を変えるとTransaction Hashの値を変えてしまいます。オリジナルのシナリオ⑤-2と同じく、こうするとStable Coinの発行体の署名検証が通らなくなるため、このTransactionは有効なものではないということになります。
シナリオ⑤まとめ
このように、アーカイブのタイミングをNotary側で適切にコントロールすると、先ほど見られたアーカイブ時の問題点をクリアすることができます。これで、Notary側は二重消費の問題に関して懸念を持つことなく、安全にアーカイブできることがわかりました。
まとめ
Corda5で実装予定のアーカイブ機能の解説を行いました。改めて全体像を確認しましょう。
1) Corda4は消費済みStateだけをNotary登録可能
2)Notaryが（誤って）アーカイブした際に、NW上の未消費の所在が分からなくなり、二重支払いが可能になってしまう。
3)そのため、Corda4ではNotaryのアーカイブはできない
1) Corda5は未消費Stateも含めて、全てのStateをNotaryに登録する。
2) その為、アーカイブしたStateはネットワーク上に存在しないStateになるため、アーカイブ後も二重消費できない状態になる。
3)しかし、発行＆アーカイブ済のStateを再登録すると、悪用可能という問題が残る。
1) Corda5では、TimeWindowを必ず付与しなければ成らない仕様に（全てのTransactionには実行可能な時刻の上限値を設定する必要がある）
2) その為、発行＆アーカイブ済みのStateの再発行は、特定の時刻を超えると不可能になる。
3) よって、Notaryはこの時刻を超えた後であれば、安全にアーカイブ可能。
4) Time Windowの値を変更したTransactionは異なるTransaction Hashを持つので、悪用はやはり不可能
Corda5では、Corda4と同レベルのアーカイブサービスとしてまだ実装できていませんが、Notaryもアーカイブ可能になっていること、またその為にNotaryとTimewindowの仕様に変更が入っている点をご理解いただけたのではないかと思います。
また、本記事をご覧いただく中で、Stable Coin発行体にとって、Notaryの持つ重要性も見えてきたのではないかと思います。ここで示したStable Coinはあくまでユースケースサンプルではありますが、リアルなStable Coinのユースケースにおいて、Notaryを発行体が管理することを想定した場合に有用なNotaryの別実装もございます（Contract Validating Notary）こちらについてもまた今後別の記事で解説いたしますのでご覧ください。
＜ご質問・ご要望の例＞
- Corda Portalの記事について質問したい
- ブロックチェーンを活用した新規事業を相談したい
- 企業でのブロックチェーン活用方法を教えて欲しい 等々
SBI R3 Japan エンジニアリング部長
書籍出してます：https://amzn.asia/d/c0V31Vd
趣味：サッカー、ガンプラ、ドライブ、キャンプ