DFINITY本家のFAQページをもとに、DFINITYについて見ていきます。
これを読むとDFINITYの検証の仕組みのうちValidation Treeについてざっくりと知ることができます。
要点まとめ
まず、本記事の要点をお伝えします。
- Validation Treeはマークルツリー作り、最終的にはルートハッシュを生成することが目的である。
- マークルツリーではノード（データリーフあるいはリーフハッシュともいう）どうしを組合わせる作業を繰り返して、単一のルートハッシュを作成する。
- ルートハッシュは、複数のシャードに保存されているグローバルステートと重要なイベントにアンカーを付けるものである。
- ルートハッシュは、完全に検証がされると閾値リレーブロックチェーン（最上位のコンセンサス履歴）に記録される。
- ルートハッシュは20バイトほどのサイズしかないが、仮想的に無限個のデータの存在を証明できる。
- マークルパスをマークルツリーを通してルートへ与えることで、データの存在を証明できる。
- DFINITYにおいては数エクサバイトほどのデータサイズを想定していることから、単にマークルツリーの仕組みだけではデータリーフが多くなりすぎる可能性がある。一方で、複数のプロセスの部分集合を使ってデータリーフからマークルツリーを作ろうとしてもツリーの正しさを判断できない。そこでValidation Towerの仕組みを導入することで解決を図る。
- ステートの更新適用と閾値リレーブロックチェーンへの記録の間には時間的隔たりがあるが、十分に大きなプロセスがシャードを維持していればファイナリティは瞬時に達成される。
次に詳細としてDIFINITY本家による英文FAQページの日本語訳を掲載します。細部を知りたい方は読み進めてください。
スポンサードサーチ
技術的な質問
Validation Treeってどう動くの？（How does a Validation Tree work?）
注）技術論文や入門資料集もご確認ください。
概略
Validation Treeの目的は、マークルツリー（筆者注：または、マークル木）を作ることです。このマークルツリーは、仮想コンピュータに保存される現在のステートデータと、ネットワークプロセス（マイニングクライアントとフルノード）が証明しなければならない重要なイベントの発生を対象としています。マークルツリーの強力な点は単一の「ルートハッシュ」ダイジェストを生成できることです。20バイトほどのサイズしかないにも拘らず、仮想的に制限なくインプットデータセットに対する署名の役割を果たすことができます。インプットデータは上手く定義された最適な形式に変換されてマークルツリーのリーフ（筆者注：葉）を形成し、単一のルートハッシュが生成されるまで、マークルツリーの中で階層的にリーフのハッシュどうしが結び付いて一組になったりN-aryツリー（筆者注：各ノードがN以上の子ノードをもたないようなツリー構造）となったりします。その後、「マークルパス」をマークルツリーを通してルートへ与えることでデータリーフの存在を証明することができます。ルートは、自身のデータに部分的に依拠する全ての上位ハッシュから成ります。
マークルルートを生成することで、ネットワークがステートとして保存したり内部関数用に保持しておく必要のあるデータに対してValidation Treeは仮想的に無限にアンカーをつけることができます。分散データ構造として、Validation TreeはそのノードとしてふるまうValidation Towerの配列を含んでいます。Validation Towerは閾値リレーシステムのようなランダムビーコンの動きで形成され、インプットを検証し「完全に検証された」ハッシュをアウトプットとして生成します。Validation Treeの下層において、Validation Towerはステートリーフの直上にあります。通常、ステートリーフはネットワークプロセスの部分集合が管理するステートシャードです。ステートリーフは、ステート遷移（トランザクションが実行する計算により生ずるステートの更新）を割り当てられたValidation Towerに渡し、Validation Towerは最終的に検証された新たなステートを示すハッシュを生成します。このシステムのよいところは、Validation Towerが別のValidation Towerのアウトプットを検証したり・結合したりして新たなマークルツリーを作り出せることです。
例えば、下層のValidation Towerがある範囲（シャード）のステートにアンカーを付けているその時点でのルートハッシュに対して証明を生成するとします。マークルツリーでは、ルートハッシュが生成されるまで当該ハッシュの親ノードが当該ハッシュと当該ハッシュの兄弟関係にあるハッシュを再帰的に組み合わせて階層を下から上へと進んでいきます。DFINITYのように巨大な非中央集権型ネットワークでこのような試行をすると、個々のプロセスがマークルツリーを作るには多すぎるほどのリーフハッシュが出てきてしまう可能性があります。単純にプロセスの部分集合を割り当ててマークルツリーの別の部分構築してもらい、構成要素からプロトコルにアセンブルしてもらうことも考えられます。しかしながらこの場合、構成要素、そして結局はツリー全体が正しいかを判断する術がありません。解決策は、ルートハッシュが生成されるまでValidation Towerを使ってツリーの中を上向きにリーフハッシュを組合わせていくことです。従って、高いValidation Towerはそれと関係ある子ノードのハッシュを受信して組合せ、親ノードへ渡す新しい完全に検証されたハッシュを生成します。これをルートハッシュが生成されるまで繰り返します。
ゆえに、有効なルートハッシュを生成するルートValidation Towerがあることになります。そしてここからネットワーク最上層のコンセンサス履歴（例えば閾値リレーブロックチェーンに）に記録される完全に検証されたルートハッシュが生まれます。Validation Tower1つ1つは独自に動作し別々の速度で進むことができます。これにより、ネットワークの進捗が実行中の処理に依存してしまうのを防ぎます。その後、コンセンサスが記録した最新のルートハッシュはいくつものシャードに保存されたグローバルステートにアンカーを付けます。また、最新のルートハッシュは発生した重要なイベントにアンカーを付けるためにも使用され、イベントもまるで単なるデータであるかのように扱われます。Validation Towerの面の生成への参加を求められているプロセス1つ1つは、コンセンサス履歴に記録されているあるルートへのマークルパスを渡すことで他のプロセスと通信しあいながらアクションのパフォーマンスを示します。このような方法で数エクサバイトのデータにアンカーを付けるとともに、ネットワークへの参加を正しいふるまいをするプロセスに限定するのです。
もちろん、ステートの更新が適用されることとマスターコンセンサスレイヤが記録するルートハッシュによって変化したステートにアンカーが付けられることとの間にはかなりの隔たりがあるでしょう（ハッシュの組合せは階層構造を上へ向かって進まなければならないため）。マスターレコードは間違っていてはいけないのでこれは避けられないことですが、全計算のファイナライズに関する速度を落とさなくても大丈夫です。シャードが十分大規模なプロセスによって維持されていれば、ネットワークのクライアントの多くはシャードが通知した瞬間にファイナライズすべくトランザクションを受け取るでしょう。同時に、最下層のValidation Towerがトランザクションを検証し終えた瞬間、たとえマスターコンセンサスが公証するのに時間を要するとしてもファイナリティは確実になるのです。非中央集権型クラウドシステムに作られる予定のアプリケーションでは、さらなる計算リソースの消費も何てことはありません。非中央集権型クラウドシステムは、自律性や安定した継続稼働、不正防止その他諸々の特性によってクラウドサービスの稼働に関連するコストの大幅削減をもたらし、人的資本支援の必要性が劇的に低下します。
（【簡単まとめ】DFINITYをFAQから見てみる4（技術編3/5） ←← 前）｜（次 →→ 【簡単まとめ】DFINITYをFAQから見てみる6（技術編5/5））