MAST

このアイデアは、実際の導入よりも前から存在していました。2つの提案、BIP-114とBIP-116が2016年と2017年にこれを記述しましたが、どちらも有効化されませんでした。Taprootは2021年にtaptreeとしてこれを導入し、そのスクリプトパスによる支出では、1つのリーフと、1レベルあたり32バイトの証明が明かされます。複数の復旧経路を持つウォレットでは、チェーン上に記録されるのは、実際に使用した1つの経路だけです。

仕組み

スクリプトのツリーは1つのハッシュに集約され、アドレスはそのハッシュにコミットします。

まず、希望する条件を用意します。たとえば4つです。日常的に使う鍵、3つの鍵のうち2つが必要な家族の定足数、1年間使用がなかった後に有効になる弁護士の鍵、そして外部に保管する緊急用の鍵です。各条件はそれぞれ小さなスクリプトとして記述され、それぞれがハッシュ化されてリーフになります。リーフはペアにされてハッシュ化され、その結果もペアにされて再びハッシュ化され、この処理は1つの32バイトのルートで終わります。

支出時には、使用したリーフ、そのスクリプト、そしてそのリーフからルートへ至る経路上の兄弟ハッシュが明かされます。ツリーが2レベルであれば兄弟ハッシュは2つ、64バイトとなり、誰でもルートを再計算して、そのスクリプトがコミットされていたことを確認できます。残りの3つの条件は一切現れません。弁護士の鍵が存在すること、家族の定足数が3つの鍵のうち2つであったこと、外部に保管された鍵がその取り決めの一部であったことは、誰にも分かりません。

コストは条件の数の対数に比例して増加し、それこそがこの構造を使う価値のある理由です。8個のスクリプトからなるツリーはウィットネスに3個のハッシュを追加し、128個のスクリプトからなるツリーは7個を追加します。また、BIP-341は128レベルの深さを許容するため、スクリプトパスによる支出に付随するコントロールブロックは最大4,129バイトになります。

名称は混乱しており、昔からそうでした。MASTは、書く人によってmerkelized alternative script treeともmerkelized abstract syntax treeとも展開されます。後者はBIP-114に由来し、そこではツリーが代替案の集合ではなく、1つのスクリプトの断片を保持していました。実際には、どちらも同じ構造を指します。

使われている場面

複数の支出方法を持つすべてのTaprootアドレスは、ウォレットがその言葉を使っているかどうかに関わらず、MASTを利用しています。

タイムロック付きの相続用ウォレットが最も分かりやすい例です。たとえばLianaは、通常の支出用の鍵と、一定の待機期間の後に使用可能になる復旧用ブランチをtaptreeに持つアドレスに入金し、通常の支出では復旧用ブランチを一切公開しません。ライトニングネットワークは、その新しいチャネルのアウトプットに同じ形を用いており、協調クローズの間は罰則の経路を隠したままにします。

構築する前に知っておく価値のある手数料の側面があります。バランスが重要です。頻繁に使うと見込まれるリーフは、ツリーの上部近くに置くべきです。なぜなら、追加の1レベルごとに、そのリーフを通るすべての支出のウィットネスに32バイトが加わるからです。ツリーのレイアウトを設定できるウォレットは通常これを代行しますが、すべての条件を平坦で均衡の取れたツリーに詰め込むコーディネーターソフトウェアでは、よく使う経路がまれな経路の分まで負担することになります。

MAST vs Taproot

MASTはツリーであり、Taprootはツリーと非常口です。純粋なMASTの設計では、すべての支出が何らかのスクリプトを明かすことを強いられるため、未使用のブランチについて何も分からなくても、コントラクトが存在したことはチェーン上に常に記録されます。

Taprootはルートに鍵を追加します。アドレスは、Merkleルートで調整（tweak）された内部公開鍵にコミットし、関係者全員が同意すれば、調整後の鍵で署名し、単一の署名以外は何も公開しません。その支出は、1人による支払いと区別がつきません。ツリーは依然として存在し、依然として執行可能であり、ただ決して示されないだけです。MASTはブランチ間のプライバシーを提供し、Taprootはコントラクトと通常の支払いとの間のプライバシーを提供します。