Taprootのマークルブランチ

ブランチ内の各ハッシュは、タプツリーの兄弟1つ分であり、ご自身のリーフから上へ根に向かう順に並びます。BIP-341はブランチを128個のハッシュ、4,096バイトに制限しており、そのソート済みツリーにより、ブランチは左右どちらの方向を示すビットを一切持ちません。ブランチの長さは公開されるため、より深いリーフはツリーの最小深度を漏らし、どのウォレットがアウトプットを構築したかを示唆します。

仕組み

Taprootのマークルブランチはコントロールブロックの中を移動します。コントロールブロックは、アネックスがあればそれを取り除いた後の、スクリプトパスによる支払いのウィットネススタックの最後の項目です。

コントロールブロックの形は固定されています。バイト0はリーフバージョンと、アウトプットキーのY座標のパリティを保持します。バイト1から32までが内部公開鍵を保持します。それ以降のすべてがブランチです。連続する32バイトのハッシュがm個並ぶため、コントロールブロックは33 + 32mバイトとなり、mは0から128までの整数でなければなりません。それ以外の長さでは、1つのオペコードが実行される前に支払いが失敗します。

検証は下から始まります。ノードは開示されたスクリプトをTapLeafタグの下でハッシュし、次にTapBranchタグの下で各ブランチハッシュを順に畳み込み、各ステップで2つの32バイトの値を辞書順に比較し、小さい方を先にハッシュします。出力されるのはタプツリーのルートであり、これがTapTweakタグの下で内部鍵とともにハッシュされ、内部点に加算され、支払い対象のアウトプット内の32バイトと照合されます。

この比較が仕組みのすべてです。BIP-341がハッシュの前に2つの子をソートするため、ブランチは兄弟がどちら側にあったかを決して示しません。検証側がそれを割り出します。BIPの根拠説明の節は理由を率直に述べており、この設計はツリー内の特定のスクリプトの位置を気にせず、それらが実際にコミットされていることだけを気にすると述べています。

128という上限は、恣意的な上限ではなくセキュリティ上の境界です。最適に詰め込まれたツリーでの深さは、リーフの確率の逆数の2を底とする対数に近づくため、深さ129は、使用される確率が2^128分の1未満のスクリプトを意味し、BIP-341によれば、それはおそらく削除できるとされています。もう一方の端では、単一リーフのタプツリーはmが0であり、ブランチは空で、タプリーフハッシュがすでにルートです。

どこで見られるか

Taprootのマークルブランチは、鍵で署名する代わりにスクリプトを開示してbc1pアウトプットを支払うあらゆるトランザクションに現れます。

BIP-341は5つのリーフからなるツリーで1つの例を挙げています。A、B、C、EはTapLeafハッシュであり、ABは最初の2つに対するTapBranchハッシュです。スクリプトDを使って支払うには、コントロールブロックはC、次にE、次にABを保持します。3つのハッシュ、96バイトのブランチ、129バイトのコントロールブロックです。EとCDが結合される際、Eはソート順で下位にあるため、Eが先にハッシュされます。

計画すべきはプライバシー上のコストです。BIP-341のセキュリティの節は、スクリプトの深さがツリーの最小深度を漏らし、それがアウトプットを構築したウォレットソフトウェアを示唆し、チェーン分析によるアドレスのクラスタリングを助けると述べており、リーフの確率が与えるツリーから逸脱することを推奨しています。リーフの再利用ももう1つの罠です。別のアウトプットを支払うと同じブランチハッシュが再公開される可能性があるため、32バイトの兄弟を共有する2つの支払いは関連しているように見えます。

Taprootのマークルブランチvsマークルブロック

Taprootのマークルブランチはスクリプトがアドレスに属することを証明し、マークルブロックはトランザクションがブロックに属することを証明します。タプツリーブランチはコンセンサス上重要であり、支払いを検証するすべてのフルノードによって再計算され、ソートによって左右を言う必要がなくなったため位置に依存しません。ブロックのトランザクションツリーに対する証明はその手法を借りることができません。ブロックのマークルルートの下でのトランザクションの順序は固定されており意味を持つため、ハッシュに加えてたどった経路も保持しなければならないからです。