著者：798.eth
Lightning Labs の共同創業者 Olaoluwa Osuntokun が最近、新しいビットコインのスケーリング設計を発表した。その名は LayerTree。
そこではかなり大胆な構想が提示されている。何千、何万、さらには何百万人ものユーザーに同じビットコインの UTXO を共有させつつ、各ユーザーには独立した資金の所有権と一方的な退出能力を保持させる、というものだ。
これは一見すると矛盾しているように聞こえる。
100万人がそれぞれビットコインを保有する場合、通常はオンチェーンに100万個の UTXO が必要になる。資金を取引所に集中させれば、確かに少数の UTXO を保持するだけで済み、内部送金も瞬時に完了するが、ユーザーは取引所のデータベースを信頼するしかない。
LayerTree は、この両者の中間に新たな立ち位置を見出そうとしている。
オンチェーンには UTXO が1つだけ保存される。誰がどれだけのビットコインを保有しているかは、オフチェーンの Merkle Sum Tree に記録される。運営者は日常のサービスを維持する責任を負うが、ユーザーの残高を勝手に変更することはできず、既存ユーザーが自分の資金をオンチェーンに引き戻すことを妨げることもできない。
1本の木がどのように全員の残高を表すのか
LayerTree では、各ユーザーが1つの葉ノードを保有する。
葉ノードには、ユーザーの残高、所有者の公開鍵、退出用公開鍵、リース期間、状態シーケンス番号が記録される。隣接する葉ノードは上へ向かって次々とマージされ、各親ノードは2つの子ノードの残高合計とハッシュを記録し、最終的に唯一の木のルートが形成される。
木の中に4人がいると仮定しよう。
Alice は 5 BTC、Bob は 3 BTC、Carol と David はそれぞれ 1 BTC を保有している。
オンチェーンの共有 UTXO は合計 10 BTC を保持している。木のルートは、4人がそれぞれどれだけの残高を保有しているか、そしてすべての残高を合計するとちょうど 10 BTC になることをコミットしている。
誰かが1つの葉ノードを変更すれば、木のルートは変化する。誰かが残高を勝手に増やそうとすれば、ルートノードの金額検証が失敗する。
ビットコインのオンチェーンには木全体を保存する必要はなく、このルートと、木の中の総残高に対応する UTXO を保存するだけでよい。
これは、多数のユーザーの財産権記録を1つの暗号学的コミットメントに圧縮したことに相当する。
ユーザーはどのように単独で退出するのか
Alice が退出したいとき、運営者の承認を得る必要も、他のユーザーがオンラインである必要もない。
彼女は自分の葉ノード、葉ノードから木のルートへ至る Merkle 証明、そして自分の署名を提出するだけでよい。
ビットコインのスクリプトは、Alice が確かにこの木の中に存在すること、彼女が対応する残高を保有していることを検証し、1つのトランザクションで2つのことを完了する。
第一に、Alice の残高を彼女が指定した退出先アドレスへ支払う。
第二に、Alice の葉ノードを削除し、残りの資金を新しい木のルートをコミットする UTXO に入れる。
木の中に100人いようと100万人いようと、Alice は退出トランザクションを1つブロードキャストするだけでよい。
LayerTree が言う O(1) 退出とは、退出に必要なトランザクション数が常に1つであることを指す。Merkle 証明のサイズは依然としてメンバー数の増加に伴って増え、およそ O(log N) で成長する。
この設計は、通常状態では多数のユーザーを1つの UTXO に圧縮しつつ、異常状態ではオンチェーンの脱出経路を保持する。
LayerTree における2種類の送金方法
ユーザーが送金のたびに木のルートを変更するなら、すべてのトランザクションが依然として順番にオンチェーンに載ることになり、スケーリング効果は非常に限定的になる。
そこで LayerTree は、日常の支払いをオフチェーンで行い、主に2つの方式を提供する。channel leaf と voucher だ。
Channel leaf：Lightning チャネルを葉ノードに入れる
1つの葉ノードは、ユーザーと運営者の間の Lightning チャネルを表すことができる。
チャネルの資金出力は、当面は単独の UTXO としてオンチェーンに現れず、LayerTree 全体の共有出力の中に含まれる。ユーザー間の支払いは、運営者を介して通常の Lightning HTLC を転送する形で行われる。
支払いの過程で、LayerTree の木のルートは変わらず、オンチェーントランザクションも発生しない。
したがって、channel leaf の支払い速度は通常の Lightning に近く、通常は数秒以内に完了する。運営者はここでルーティングノードの役割を担い、LayerTree はチャネルに必要なオンチェーン UTXO を圧縮する役割を担う。
それはまるで、オンチェーン上では1つの出力しか占有しない大型の Lightning ハブのようだ。
Voucher：オンチェーンで換金できるデジタル小切手
LayerTree のより創造的な部分は voucher だ。
Voucher は、ユーザーが署名し、ビットコインスクリプトが最終的な執行能力を提供するデジタル小切手と理解できる。
Alice の葉ノードに 100,000 sats があり、彼女が Bob に 10,000 sats を支払うと仮定しよう。
Alice は木全体を即座に変更する必要はない。彼女は1つのメッセージに署名するだけでよい。そのメッセージには、この voucher がどの LayerTree に属するか、資金がどの葉ノードから来るか、Bob がどのような新しい葉ノードを得るか、支払い金額はいくらか、そして Alice の葉ノードの現在の状態シーケンス番号が記される。
Alice が署名済みの voucher を Bob に送れば、オフチェーン支払いは完了する。
このプロセスは署名とネットワーク転送のみで構成され、速度は取引所の内部送金に近づくことができる。
重要な違いは、Bob が手にするのが単なる運営者データベース上の残高記録ではないことだ。彼が手にするのは、ビットコインスクリプトに渡して執行できる支払い命令である。
Alice または運営者が協力をやめた場合、Bob は自分で voucher をオンチェーンに提出できる。LayerTree コントラクトは Alice の葉ノードから対応する金額を差し引き、同時に Bob のために新しい葉ノードを作成する。
このプロセス全体を CLAIM と呼ぶ。
Alice が再度署名する必要はなく、運営者も Bob の換金を阻止できない。
1枚の voucher がなぜ1回しか使えないのか
各 LayerTree の葉ノードには状態シーケンス番号があり、seq と呼ばれる。
Alice の現在の seq が 7 だとすると、彼女が署名する voucher は明確に seq 7 にバインドされる。
1枚の voucher が換金されると、Alice の残高は減少し、seq も 7 から 8 に増える。seq 7 にバインドされた古い voucher はすべて無効になる。
これにより、同じ小切手が重複して換金されるのを防げる。
Alice が Bob に頻繁に支払う場合、毎回独立した voucher を作成する必要もない。
最初の支払いで 10,000 sats を支払うとき、Alice は累計金額 10,000 sats の voucher に署名できる。2回目にさらに 20,000 sats を支払うとき、彼女は累計金額 30,000 sats の voucher に再署名できる。
Bob は最新の1枚だけを保存すればよい。
何百、何千もの少額支払いを、最終的な累計残高を表す1枚の証憑に圧縮できる。双方が協力を続ける限り、毎回の支払いをビットコインのブロックに書き込む必要はまったくない。
Voucher は信用リスクを排除できない
Voucher は本物の署名を持ち、オンチェーン換金経路も持つが、換金されるまでは依然として発行者の信用リスクを伴う。
Alice の葉ノードに 100,000 sats しかないと仮定しよう。
彼女は Bob に 80,000 sats の voucher を発行し、同時に Carol にもう1枚の 80,000 sats の voucher を発行できる。
2枚の voucher の署名はどちらも本物だが、Alice の残高は両方を同時にカバーできない。
ビットコインスクリプトは超過資金の換金を阻止できるが、Alice がオフチェーンで残高を超える複数の証憑に署名することを阻止はできない。最終的に誰が資金を得られるかは、誰が先に換金を完了するかに左右されるかもしれない。
Alice は他の合法的な操作を通じて自分の葉ノードを更新し、seq を増やすこともできる。古い状態の voucher はその後無効になる。
したがって、まだ決済されていない voucher は伝統的な小切手によく似ている。
署名は誰が発行したかを証明でき、保有者は換金を試みられるが、口座残高が不足しているかもしれず、複数の小切手が同じ残高を奪い合うかもしれない。
受取人は、支払人の利用可能残高、現在の seq、未決済の証憑、葉ノードのリース期間、そして支払人の信用状況に注意を払う必要がある。見知らぬ相手や大口の支払いに直面した場合、受取人は即時換金を選ぶかもしれない。長期的な協力関係にある相手との少額・高頻度の支払いは、引き続きオフチェーンで累計できる。
LayerTree の公式サイトも、受取人は voucher が換金されるか他の方法で決済されるまでは、それを credit とみなすべきだと明言している。
この信用リスクは、voucher が高い効率を得るために支払う代償である。
なぜ voucher を設計するのか
信用リスクがあるなら、なぜすべて Lightning チャネルを使わないのか。
それは voucher の構造がよりシンプルで、より柔軟だからだ。
支払いの双方が事前に独立したチャネルを確立する必要がなく、どの葉ノードの所有者でも直接発行でき、何度も累計更新でき、LayerTree と Lightning の間の決済証憑としても機能する。
LayerTree は credit leaf というものを設計し、Lightning からの支払いを受け取るために使う。
運営者は Lightning の支払いを受け取った後、自分が資金を提供する葉ノードを使って、受取人に新しい累計 voucher を発行できる。受取人はそれを保持し続けることも、必要に応じて自分でオンチェーン換金することもできる。
基本的なフローには短い信頼の窓が存在する。運営者は Lightning の支払いをすでに受け取っているが、まだ受取人に voucher を発行していない状態だ。論文では pending pair も設計されており、ハッシュロック、事前署名済み voucher、決済窓を通じて、受取人が先に執行可能な証憑を取得してから、Lightning 支払いの preimage を解放する。
この構造において、voucher は Lightning 支払いと共有 UTXO 残高の間の橋渡しとなる。
特に、高頻度の少額支払い、給与ストリーム、コンテンツ課金、長期サービス決済、そして運営者が定期的に一括清算するシナリオに適している。日常の状態では署名を交換するだけでよく、オンチェーン換金は紛争処理と最終決済のツールとして温存される。
LayerTree はどのビットコインアップグレードに依存するのか
LayerTree は現時点ではビットコインのメインネットで稼働できない。
covenant、つまり1つの UTXO が将来の使用（スペンド）方法に制約を課す仕組みが必要になる。例えば、スクリプトはユーザー退出後に残りの資金が新しい木のルートをコミットする出力に再び入ることを保証し、任意のアドレスに持ち去られないようにしなければならない。
プロジェクトは4種類のオペコードの組み合わせを設計している。
FULL バージョンは BIP 441、BIP 440、OP_TX、BIP 348、そして一連の楕円曲線オペコードに依存する。
BIP 441 は初期に無効化された一部のスクリプト能力を復元し、より柔軟なデータと数値の処理をサポートする。BIP 440 はこれらの可変コスト操作に計算予算を提供する。
MID バージョンは BIP 347 の OP_CAT、OP_TX、BIP 348 の OP_CHECKSIGFROMSTACK、そして BIP 449 の OP_TWEAKADD に依存する。
OP_CAT はスクリプト内のデータを連結するために使われる。OP_TX はスクリプトが現在のトランザクションを読み取り、制約することを可能にする。OP_TWEAKADD は新しい状態をコミットする Taproot 公開鍵を計算するために使われる。
中でも BIP 348 は voucher にとって特に重要だ。ビットコインスクリプトが任意のデータ上の署名を検証することを可能にする。この能力がなければ、スクリプトが Alice がオフチェーンで署名したデジタル小切手を検証するのは難しい。
MIN バージョンは OP_CAT と OP_TWEAKADD のみに依存するが、退出と SPLIT しか実現できず、voucher と channel leaf をサポートできない。これは LayerTree の最低能力の境界を証明する実験に近い。
CCV バージョンは BIP 443 の OP_CHECKCONTRACTVERIFY、OP_TX、そして voucher 用に用意された BIP 348 に依存する。
BIP 443 は UTXO が動的な状態コミットメントを保持し、新しい出力が更新後の状態を継承しなければならないことを制約できる。これは LayerTree のようなオンチェーン状態マシンと非常によく噛み合い、4つの方式の中で退出サイズが最も小さい部類に入る。
ただし、これらの BIP はいずれもまだビットコインのメインネットでアクティベートされていない。
「100万人が1つのUTXOを共有」にはもう1つの追加前提がある
LayerTree の宣伝で最も性能が美しいバージョンは、OP_MERKLESUMUPDATE という専用オペコードにも依存している。
これは Merkle Sum 証明を検証し、1つの葉ノードを置き換えた後の新しい木のルートを直接計算できる。
これがあれば、65,536 人のメンバーを含む LayerTree で、1人の退出はおよそ 540 vB で済む。メンバー数が倍になるごとに、退出トランザクションは約 10 vB しか増えない。
しかし OP_MERKLESUMUPDATE は現時点ではプロジェクトのリポジトリにある設計とシミュレーション実装にすぎず、正式な BIP になっておらず、ビットコインのアップグレードプロセスにも入っていない。
既存のオペコード提案だけを使う場合、65,536 人規模での退出コストはおよそ 908 から 1,473 vB になる。
したがって「1本の木が数百万人を支える」ことは暗号学的構造としては成立するが、その高効率な実装は依然として現在の BIP よりさらに進んだビットコインのスクリプト能力に依存している。
大規模な取り付け騒ぎを解決できるか
LayerTree は通常状態でのオンチェーン占有を大幅に圧縮できるが、ビットコインのブロック自体の容量を増やすことはできない。
同じ木のすべての状態更新は、同じ共有 UTXO を消費して再作成する必要があるため、単独退出は順番待ちで実行される。
プロジェクト自身の試算によれば、65,536 人のユーザーが同じ木からそれぞれ退出する場合、およそ 2,622 ブロック、約18日かかる。
実際のデプロイでは、ユーザーを多数のより小さな木に分散させ、同時に一括参加、一括決済、一括退出を使う必要がある。
これは LayerTree の設計目標も示している。大多数の通常活動をオフチェーンに留め、限られたオンチェーン空間を最終決済と異常処理に残す、ということだ。
LayerTree の意義
LayerTree には依然として明確な運営者が存在する。
運営者はユーザーの受け入れ、サービスの維持、支払いのルーティング、一括更新の組織化を担当する。新規ユーザーを拒否することも、リアルタイムサービスの提供を停止することもできる。したがって、単一の LayerTree は完全に非中央集権的とは言えない。
それは「非カストディ型共有 UTXO システム」と呼ぶ方が適切だ。
運営者はサービスの入口を掌握し、ユーザーは資金の退出権を掌握する。運営者は閉鎖するかもしれないし、サービスを拒否するかもしれないが、プロトコルの設計上、ユーザーの葉ノードにある残高を勝手に持ち去ることはできない。
LayerTree で最も注目すべき部分は、通常の UTXO、Lightning チャネル、カストディ型データベースのほかに、別の資金形態を示したことだ。
瞬時に流通し、継続的に累計され、最終的にビットコインスクリプトに強制換金を委ねるデジタル小切手である。
それは信用リスクを排除しておらず、ブロック空間の上限を突破してもいない。
信用をオフチェーン支払いの段階に限定しつつ、受取人に許可不要のオンチェーン執行経路を残している。
これはかなり創造性に富んだビットコインのスケーリング発想である。
