Hyper Tree

GBECの解説動画のスライドです。
https://goblockchain.network/2026/08/Hyper-Tree/

Transcript

1. Hyper Tree
2. XMSS (xTended Merkle Signature Scheme) XMSSは、W-OTS+の公開鍵をリーフとしたマークル署名スキーム • 高さh’の二分木で、2h’個のW-OTS+鍵を包含 W-OTS+（https://goblockchain.network/2026/03/wots-plus/） • 1つのXMSS鍵ペアで2h’個のメッセージに署名できる 1
3. XMSS の鍵生成と署名/検証 • • • 鍵生成 a. ランダムなシード値を生成して擬似ランダム化数（PRF）で2h’個のW-OTS+秘密鍵を 導出し、対応するW-OTS+公開鍵を計算 b. 各W-OTS+公開鍵でマークルツリーを構成しルートハッシュが公開鍵 ※ルートの計算には2h’個すべてのW-OTS+鍵ペアが必要 署名生成 a. 未使用のリーフのインデックス（idx）を選択し b. idxのW-OTS+秘密鍵でメッセージダイジェストに署名 c. 署名は（idx、W-OTS+署名、ツリーのルートまでのマークルパス） 署名検証 a. W-OTS+署名からW-OTS+公開鍵を復元し、ハッシュしてリーフ値を計算 b. マークルパスとidxを使ってルートを再計算し、XMSSの公開鍵と一致するか検証 ※ 同じidxを2回使うとW-OTS+のワンタイム性が破れるため、使用済みidxの管理が必須 2
4. XMSSの課題 • ステートフルである ◦ 署名のたびに「どのidxを使ったか」という状態を管理する必要がある ◦ バックアップからの復元、複数マシンでの署名で同じidxを使用すると W-OTS+の秘密鍵の一部が漏れ署名偽造が可能になる • 鍵生成コスト ◦ 公開鍵の計算のために2h’個のすべての鍵ペアの計算が必要 ◦ h’ = 20（約100万回の署名）でも鍵生成に220回のリーフ計算が必要で、 署名回数を増やすためにh’を大きくすると鍵生成が現実的な時間で 終わらなくなる ※SPHINCS+が必要とする264回規模の署名を単一のツリーで実現するのは不可能 → Hyper Tree 3
5. Hyper Tree Hyper Tree（HT）はXMSSツリーをd層積み上げた構造で、 XMSS^MTをSPHINCS+用に固定入力長化した変種 • 全体の高さhをd層に分割し、各層は高さh’ = h/dのXMSSツリー • 最上層のルートがHTの公開鍵 • 上位層のツリーのリーフ（W-OTS+鍵）で 下位層ツリーのルートに署名 • 最下層ツリーのリーフの鍵で 実際にメッセージに署名 4
6. Hyper Tree の署名と検証 • 署名生成 a. 最下層（レイヤー0）ツリーのW-OTS+鍵でメッセージに署名し、 XMSSと同様にマークルパスを添付 b. レイヤー1〜d-1の各ツリーでは、1つ下のツリーのルートにW-OTS+鍵で 署名し、マークルパスを添付 c. • HT署名 = d個の（W-OTS+署名 + マークルパス）を連結したもの 署名検証 a. 最下層から順に、W-OTS+署名から公開鍵を復元してリーフ値を計算し、 マークルパスでそのツリーのルートを算出 b. 算出したルートが上位層のW-OTS+署名の署名対象として 同じ計算を最上位層まで繰り返す c. 最終的に得られた最上位層のルートがHyper Treeの公開鍵と一致するか検証 5
7. なぜ多層化するのか？ • 鍵生成に必要なのは最上位層のツリーのみ、つまり2h’=h/d個の鍵計算 ◦ 下位層のツリーはすべてシードから決定論的に導出可能なため、 署名時にオンデマンドで計算 ◦ h=64を単一ツリーにすると264個の鍵生成が必要で非現実的 しかしd=8にすると28=256個の鍵生成で済む • 中間層のW-OTS+鍵は常に同じ値（下位ツリーのルート）に署名するため、 同じ署名の再計算であれば何度使っても安全 ◦ 下位層のツリーを変更するとW-OTS+署名のワンタイム性が破れるため、 下位ツリーは決定論的に導出され１つに固定される 6