ハッシュベースのアキュムレーター Utreexoの仕組み

GBEC動画解説コンテンツのスライドです。
https://goblockchain.network/2019/08/utreexo/

Transcript

1. Utreexo
2. 1 Utreexo
 Lightning Networkのホワイトペーパーの共著者
 でもあるTaddeus Dryjaによるハッシュベースの
 アキュムレータ Utreexoの提案
 
 • Bitcoinのフルノードは未使用のトランザクションアウト 
 プット＝UTXOの状態（現在約4GB）を管理している。 
 • UTXOは現状ディスク上のDB程度に保存されるが、 
 保存されたUTXOがアクセスされるのは削除される 
 タイミング（使用時）のみ。 
 • 将来的にUTXOは増加し、UTXOを保持するための
 コストも長期的には増加すると思われる。 
 • 休止中のUTXOの保持を省略できると、ストレージだけでなく、ディ スクIOが最小限に抑えられ、同期速度も向上する。 
 • Txの検証もUTXOのDB全体ではなく単体の Txと同サイズの証明 のみがあれば良い。 
 https://eprint.iacr.org/2019/611.pdf
3. 2 Utreexoの構造
 Utreexoはハッシュベースのアキュムレータで
 完全二分木の複数のマークルツリーで構成される
 1
 2
 3
 4
 8
 9
 11
 5
 6
 10
 7
 左のツリーから順に大きくなるように完全二分木のツリーを配置する。 
 新しいリーフは随時１番右側に追加していく。 
 UTXOのハッシュをリーフとして追加し、 
 マークルツリーを構成する。 
 フルノードが保持するのは各ツリーの ルートハッシュのみ。
 ウォレット等でUTXOを管理する場合は、 
 そのUTXOのInclusion Proofが必要になる。
 Txには既存のTxに加えInclusion Proofを添付する。

4. リーフ1,2に新しい要素3を追加すると 
 2つの二分木になる。 
 3 要素の追加
 1
 2
 3
 1
 2
 3
 1
 2
 3
 4
 要素4を追加すると4つのリーフで 
 構成される１つの二分木になる。 
 1
 2
 3
 4
 1
 2
 3
 4
 5
 1
 2
 3
 4
 5
 要素5を追加すると
 2つの二分木になる。 

5. 4 要素のInclusion Proof
 1
 2
 3
 4
 5
 6
 7
 8
 各UTXOのハッシュをリーフとしてマークルツリーを形成
 
 ・・・
 リーフ5のUTXOを使用する場合、リーフ 5が存在する
 ツリーにおけるリーフ 5のInclusion Proofを
 トランザクションに添付する必要がある。 
 Inclusion Proofは
 • リーフの位置
 • （リーフの兄弟の）ハッシュリスト 
 で構成される。
 各ノードはトランザクションが参照する UTXOが
 自身のUTXOのツリー内に存在するか、 
 Inclusion Proofからマークルルートを計算し、 
 自身のツリーのマークルルートと検証する。

6. 5 要素の削除
 1
 2
 3
 4
 5
 1
 2
 ５
 4
 リーフ3を削除すると、リーフ5がリーフ 3の位 置に配置される。
 リーフ1,2,4,5のUTXOの
 Inclusion Proofを管理している場合、その Inclusion Proofは更新される。
 1
 2
 3
 4
 5
 6
 1
 2
 5
 6
 4
 リーフ3を削除すると、リーフ 5, 6をリーフ3, 4 の位置に配置し、リーフ 4は単一のマークル ツリーになる。
 要素を削除する際は、1番高さが低いツリー（1番右側のツリー）と 
 削除対象のリーフが存在するツリーの一部を入れ替えて、ツリーを再構成する。 

7. 6 バッチ削除
 新しいブロックを受信すると、大量の UTXOをツリーから削除し、大量の新しい UTXOをツリーに追加する必要が ある。要素を１つずつ削除するのは非効率であるため、バッチ処理化することで必要なハッシュ操作の数を大幅 に削減する。
 
 Twin -> Swap -> Root -> Climb
 
 • Twin
 7
 1
 2
 5
 3
 4
 6
 Twinはリーフの左右両方のノードの削除を指す。
 リーフ1,2のTwinを削除すると、その親ノード5も
 削除対象としてマークする。
 

8. 削除処理を行う行に複数の削除がある場合、 Twin/Swap後、Rootステップは実行されない。 
 削除数が奇数の場合、 Twin/Swap後１つのノードが残り、その1つが Rootステップで処理される。 
 7 バッチ削除
 • Swap
 
 
 
 
 
 • Root
 7
 1
 2
 5
 3
 4
 6
 Swapはツリー内に2つ以上の削除リーフがある
 状態で、残る兄弟要素を入れ替える処理を指す。
 リーフ2,3を削除する際、2と4の位置を交換し、
 親ノード6,7を削除対象としてマークする。
 
 8
 1
 2
 6
 3
 4
 7
 5
 高さ1のツリーがある場合は、そのリーフと
 削除対象のリーフの位置を変える。
 7
 1
 2
 5
 3
 4
 6
 3
 高さ1のツリーが無い場合は、3を
 高さ1のツリーのルートに昇格させる。

9. 8 バッチ削除
 • Climb
 
 
 
 
 
 • バッチ削除フローのサンプル
 7
 1
 2
 5
 3
 4
 6
 Rootステップが終了すると、次の行に移動して削除を進 める。これをツリー群の頂点まで繰り返す。
 13
 1
 2
 9
 3
 4
 10
 14
 5
 6
 11
 7
 8
 12
 15
 8つのリーフを持つ中、リーフ6,7を削除する。
 ① Twinは無いので、まずSwapにより
 リーフ6とリーフ8を入れ替える。

10. 9 バッチ削除
 13
 1
 2
 9
 3
 4
 10
 14
 5
 8
 11
 7
 6
 12
 15
 ② 1番下の行の処理が終わったので、 
 Climbして次の行へ移る。
 13
 1
 2
 9
 3
 4
 10
 14
 5
 8
 11
 7
 6
 12
 15
 ③ 子ノードの無くなった 12を削除対象とし、
 子が新しくなった11のハッシュを再計算する。 

11. 10 バッチ削除
 ④ 2つめの行では、Twin/Swapも無いので、
 Rootを実行し、11がルートとなるツリーができる。 
 13
 1
 2
 9
 3
 4
 10
 14
 5
 8
 11
 12
 15
 ⑤ Climbにより3つめの行の処理に移動する。 
 13
 1
 2
 9
 3
 4
 10
 14
 5
 8
 11
 12
 15

12. 11 バッチ削除
 ⑥ 3つめの行でもRootを実行し、
 13がルートとなるツリーになる。 
 13
 1
 2
 9
 3
 4
 10
 14
 5
 8
 11
 12
 15
 ⑧ Climbにより最後の行の処理に移り、 
 15を削除する。
 13
 1
 2
 9
 3
 4
 10
 14
 5
 8
 11
 15
 13
 1
 2
 9
 3
 4
 10
 5
 8
 11
 バッチ処理後のツリー群は 

13. 12 ブリッジノード
 Bitcoinは既に稼働中のチェーンで、 UTXOのアキュムレータも各 UTXOのInclusion Proofも
 管理していないが、アキュムレータをサポートするノードは、トランザクションを受信した際、 
 トランザクションで使用される TXOのInclusion Proofを必要とする。
 そのため、そのような Compact State Node と既存のFull Nodeが共存するためには、 
 トランザクションのInclusion Proofを提供するBridge Nodeが必要になる。

14. 13 Utreexoの実装
 • Taddeus Dryjaが公開している実装↓
 https://github.com/mit-dci/utreexo
 Goで書かれている２つのタイプのアキュムレータを提供。
 ◦ Forest
 ブリッジノード向けに全リーフを保持するアキュムレータ実装。
 ◦ Pollard
 全リーフは保持しないがアキュムレータおよびForestが生成したInclusion Proofの検証が可能な実装。全リーフを管理することも
 可能だが、その場合Forestの実装の方が効率的。
 • Utreexorb
 Utreexoの動作を理解するためにRubyで実装したアキュムレータ実装。
 https://github.com/chaintope/utreexorb