ソフトフォーク/契約依存のレイヤー2レビュー
オンチェーンウォレットは、トランザクションとトランザクションのほぼ1対1のマッピングを実現します。つまり、ユーザーが行う経済取引ごとに、おおよそ1つのブロックチェーントランザクションが必要です。集約、コインジョイン、カットスルーペイメントなどは、この文をやや変更しますが、大体正確です。
Lightningは、トランザクションをトランザクションに多対1のマッピングを実現しました：Lightningの魔法は、無限に近い数の経済取引が単一のLightningチャネルで発生できることです。それ自体が単一の未使用トランザクション出力（UTXO）に関連しています。基本的には、私たちは「時間」の次元であるトランザクションを取り、その次元を折りたたむことにより、大幅なスケーリングを実現しました。
ただし、ユーザーごとに1つのUTXOを作成することは、議論の余地があると言えます。したがって、自己主権的な方法で複数のユーザーが1つのUTXOを共有できるようにするための多くの提案があります。再び、スケーリングの「空間」次元、つまりユーザーを1つのUTXOにまとめることによって、さらなるスケーリングを実現するための多くの提案があります。
ここでの目標は、これらすべての提案の概要を行い、彼らが共有する技術的なパターン、どのような新しいオペコードやその他のソフトフォークのアップグレードが必要であるか、そしてすべての部分がどのように組み合わさるかの比較表を作成することです。 その過程で、L2プロトコルの実際の定義、ライトニングが既に可能なスケーリングの種類、およびこれらすべてを実現するためのメンプールに行う必要のある改善の理解も得ます。
お礼がありますFulgur Venturesこの研究のスポンサーとして。彼らはこの投稿の内容に編集上の制御を持っておらず、公開前にそれをレビューしていませんでした。
ありがとうございますダニエラ・ブロッゾーニ、Sarah Coxおよびその他の先行公開レビュー用のもの。
定義
レイヤー2とは何ですか？
「Layer 2」という用語はしばしば広義で定義されます。そのため、銀行のようなエンティティ（例：Liquid）もLayer 2と定義されることがあります。この記事では厳密な定義を採用します：Layer 2（L2）は、Bitcoinで表現されるシステムであり、他の当事者とのオンチェーントランザクションの数よりもBTCをより頻繁に取引できるようにすることを目的としています。具体的には以下のいずれかの方法で実現します。
- システム内のペナルティやコストを考慮に入れると、誰もがシステム内で収益を得ることはできません。評判の損失、法的な結果などのシステム外のコストやペナルティは、私たちの定義には含まれていません。
- (好ましい) 資金の真の所有者は、第三者の協力なしに手数料を差し引いて資金を一方的に引き出すことができます。
L2システムがオンチェーンで表現できないほど小さな価値の量や取引を表現できるようにするため、最初のオプションが必要です。例えば、Lightningでは、HTLCはオンチェーンで表現できないほど小さな価値を持つことがあります。その場合、HTLCの価値はコミットメントトランザクションの手数料に追加されます。Lightningノードは、ダストHTLCを正しいタイミングでチャネルを閉じることで「盗む」ことができますが、その場合、より高額になります。1HTLCの価値を下回る場合、盗難は利益にならないようです。
とは言っても、一方的な撤退は常に私たちの主要な設計目標です。2
この定義によれば、ライトニングのようなものはL2システムと見なされます。ただし、Liquid、Cashu、およびFedimintのようなシステムはL2ではありません。なぜなら、他の当事者があなたの資金を管理しているからです。RGBのようなクライアント側の検証スキームも、この定義によればL2ではありません。なぜなら、BTCそれ自体を信頼できないからです。最後に、@RubenSomsen"/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechainsはカットされることに失敗しました。なぜなら、Statechainエンティティがプロトコルに従わない場合、資金を盗むことができるからです。
Covenantsとは何ですか？
…そしてなぜよりスケーラブルなレイヤー2システムがそれらを必要とするのですか？
Bitcoinスクリプトでは、契約は、txoutの支出方法が事前に制限されるメカニズムであり、そのtxoutを支出するために使用されるトランザクションの形式が事前に定義されたり、純粋な署名に限定されない方法で制限されるようにするものです。複数の当事者間でUTXOを共有するL2システムは、L2プロトコルのルールとインセンティブを実装するためにUTXOの支出方法を制約する必要があるため、契約が必要です。
再帰契約
再帰契約とは、支出されるUTXOの制約ルールが無制限に支出トランザクションの子UTXOに再帰的に適用できる特性を持つ契約です。再帰契約には、長い間、一部の人々にとっては望ましくないと考えられてきましたなぜなら、彼らはコインに永久に拘束することができるからです。少なくとも、政府のような第三者の許可なしに永久に拘束することができます。
目標
ライトニングは現在の「ベストインクラス」のレイヤー2システムです。ただし、制限があります。具体的には：
- スケーリング-ライトニングは現在、エンドユーザーごとに少なくとも1つのUTXOが必要です。3
- 流動性 - Lightningは、資金をチャネルに拘束する必要があります。
- インタラクティビティ - Lightningは、支払いの受取人がオンラインである必要があります。これにより、信頼性のある受け取りが可能となります。
レイヤー2システムを評価する際、私たちの目標はこれらの主要な制限を改善することであり、できれば新しい制限を追加せずに行うことです。
Lightning のスケーリング制限
実践での「エンドユーザーごとの1つのUTXO」とはどういう意味ですか？ライトニングチャネルは無期限に稼働できるため、これを見る方法の1つは、1年間に新たに何本のチャネルを作成できるかを尋ねることです。4Taprootアウトプットを作成するには、43vBの余白コストがかかります。チャネルの作成が分散され、1つの取引で多数のチャネルを作成する場合、その他の取引オーバーヘッドは無視できるほど小さくなり、大量のチャネルを年間に開設して新規ユーザーをオンボードすることができます。たとえば、ブロックの90%が新しいTaproot Lightningチャネルの開設に充てられたとします。
推定されるところによると、世界の人口の約半数がスマートフォンを所有しています43億人。したがって、1年ごとにライトニングチャネルを利用できる可能性のある全人口のかなりの割合を実際にオンボードすることができます。
しかし、チャンネルは永遠に続くわけではありません。時々、ユーザーはウォレットを切り替えたり、チャンネル容量を増減させたりしたいと思うでしょう。チャンネル容量を変更する最も効率的な方法は、スプライシング、特に実装されている フェニックスウォレット
チャネルが開かれるのと同様に、スプライシングも効率を向上させるために摘み取りの形で行うことができ、複数のスプライス操作が1つの取引を共有して資金の追加および削除に必要な入出力の数を減らすことができます5. したがって、ユーザーのスプライスごとに必要なデルタブロックスペースは、使用されると仮定していますmusig, これは43vBのTaproot出力にプラスします
57.5vBのタップルートキーパスペンド、合計100.5vBです。再度90%のブロックスペース使用を想定した場合、次のようになります:
最後に、ウォレット間でのライトニングチャネルの切り替えが、次のウォレットがコミットメントアドレスに送金された後にコミットメントトランザクションに署名することを信頼するか、または両方のウォレット実装で協力的なチャネルサポートを使用して単一のトランザクションで行うことに注意してください。
もちろん、ライトニング・チャネル以外のビットコインの競合ユースケースが存在し、それが手数料にどのように反映されるかはわかりにくいです。しかし、これらの数値は、現在の技術で数億の自己主権ライトニングユーザーをサポートすることが少なくとも技術的に可能であることを示唆している近似値を与えています。
レイヤー2の概要
私たちのL2システムの定義に基づいて、ビットコイン開発コミュニティで議論されている主なデザインパターンは2つあります。
- チャンネル
- 仮想UTXOs
Lightningが主な例であるチャネルパターンでは、プロトコルは「ハッピー・パス」にはないがマイニングされる可能性がある当事者間の事前署名済みトランザクションを交換することによって進行します。これらの事前署名済みトランザクションは、UTXOを当事者間で分割します。トランザクションは、その分割のバランスを繰り返し変更することで行われ、新しい事前署名済みトランザクションが生成されます。同じUTXOを支出する多くの異なる可能な有効なトランザクションが存在するため、正しいトランザクションが実際にマイニングされるようにするために、何らかのインセンティブメカニズムが必要です。
仮想UTXO（V-UTXO）設計パターンでは、Arkが最も顕著な例ですが、V-UTXOは契約または多数派の合意によって作成されます。これにより、V-UTXOの資金を単独で引き出すためにマイニングできる取引が作成されますが、「ハッピーパス」にはありません。 この意味では、V-UTXOはチャネルに類似しています。 ただし、チャネルとは異なり、V-UTXOスキームは（概念上）V-UTXO自体を消費することで取引を行います。6pre-signedトランザクション。
“ハッピーパス”デザインパターンは、「すべての当事者が同意する」スクリプトパス、例えばN-of-Nマルチシグのようなものの使用です。 taprootはこのコンセプトに特化して設計されており、キーパスがmusigを介したN-of-Nマルチシグになるように許可しています。 すべての当事者が同意すると仮定すると、ハッピーパスはコインを効率的に（かつプライベートに）支出することを可能にします。
興味深いことに、仮想UTXOは多くの意味で「実際の」ものであるため、仮想UTXO上にチャネルを簡単に構築することができます。単に、仮想UTXOを作成し、採掘された場合にはチャネルに必要なUTXOの作成につながるようなものです。この意味では、仮想UTXOスキームは
チャンネルよりやや下のレイヤー。
ライトニング
プロダクションで実装された現状、主にLightning Networkに基づいていますBOLTsの基準. Lightningは、LightningチャネルとHTLC、P2Pルーティングネットワーク、オニオンルーティング、請求書の標準など、さまざまな要素の組み合わせです。特に、Lightningはコンセンサスシステムではないため、Lightningシステムの異なる要素は、すべてのユーザーがまったく同じ方法で採用する必要はありません。この記事の目的のために、「Lightning」という言葉は、広義に使用し、広く使用されている現行（典型的な）Lightningプロトコルの容易に予測されるアップグレードも含みます。
前述したように、Lightning の主な特徴は、ユーザーごとに少なくとも 1 つの UTXO を持つ必要があるため、エンドユーザーのスケーラビリティの制限です。とはいえ、Lightningの「コア」ルーティング要素(トランザクションの大部分をルーティングするパブリックLightningノード)では、支払いルーティングに使用される各パブリックチャネルが毎秒多数のトランザクションを簡単にサポートできるため、ルーティングノードよりもはるかに多くのエンドユーザーがいる場合、Lightningは問題なく機能するため、これらのスケーラビリティの制限はそれほど問題になりません。これは、将来の多くのL2システムもライトニングネットワークに参加することを期待している理由でもあります。これは、Cashu のような既存の L2 システムが実際に役立つために Lightning ネットワークに大きく依存していることにも表れています: Cashu の主な用途は、おそらく Lightning 支払いの送受信です。
非対話チャンネル
この構造では、OP_CTVを使用してインタラクティビティの要件を減らすことで、Lightning チャネルを改善します。ただし、1ユーザーあたり1UTXOのスケーリング制限は改善されないため、これ以上は説明しません。
チャネルファクトリー
ここでは、複数の当事者が1つのn-of-nマルチシグアドレスを交渉し、そのマルチシグアドレスを使用してn個の異なるUTXOを作成するトランザクションが行われます。それらのUTXOは支払いチャネルに使用されます。チャネルは、チャネルの状態をオンチェーンに置く必要がある場合でも、分割トランザクションをマイニングできるため、オンチェーンで直接開かれた場合と同じセキュリティで使用できます。チャネルが閉じられると、チャネルはすべてのnnチャネルを協力して一度に閉じることができるため、オンチェーンのスペースを節約できる可能性があります。
チャネルファクトリーは、採掘される可能性があるが、実際にはハッピーパスで採掘されることは予想されていないUTXOを交渉しているため、V-UTXOの非常に原始的な例です。
チャネルファクトリー自体は、可能にするためにソフトフォークを必要としません。ただし、上記で説明したシンプルなチャネルファクトリーは、実際にスケーリングの利益を得るために必要な調整のため、おそらく小規模な参加者の数を超える場合には実用的ではない可能性があります。したがって、契約提案などのOP_EvictまたはCTV(txoutツリー経由)は、全員を一度にオンチェーンに強制するのではなく、個々の当事者をオンチェーンに強制できる、よりきめ細かな結果を可能にすることを目的としています。
Eltoo/LN-対称性
Eltooという名前は非常に混乱を招くため、今後は更新された名前であるLN-Symmetryのみを使用します。
Poon-Dryjaチャネルは、誤った状態を罰することで、正しい状態をオンチェーンで公開することを奨励しますが、LN-Symmetryは、代わりに、誤った状態を追加トランザクションで更新することを許可します。これには、ペナルティの複雑さが解消され、Lightning チャネルが簡素化されるという利点があります。ただし、不正行為を阻止するためにペナルティが必要であることは間違いないため、信頼できないシナリオでは不利になる可能性があります。
LN-Symmetry needs a soft-fork to enable SIGHASH_ANYPREVOUT, 他の状態トランザクションを更新中に再支出できるようにするために必要です。
単独では、LN-Symmetryは従来のライトニングチャネルにスケーリングの改善を提供しません。しかし、支持者は次のように主張しているそれにより、チャネルファクトリーのようなものを実装しやすくなります。
アーク
Arkは取引のスケーリングに新しいアプローチを取っています：完全に移動可能な仮想UTXO（V-UTXO）、それはアトミックにマージおよび分割することができます7オフチェーン取引。アークでは、アークサービスプロバイダ（ASP）と呼ばれる中央コーディネータが、ユーザーに対して定義された有効期間（例：4週間）を持つV-UTXOを提供します。これらの期間はラウンドとして知られています。これらのV-UTXOは、CTVなどのメカニズムを介して、1ラウンドごとにプールtxoutを介して作成され、単一のオンチェーンtxoutがV-UTXOのツリーにコミットできるようにします。ラウンドの有効期限は、アークがスケーリングの利点を実現する方法です：ラウンドの終わりに、プールtxoutがアンロックされ、ASPが単一の署名でそれを支出できるようになります。ラウンドの有効期限が経過すると、V-UTXO自体もプールtxoutの有効期限が切れるときに期限が切れます：V-UTXOを所有するユーザーは、プールtxoutの有効期限に達する前にそのV-UTXOを支出するか、オンチェーンに配置する必要があります（単独の引き出し）。
当事者間でV-UTXOを取引するために、Arkコーディネーターは、1つ以上のV-UTXOを使用するトランザクションに連署し、トランザクションが1つ以上の他のV-UTXOが別のラウンドで作成された場合にのみ有効になるようにします。慎重なタイムアウト(詳細はArkのドキュメントを参照)と相まって、この依存関係がV-UTXOの支出をトラストレスなものにしています:V-UTXOは、別のプールトランザクションで新しいV-UTXOが作成されない限り、オンチェーンで請求することはできません。その依存関係を実際に実装する方法はいくつか考えられます。ただし、正確な詳細はこの記事の目的とは関係ありません。
これにより、特定のASPには同時に多くの異なるアクティブなラウンドが行われることに注意してください。新しいラウンドは頻繁に作成され、既存のラウンドの資金を移動するために許可されます。ただし、既存のラウンドは新しいラウンドと重なります。通常、新しいラウンドの後に一定期間が経過した後、既存のラウンドと新しいプールのトランザクションが作成されます。
アーク・エコノミクス
V-UTXOが使用されると、ASPは新しいラウンドを表す新しいプールtxoutで対応するBTCを提供する必要があります。しかし、ラウンドが終了するまで、使用されたV-UTXOの価値を回復することはできません。したがって、V-UTXOの使用には時間価値のあるコストがかかります。これは、ASPが提供する流動性によるものです。
具体的には、コストはV-UTXOが使用されたときに発生します。V-UTXOが未使用の場合、それはチェーンに置かれた可能性が非常に高いUTXOを表し、ユーザーはそれらの資金を所有しています。ただし、V-UTXOを使用するには、ASPは別の場所で取得した資金を使用して新しいプールtxoutを作成する必要があります。使用されたV-UTXOの資金は有効期限が切れるまでASPで使用できません。
したがって、V-UTXOを使うためには、短期間のローンが必要で、ラウンドの期限が切れるまでの現在との時間間隔をカバーするために資金を借りる必要があります。これは、V-UTXOを使うための流動性コストが実際には減少し、V-UTXOが古くなり、期限が近づくにつれて、理論上はゼロに近づくということを意味します。
最後に、V-UTXOの費用は、費やしたV-UTXOの合計サイズに関係していることを覚えておいてください。受取人に支払われる金額ではありません。つまり、V-UTXOを直接取引することを目的としたウォレット(例えば、V-UTXOベースのライティングチャネルのために1つのV-UTXOを管理するのとは対照的に)は、資金をV-UTXOに分割する方法でトレードオフを行う必要があります。単一のV-UTXOは、一方的な引き出しのコストを最小限に抑えながら、流動性ベースの取引手数料を最大化します。資金を多くのV-UTXOに分割すると、その逆になります。これは、オンチェーンのビットコインやライトニングトランザクションの経済性とはまったく異なります。
この流動性コストとは?本稿執筆時点では、ライトニングウォレットのPhoenixは、チャネルの流動性を1年間確保するために1%の手数料を請求します。最悪の場合、フェニックスは1年間資金を縛らなければならない。ただし、これは流動性が使用されていないことを前提としています。フェニックスへの資本コストは実際には高い可能性が高く、平均的な顧客は1年以内に流入した流動性を使用すると仮定しています。また、Phoenixは取引手数料から収益を得ており、チャネルの流動性を助成する可能性があります。最後に、フェニックスは儲からないかもしれません!
米国財務省短期証券レートは、別の推定値を提供します。執筆時点では、3か月の財務省短期証券レートは年間約5%です。このレートは米ドルがインフレしているために膨らんでいるという議論があるため、分析ではBTC建てファンドの流動性コストを年率3%と仮定します。
ラウンド間隔が4週間の場合、取引は流動性コストをかかえて開始されることを意味します。
,最終的にゼロに減少します。ユーザーが資金を新しいラウンドに移動しようとすると、ラウンドの期限切れの2週間前に、ユーザーは自己保管を達成するために年間約1.5%の流動性コストを支払っています。一方、ユーザーが最後の瞬間まで待つと8、コストはほぼゼロになる可能性がありますが、期限切れのリスクがあります。
ユーザーはこれを些細な費用とは見なさないかもしれません。また、この費用は、トランザクション手数料やその他の費用を多数の参加者に分散させることで、各ラウンドの固定費用を無視できるようにすることを前提としています。
もし固定費がそんなに無視できない場合はどうでしょうか？ASPに1000人のユーザーがいて、プールの送金は平均して1時間に1回行われます。4週間の期間で、それは672回のオンチェーン取引になります。つまり、彼らの資金を単に保持するために、ASPのユーザーはユーザーと同じくらいの取引手数料を支払わなければなりません！ASPが確認まで1時間待たせることを要求しているにもかかわらず、彼ら全員が独自のライトニングチャネルを開く方がおそらく安くなるでしょう。
ブートストラップアーク
ユーザー数が少ない新しいASPはジレンマに直面しています。要求されたラウンドが十分なV-UTXOを集めて有用なスケーリングとトランザクション手数料の削減を達成するために長時間待たなければなりません。または、ASPプールトランザクションが頻繁に発生し、ユーザーごとに高いトランザクション手数料が支払われます。前のセクションで示したように、頻繁なラウンドを分散するために多くのユーザーが必要であり、その基礎となるプールのtxoutsがかかることがあります。
ラウンドには期限が切れるため、この問題は進行中の問題であり、Lightningチャネルが直面している問題よりもさらに深刻です:少なくともLightningチャネルは無期限に有用であり続けることができ、チャネルを今すぐ開き、何ヶ月にもわたって徐々に償却することができます。第二に、ラウンドの期限が切れるため、これらのラウンドをバックアップする新しいtxoutをいつ作成するかについての柔軟性が低くなります:手数料が1週間または2週間高い場合、プールのtxoutが期限切れになるユーザーは、資金の管理を維持するためにそれらの高い手数料を(まとめて)支払うしかありません。Lightning チャネルでは、チャネルを実際に開くタイミングについて、より柔軟に対応できます。
Arkの作者たちが最初に想定したのは非常に楽観的なシナリオで、新しいラウンドが数秒ごとに行われることですが、初期のブートストラップはおそらくArkのトランザクションが確認されるまで数時間待つことができるユースケースで行われるでしょう（トランザクション手数料が補助されない場合）。
インタラクティブ
非保管型のArkは非常にインタラクティブなプロトコルです：あなたのV-UTXOが期限切れになるため、ASPとやり取りするための厳しい締め切りがあり、それを過ぎるとASPはあなたの資金を取ることを選択するかもしれません。この相互作用は外部委託することはできません：一方で、Lightningは望楼Arkコイン所有者は、オンラインになっていなくても、カウンターパーティがあなたをだまし取ろうとするのを防止するために、自分自身の秘密鍵を使用して信頼を必要とせずに資金を更新する必要があります。Arkで可能な最も近いものは、ウォッチタワーを許可するトランザクションに署名して、有効期限までにチェーン上であなたの資金を一方的に引き出すことができることであり、著しいトランザクション手数料がかかります。
V-UTXOの所有者がオフラインになった場合、何が起こるか考えてみましょう。ラウンドの有効期限が切れると、ASPはさらなるラウンドのために流動性を回復するために資金を回収する必要があります。V-UTXOの所有者がオフラインになった場合、そのV-UTXOをオンチェーンに置くことは、V-UTXOツリーの複数のレベルで資金を回収する必要があるため、著しいトランザクションコストがかかります。ASPは新しいラウンドで未使用のV-UTXOを再作成することができます。しかし、これはV-UTXOの所有者の観点からは信頼性がなく、データを取得しない限り、それらのV-UTXOを使用することはできません。9ASPから。ASPは、未使用のV-UTXOを受託残高として単純に記録することもできます。または、資金を押収する方針を持つかもしれません！
個人的には、Arkのセルフカストディのコストを考えると、多くのユーザーは代わりに、資金を新しいラウンドにロールオーバーするポリシーを持つASPを選択し、各ラウンドの終わりに詐欺の可能性を受け入れるのではないかと思います。これは、ウォレットが資金を新しいラウンドに移動するのに間に合わない場合など、安全を保証するために資金を早めに積極的に移動するよりも安価です。
高度なアーク
充分に高度な契約で可能であると思われます。おそらく、一度に多くの有用なオペコードを追加するスクリプトの復活ソフトフォークを介して、これを行うことができるはずです。
同様に、Sufficiently Advanced™契約を介して、全体的なtxoutツリー構造をいくつかの種類のローリング引き出しスキームで置き換えることができ、潜在的にスペースの節約が可能です。この技術は他のスキームにも潜在的に有用ですので、後のセクションで詳しく説明します。
ラウンド終了時の親権の問題は、十分に高度な™コベナンツが問題を解決できるもう一つのケースです:コベナンツ、特にZKプルーフコベナントは、ASPに次のラウンドですべての未使用のV-UTXOを再作成させ、ラウンド終了時にカストディがそれらに戻るという問題を取り除くことができます。ユーザーが新しいラウンドでV-UTXOを使用するためにASPからのデータが必要になる可能性が高いため、これをトラストレスにすることはおそらく不可能ですが、ASPがオフラインユーザーに対する詐欺から金銭的な利益を得るのを防ぐことができます。
単方向引き出しでのオンチェーン手数料支払い
Lightningに似ていますが、オンチェーンの手数料支払いの経済性と手数料後のV-UTXOの実際の価値は、Arkの使用が一方的な引き出しまたはASPの利益を受けない詐欺によってL2の定義に適合するかどうかを決定します。 txoutツリーデザインパターンについては、後述します。
バリディティロールアップ
様々な形式のゼロ知識（ZK）証明技術を使用してチェーンのルールを強制するために一般的に提案される、サイドチェーンのような構造の大規模なクラス。ZK証明技術は、妥当性ロールアップ技術と他の形式のサイドチェーンとの重要な違いです：もしZK証明スキームが機能するなら、取引の妥当性は第三者を信頼するのではなく、数学によって保証されることができます。ZK証明の「ゼロ知識」の側面は、実際にはこのユースケースでは要件ではありません：証明が何を証明しているかに関する情報が「漏れて」いる場合でも、それは完全に問題ありません。ただし、このクラスの証明のほとんどの数学的なスキームがゼロ知識証明であるという偶然があります。
Bitcoinの観点からすると、有効性ロールアップスキームには契約が必要です。スキームのためにUTXOを作成できるようにするには、スキームのルールに従われた場合にのみ使用できるUTXOを作成する必要があります。これは必ずしも分散化されたプロセスではありません。多くの有効性ロールアップスキームは実際には完全に中央集権化されています。ロールアップの証明は、中央集権化されたトランザクションシーケンサーが特定のトランザクションシーケンスのルールに従ったことを証明しています。
どのような誓約かというと...ゼロ知識証明技術はまだ非常に新しい分野であり、進歩は頻繁に行われています。したがって、特定のZKプルーフスキームを直接検証するオペコードがビットコインに追加される可能性はほとんどありません。代わりに、特定のスキームでは、より一般的なオペコード、特にOP_CATを使用して、スクリプトを介してZKプルーフを検証することが一般的に受け入れられています。例えばStarkWareはキャンペーン中OP_CATが採用されるようになりました。
バリディティロールアップは、多くの低品質/高ハイプのプロジェクトがある非常に大きな潜在的なトピックであり、この設計クラスを可能にする可能性のあるオペコードを指摘することを超えて、さらに議論しません。
BitVM
ざっくり言えば、BitVMは、ライトニングチャネルを構築する方法であり、ライトニングチャネルのルールがゼロ知識証明によって強制されるようになっています。Bitcoin上で契約を実装する必要がなく、1つのUTXOあたりのユーザー制限を超えるスケーリングを実現することができないため、これ以上議論しません。
階層チャネル
階層チャネル10aims to make channel resizing fast and cheap: “Hierarchical channels do for channel capacity what the LN does for bitcoin”. However they still don’t fundamentally exceed the 1 UTXO-per-user limit. They also don’t require any changes to the Bitcoin protocol anyway. So we’re not going to discuss them further. Their proponents should simply implement them! They don’t need our permission.
コインプール
CoinPoolでは、複数のユーザーが1つのUTXOを共有し、異なるユーザー間で資金を送金し、一方的に出金することができます。CoinPoolのペーパー提案では、SIGHASH_ANYPREVOUT、特定のUTXOにのみ署名を適用できるSIGHASH_GROUP、マークルツリーからの特定のブランチの削除を検証するOP_MerkleSubの3つの新しいソフトフォーク機能が必要です。後者はOP_CATでも実現できます。
現時点では、CoinPoolの開発は停滞しているようで、仕様ウェブサイトへの最後のコミットは2年前になります。
Enigma Network
Enigma Networkをカバーするように頼まれましたが、提案が本当に何であるかについての文書化が不十分なようです。 Bitfinexのブログ投稿多くの主張を行います; そのMITのページは空です。このブログ記事では、具体的に何が起こっているのかが明確になっていないので、これ以上は説明しません。
メンプールに関する考慮事項
Bitcoin Coreの現在のメンプールポリシーは、L2システムにとって理想的ではありません。ここでは、彼らが直面する主な課題と潜在的な改善策について説明します。
トランザクションピニング
結局のところ、経済的な攻撃であるトランザクションピンニング攻撃は、誰かが意図的に（or unintentionally)は、マイニングされない競合するトランザクションの事前ブロードキャストにより、目的のトランザクションをマイニングすることを困難にします。これは経済的なエクスプロイトであり、真のトランザクションピンニングの状況では、マイナーがマイニングした場合に利益を得る望ましいトランザクションが存在するためです。競合するピン留めトランザクションは、妥当な時間内にマイニングされません。
ピン留めの最も単純な例は、完全RBFがない場合、トランザクションの置換がオフになるという事実から来ています。したがって、置換がオフになっている低料金率のトランザクションがあり、採掘されないが置換できない場合があります。実質的に、100％のハッシュパワーが完全RBFを有効にすることで、書いている時点では、Bitcoin Coreの次のリリースでデフォルトで完全RBFが有効になるはずです。11年間の努力!).
それにより、マルチパーティL2プロトコルに関連し、Bitcoin Coreで修正されていない唯一の残りのピン留め問題であるBIP-125ルール＃3のピン留めが残ります。参考のために、BIP-125ルール＃3は次のように述べています。
より高い絶対手数料を支払うために、代替トランザクションが必要です（not）
Just Fee Rate)は、置き換えられるすべてのトランザクションによって支払われる手数料の合計よりも高くなります。
このルールは、マルチパーティプロトコルに関連する出力を消費する大きな低手数料のピン留めトランザクションをブロードキャストすることで悪用することができます（または、トランザクションのグループ）。トランザクションの手数料率が低いため、タイムリーにマイニングされないかもしれません。しかし、トランザクションの合計手数料が高いため、別のトランザクションで置き換えることは経済的ではありません。
ルール＃3のピニングは比較的簡単に修正できますreplace-by-fee-rate、この修正はすべての状況で機能します。残念ながら、RBFRが近い将来にCoreに採用されるかどうかは不明です。TRUC/V3 トランザクション.
料金の支払い:RBF、CPFP、SIGHASH_ANYONECANPAY、アンカー、およびスポンサーシップ
手数料率は予測不可能なため、取引が事前に署名されている状況で確実かつ経済的に支払うことは困難です。手数料支払いのゴールドスタンダードは、RBFを使用し、最初の「ローボール」見積もりから始めて、マイニングされるまで必要に応じてトランザクションをより高い手数料バージョンに置き換えることです。たとえば、OpenTimestampsカレンダーソフトウェアは何年も前からRBFをこのように使用しており、LNDはv0.18の期限対応RBF.
RBFは、ほとんどすべてのブロックスペースの中で最も効率的なため、手数料支払いのゴールドスタンダードです11状況: 交換トランザクションには、最初の試行で正しい手数料が推測されていた場合に必要とされた追加の入力や出力は必要ありません。
効率は重要です、なぜなら手数料支払いの非効率性は重要だからです帯域外料金の支払い大規模な鉱山労働者にとって収益性の高い収入源。小規模で分散化されたマイナーは、取引を確認するために小規模なマイナーに支払うことの非実用性と無意味さのために、帯域外の手数料支払いから利益を得ることができません。現在、実際に利用可能な帯域外手数料支払いシステムのほとんどは、手数料の支払いを行うために何らかのAML/KYCプロセスを必要とします。mempool.spaceアクセラレーター執筆時点(2024年8月)では、アカウントなしでLightningを受け入れます。
事前に署名されたトランザクションの状況でRBFを直接利用するためには、潜在的な手数料の全範囲をカバーするために事前に署名された手数料バリアントが必要です。多くの場合、必要なバリアントの数は比較的少ないため、これはかなり実現可能です。12これまでのところ、本番環境のLightningプロトコル(およびその他の提案されているプロトコル)は、代わりに子が親に支払う(CPFP)、通常はアンカー出力を介して。
アンカーアウトプットのアイデアは、最小またはゼロの価値を持つ1つ以上のアウトプットをトランザクションに追加し、そのアウトプットを二次トランザクションで支払い手数料（CPFP）として使用する意図であります。これは、LNのようなオンチェーントランザクションが小さいプロトコルに適用される場合に非常に効率が悪いです。エフェメラルアンカーアウトプットを使用したLNコミットメントトランザクションの合計サイズを2倍にする.コベナンツを実装するためにOP_CATを使用するものなど、より大きなトランザクションを利用するプロトコルを適用する場合、それはそれほど問題ではありません。
アンカーアウトプットのあまり目立たない問題は、手数料を支払うために追加のUTXOを手元に置いておく必要があることです。典型的な「クライアント」アプリケーションでは、アンカー出力がなければ、複数のUTXOを維持する必要がまったくないことが多いため、これは全体的な大きな負担になる可能性があります。実際、既存の消費者向けLightningウォレットの中には、手数料を支払うことができないため、高手数料環境でチャネルのリモート側による盗難に対して脆弱なものがある可能性があります。
SIGHASH_ANYONECANPAYは、署名済みトランザクションに追加のインプットを許可することで、一部のケースで手数料支払いに使用することができます； SIGHASH_SINGLEはアウトプットも追加できるようにします。ライトニングはHTLCトランザクションにこれを使用しています。現時点では、この方法は慎重に処理されないとトランザクションのピン留めの脆弱性にさらされる可能性があります13攻撃者は、トランザクションに大量の入力と/または出力を追加して高手数料/低手数料率ピンを作成できるため、RBFRはこの問題を修正します。TRUC/V3トランザクションで使用されるアプローチでは、この問題を修正することができません。このスタイルの手数料支払いは、RBFほど効率的ではありませんが、アンカーアウトプットよりも効率的であることがあります。
最終的には、ソフトフォークを追加するためのさまざまな提案がありました。手数料スポンサーシップビットコインプロトコルへのシステム。これにより、取引は他の取引に依存関係を宣言でき、スポンサー取引は、おそらく同じブロックで採掘された場合にのみ採掘できるようになります。これは、スポンサー取引が取引のインプットのサイズよりもはるかに少ないvバイトを使用してその依存関係を宣言できるため、従来のCPFPよりもはるかに効率的である可能性があります。
交換用サイクリング
置換サイクリング攻撃14取引の置き換えを利用して、望ましくないトランザクションを採掘するために、望ましいL2トランザクションを置き換えようとする。基本的に、攻撃者にとって、置換サイクル攻撃はトランザクションピン技術の代わりとなり、望ましい誠実なトランザクションが採掘されることを防ぎ、代わりに望ましくない不誠実なトランザクションが採掘されることを目指します。トランザクションピン攻撃とは異なり、置換サイクル攻撃は偶然には起こりません。
標準的な例は、Hashed-Time-Locked-Contract(HTLC)に対するものです。HTLCは、プリイメージの公開またはタイムアウトを介してトランザクションを使用できるようにするコントラクトと考えるのは簡単です。実際には、ビットコインスクリプトの制限により、HTLCでは、常にプリイメージを表示することでトランザクションを使用し、タイムアウト後にさらにタイムアウトメカニズムを介してトランザクションを使用できます。
この置換サイクルは、タイムアウト後の画像を使用して、被害者が画像を学習しないように、HLTCの出力を償還しようとするトランザクションを置き換えるために利用します。成功した置換サイクル攻撃は、異なるチャネルのHTLCのタイムアウトが長いことを行います。
置き換えサイクルを収益化する上での主な課題は、各置き換えラウンドにコストがかかることです。締め切りを意識したLightning実装は、次に期限切れになるHTLC出力の期限が切れる前に期限切れになったHTLC出力を支払うためにますます高い手数料を費やします。第二に、置き換えトランザクションを再ブロードキャストするだけで攻撃を防ぐことができます。15交換サイクルが終了したら。
トランザクションピニングと同様に、置換サイクルもマイナーにとって経済的な搾取である。置換サイクルの終わりには、メンプールから削除されたが完全に有効であり、マイナーがまだメンプールに保持していれば採掘できるトランザクションが存在する。
機能パターンとソフトフォーク
さて、さまざまな契約に依存するL2システムとメンプールの課題の概要をご説明しましたので、これらのL2システムが共有する注目すべきソフトフォークの特徴（主に新しいオペコード）とデザインパターンについてまとめてみます。ソフトフォークの提案については、提案ごとの技術的なリスクと課題についても議論します。提案ごとのデプロイのリスクと課題についても議論します。
OP_Expire
まず、これを片付けましょう。 OP_Expireが提案されました16根本的な問題を解決することで、置換サイクル攻撃を排除する簡単な方法として、HTLCは一度に2つの異なる方法で使用できるという事実です。L2システムのコンテキストでは、これはHTLCのようなメカニズムを使用するもの、およびおそらく他のユースケースに関連しています。OP_Expire、ある時点を過ぎるとトランザクション出力が使用できなくなることを可能にし、HTLCの支出条件を「プログラマーOR」ではなく、真の排他的ORにすることができます。
実際のOP_Expireソフトフォークは、おそらく2つの機能から構成されることが多いでしょう。これは、類似している方法で行われます。OP_CheckLockTimeVerifyとOP_CheckSequenceVerifyオペコードは2つのパートに分かれています。
- トランザクションの有効期限高さフィールド、おそらくはタップルートの付録で実装されることが最もあります。
- 所望の高さに最低限設定されていることをチェックするOP_Expireオペコード。
OP_Expire自体はほとんど契約としては資格がありませんが、多くの契約依存型L2システムにとって有用であるようです。ただし、代替サイクルは利他的な再送信によっても緩和される可能性があるため、十分に有用でないかもしれません15
OP_Expireのデプロイと使用に関する非常に注目すべき課題は、Satoshiをはじめとするビットコイン技術コミュニティの再編成です17、はBitcoinのコンセンサスプロトコルが、深い再編成の後でも以前に採掘されたトランザクションを新しいブロックに採掘できるように設計されていることを確認しました。この設計原則は、コンセンサスの失敗が大規模な再編成につながった場合、大量の確認済みのコインが永久に無効になる悪夢のシナリオを避けることを試みています。その結果、それらのコインに依存している人々はお金を失います。
大規模な再編成の場合、有効期限を使用するトランザクションは、有効期限の高さに達するため、マイニング不能になる可能性があります。OP_Expire提案では、有効期限を使用するトランザクションのアウトプットをコインベーストランザクションと同様に扱い、~100ブロックの間使用できないようにすることで、この問題をmitiGateすることを提案しています。
トランザクションの有効期限を導入する際の大きな障壁は、このトレードオフが許容できるかどうか、あるいは必要かどうかについてコンセンサスを得ることです。OP_Expireが役立つトランザクションの種類には、ユーザーの資金が凍結される長いタイムアウトがすでに含まれています。これらのタイムアウトにさらに時間を追加することは望ましくありません。また、二重支払いは、再編成後にコインを無効にする別の方法であり、RBFの使用が増加し、キーレスアンカー出力の使用が提案されている中、トランザクションの有効期限は大きな違いを生むのでしょうか?
SIGHASH_ANYPREVOUT
BIP-1182つの新しい署名ハッシュモードを提案しますが、いずれも特定のUTXOが支払われることを確約しません。SIGHASH_ANYPREVOUTは、代わりにscriptPubKeyに確約します（基本的に）。一方、SIGHASH_ANYPREVOUTANYSCRIPTは、任意のスクリプトを許可します。前述のように、これはLN-Symmetryによって、個々の前のチャネル状態に個別に署名する必要があるかもしれない必要性を回避するために提案されました。
SIGHASH_ANYPREVOUTは、特定のtxidに依存しなくなったという事実が、事前に署名されたRBF手数料率のバリアントと事前に署名された取引を併用したい場合にも潜在的に役立つことがあります。手数料率変数の組み合わせ爆発ただし、現在のBIP-118提案ではこのユースケースに対応していない可能性があり、SIGHASH_ANYPREVOUTもUTXOの値にもコミットすることが提案されているため、互換性がないかもしれません。
SIGHASH_ANYPREVOUTに対する最初の反対意見は、ウォレットを不適切な方法で使用することでトラブルに巻き込まれるという考えでした。問題は、1 つの SIGHASH_ANYPREVOUT 署名が公開されると、指定されたスクリプトで任意の txout を使用するために使用できることです。したがって、同じスクリプトで2番目の出力が誤って作成された場合、SIGHASH_ANYPREVOUT、それらのコインを盗むための些細なリプレイ攻撃が可能になります。しかし、ウォレットやL2の実装には他にも多くのフットガンがあるため、この懸念は解消されたようです。
現在、一般の技術コミュニティはBIP-118の実装についてかなり前向きな意見を持っています。しかし、LN-Symmetryの議論で上述したように、その主な使用ケースであるLN-Symmetryが実際には良いアイデアなのかについては議論があります。
OP_CheckTemplateVerify
最初の契約固有のオペコード提案であるOP_CheckTemplateVerify（通常CTVと呼ばれる）は、指定された方法で支出トランザクションをハッシュし、入力UTXOにコミットしないようにする非常に具体的で制限された契約オペコードを作成することを目的としています。その結果のダイジェストをトップスタック要素と照合することで、支出トランザクションを事前に制約することができます。これにより、真の再帰的な契約制限を可能にすることなく、支出トランザクションを制約することができます。
なぜCTVでは再帰的契約は不可能なのですか？ハッシュ関数のためです：CTVは支出トランザクションをテンプレートハッシュと照合し、方法がありません18自身のハッシュを持つCTVを含むテンプレートを作成する
とはいえ、これは必ずしも本当の制限ではなく、最新のコンピュータでは、CTVテンプレートハッシュのチェーンをわずか数秒で数千万トランザクションの深さまで簡単にハッシュ化することができます。で相対的なnSequenceタイムロックそして、制限されたブロックサイズは実際にそのようなチェーンの終わりに到達することができ、数千年にわたって簡単に作成されることができました。
現在のCTV提案はBIP-119は、DefaultCheckTemplateVerifyHashとして知られる単一のハッシュモードしか持っていません。これは、テンプレートハッシュ内の支出トランザクションのすべての側面にコミットするものです。実際的な観点からは、これは多くの場合、手数料支払いのための唯一の利用可能なメカニズムがCPFPであることを意味します。上記で述べたように、これはCTVを使用するトランザクションが小さな場合には、帯域外の手数料支払いが非常にコスト削減となるため、潜在的な問題です。
CTVは、その相対的な単純さと幅広いユースケースのため、技術コミュニティの間で最も広範なサポートを持つコヴナントオプコード提案と言えるでしょう。
LNHANCE(エヌハンス)
CTVを実装するための提案の1つは、それをOP_CheckSigFromStack（Verify）とOP_InternalKeyの2つの追加のオペコードと組み合わせることです。問題は、現時点では、そのプルリクエストと関連するBIPのドキュメントがこの提案に賛成か反対かを議論するには十分ではないことです。これらのBIPには、実際の世界の例でオペコードが実際に何を行うことが期待されているかについての合理的な説明がまったくありませんし、さらには詳細な例のスクリプトもありません。
著者たちはおそらく彼らの提案に良い理由があるのでしょうが、その理由を実際に説明し、適切に正当化する責任があります。したがって、これ以上議論はしません。
OP_TXHASH
CTVに類似したこの提案は、支出トランザクションからデータをハッシュ化することで、再帰的な契約機能を実現します。CTVとは異なり、TXHASH提案は「フィールドセレクター」メカニズムを提供し、支出トランザクションがどのように制約されるかについて柔軟性を持たせます。この柔軟性により、2つの主な目標が達成されます:
- マルチTXプロトコルを壊すことなく、トランザクションに手数料を追加することを可能にすること。
- ユーザーが自分の入力と出力のみを制限するマルチユーザープロトコル。
OP_TXHASHの主な問題は、フィールドセレクタメカニズムがかなりの複雑さを加え、CTV提案と比較して、レビューやテストが非常に困難になることです。現時点では、フィールドセレクタメカニズムが実際にどれだけ有益であるか、また具体的にどのように使用されるかについて十分な設計分析が行われていません。したがって、これ以上は議論しません。
OP_CAT
スタックのトップ2つの要素を連結し、連結された結果をスタックにプッシュする連結演算子。元々、ビットコインにはOP_CATが有効になって出荷されていましたが、サトシ 2010年に静かに削除されました, probably due to the fact that the initial implementation was vulnerable to DoS attacks due to the lack of restrictions on the size of the resulting script element. Consider the following script:
DUP CAT DUP CAT…
要素のサイズ制限がない場合、各DUP CATイテレーションはトップスタック要素のサイズを2倍にし、最終的には利用可能なメモリをすべて使用します。
連結は、次のようにして再帰契約を含む多くの種類の契約を実装するために十分です。
- OP_CAT（および必要な契約固有のロジック）を1回以上呼び出して、ウィットネスデータなしでスタックに部分トランザクションを組み立てます。
- スタック上のトランザクションが支出トランザクションと一致していることを検証します。
実際には、Schnorr署名の数学を濫用する、慎重に構築された署名を使用して、OP_CheckSigを介して第2ステップを実行することができます。ただし、おそらくOP_CATソフトフォークがOP_CheckSigFromStackと組み合わされ、スタック上の署名がトランザクションの有効な署名であることを検証することによって、第2ステップを実行します。19その後、同じ署名を使用して、支出トランザクションが一致していることをOP_CheckSigで検証します。20
証人データなしでトランザクションを組み立てる必要があるという事実は重要です: 契約はトランザクションが行うこと、つまりその入力と出力を検証するだけで十分であり、実際にそれを有効にする証人データは（あれば）検証する必要はありません。
モジュロスクリプトサイズの制限を除いて、OP_CATとOP_CheckSigFromStackの組み合わせは、再帰的契約を含む多くの種類の契約を構築するために十分です。CTVのような効率的な解決策と比較して、それはより高価です。しかし、コストの違いはあなたが期待するよりも少ないです！
大まかに言えば、これを行うためにOP_CATを使用するには、支出トランザクションの非ウィットネス部分すべてを証人を介してスタックに配置する必要があります。TXOUTツリーなどの典型的なCTVユースケースでは、支出トランザクションにはウィットネスデータがまったくありません。証人スペースが75％割引されるため、子トランザクションの実効トランザクション手数料が25％増加します。悪くないですね！
OP_CATは強すぎるのか？
これはおそらくOP_CATの展開にとって最大の政治的および技術的な障害であり、OP_CATによって可能になるユースケースを予測するのは非常に難しいです。そして一旦「猫」が袋から出てしまうと、それを元に戻すのは非常に難しいです。
OP_CATは、合理的に効率的で安全であると主張されているため、素晴らしい例です。BitcoinスクリプトにSTARK検証を実装する.STARKは非常に一般的なステートメントを証明できるため、STARKを効率的に実装できるようにすると、ビットコインの上にさまざまなシステムを構築できるため、L2システムの範囲を超えた大きな影響があります。OP_CATに対する強力な反論は、これらのユースケースがビットコインユーザーにとって全体的に良いとは限らない可能性があるということです。
有害な中央集権的なマイナー抽出可能な価値の生成は、重要な潜在的な問題です。「MEV that is evIL」と呼ばれるもの（MEVil）Matt Corallo氏によると、MEVilとは、大規模なマイナー/プールが、単に総手数料を最大化するだけでなく、小規模なマイナー/プールが採用するのが不可能な高度なトランザクションマイニング戦略を用いて追加価値を抽出できる状況のことです。OP_CATで作成できる潜在的な金融商品の複雑さから、MEVilを排除することは非常に困難です。トークンオークションプロトコルからBitcoinで既に重要なMEVilが現れていますが、幸いにもその特定のケースは完全RBFの採用によって撃退されました。
MEVilの可能性に加えて、潜在的に有害な具体的なOP_CATユースケースは他にもたくさんあります。たとえば、Drivechainsの提案はここでレビューされました, そしてビットコインにとって有害であると広く考えられています。可能だと信じられているOP_CATを使用してDrivechainを実装する。もう一つの例として、Taproot Assetsのようなトークン提案が挙げられます。一般的には、それらが実装されるのを防ぐことは不可能ですが、クライアントサイドの検証、これらをOP_CATを使用して実装する提案があり、これによりエンドユーザーにとってはより魅力的な方法で実装できる可能性がありますが、それによりはるかに多くのブロックスペースが使用されるため、「正当な」ビットコイン取引を潰す可能性があります。 これらのユースケースは、金融詐欺に使用されるトークンプロトコルが頻繁に使用されるため、法的問題も引き起こす可能性があります。
インクリメンタルハッシング
コベナンツの場合、OP_CATは主にデータを連結し、ハッシュ化するために使用されます。これと同じ目標を達成する別の方法は、ある種のSHA256中間状態を受け取り、それにより多くのデータをハッシュする、ある種のインクリメンタルハッシュオペコードを使用することです。SHA256 自体は 64 バイトのブロックで動作します。インクリメンタル ハッシュ オペコードには多くの設計があります。
重要な設計の決定事項の1つは、スタック上で実際の中間状態バイトをいくつかの正規形式で公開するか、直接操作できない新しい不透明なスタック項目タイプで表現するかどうかです。SHA256は特定の固定の初期化ベクトルに対して指定されており、任意の中間状態/初期化ベクトルが許容される場合、SHA256の暗号特性が成り立つかどうかは不明です。
もちろん、増分ハッシングはOP_CATができることのほとんどを効率的に行うことができるため、OP_CATに関するすべての懸念を共有しています。
スクリプト復興
OP_CATはSatoshiが無効にした15のオペコードの1つでした。OP_CATを復元するだけでなく、Rusty Russellは提案しています。21ほとんどのオペコードを再度有効にし、DoS制限を追加し、同じソフトフォークでいくつかのオペコードを追加することにより、「サトシのオリジナルビジョン」にBitcoinのスクリプトを本質的に復元することを目的としています。特に、OP_CheckSigFromStackが可能性が高いです。
OP_CATだけでも（再帰的な）契約を可能にしますが、完全な「スクリプトの復活」がより洗練された契約を可能にし、支出トランザクションの一部を直接操作することをはるかに簡単に実装します。例えば、トランザクション内のtxoutの合計値が特定の条件を満たすことを保証するために算術演算コードを使用する契約スクリプトを想像することができます。
再び、スクリプトの復活は、OP_CATだけではなく、過度に強力であることに関するすべての同様の懸念とその他の懸念を引き起こします。
シンプリシティー
Script Revivalと同様に、SimplicityはL2と契約に関連しており、何でも可能にすることができます。 Script Revivalとは異なり、Simplicityソフトフォークは、コンビネータとして知られる9つのプリミティブオペレータに基づいたBitcoinのスクリプトシステムに完全に新しいプログラミング言語を追加します。
実際には、シンプルさは単純すぎると同時に、まったく単純ではありません。原始的なコンビネータは途方もなく低レベルなので、加算などの基本的な操作は苦労してゼロから実装する必要があります。生の Simplicity は、実際には非常に冗長です。したがって、Simplicityの実際の使用法は、ライブラリ関数呼び出しに似たコード置換のシステムを利用します。ジェット機.これは実際的/政治的な問題を提起します:どのジェット機を実装するかをどのように決定しますか?ほとんどの場合、ジェットは他のオペコードと同様に C++ で実装され、新しいジェットごとにソフトフォークが必要になります。
OP_FancyTreeManipulationStuff
比較的特殊化された多様なオペコードが提案されており、契約に依存するL2提案のために効率的な空間でツリー操作を行うための。たとえば、Coinpoolsは両方を提案していますTAPLEAF_UPDATE_VERIFYそしてOP_MERKLESUBCoinpools提案に必要な方法で、両方の提案はタプルートツリーを操作します。マット提案は、基本的には、Merkleツリーに関する文を検証するOP_CheckContractVerifyオペコードを提案しています。
この記事では、これらの多くの提案のそれぞれについて詳細に説明する必要はありません。むしろ、それらをグループとして話すことができます:それらはすべて、理想的には意図しない副作用なしに、L2の1つのクラスを可能にする比較的ユースケース固有の提案です。これらはすべて、OP_CAT操作などのより一般的なオペコードで同じ目標を達成するよりも少ないブロックスペースを使用するという効率の利点があります。しかし、これらはすべて、潜在的にニッチなユースケースのために、スクリプトシステムに複雑さを加えるという欠点があります。
BitcoinがSimplicityスクリプティングシステムを採用した場合、同じような動きが起こります。Simplicityにおけるオペコードに相当するものは、よく使われるパターンに対してジェットを追加することです。再び、木の操作のようなユースケース固有の操作に対するジェットの実装は、ユースケース固有の操作に対する複雑なオペコードの実装と同様の利点と欠点があります。
ファンドプール
単一のUTXOを複数のユーザーで共有しようとするすべてのL2システムは、何らかのマルチユーザーファンドプールと見なすことができます。ユーザーは引き出しの権利を持っています。潜在的には、プールに資金を追加するメカニズムも存在するでしょう（資金を事前に割り当てた状態でプールを作成する以外に）。
ファンドプールが有用であるためには、それに関連する「共有データ状態」を持つ必要があります。つまり、txoutの値がどのように分割されるかです。ファンドプールが時間とともに進化する場合、その状態はファンドがプールから追加または削除されるたびに変更する必要があります。 Bitcoin上に構築しているため、プールから資金を追加または削除する場合は、プールが制御するUTXOを消費する必要があります。
ビットコインのコンセンサスシステム自体は状態変更の検証に基づいています: トランザクションは、その証人によって、UTXOセットの状態への変更が有効であることを証明します。Proof-of-workによって、どのセットのトランザクションが正しいかについての合意に至ります。これは、資金プール自体も状態変更の検証に基づいていることを意味します: 我々は、すべてのビットコインノードに、資金プールのルールが状態変更ごとに遵守されていることを証明しています。
だが、信頼できるL2ファンドプールのもう一つの重要な側面があります。つまり、ファンドプールの状態が変化すると、システムは、ファンドプールに参加するユーザーが自分の資金を回収するために十分なデータを公開する必要があります。もし我々がそれを行わなかった場合、システムは第三者の協力なしに一方的な引き出しを提供することができず、失敗します。多くのロールアップベースのスキームはここで失敗します。データの可用性の問題に苦しんでおり、第三者のコーディネーターがオフラインになった場合、ユーザーは有効なファンド回復トランザクションを構築するために必要なデータを入手する方法がないため、自分の資金を回収できません。
これらの制約を念頭に置いて、ファンドプールはどのようなデータ構造に基づいているのでしょうか?必然的に、それらはすべてある種の木です。具体的には、ある種のマークルツリーです。なぜなら、それがコンピュータサイエンスにおける唯一のスケーラブルなデータ構造だからです。なぜなら、それが基本的にツリーの状態に暗号的にコミットする唯一の合理的な方法だからです。最後に、ツリーの更新は必然的にビットコインブロックチェーンに公開されます出版媒体すべてのL2ユーザーが共有し、コインを移動するためにユーザーに公開することを強制できる唯一の方法です。そして、どの契約の実装にも、契約のルールが守られていることを検証するためにツリーの一部が必要になるためです。
では、高レベルの理論を押しのけて、これは実際にビットコインのスクリプトとトランザクションにどのように変換されるのでしょうか？
個別の事前署名トランザクション
木の退化した状態で、正確に1つの葉が含まれています。ここでは、資金プールの状態がおおよそ一度変化します。例えば、標準的なライトニングチャネルはこのカテゴリに該当し、開かれると閉じることしかできません。チャネルが閉じられる際に公開されるデータは、トランザクションそのものであり、チャネルの相手方はブロックチェーンデータからtxidを学び、それを使って自分の資金を回収するための十分な情報です。
ここで必要なのは最も基本的な契約である「事前署名済みトランザクション」のみです。
Txout Trees
ファンドプールで見られる次のより複雑なデザインパターンは、txoutツリーです。Arkは注目すべき例です。ここでは、予め定義されたトランザクションのツリーで、ルートのUTXOを使用してファンドプールを分割することができます。事前に署名されたトランザクションやCTVなどのシンプルな契約によって強制され、そのUTXOの価値を小さな金額に分割し、最終的には正当な所有者によって使用可能な葉ノードまで分割されます。
txoutツリーの目的は、ユーザーが自分の資金を回収する方法を選択できるようにすることであることを認識することが重要です。そして、これらのオプションにはコストがかかります。txoutツリーは、単一のトランザクションでUTXOを分割するよりも、資金プールを分割して所有者に返すためのより高価な方法になります。ツリー内の各層は、その層を作成するために必要なtxoutsおよびtxinsで使用されるバイト数のため、コストがかかります。
では、txoutツリーがどのようなオプションを提供する可能性がありますか？Arkは再び素晴らしい例です：単一のV-UTXOのチェーン上での償還にすべてのV-UTXOをチェーン上に配置する必要はありません。ツリーを使用することで、償還は代わりにツリーをより小さな部分に分割して、望ましいV-UTXOがチェーン上に配置されるまでになります。
個々の署名済み取引のケースと同様に、公開される情報は取引そのものであり、必要に応じて他のユーザーのウォレットに資金の使い道を通知します。
txoutツリーのスケーラビリティには興味深い規模の経済があります。 n個のV-UTXOがあるファンドプールに最初のV-UTXOをチェーンに配置するコストは、単一トランザクションよりもおよそlog2(n)log2(n)倍高価です。なぜならlog2(n)レベルの分割トランザクションをチェーンに配置する必要があるからです。ただし、最初のV-UTXOをチェーンに配置した後は、他の人が中間トランザクションの採掘コストを支払ったため、その後のV-UTXOはチェーン上での償還が安くなります。
二分木の要素数が全体であることを思い出してください。
n枚の葉は2nです。これは、すべてのV-UTXOをチェーン上に配置するために、txoutツリーを介して行うための合計コストが、単一の取引で行うための合計コストの小さな倍数であることを意味します。驚くほど効率的です！
もしくは、そうでないかもしれません...基金プールの全体サイズの償還が十分に大きい場合、それらは総合的なブロックスペースに対する非自明な需要を表す可能性があります。ブロックスペースは供給と需要のシステムですので、ある時点で需要が高いため手数料が上昇することになります。極端な場合、実際にはすべてのトランザクションアウトプットツリーが非常に大きく、深いために償還することが可能です
ツリー内のV-UTXOは不可能です。
txoutツリーに関するオープンな問題は、誰が手数料を支払い、どのように支払うかですか？明らかな解決策の1つは、リーフトランザクションのキーレスアンカーアウトプットを使用し、リーフトランザクションをマイニングしたい人が手数料をCPFP経由で支払うことを許可することです。一部のユースケースでは、V-UTXO自体はCSVの遅延なしに直ちに支出することができるため、V-UTXO自体がCPFP経由で手数料を追加するために支出される可能性があります。
RBFは許可によって実装が複雑です：RBFの手数料を取る明らかな場所は、V-UTXOの値からです。しかし、どのようにして所有者だけがより高い手数料のトランザクションに署名する能力を持つことを保証しますか？多くの場合、これをキーレスアンカーアウトプットよりも効率的な方法で行う方法は明確ではありません。ただし、V-UTXO自体が直ちに使われない場合、エンドユーザーウォレットが使用するスキームに対して重大な課題を提起する可能性があります。これにより、CPFPを実行するために使うUTXOがない場合。
最後に、手数料支払いを考慮に入れたtxoutツリーシステムにおけるインセンティブについて慎重な考慮が必要です。例えば、Arkのようなシステムでは、個々のV-UTXOがオンチェーンのV-UTXOに引き換える価値があるほど高価である場合、協力しないコーディネーターはこれらのV-UTXOをオフチェーンで償還することを拒否し、タイムアウトが発生すると、これらのV-UTXOの価値を一度に盗むことで利益を得ることができます。
もしそうだとすれば、このようなシステムは、小型のV-UTXOのL2であるという我々の基準を満たさないことになるでしょう。
バランスベースのスキーム
トランザクションアウトツリーの状態機械はまだ比較的単純です。ファンドプールが存在するか、それが使用されて、2つ以上の小さなファンドプールが作成されます。より高度な契約では、ファンドプールを進化するバランスとして扱うこともでき、そのバランスから資金を追加したり減らしたりすることができます。
これを行うには、非自明なステートマシンを実装する必要があります。しかし、本質的に共有データベースが必要です。なぜなら、ここでの目標は、1つのUTXOを多くの所有者で共有することです。最後に、実際にスケーラビリティの改善を得るためには、その所有権データをチェーンにできるだけ少なくする方法で行わなければなりません。
これらの要件は、メルケルサムツリーなどのツリー状のメルケル化されたデータ構造のようなものに私たちを不可避的に導きます。そのデータ構造を操作することは、OP_CATのような何らかのゼロ知識証明検証オペコード、または特定の目的のためのツリー操作オペコードが必要になる可能性があります。
興味深いことに、txoutツリーと同様のセキュリティ特性を維持しながら、log(n)のスケーリングよりも優れたものはありません。なぜでしょうか？仮に、ある仮想的なOP_ZKPが存在し、ある高度な数学を通じて任意の文を証明するためにわずか32バイトしか必要としないとします。このzk-proofは、レイヤー2システムのルールに従ってマークル化されたデータ構造が操作されたことを証明できるかもしれませんが、次のユーザーが状態変更を行うために必要なデータを提供することはできません。これは、無条件の引き出しを可能にするという私たちの基準を満たしていません：最大で1人のユーザーが無条件の引き出しを達成できるかもしれませんが、他のユーザーはできません。
それに対して、マークル化されたデータ構造の修正された部分が契約スクリプトシグを介して公開される場合、例えば、マークルツリー内の兄弟ダイジェストの場合、次のユーザーはシステムの状態の理解を更新するために十分なデータを持ち、自分自身で無条件の引き出しを行うことができます。
この問題を回避する可能な方法は、契約がビットコインチェーンとは異なる出版媒体における公表の証拠を要求する場合です。ただし、セキュリティの保証はビットコインを介した場合よりも弱くなります。
最後に、txoutツリーとバランスベースのアプローチを組み合わせる方法について注意してください。操作されるデータ構造がtxoutツリーである場合、出力を使って新しい資金を追加することでtxoutツリーに資金を追加することができます。ただし、追加された資金が実際にtxoutツリーに追加されたことを検証する契約スクリプトが必要です。同様に、資金は通常のtxoutツリーに利用可能なすべてのメカニズムによって削除することもできます。Advanced Arkはこの種のスキームの例です。
失敗データ比率
L2は、敵対的な状況で相互作用の要件を追加することでスケーリングを実現します。ほとんどの場合、これはプロトコル内の正直な参加者がトランザクションをマイニングするための締め切りを持っていることを意味します。締め切りに間に合わない場合、資金が盗まれる可能性があります。
すべての分散（および集中）型ブロックチェーンの最大ブロック容量は技術的な制約によって制限されています。ビットコインでは、ブロックサイズの最大値は、ビットコインが基本的に時間のほぼ100％で容量制限に達していることを意味します。ビットコインマイニングはオークションシステムとして機能し、ブロックスペースを最も高く入札する人にオークションで提供します。したがって、実際には需要が増減するにつれてトランザクションがマイニングされるための最低料金率が上下します。
手数料率は、常にL2の経済性と故障モードを考慮に入れます。たとえば、Lightningでは、オンチェーンで利益を上げるには小さすぎる「ダストサイズ」のHTLCは、大規模なHTLCとは異なるセキュリティモデルを使用します。Lightningプロトコルはまだこれを適切に実装していませんが、理論的には、このしきい値は、上下する手数料率に基づいて動的であるべきであり、理想的には、手数料率に基づいて特定のコミットメントトランザクションにHTLCが存在するかどうかを当事者が選択できるところまでです。
Lightningでは、洪水や略奪など、この状況を意図的に引き起こすさまざまな攻撃が提案されています22マスエキシット攻撃23. ビットコインブロックチェーンの容量はすべてのユースケースで共有されているため、異なるL2システム間での攻撃も可能です。たとえば、Arkでの大規模な退出を誘発して、ライトニングチャネルから利益を得ることができます。
複数のユーザー間でUTXOを共有するL2は、障害発生時の最悪の場合のブロックスペースの需要が比例して高くなるため、本質的にこれらの問題を悪化させる可能性があります。この記事を書いている時点では、Lightning で多数のチャネルを一度に閉じなければならないような大規模な障害は実際に見たことがありません。UTXO共有スキームでさらに限界を押し広げる前に、Lightningとそのユーザーあたり約1UTXOのスケーリングで追加の運用経験を積む必要があるという正当な議論があります。
第二に、新しいUTXO共有スキームが広く採用される前に、ブロックスペースの需要が高い場合の攻撃の潜在的な収益性について慎重な調査を行う必要があります。例えば、Arkのように、ASPが他の当事者よりもはるかに少ないブロックスペースで資金を償還できるシステムでは、意図的に高い手数料率をトリガーし、一方的に利益が出ることができない資金を差し押さえることは、収益性の高い詐欺であり、真のL2システムの両方の条件に違反している可能性があります。
コンセンサスのクリーンアップ
初期のBitcoinプロトコルには、特に、スクリプトDoS攻撃、タイムワープ攻撃、マークルツリーの問題など、Satoshiが間違えたことがいくつかあります。以前にも、時間ベースのnLockTimeの評価に切り替えるなど、ソフトフォークで他のコンセンサスバグが修正されています（重複txidの問題を修正しようとしているなど）。
最新のソフトフォークであるタップルートは、相当な時間をかけて展開されるという比較的議論のあるプロセスを経ています。新しいタイプのL2に対して新しいオペコードやその他の機能を有効にする前に、コンセンサスクリーンアップソフトフォークを先に行うことの理由は、比較的議論のないソフトフォークを実装する意欲の広がりをより詳しく知ることができるということです。これはおそらく誰にとっても利益のあるものだと言えます。
ソフトフォークに依存するレイヤー2のテスト
開発者は、実際にソフトフォークが起こるのを待つ必要はありません。Arkの開発者が使用している特に洗練されたアプローチの1つは、アイデアをテストするためのものです。契約なしのArkは、予め署名されたトランザクションを使用して必要な契約をシミュレートするためのものです。これにより、実際のBTCを使用してアイデアをテストし、Arkが契約を使用して達成することが期待される同じ信頼性を持つメインネット上で行うことができます。そのトレードオフは、契約を持たないArkはすべての当事者がオンラインでトランザクションに署名する必要があるということです。clArkは実際のBTCと連携するため、インタラクティブなトレードオフを許容できる特定のユースケースのために製品として使用するのに十分役立つことが証明されるかもしれません。
より単純なアプローチは、単に特定の当事者が契約が防止するアクションを行えないというふりをすることです。たとえば、提案されたプロトコルがCTVを使用して、トランザクションツリーでtxoutツリーが使用されることを強制する場合、CTVの各使用はNOPまたはCheckSigで置き換えることができます。実際にはtxoutツリーは実際には強制されていませんが、ツリーと各当事者との相互作用するコードのすべてと、NOPとCheckSigが標準スクリプトで許可されているため、プロトコルは実際の資金を使用して本番ネットでテストできます。
ソフトフォークの可能性
今後の方針は何ですか？ ここでは、私たちが分析したすべての主要なL2スキームと、これらのL2スキームを成功させるために有用なソフトフォーク（U）または必須（R）であるものを示します。 上記で説明したように、OP_CAT（およびOP_CATを含むScript Revival）は、OP_ExpireおよびFee Sponsorshipを除いて、このリストの他のすべてのソフトフォークをエミュレートできるため、プロジェクトのニーズが他のソフトフォークによって直接効率的に満たされる場合、OP_CATを含めません。
また、提案されているマークルツリー操作オペコードもすべて除外します。これらはすべてニッチで、ユースケースに特化しすぎているため、現時点では採用される可能性が高くありません。これらのオペコードが有用である限り、OP_CATやスクリプトリバイバルを介してその効果を実装することは、採用への道がはるかに高いです。
ここではCTVが明らかに勝者であり、SIGHASH_ANYPREVOUTがそれに続きます(OP_Expireは代替のサイクリング修正であるため、多くのことに役立ちますが、必須ではありません)。CTVが勝つのは、「支出トランザクションがこのテンプレートと一致することを確認する」というデザインパターンに多くのことが当てはまるからです。OP_CAT工事でもCTVを効率的に活用できます。
OP_CATとは異なり、CTVは特定の場合においてアウトオブバンドの手数料支払いを奨励するという意図しない結果のリスクをほとんど引き起こすことはありません。これは理想的ではありませんが、広く支持される代替案は誰も提案していません。
私の個人的なおすすめは、コンセンサスクリーンアップのソフトフォークを行い、その後にCTVを行うことです。
免責事項：
この記事は[から転載されました。ピータートッド], オリジナルタイトル『イーサリアムのロードマップはオフトラックですか？』を転送します。すべての著作権は元の著者[petertodd]に帰属します。この転載に異議がある場合は、お問い合わせください。Gate Learn(ゲート・ラーン)チームが迅速に対応します。
免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
記事の翻訳は、Gate Learnチームによって他の言語に翻訳されます。特に記載がない限り、翻訳された記事の複製、配布、または盗作は禁止されています。
บทความที่เกี่ยวข้อง
暗号通貨における完全に希釈された評価（FDV）とは何ですか？
スマートマネーコンセプトとICTトレーディング
BlackRockのBUIDLトークン化ファンド実験の概要：構造、進捗、および課題
ソフトフォーク/契約依存のレイヤー2レビュー
オンチェーンウォレットは、トランザクションとトランザクションのほぼ1対1のマッピングを実現します。つまり、ユーザーが行う経済取引ごとに、おおよそ1つのブロックチェーントランザクションが必要です。集約、コインジョイン、カットスルーペイメントなどは、この文をやや変更しますが、大体正確です。
Lightningは、トランザクションをトランザクションに多対1のマッピングを実現しました：Lightningの魔法は、無限に近い数の経済取引が単一のLightningチャネルで発生できることです。それ自体が単一の未使用トランザクション出力（UTXO）に関連しています。基本的には、私たちは「時間」の次元であるトランザクションを取り、その次元を折りたたむことにより、大幅なスケーリングを実現しました。
ただし、ユーザーごとに1つのUTXOを作成することは、議論の余地があると言えます。したがって、自己主権的な方法で複数のユーザーが1つのUTXOを共有できるようにするための多くの提案があります。再び、スケーリングの「空間」次元、つまりユーザーを1つのUTXOにまとめることによって、さらなるスケーリングを実現するための多くの提案があります。
ここでの目標は、これらすべての提案の概要を行い、彼らが共有する技術的なパターン、どのような新しいオペコードやその他のソフトフォークのアップグレードが必要であるか、そしてすべての部分がどのように組み合わさるかの比較表を作成することです。 その過程で、L2プロトコルの実際の定義、ライトニングが既に可能なスケーリングの種類、およびこれらすべてを実現するためのメンプールに行う必要のある改善の理解も得ます。
お礼がありますFulgur Venturesこの研究のスポンサーとして。彼らはこの投稿の内容に編集上の制御を持っておらず、公開前にそれをレビューしていませんでした。
ありがとうございますダニエラ・ブロッゾーニ、Sarah Coxおよびその他の先行公開レビュー用のもの。
定義
レイヤー2とは何ですか？
「Layer 2」という用語はしばしば広義で定義されます。そのため、銀行のようなエンティティ（例：Liquid）もLayer 2と定義されることがあります。この記事では厳密な定義を採用します：Layer 2（L2）は、Bitcoinで表現されるシステムであり、他の当事者とのオンチェーントランザクションの数よりもBTCをより頻繁に取引できるようにすることを目的としています。具体的には以下のいずれかの方法で実現します。
- システム内のペナルティやコストを考慮に入れると、誰もがシステム内で収益を得ることはできません。評判の損失、法的な結果などのシステム外のコストやペナルティは、私たちの定義には含まれていません。
- (好ましい) 資金の真の所有者は、第三者の協力なしに手数料を差し引いて資金を一方的に引き出すことができます。
L2システムがオンチェーンで表現できないほど小さな価値の量や取引を表現できるようにするため、最初のオプションが必要です。例えば、Lightningでは、HTLCはオンチェーンで表現できないほど小さな価値を持つことがあります。その場合、HTLCの価値はコミットメントトランザクションの手数料に追加されます。Lightningノードは、ダストHTLCを正しいタイミングでチャネルを閉じることで「盗む」ことができますが、その場合、より高額になります。1HTLCの価値を下回る場合、盗難は利益にならないようです。
とは言っても、一方的な撤退は常に私たちの主要な設計目標です。2
この定義によれば、ライトニングのようなものはL2システムと見なされます。ただし、Liquid、Cashu、およびFedimintのようなシステムはL2ではありません。なぜなら、他の当事者があなたの資金を管理しているからです。RGBのようなクライアント側の検証スキームも、この定義によればL2ではありません。なぜなら、BTCそれ自体を信頼できないからです。最後に、@RubenSomsen"/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechainsはカットされることに失敗しました。なぜなら、Statechainエンティティがプロトコルに従わない場合、資金を盗むことができるからです。
Covenantsとは何ですか？
…そしてなぜよりスケーラブルなレイヤー2システムがそれらを必要とするのですか？
Bitcoinスクリプトでは、契約は、txoutの支出方法が事前に制限されるメカニズムであり、そのtxoutを支出するために使用されるトランザクションの形式が事前に定義されたり、純粋な署名に限定されない方法で制限されるようにするものです。複数の当事者間でUTXOを共有するL2システムは、L2プロトコルのルールとインセンティブを実装するためにUTXOの支出方法を制約する必要があるため、契約が必要です。
再帰契約
再帰契約とは、支出されるUTXOの制約ルールが無制限に支出トランザクションの子UTXOに再帰的に適用できる特性を持つ契約です。再帰契約には、長い間、一部の人々にとっては望ましくないと考えられてきましたなぜなら、彼らはコインに永久に拘束することができるからです。少なくとも、政府のような第三者の許可なしに永久に拘束することができます。
目標
ライトニングは現在の「ベストインクラス」のレイヤー2システムです。ただし、制限があります。具体的には：
- スケーリング-ライトニングは現在、エンドユーザーごとに少なくとも1つのUTXOが必要です。3
- 流動性 - Lightningは、資金をチャネルに拘束する必要があります。
- インタラクティビティ - Lightningは、支払いの受取人がオンラインである必要があります。これにより、信頼性のある受け取りが可能となります。
レイヤー2システムを評価する際、私たちの目標はこれらの主要な制限を改善することであり、できれば新しい制限を追加せずに行うことです。
Lightning のスケーリング制限
実践での「エンドユーザーごとの1つのUTXO」とはどういう意味ですか？ライトニングチャネルは無期限に稼働できるため、これを見る方法の1つは、1年間に新たに何本のチャネルを作成できるかを尋ねることです。4Taprootアウトプットを作成するには、43vBの余白コストがかかります。チャネルの作成が分散され、1つの取引で多数のチャネルを作成する場合、その他の取引オーバーヘッドは無視できるほど小さくなり、大量のチャネルを年間に開設して新規ユーザーをオンボードすることができます。たとえば、ブロックの90%が新しいTaproot Lightningチャネルの開設に充てられたとします。
推定されるところによると、世界の人口の約半数がスマートフォンを所有しています43億人。したがって、1年ごとにライトニングチャネルを利用できる可能性のある全人口のかなりの割合を実際にオンボードすることができます。
しかし、チャンネルは永遠に続くわけではありません。時々、ユーザーはウォレットを切り替えたり、チャンネル容量を増減させたりしたいと思うでしょう。チャンネル容量を変更する最も効率的な方法は、スプライシング、特に実装されている フェニックスウォレット
チャネルが開かれるのと同様に、スプライシングも効率を向上させるために摘み取りの形で行うことができ、複数のスプライス操作が1つの取引を共有して資金の追加および削除に必要な入出力の数を減らすことができます5. したがって、ユーザーのスプライスごとに必要なデルタブロックスペースは、使用されると仮定していますmusig, これは43vBのTaproot出力にプラスします
57.5vBのタップルートキーパスペンド、合計100.5vBです。再度90%のブロックスペース使用を想定した場合、次のようになります:
最後に、ウォレット間でのライトニングチャネルの切り替えが、次のウォレットがコミットメントアドレスに送金された後にコミットメントトランザクションに署名することを信頼するか、または両方のウォレット実装で協力的なチャネルサポートを使用して単一のトランザクションで行うことに注意してください。
もちろん、ライトニング・チャネル以外のビットコインの競合ユースケースが存在し、それが手数料にどのように反映されるかはわかりにくいです。しかし、これらの数値は、現在の技術で数億の自己主権ライトニングユーザーをサポートすることが少なくとも技術的に可能であることを示唆している近似値を与えています。
レイヤー2の概要
私たちのL2システムの定義に基づいて、ビットコイン開発コミュニティで議論されている主なデザインパターンは2つあります。
- チャンネル
- 仮想UTXOs
Lightningが主な例であるチャネルパターンでは、プロトコルは「ハッピー・パス」にはないがマイニングされる可能性がある当事者間の事前署名済みトランザクションを交換することによって進行します。これらの事前署名済みトランザクションは、UTXOを当事者間で分割します。トランザクションは、その分割のバランスを繰り返し変更することで行われ、新しい事前署名済みトランザクションが生成されます。同じUTXOを支出する多くの異なる可能な有効なトランザクションが存在するため、正しいトランザクションが実際にマイニングされるようにするために、何らかのインセンティブメカニズムが必要です。
仮想UTXO（V-UTXO）設計パターンでは、Arkが最も顕著な例ですが、V-UTXOは契約または多数派の合意によって作成されます。これにより、V-UTXOの資金を単独で引き出すためにマイニングできる取引が作成されますが、「ハッピーパス」にはありません。 この意味では、V-UTXOはチャネルに類似しています。 ただし、チャネルとは異なり、V-UTXOスキームは（概念上）V-UTXO自体を消費することで取引を行います。6pre-signedトランザクション。
“ハッピーパス”デザインパターンは、「すべての当事者が同意する」スクリプトパス、例えばN-of-Nマルチシグのようなものの使用です。 taprootはこのコンセプトに特化して設計されており、キーパスがmusigを介したN-of-Nマルチシグになるように許可しています。 すべての当事者が同意すると仮定すると、ハッピーパスはコインを効率的に（かつプライベートに）支出することを可能にします。
興味深いことに、仮想UTXOは多くの意味で「実際の」ものであるため、仮想UTXO上にチャネルを簡単に構築することができます。単に、仮想UTXOを作成し、採掘された場合にはチャネルに必要なUTXOの作成につながるようなものです。この意味では、仮想UTXOスキームは
チャンネルよりやや下のレイヤー。
ライトニング
プロダクションで実装された現状、主にLightning Networkに基づいていますBOLTsの基準. Lightningは、LightningチャネルとHTLC、P2Pルーティングネットワーク、オニオンルーティング、請求書の標準など、さまざまな要素の組み合わせです。特に、Lightningはコンセンサスシステムではないため、Lightningシステムの異なる要素は、すべてのユーザーがまったく同じ方法で採用する必要はありません。この記事の目的のために、「Lightning」という言葉は、広義に使用し、広く使用されている現行（典型的な）Lightningプロトコルの容易に予測されるアップグレードも含みます。
前述したように、Lightning の主な特徴は、ユーザーごとに少なくとも 1 つの UTXO を持つ必要があるため、エンドユーザーのスケーラビリティの制限です。とはいえ、Lightningの「コア」ルーティング要素(トランザクションの大部分をルーティングするパブリックLightningノード)では、支払いルーティングに使用される各パブリックチャネルが毎秒多数のトランザクションを簡単にサポートできるため、ルーティングノードよりもはるかに多くのエンドユーザーがいる場合、Lightningは問題なく機能するため、これらのスケーラビリティの制限はそれほど問題になりません。これは、将来の多くのL2システムもライトニングネットワークに参加することを期待している理由でもあります。これは、Cashu のような既存の L2 システムが実際に役立つために Lightning ネットワークに大きく依存していることにも表れています: Cashu の主な用途は、おそらく Lightning 支払いの送受信です。
非対話チャンネル
この構造では、OP_CTVを使用してインタラクティビティの要件を減らすことで、Lightning チャネルを改善します。ただし、1ユーザーあたり1UTXOのスケーリング制限は改善されないため、これ以上は説明しません。
チャネルファクトリー
ここでは、複数の当事者が1つのn-of-nマルチシグアドレスを交渉し、そのマルチシグアドレスを使用してn個の異なるUTXOを作成するトランザクションが行われます。それらのUTXOは支払いチャネルに使用されます。チャネルは、チャネルの状態をオンチェーンに置く必要がある場合でも、分割トランザクションをマイニングできるため、オンチェーンで直接開かれた場合と同じセキュリティで使用できます。チャネルが閉じられると、チャネルはすべてのnnチャネルを協力して一度に閉じることができるため、オンチェーンのスペースを節約できる可能性があります。
チャネルファクトリーは、採掘される可能性があるが、実際にはハッピーパスで採掘されることは予想されていないUTXOを交渉しているため、V-UTXOの非常に原始的な例です。
チャネルファクトリー自体は、可能にするためにソフトフォークを必要としません。ただし、上記で説明したシンプルなチャネルファクトリーは、実際にスケーリングの利益を得るために必要な調整のため、おそらく小規模な参加者の数を超える場合には実用的ではない可能性があります。したがって、契約提案などのOP_EvictまたはCTV(txoutツリー経由)は、全員を一度にオンチェーンに強制するのではなく、個々の当事者をオンチェーンに強制できる、よりきめ細かな結果を可能にすることを目的としています。
Eltoo/LN-対称性
Eltooという名前は非常に混乱を招くため、今後は更新された名前であるLN-Symmetryのみを使用します。
Poon-Dryjaチャネルは、誤った状態を罰することで、正しい状態をオンチェーンで公開することを奨励しますが、LN-Symmetryは、代わりに、誤った状態を追加トランザクションで更新することを許可します。これには、ペナルティの複雑さが解消され、Lightning チャネルが簡素化されるという利点があります。ただし、不正行為を阻止するためにペナルティが必要であることは間違いないため、信頼できないシナリオでは不利になる可能性があります。
LN-Symmetry needs a soft-fork to enable SIGHASH_ANYPREVOUT, 他の状態トランザクションを更新中に再支出できるようにするために必要です。
単独では、LN-Symmetryは従来のライトニングチャネルにスケーリングの改善を提供しません。しかし、支持者は次のように主張しているそれにより、チャネルファクトリーのようなものを実装しやすくなります。
アーク
Arkは取引のスケーリングに新しいアプローチを取っています：完全に移動可能な仮想UTXO（V-UTXO）、それはアトミックにマージおよび分割することができます7オフチェーン取引。アークでは、アークサービスプロバイダ（ASP）と呼ばれる中央コーディネータが、ユーザーに対して定義された有効期間（例：4週間）を持つV-UTXOを提供します。これらの期間はラウンドとして知られています。これらのV-UTXOは、CTVなどのメカニズムを介して、1ラウンドごとにプールtxoutを介して作成され、単一のオンチェーンtxoutがV-UTXOのツリーにコミットできるようにします。ラウンドの有効期限は、アークがスケーリングの利点を実現する方法です：ラウンドの終わりに、プールtxoutがアンロックされ、ASPが単一の署名でそれを支出できるようになります。ラウンドの有効期限が経過すると、V-UTXO自体もプールtxoutの有効期限が切れるときに期限が切れます：V-UTXOを所有するユーザーは、プールtxoutの有効期限に達する前にそのV-UTXOを支出するか、オンチェーンに配置する必要があります（単独の引き出し）。
当事者間でV-UTXOを取引するために、Arkコーディネーターは、1つ以上のV-UTXOを使用するトランザクションに連署し、トランザクションが1つ以上の他のV-UTXOが別のラウンドで作成された場合にのみ有効になるようにします。慎重なタイムアウト(詳細はArkのドキュメントを参照)と相まって、この依存関係がV-UTXOの支出をトラストレスなものにしています:V-UTXOは、別のプールトランザクションで新しいV-UTXOが作成されない限り、オンチェーンで請求することはできません。その依存関係を実際に実装する方法はいくつか考えられます。ただし、正確な詳細はこの記事の目的とは関係ありません。
これにより、特定のASPには同時に多くの異なるアクティブなラウンドが行われることに注意してください。新しいラウンドは頻繁に作成され、既存のラウンドの資金を移動するために許可されます。ただし、既存のラウンドは新しいラウンドと重なります。通常、新しいラウンドの後に一定期間が経過した後、既存のラウンドと新しいプールのトランザクションが作成されます。
アーク・エコノミクス
V-UTXOが使用されると、ASPは新しいラウンドを表す新しいプールtxoutで対応するBTCを提供する必要があります。しかし、ラウンドが終了するまで、使用されたV-UTXOの価値を回復することはできません。したがって、V-UTXOの使用には時間価値のあるコストがかかります。これは、ASPが提供する流動性によるものです。
具体的には、コストはV-UTXOが使用されたときに発生します。V-UTXOが未使用の場合、それはチェーンに置かれた可能性が非常に高いUTXOを表し、ユーザーはそれらの資金を所有しています。ただし、V-UTXOを使用するには、ASPは別の場所で取得した資金を使用して新しいプールtxoutを作成する必要があります。使用されたV-UTXOの資金は有効期限が切れるまでASPで使用できません。
したがって、V-UTXOを使うためには、短期間のローンが必要で、ラウンドの期限が切れるまでの現在との時間間隔をカバーするために資金を借りる必要があります。これは、V-UTXOを使うための流動性コストが実際には減少し、V-UTXOが古くなり、期限が近づくにつれて、理論上はゼロに近づくということを意味します。
最後に、V-UTXOの費用は、費やしたV-UTXOの合計サイズに関係していることを覚えておいてください。受取人に支払われる金額ではありません。つまり、V-UTXOを直接取引することを目的としたウォレット(例えば、V-UTXOベースのライティングチャネルのために1つのV-UTXOを管理するのとは対照的に)は、資金をV-UTXOに分割する方法でトレードオフを行う必要があります。単一のV-UTXOは、一方的な引き出しのコストを最小限に抑えながら、流動性ベースの取引手数料を最大化します。資金を多くのV-UTXOに分割すると、その逆になります。これは、オンチェーンのビットコインやライトニングトランザクションの経済性とはまったく異なります。
この流動性コストとは?本稿執筆時点では、ライトニングウォレットのPhoenixは、チャネルの流動性を1年間確保するために1%の手数料を請求します。最悪の場合、フェニックスは1年間資金を縛らなければならない。ただし、これは流動性が使用されていないことを前提としています。フェニックスへの資本コストは実際には高い可能性が高く、平均的な顧客は1年以内に流入した流動性を使用すると仮定しています。また、Phoenixは取引手数料から収益を得ており、チャネルの流動性を助成する可能性があります。最後に、フェニックスは儲からないかもしれません!
米国財務省短期証券レートは、別の推定値を提供します。執筆時点では、3か月の財務省短期証券レートは年間約5%です。このレートは米ドルがインフレしているために膨らんでいるという議論があるため、分析ではBTC建てファンドの流動性コストを年率3%と仮定します。
ラウンド間隔が4週間の場合、取引は流動性コストをかかえて開始されることを意味します。
,最終的にゼロに減少します。ユーザーが資金を新しいラウンドに移動しようとすると、ラウンドの期限切れの2週間前に、ユーザーは自己保管を達成するために年間約1.5%の流動性コストを支払っています。一方、ユーザーが最後の瞬間まで待つと8、コストはほぼゼロになる可能性がありますが、期限切れのリスクがあります。
ユーザーはこれを些細な費用とは見なさないかもしれません。また、この費用は、トランザクション手数料やその他の費用を多数の参加者に分散させることで、各ラウンドの固定費用を無視できるようにすることを前提としています。
もし固定費がそんなに無視できない場合はどうでしょうか？ASPに1000人のユーザーがいて、プールの送金は平均して1時間に1回行われます。4週間の期間で、それは672回のオンチェーン取引になります。つまり、彼らの資金を単に保持するために、ASPのユーザーはユーザーと同じくらいの取引手数料を支払わなければなりません！ASPが確認まで1時間待たせることを要求しているにもかかわらず、彼ら全員が独自のライトニングチャネルを開く方がおそらく安くなるでしょう。
ブートストラップアーク
ユーザー数が少ない新しいASPはジレンマに直面しています。要求されたラウンドが十分なV-UTXOを集めて有用なスケーリングとトランザクション手数料の削減を達成するために長時間待たなければなりません。または、ASPプールトランザクションが頻繁に発生し、ユーザーごとに高いトランザクション手数料が支払われます。前のセクションで示したように、頻繁なラウンドを分散するために多くのユーザーが必要であり、その基礎となるプールのtxoutsがかかることがあります。
ラウンドには期限が切れるため、この問題は進行中の問題であり、Lightningチャネルが直面している問題よりもさらに深刻です:少なくともLightningチャネルは無期限に有用であり続けることができ、チャネルを今すぐ開き、何ヶ月にもわたって徐々に償却することができます。第二に、ラウンドの期限が切れるため、これらのラウンドをバックアップする新しいtxoutをいつ作成するかについての柔軟性が低くなります:手数料が1週間または2週間高い場合、プールのtxoutが期限切れになるユーザーは、資金の管理を維持するためにそれらの高い手数料を(まとめて)支払うしかありません。Lightning チャネルでは、チャネルを実際に開くタイミングについて、より柔軟に対応できます。
Arkの作者たちが最初に想定したのは非常に楽観的なシナリオで、新しいラウンドが数秒ごとに行われることですが、初期のブートストラップはおそらくArkのトランザクションが確認されるまで数時間待つことができるユースケースで行われるでしょう（トランザクション手数料が補助されない場合）。
インタラクティブ
非保管型のArkは非常にインタラクティブなプロトコルです：あなたのV-UTXOが期限切れになるため、ASPとやり取りするための厳しい締め切りがあり、それを過ぎるとASPはあなたの資金を取ることを選択するかもしれません。この相互作用は外部委託することはできません：一方で、Lightningは望楼Arkコイン所有者は、オンラインになっていなくても、カウンターパーティがあなたをだまし取ろうとするのを防止するために、自分自身の秘密鍵を使用して信頼を必要とせずに資金を更新する必要があります。Arkで可能な最も近いものは、ウォッチタワーを許可するトランザクションに署名して、有効期限までにチェーン上であなたの資金を一方的に引き出すことができることであり、著しいトランザクション手数料がかかります。
V-UTXOの所有者がオフラインになった場合、何が起こるか考えてみましょう。ラウンドの有効期限が切れると、ASPはさらなるラウンドのために流動性を回復するために資金を回収する必要があります。V-UTXOの所有者がオフラインになった場合、そのV-UTXOをオンチェーンに置くことは、V-UTXOツリーの複数のレベルで資金を回収する必要があるため、著しいトランザクションコストがかかります。ASPは新しいラウンドで未使用のV-UTXOを再作成することができます。しかし、これはV-UTXOの所有者の観点からは信頼性がなく、データを取得しない限り、それらのV-UTXOを使用することはできません。9ASPから。ASPは、未使用のV-UTXOを受託残高として単純に記録することもできます。または、資金を押収する方針を持つかもしれません！
個人的には、Arkのセルフカストディのコストを考えると、多くのユーザーは代わりに、資金を新しいラウンドにロールオーバーするポリシーを持つASPを選択し、各ラウンドの終わりに詐欺の可能性を受け入れるのではないかと思います。これは、ウォレットが資金を新しいラウンドに移動するのに間に合わない場合など、安全を保証するために資金を早めに積極的に移動するよりも安価です。
高度なアーク
充分に高度な契約で可能であると思われます。おそらく、一度に多くの有用なオペコードを追加するスクリプトの復活ソフトフォークを介して、これを行うことができるはずです。
同様に、Sufficiently Advanced™契約を介して、全体的なtxoutツリー構造をいくつかの種類のローリング引き出しスキームで置き換えることができ、潜在的にスペースの節約が可能です。この技術は他のスキームにも潜在的に有用ですので、後のセクションで詳しく説明します。
ラウンド終了時の親権の問題は、十分に高度な™コベナンツが問題を解決できるもう一つのケースです:コベナンツ、特にZKプルーフコベナントは、ASPに次のラウンドですべての未使用のV-UTXOを再作成させ、ラウンド終了時にカストディがそれらに戻るという問題を取り除くことができます。ユーザーが新しいラウンドでV-UTXOを使用するためにASPからのデータが必要になる可能性が高いため、これをトラストレスにすることはおそらく不可能ですが、ASPがオフラインユーザーに対する詐欺から金銭的な利益を得るのを防ぐことができます。
単方向引き出しでのオンチェーン手数料支払い
Lightningに似ていますが、オンチェーンの手数料支払いの経済性と手数料後のV-UTXOの実際の価値は、Arkの使用が一方的な引き出しまたはASPの利益を受けない詐欺によってL2の定義に適合するかどうかを決定します。 txoutツリーデザインパターンについては、後述します。
バリディティロールアップ
様々な形式のゼロ知識（ZK）証明技術を使用してチェーンのルールを強制するために一般的に提案される、サイドチェーンのような構造の大規模なクラス。ZK証明技術は、妥当性ロールアップ技術と他の形式のサイドチェーンとの重要な違いです：もしZK証明スキームが機能するなら、取引の妥当性は第三者を信頼するのではなく、数学によって保証されることができます。ZK証明の「ゼロ知識」の側面は、実際にはこのユースケースでは要件ではありません：証明が何を証明しているかに関する情報が「漏れて」いる場合でも、それは完全に問題ありません。ただし、このクラスの証明のほとんどの数学的なスキームがゼロ知識証明であるという偶然があります。
Bitcoinの観点からすると、有効性ロールアップスキームには契約が必要です。スキームのためにUTXOを作成できるようにするには、スキームのルールに従われた場合にのみ使用できるUTXOを作成する必要があります。これは必ずしも分散化されたプロセスではありません。多くの有効性ロールアップスキームは実際には完全に中央集権化されています。ロールアップの証明は、中央集権化されたトランザクションシーケンサーが特定のトランザクションシーケンスのルールに従ったことを証明しています。
どのような誓約かというと...ゼロ知識証明技術はまだ非常に新しい分野であり、進歩は頻繁に行われています。したがって、特定のZKプルーフスキームを直接検証するオペコードがビットコインに追加される可能性はほとんどありません。代わりに、特定のスキームでは、より一般的なオペコード、特にOP_CATを使用して、スクリプトを介してZKプルーフを検証することが一般的に受け入れられています。例えばStarkWareはキャンペーン中OP_CATが採用されるようになりました。
バリディティロールアップは、多くの低品質/高ハイプのプロジェクトがある非常に大きな潜在的なトピックであり、この設計クラスを可能にする可能性のあるオペコードを指摘することを超えて、さらに議論しません。
BitVM
ざっくり言えば、BitVMは、ライトニングチャネルを構築する方法であり、ライトニングチャネルのルールがゼロ知識証明によって強制されるようになっています。Bitcoin上で契約を実装する必要がなく、1つのUTXOあたりのユーザー制限を超えるスケーリングを実現することができないため、これ以上議論しません。
階層チャネル
階層チャネル10aims to make channel resizing fast and cheap: “Hierarchical channels do for channel capacity what the LN does for bitcoin”. However they still don’t fundamentally exceed the 1 UTXO-per-user limit. They also don’t require any changes to the Bitcoin protocol anyway. So we’re not going to discuss them further. Their proponents should simply implement them! They don’t need our permission.
コインプール
CoinPoolでは、複数のユーザーが1つのUTXOを共有し、異なるユーザー間で資金を送金し、一方的に出金することができます。CoinPoolのペーパー提案では、SIGHASH_ANYPREVOUT、特定のUTXOにのみ署名を適用できるSIGHASH_GROUP、マークルツリーからの特定のブランチの削除を検証するOP_MerkleSubの3つの新しいソフトフォーク機能が必要です。後者はOP_CATでも実現できます。
現時点では、CoinPoolの開発は停滞しているようで、仕様ウェブサイトへの最後のコミットは2年前になります。
Enigma Network
Enigma Networkをカバーするように頼まれましたが、提案が本当に何であるかについての文書化が不十分なようです。 Bitfinexのブログ投稿多くの主張を行います; そのMITのページは空です。このブログ記事では、具体的に何が起こっているのかが明確になっていないので、これ以上は説明しません。
メンプールに関する考慮事項
Bitcoin Coreの現在のメンプールポリシーは、L2システムにとって理想的ではありません。ここでは、彼らが直面する主な課題と潜在的な改善策について説明します。
トランザクションピニング
結局のところ、経済的な攻撃であるトランザクションピンニング攻撃は、誰かが意図的に（or unintentionally)は、マイニングされない競合するトランザクションの事前ブロードキャストにより、目的のトランザクションをマイニングすることを困難にします。これは経済的なエクスプロイトであり、真のトランザクションピンニングの状況では、マイナーがマイニングした場合に利益を得る望ましいトランザクションが存在するためです。競合するピン留めトランザクションは、妥当な時間内にマイニングされません。
ピン留めの最も単純な例は、完全RBFがない場合、トランザクションの置換がオフになるという事実から来ています。したがって、置換がオフになっている低料金率のトランザクションがあり、採掘されないが置換できない場合があります。実質的に、100％のハッシュパワーが完全RBFを有効にすることで、書いている時点では、Bitcoin Coreの次のリリースでデフォルトで完全RBFが有効になるはずです。11年間の努力!).
それにより、マルチパーティL2プロトコルに関連し、Bitcoin Coreで修正されていない唯一の残りのピン留め問題であるBIP-125ルール＃3のピン留めが残ります。参考のために、BIP-125ルール＃3は次のように述べています。
より高い絶対手数料を支払うために、代替トランザクションが必要です（not）
Just Fee Rate)は、置き換えられるすべてのトランザクションによって支払われる手数料の合計よりも高くなります。
このルールは、マルチパーティプロトコルに関連する出力を消費する大きな低手数料のピン留めトランザクションをブロードキャストすることで悪用することができます（または、トランザクションのグループ）。トランザクションの手数料率が低いため、タイムリーにマイニングされないかもしれません。しかし、トランザクションの合計手数料が高いため、別のトランザクションで置き換えることは経済的ではありません。
ルール＃3のピニングは比較的簡単に修正できますreplace-by-fee-rate、この修正はすべての状況で機能します。残念ながら、RBFRが近い将来にCoreに採用されるかどうかは不明です。TRUC/V3 トランザクション.
料金の支払い:RBF、CPFP、SIGHASH_ANYONECANPAY、アンカー、およびスポンサーシップ
手数料率は予測不可能なため、取引が事前に署名されている状況で確実かつ経済的に支払うことは困難です。手数料支払いのゴールドスタンダードは、RBFを使用し、最初の「ローボール」見積もりから始めて、マイニングされるまで必要に応じてトランザクションをより高い手数料バージョンに置き換えることです。たとえば、OpenTimestampsカレンダーソフトウェアは何年も前からRBFをこのように使用しており、LNDはv0.18の期限対応RBF.
RBFは、ほとんどすべてのブロックスペースの中で最も効率的なため、手数料支払いのゴールドスタンダードです11状況: 交換トランザクションには、最初の試行で正しい手数料が推測されていた場合に必要とされた追加の入力や出力は必要ありません。
効率は重要です、なぜなら手数料支払いの非効率性は重要だからです帯域外料金の支払い大規模な鉱山労働者にとって収益性の高い収入源。小規模で分散化されたマイナーは、取引を確認するために小規模なマイナーに支払うことの非実用性と無意味さのために、帯域外の手数料支払いから利益を得ることができません。現在、実際に利用可能な帯域外手数料支払いシステムのほとんどは、手数料の支払いを行うために何らかのAML/KYCプロセスを必要とします。mempool.spaceアクセラレーター執筆時点(2024年8月)では、アカウントなしでLightningを受け入れます。
事前に署名されたトランザクションの状況でRBFを直接利用するためには、潜在的な手数料の全範囲をカバーするために事前に署名された手数料バリアントが必要です。多くの場合、必要なバリアントの数は比較的少ないため、これはかなり実現可能です。12これまでのところ、本番環境のLightningプロトコル(およびその他の提案されているプロトコル)は、代わりに子が親に支払う(CPFP)、通常はアンカー出力を介して。
アンカーアウトプットのアイデアは、最小またはゼロの価値を持つ1つ以上のアウトプットをトランザクションに追加し、そのアウトプットを二次トランザクションで支払い手数料（CPFP）として使用する意図であります。これは、LNのようなオンチェーントランザクションが小さいプロトコルに適用される場合に非常に効率が悪いです。エフェメラルアンカーアウトプットを使用したLNコミットメントトランザクションの合計サイズを2倍にする.コベナンツを実装するためにOP_CATを使用するものなど、より大きなトランザクションを利用するプロトコルを適用する場合、それはそれほど問題ではありません。
アンカーアウトプットのあまり目立たない問題は、手数料を支払うために追加のUTXOを手元に置いておく必要があることです。典型的な「クライアント」アプリケーションでは、アンカー出力がなければ、複数のUTXOを維持する必要がまったくないことが多いため、これは全体的な大きな負担になる可能性があります。実際、既存の消費者向けLightningウォレットの中には、手数料を支払うことができないため、高手数料環境でチャネルのリモート側による盗難に対して脆弱なものがある可能性があります。
SIGHASH_ANYONECANPAYは、署名済みトランザクションに追加のインプットを許可することで、一部のケースで手数料支払いに使用することができます； SIGHASH_SINGLEはアウトプットも追加できるようにします。ライトニングはHTLCトランザクションにこれを使用しています。現時点では、この方法は慎重に処理されないとトランザクションのピン留めの脆弱性にさらされる可能性があります13攻撃者は、トランザクションに大量の入力と/または出力を追加して高手数料/低手数料率ピンを作成できるため、RBFRはこの問題を修正します。TRUC/V3トランザクションで使用されるアプローチでは、この問題を修正することができません。このスタイルの手数料支払いは、RBFほど効率的ではありませんが、アンカーアウトプットよりも効率的であることがあります。
最終的には、ソフトフォークを追加するためのさまざまな提案がありました。手数料スポンサーシップビットコインプロトコルへのシステム。これにより、取引は他の取引に依存関係を宣言でき、スポンサー取引は、おそらく同じブロックで採掘された場合にのみ採掘できるようになります。これは、スポンサー取引が取引のインプットのサイズよりもはるかに少ないvバイトを使用してその依存関係を宣言できるため、従来のCPFPよりもはるかに効率的である可能性があります。
交換用サイクリング
置換サイクリング攻撃14取引の置き換えを利用して、望ましくないトランザクションを採掘するために、望ましいL2トランザクションを置き換えようとする。基本的に、攻撃者にとって、置換サイクル攻撃はトランザクションピン技術の代わりとなり、望ましい誠実なトランザクションが採掘されることを防ぎ、代わりに望ましくない不誠実なトランザクションが採掘されることを目指します。トランザクションピン攻撃とは異なり、置換サイクル攻撃は偶然には起こりません。
標準的な例は、Hashed-Time-Locked-Contract(HTLC)に対するものです。HTLCは、プリイメージの公開またはタイムアウトを介してトランザクションを使用できるようにするコントラクトと考えるのは簡単です。実際には、ビットコインスクリプトの制限により、HTLCでは、常にプリイメージを表示することでトランザクションを使用し、タイムアウト後にさらにタイムアウトメカニズムを介してトランザクションを使用できます。
この置換サイクルは、タイムアウト後の画像を使用して、被害者が画像を学習しないように、HLTCの出力を償還しようとするトランザクションを置き換えるために利用します。成功した置換サイクル攻撃は、異なるチャネルのHTLCのタイムアウトが長いことを行います。
置き換えサイクルを収益化する上での主な課題は、各置き換えラウンドにコストがかかることです。締め切りを意識したLightning実装は、次に期限切れになるHTLC出力の期限が切れる前に期限切れになったHTLC出力を支払うためにますます高い手数料を費やします。第二に、置き換えトランザクションを再ブロードキャストするだけで攻撃を防ぐことができます。15交換サイクルが終了したら。
トランザクションピニングと同様に、置換サイクルもマイナーにとって経済的な搾取である。置換サイクルの終わりには、メンプールから削除されたが完全に有効であり、マイナーがまだメンプールに保持していれば採掘できるトランザクションが存在する。
機能パターンとソフトフォーク
さて、さまざまな契約に依存するL2システムとメンプールの課題の概要をご説明しましたので、これらのL2システムが共有する注目すべきソフトフォークの特徴（主に新しいオペコード）とデザインパターンについてまとめてみます。ソフトフォークの提案については、提案ごとの技術的なリスクと課題についても議論します。提案ごとのデプロイのリスクと課題についても議論します。
OP_Expire
まず、これを片付けましょう。 OP_Expireが提案されました16根本的な問題を解決することで、置換サイクル攻撃を排除する簡単な方法として、HTLCは一度に2つの異なる方法で使用できるという事実です。L2システムのコンテキストでは、これはHTLCのようなメカニズムを使用するもの、およびおそらく他のユースケースに関連しています。OP_Expire、ある時点を過ぎるとトランザクション出力が使用できなくなることを可能にし、HTLCの支出条件を「プログラマーOR」ではなく、真の排他的ORにすることができます。
実際のOP_Expireソフトフォークは、おそらく2つの機能から構成されることが多いでしょう。これは、類似している方法で行われます。OP_CheckLockTimeVerifyとOP_CheckSequenceVerifyオペコードは2つのパートに分かれています。
- トランザクションの有効期限高さフィールド、おそらくはタップルートの付録で実装されることが最もあります。
- 所望の高さに最低限設定されていることをチェックするOP_Expireオペコード。
OP_Expire自体はほとんど契約としては資格がありませんが、多くの契約依存型L2システムにとって有用であるようです。ただし、代替サイクルは利他的な再送信によっても緩和される可能性があるため、十分に有用でないかもしれません15
OP_Expireのデプロイと使用に関する非常に注目すべき課題は、Satoshiをはじめとするビットコイン技術コミュニティの再編成です17、はBitcoinのコンセンサスプロトコルが、深い再編成の後でも以前に採掘されたトランザクションを新しいブロックに採掘できるように設計されていることを確認しました。この設計原則は、コンセンサスの失敗が大規模な再編成につながった場合、大量の確認済みのコインが永久に無効になる悪夢のシナリオを避けることを試みています。その結果、それらのコインに依存している人々はお金を失います。
大規模な再編成の場合、有効期限を使用するトランザクションは、有効期限の高さに達するため、マイニング不能になる可能性があります。OP_Expire提案では、有効期限を使用するトランザクションのアウトプットをコインベーストランザクションと同様に扱い、~100ブロックの間使用できないようにすることで、この問題をmitiGateすることを提案しています。
トランザクションの有効期限を導入する際の大きな障壁は、このトレードオフが許容できるかどうか、あるいは必要かどうかについてコンセンサスを得ることです。OP_Expireが役立つトランザクションの種類には、ユーザーの資金が凍結される長いタイムアウトがすでに含まれています。これらのタイムアウトにさらに時間を追加することは望ましくありません。また、二重支払いは、再編成後にコインを無効にする別の方法であり、RBFの使用が増加し、キーレスアンカー出力の使用が提案されている中、トランザクションの有効期限は大きな違いを生むのでしょうか?
SIGHASH_ANYPREVOUT
BIP-1182つの新しい署名ハッシュモードを提案しますが、いずれも特定のUTXOが支払われることを確約しません。SIGHASH_ANYPREVOUTは、代わりにscriptPubKeyに確約します（基本的に）。一方、SIGHASH_ANYPREVOUTANYSCRIPTは、任意のスクリプトを許可します。前述のように、これはLN-Symmetryによって、個々の前のチャネル状態に個別に署名する必要があるかもしれない必要性を回避するために提案されました。
SIGHASH_ANYPREVOUTは、特定のtxidに依存しなくなったという事実が、事前に署名されたRBF手数料率のバリアントと事前に署名された取引を併用したい場合にも潜在的に役立つことがあります。手数料率変数の組み合わせ爆発ただし、現在のBIP-118提案ではこのユースケースに対応していない可能性があり、SIGHASH_ANYPREVOUTもUTXOの値にもコミットすることが提案されているため、互換性がないかもしれません。
SIGHASH_ANYPREVOUTに対する最初の反対意見は、ウォレットを不適切な方法で使用することでトラブルに巻き込まれるという考えでした。問題は、1 つの SIGHASH_ANYPREVOUT 署名が公開されると、指定されたスクリプトで任意の txout を使用するために使用できることです。したがって、同じスクリプトで2番目の出力が誤って作成された場合、SIGHASH_ANYPREVOUT、それらのコインを盗むための些細なリプレイ攻撃が可能になります。しかし、ウォレットやL2の実装には他にも多くのフットガンがあるため、この懸念は解消されたようです。
現在、一般の技術コミュニティはBIP-118の実装についてかなり前向きな意見を持っています。しかし、LN-Symmetryの議論で上述したように、その主な使用ケースであるLN-Symmetryが実際には良いアイデアなのかについては議論があります。
OP_CheckTemplateVerify
最初の契約固有のオペコード提案であるOP_CheckTemplateVerify（通常CTVと呼ばれる）は、指定された方法で支出トランザクションをハッシュし、入力UTXOにコミットしないようにする非常に具体的で制限された契約オペコードを作成することを目的としています。その結果のダイジェストをトップスタック要素と照合することで、支出トランザクションを事前に制約することができます。これにより、真の再帰的な契約制限を可能にすることなく、支出トランザクションを制約することができます。
なぜCTVでは再帰的契約は不可能なのですか？ハッシュ関数のためです：CTVは支出トランザクションをテンプレートハッシュと照合し、方法がありません18自身のハッシュを持つCTVを含むテンプレートを作成する
とはいえ、これは必ずしも本当の制限ではなく、最新のコンピュータでは、CTVテンプレートハッシュのチェーンをわずか数秒で数千万トランザクションの深さまで簡単にハッシュ化することができます。で相対的なnSequenceタイムロックそして、制限されたブロックサイズは実際にそのようなチェーンの終わりに到達することができ、数千年にわたって簡単に作成されることができました。
現在のCTV提案はBIP-119は、DefaultCheckTemplateVerifyHashとして知られる単一のハッシュモードしか持っていません。これは、テンプレートハッシュ内の支出トランザクションのすべての側面にコミットするものです。実際的な観点からは、これは多くの場合、手数料支払いのための唯一の利用可能なメカニズムがCPFPであることを意味します。上記で述べたように、これはCTVを使用するトランザクションが小さな場合には、帯域外の手数料支払いが非常にコスト削減となるため、潜在的な問題です。
CTVは、その相対的な単純さと幅広いユースケースのため、技術コミュニティの間で最も広範なサポートを持つコヴナントオプコード提案と言えるでしょう。
LNHANCE(エヌハンス)
CTVを実装するための提案の1つは、それをOP_CheckSigFromStack（Verify）とOP_InternalKeyの2つの追加のオペコードと組み合わせることです。問題は、現時点では、そのプルリクエストと関連するBIPのドキュメントがこの提案に賛成か反対かを議論するには十分ではないことです。これらのBIPには、実際の世界の例でオペコードが実際に何を行うことが期待されているかについての合理的な説明がまったくありませんし、さらには詳細な例のスクリプトもありません。
著者たちはおそらく彼らの提案に良い理由があるのでしょうが、その理由を実際に説明し、適切に正当化する責任があります。したがって、これ以上議論はしません。
OP_TXHASH
CTVに類似したこの提案は、支出トランザクションからデータをハッシュ化することで、再帰的な契約機能を実現します。CTVとは異なり、TXHASH提案は「フィールドセレクター」メカニズムを提供し、支出トランザクションがどのように制約されるかについて柔軟性を持たせます。この柔軟性により、2つの主な目標が達成されます:
- マルチTXプロトコルを壊すことなく、トランザクションに手数料を追加することを可能にすること。
- ユーザーが自分の入力と出力のみを制限するマルチユーザープロトコル。
OP_TXHASHの主な問題は、フィールドセレクタメカニズムがかなりの複雑さを加え、CTV提案と比較して、レビューやテストが非常に困難になることです。現時点では、フィールドセレクタメカニズムが実際にどれだけ有益であるか、また具体的にどのように使用されるかについて十分な設計分析が行われていません。したがって、これ以上は議論しません。
OP_CAT
スタックのトップ2つの要素を連結し、連結された結果をスタックにプッシュする連結演算子。元々、ビットコインにはOP_CATが有効になって出荷されていましたが、サトシ 2010年に静かに削除されました, probably due to the fact that the initial implementation was vulnerable to DoS attacks due to the lack of restrictions on the size of the resulting script element. Consider the following script:
DUP CAT DUP CAT…
要素のサイズ制限がない場合、各DUP CATイテレーションはトップスタック要素のサイズを2倍にし、最終的には利用可能なメモリをすべて使用します。
連結は、次のようにして再帰契約を含む多くの種類の契約を実装するために十分です。
- OP_CAT（および必要な契約固有のロジック）を1回以上呼び出して、ウィットネスデータなしでスタックに部分トランザクションを組み立てます。
- スタック上のトランザクションが支出トランザクションと一致していることを検証します。
実際には、Schnorr署名の数学を濫用する、慎重に構築された署名を使用して、OP_CheckSigを介して第2ステップを実行することができます。ただし、おそらくOP_CATソフトフォークがOP_CheckSigFromStackと組み合わされ、スタック上の署名がトランザクションの有効な署名であることを検証することによって、第2ステップを実行します。19その後、同じ署名を使用して、支出トランザクションが一致していることをOP_CheckSigで検証します。20
証人データなしでトランザクションを組み立てる必要があるという事実は重要です: 契約はトランザクションが行うこと、つまりその入力と出力を検証するだけで十分であり、実際にそれを有効にする証人データは（あれば）検証する必要はありません。
モジュロスクリプトサイズの制限を除いて、OP_CATとOP_CheckSigFromStackの組み合わせは、再帰的契約を含む多くの種類の契約を構築するために十分です。CTVのような効率的な解決策と比較して、それはより高価です。しかし、コストの違いはあなたが期待するよりも少ないです！
大まかに言えば、これを行うためにOP_CATを使用するには、支出トランザクションの非ウィットネス部分すべてを証人を介してスタックに配置する必要があります。TXOUTツリーなどの典型的なCTVユースケースでは、支出トランザクションにはウィットネスデータがまったくありません。証人スペースが75％割引されるため、子トランザクションの実効トランザクション手数料が25％増加します。悪くないですね！
OP_CATは強すぎるのか？
これはおそらくOP_CATの展開にとって最大の政治的および技術的な障害であり、OP_CATによって可能になるユースケースを予測するのは非常に難しいです。そして一旦「猫」が袋から出てしまうと、それを元に戻すのは非常に難しいです。
OP_CATは、合理的に効率的で安全であると主張されているため、素晴らしい例です。BitcoinスクリプトにSTARK検証を実装する.STARKは非常に一般的なステートメントを証明できるため、STARKを効率的に実装できるようにすると、ビットコインの上にさまざまなシステムを構築できるため、L2システムの範囲を超えた大きな影響があります。OP_CATに対する強力な反論は、これらのユースケースがビットコインユーザーにとって全体的に良いとは限らない可能性があるということです。
有害な中央集権的なマイナー抽出可能な価値の生成は、重要な潜在的な問題です。「MEV that is evIL」と呼ばれるもの（MEVil）Matt Corallo氏によると、MEVilとは、大規模なマイナー/プールが、単に総手数料を最大化するだけでなく、小規模なマイナー/プールが採用するのが不可能な高度なトランザクションマイニング戦略を用いて追加価値を抽出できる状況のことです。OP_CATで作成できる潜在的な金融商品の複雑さから、MEVilを排除することは非常に困難です。トークンオークションプロトコルからBitcoinで既に重要なMEVilが現れていますが、幸いにもその特定のケースは完全RBFの採用によって撃退されました。
MEVilの可能性に加えて、潜在的に有害な具体的なOP_CATユースケースは他にもたくさんあります。たとえば、Drivechainsの提案はここでレビューされました, そしてビットコインにとって有害であると広く考えられています。可能だと信じられているOP_CATを使用してDrivechainを実装する。もう一つの例として、Taproot Assetsのようなトークン提案が挙げられます。一般的には、それらが実装されるのを防ぐことは不可能ですが、クライアントサイドの検証、これらをOP_CATを使用して実装する提案があり、これによりエンドユーザーにとってはより魅力的な方法で実装できる可能性がありますが、それによりはるかに多くのブロックスペースが使用されるため、「正当な」ビットコイン取引を潰す可能性があります。 これらのユースケースは、金融詐欺に使用されるトークンプロトコルが頻繁に使用されるため、法的問題も引き起こす可能性があります。
インクリメンタルハッシング
コベナンツの場合、OP_CATは主にデータを連結し、ハッシュ化するために使用されます。これと同じ目標を達成する別の方法は、ある種のSHA256中間状態を受け取り、それにより多くのデータをハッシュする、ある種のインクリメンタルハッシュオペコードを使用することです。SHA256 自体は 64 バイトのブロックで動作します。インクリメンタル ハッシュ オペコードには多くの設計があります。
重要な設計の決定事項の1つは、スタック上で実際の中間状態バイトをいくつかの正規形式で公開するか、直接操作できない新しい不透明なスタック項目タイプで表現するかどうかです。SHA256は特定の固定の初期化ベクトルに対して指定されており、任意の中間状態/初期化ベクトルが許容される場合、SHA256の暗号特性が成り立つかどうかは不明です。
もちろん、増分ハッシングはOP_CATができることのほとんどを効率的に行うことができるため、OP_CATに関するすべての懸念を共有しています。
スクリプト復興
OP_CATはSatoshiが無効にした15のオペコードの1つでした。OP_CATを復元するだけでなく、Rusty Russellは提案しています。21ほとんどのオペコードを再度有効にし、DoS制限を追加し、同じソフトフォークでいくつかのオペコードを追加することにより、「サトシのオリジナルビジョン」にBitcoinのスクリプトを本質的に復元することを目的としています。特に、OP_CheckSigFromStackが可能性が高いです。
OP_CATだけでも（再帰的な）契約を可能にしますが、完全な「スクリプトの復活」がより洗練された契約を可能にし、支出トランザクションの一部を直接操作することをはるかに簡単に実装します。例えば、トランザクション内のtxoutの合計値が特定の条件を満たすことを保証するために算術演算コードを使用する契約スクリプトを想像することができます。
再び、スクリプトの復活は、OP_CATだけではなく、過度に強力であることに関するすべての同様の懸念とその他の懸念を引き起こします。
シンプリシティー
Script Revivalと同様に、SimplicityはL2と契約に関連しており、何でも可能にすることができます。 Script Revivalとは異なり、Simplicityソフトフォークは、コンビネータとして知られる9つのプリミティブオペレータに基づいたBitcoinのスクリプトシステムに完全に新しいプログラミング言語を追加します。
実際には、シンプルさは単純すぎると同時に、まったく単純ではありません。原始的なコンビネータは途方もなく低レベルなので、加算などの基本的な操作は苦労してゼロから実装する必要があります。生の Simplicity は、実際には非常に冗長です。したがって、Simplicityの実際の使用法は、ライブラリ関数呼び出しに似たコード置換のシステムを利用します。ジェット機.これは実際的/政治的な問題を提起します:どのジェット機を実装するかをどのように決定しますか?ほとんどの場合、ジェットは他のオペコードと同様に C++ で実装され、新しいジェットごとにソフトフォークが必要になります。
OP_FancyTreeManipulationStuff
比較的特殊化された多様なオペコードが提案されており、契約に依存するL2提案のために効率的な空間でツリー操作を行うための。たとえば、Coinpoolsは両方を提案していますTAPLEAF_UPDATE_VERIFYそしてOP_MERKLESUBCoinpools提案に必要な方法で、両方の提案はタプルートツリーを操作します。マット提案は、基本的には、Merkleツリーに関する文を検証するOP_CheckContractVerifyオペコードを提案しています。
この記事では、これらの多くの提案のそれぞれについて詳細に説明する必要はありません。むしろ、それらをグループとして話すことができます:それらはすべて、理想的には意図しない副作用なしに、L2の1つのクラスを可能にする比較的ユースケース固有の提案です。これらはすべて、OP_CAT操作などのより一般的なオペコードで同じ目標を達成するよりも少ないブロックスペースを使用するという効率の利点があります。しかし、これらはすべて、潜在的にニッチなユースケースのために、スクリプトシステムに複雑さを加えるという欠点があります。
BitcoinがSimplicityスクリプティングシステムを採用した場合、同じような動きが起こります。Simplicityにおけるオペコードに相当するものは、よく使われるパターンに対してジェットを追加することです。再び、木の操作のようなユースケース固有の操作に対するジェットの実装は、ユースケース固有の操作に対する複雑なオペコードの実装と同様の利点と欠点があります。
ファンドプール
単一のUTXOを複数のユーザーで共有しようとするすべてのL2システムは、何らかのマルチユーザーファンドプールと見なすことができます。ユーザーは引き出しの権利を持っています。潜在的には、プールに資金を追加するメカニズムも存在するでしょう（資金を事前に割り当てた状態でプールを作成する以外に）。
ファンドプールが有用であるためには、それに関連する「共有データ状態」を持つ必要があります。つまり、txoutの値がどのように分割されるかです。ファンドプールが時間とともに進化する場合、その状態はファンドがプールから追加または削除されるたびに変更する必要があります。 Bitcoin上に構築しているため、プールから資金を追加または削除する場合は、プールが制御するUTXOを消費する必要があります。
ビットコインのコンセンサスシステム自体は状態変更の検証に基づいています: トランザクションは、その証人によって、UTXOセットの状態への変更が有効であることを証明します。Proof-of-workによって、どのセットのトランザクションが正しいかについての合意に至ります。これは、資金プール自体も状態変更の検証に基づいていることを意味します: 我々は、すべてのビットコインノードに、資金プールのルールが状態変更ごとに遵守されていることを証明しています。
だが、信頼できるL2ファンドプールのもう一つの重要な側面があります。つまり、ファンドプールの状態が変化すると、システムは、ファンドプールに参加するユーザーが自分の資金を回収するために十分なデータを公開する必要があります。もし我々がそれを行わなかった場合、システムは第三者の協力なしに一方的な引き出しを提供することができず、失敗します。多くのロールアップベースのスキームはここで失敗します。データの可用性の問題に苦しんでおり、第三者のコーディネーターがオフラインになった場合、ユーザーは有効なファンド回復トランザクションを構築するために必要なデータを入手する方法がないため、自分の資金を回収できません。
これらの制約を念頭に置いて、ファンドプールはどのようなデータ構造に基づいているのでしょうか?必然的に、それらはすべてある種の木です。具体的には、ある種のマークルツリーです。なぜなら、それがコンピュータサイエンスにおける唯一のスケーラブルなデータ構造だからです。なぜなら、それが基本的にツリーの状態に暗号的にコミットする唯一の合理的な方法だからです。最後に、ツリーの更新は必然的にビットコインブロックチェーンに公開されます出版媒体すべてのL2ユーザーが共有し、コインを移動するためにユーザーに公開することを強制できる唯一の方法です。そして、どの契約の実装にも、契約のルールが守られていることを検証するためにツリーの一部が必要になるためです。
では、高レベルの理論を押しのけて、これは実際にビットコインのスクリプトとトランザクションにどのように変換されるのでしょうか？
個別の事前署名トランザクション
木の退化した状態で、正確に1つの葉が含まれています。ここでは、資金プールの状態がおおよそ一度変化します。例えば、標準的なライトニングチャネルはこのカテゴリに該当し、開かれると閉じることしかできません。チャネルが閉じられる際に公開されるデータは、トランザクションそのものであり、チャネルの相手方はブロックチェーンデータからtxidを学び、それを使って自分の資金を回収するための十分な情報です。
ここで必要なのは最も基本的な契約である「事前署名済みトランザクション」のみです。
Txout Trees
ファンドプールで見られる次のより複雑なデザインパターンは、txoutツリーです。Arkは注目すべき例です。ここでは、予め定義されたトランザクションのツリーで、ルートのUTXOを使用してファンドプールを分割することができます。事前に署名されたトランザクションやCTVなどのシンプルな契約によって強制され、そのUTXOの価値を小さな金額に分割し、最終的には正当な所有者によって使用可能な葉ノードまで分割されます。
txoutツリーの目的は、ユーザーが自分の資金を回収する方法を選択できるようにすることであることを認識することが重要です。そして、これらのオプションにはコストがかかります。txoutツリーは、単一のトランザクションでUTXOを分割するよりも、資金プールを分割して所有者に返すためのより高価な方法になります。ツリー内の各層は、その層を作成するために必要なtxoutsおよびtxinsで使用されるバイト数のため、コストがかかります。
では、txoutツリーがどのようなオプションを提供する可能性がありますか？Arkは再び素晴らしい例です：単一のV-UTXOのチェーン上での償還にすべてのV-UTXOをチェーン上に配置する必要はありません。ツリーを使用することで、償還は代わりにツリーをより小さな部分に分割して、望ましいV-UTXOがチェーン上に配置されるまでになります。
個々の署名済み取引のケースと同様に、公開される情報は取引そのものであり、必要に応じて他のユーザーのウォレットに資金の使い道を通知します。
txoutツリーのスケーラビリティには興味深い規模の経済があります。 n個のV-UTXOがあるファンドプールに最初のV-UTXOをチェーンに配置するコストは、単一トランザクションよりもおよそlog2(n)log2(n)倍高価です。なぜならlog2(n)レベルの分割トランザクションをチェーンに配置する必要があるからです。ただし、最初のV-UTXOをチェーンに配置した後は、他の人が中間トランザクションの採掘コストを支払ったため、その後のV-UTXOはチェーン上での償還が安くなります。
二分木の要素数が全体であることを思い出してください。
n枚の葉は2nです。これは、すべてのV-UTXOをチェーン上に配置するために、txoutツリーを介して行うための合計コストが、単一の取引で行うための合計コストの小さな倍数であることを意味します。驚くほど効率的です！
もしくは、そうでないかもしれません...基金プールの全体サイズの償還が十分に大きい場合、それらは総合的なブロックスペースに対する非自明な需要を表す可能性があります。ブロックスペースは供給と需要のシステムですので、ある時点で需要が高いため手数料が上昇することになります。極端な場合、実際にはすべてのトランザクションアウトプットツリーが非常に大きく、深いために償還することが可能です
ツリー内のV-UTXOは不可能です。
txoutツリーに関するオープンな問題は、誰が手数料を支払い、どのように支払うかですか？明らかな解決策の1つは、リーフトランザクションのキーレスアンカーアウトプットを使用し、リーフトランザクションをマイニングしたい人が手数料をCPFP経由で支払うことを許可することです。一部のユースケースでは、V-UTXO自体はCSVの遅延なしに直ちに支出することができるため、V-UTXO自体がCPFP経由で手数料を追加するために支出される可能性があります。
RBFは許可によって実装が複雑です：RBFの手数料を取る明らかな場所は、V-UTXOの値からです。しかし、どのようにして所有者だけがより高い手数料のトランザクションに署名する能力を持つことを保証しますか？多くの場合、これをキーレスアンカーアウトプットよりも効率的な方法で行う方法は明確ではありません。ただし、V-UTXO自体が直ちに使われない場合、エンドユーザーウォレットが使用するスキームに対して重大な課題を提起する可能性があります。これにより、CPFPを実行するために使うUTXOがない場合。
最後に、手数料支払いを考慮に入れたtxoutツリーシステムにおけるインセンティブについて慎重な考慮が必要です。例えば、Arkのようなシステムでは、個々のV-UTXOがオンチェーンのV-UTXOに引き換える価値があるほど高価である場合、協力しないコーディネーターはこれらのV-UTXOをオフチェーンで償還することを拒否し、タイムアウトが発生すると、これらのV-UTXOの価値を一度に盗むことで利益を得ることができます。
もしそうだとすれば、このようなシステムは、小型のV-UTXOのL2であるという我々の基準を満たさないことになるでしょう。
バランスベースのスキーム
トランザクションアウトツリーの状態機械はまだ比較的単純です。ファンドプールが存在するか、それが使用されて、2つ以上の小さなファンドプールが作成されます。より高度な契約では、ファンドプールを進化するバランスとして扱うこともでき、そのバランスから資金を追加したり減らしたりすることができます。
これを行うには、非自明なステートマシンを実装する必要があります。しかし、本質的に共有データベースが必要です。なぜなら、ここでの目標は、1つのUTXOを多くの所有者で共有することです。最後に、実際にスケーラビリティの改善を得るためには、その所有権データをチェーンにできるだけ少なくする方法で行わなければなりません。
これらの要件は、メルケルサムツリーなどのツリー状のメルケル化されたデータ構造のようなものに私たちを不可避的に導きます。そのデータ構造を操作することは、OP_CATのような何らかのゼロ知識証明検証オペコード、または特定の目的のためのツリー操作オペコードが必要になる可能性があります。
興味深いことに、txoutツリーと同様のセキュリティ特性を維持しながら、log(n)のスケーリングよりも優れたものはありません。なぜでしょうか？仮に、ある仮想的なOP_ZKPが存在し、ある高度な数学を通じて任意の文を証明するためにわずか32バイトしか必要としないとします。このzk-proofは、レイヤー2システムのルールに従ってマークル化されたデータ構造が操作されたことを証明できるかもしれませんが、次のユーザーが状態変更を行うために必要なデータを提供することはできません。これは、無条件の引き出しを可能にするという私たちの基準を満たしていません：最大で1人のユーザーが無条件の引き出しを達成できるかもしれませんが、他のユーザーはできません。
それに対して、マークル化されたデータ構造の修正された部分が契約スクリプトシグを介して公開される場合、例えば、マークルツリー内の兄弟ダイジェストの場合、次のユーザーはシステムの状態の理解を更新するために十分なデータを持ち、自分自身で無条件の引き出しを行うことができます。
この問題を回避する可能な方法は、契約がビットコインチェーンとは異なる出版媒体における公表の証拠を要求する場合です。ただし、セキュリティの保証はビットコインを介した場合よりも弱くなります。
最後に、txoutツリーとバランスベースのアプローチを組み合わせる方法について注意してください。操作されるデータ構造がtxoutツリーである場合、出力を使って新しい資金を追加することでtxoutツリーに資金を追加することができます。ただし、追加された資金が実際にtxoutツリーに追加されたことを検証する契約スクリプトが必要です。同様に、資金は通常のtxoutツリーに利用可能なすべてのメカニズムによって削除することもできます。Advanced Arkはこの種のスキームの例です。
失敗データ比率
L2は、敵対的な状況で相互作用の要件を追加することでスケーリングを実現します。ほとんどの場合、これはプロトコル内の正直な参加者がトランザクションをマイニングするための締め切りを持っていることを意味します。締め切りに間に合わない場合、資金が盗まれる可能性があります。
すべての分散（および集中）型ブロックチェーンの最大ブロック容量は技術的な制約によって制限されています。ビットコインでは、ブロックサイズの最大値は、ビットコインが基本的に時間のほぼ100％で容量制限に達していることを意味します。ビットコインマイニングはオークションシステムとして機能し、ブロックスペースを最も高く入札する人にオークションで提供します。したがって、実際には需要が増減するにつれてトランザクションがマイニングされるための最低料金率が上下します。
手数料率は、常にL2の経済性と故障モードを考慮に入れます。たとえば、Lightningでは、オンチェーンで利益を上げるには小さすぎる「ダストサイズ」のHTLCは、大規模なHTLCとは異なるセキュリティモデルを使用します。Lightningプロトコルはまだこれを適切に実装していませんが、理論的には、このしきい値は、上下する手数料率に基づいて動的であるべきであり、理想的には、手数料率に基づいて特定のコミットメントトランザクションにHTLCが存在するかどうかを当事者が選択できるところまでです。
Lightningでは、洪水や略奪など、この状況を意図的に引き起こすさまざまな攻撃が提案されています22マスエキシット攻撃23. ビットコインブロックチェーンの容量はすべてのユースケースで共有されているため、異なるL2システム間での攻撃も可能です。たとえば、Arkでの大規模な退出を誘発して、ライトニングチャネルから利益を得ることができます。
複数のユーザー間でUTXOを共有するL2は、障害発生時の最悪の場合のブロックスペースの需要が比例して高くなるため、本質的にこれらの問題を悪化させる可能性があります。この記事を書いている時点では、Lightning で多数のチャネルを一度に閉じなければならないような大規模な障害は実際に見たことがありません。UTXO共有スキームでさらに限界を押し広げる前に、Lightningとそのユーザーあたり約1UTXOのスケーリングで追加の運用経験を積む必要があるという正当な議論があります。
第二に、新しいUTXO共有スキームが広く採用される前に、ブロックスペースの需要が高い場合の攻撃の潜在的な収益性について慎重な調査を行う必要があります。例えば、Arkのように、ASPが他の当事者よりもはるかに少ないブロックスペースで資金を償還できるシステムでは、意図的に高い手数料率をトリガーし、一方的に利益が出ることができない資金を差し押さえることは、収益性の高い詐欺であり、真のL2システムの両方の条件に違反している可能性があります。
コンセンサスのクリーンアップ
初期のBitcoinプロトコルには、特に、スクリプトDoS攻撃、タイムワープ攻撃、マークルツリーの問題など、Satoshiが間違えたことがいくつかあります。以前にも、時間ベースのnLockTimeの評価に切り替えるなど、ソフトフォークで他のコンセンサスバグが修正されています（重複txidの問題を修正しようとしているなど）。
最新のソフトフォークであるタップルートは、相当な時間をかけて展開されるという比較的議論のあるプロセスを経ています。新しいタイプのL2に対して新しいオペコードやその他の機能を有効にする前に、コンセンサスクリーンアップソフトフォークを先に行うことの理由は、比較的議論のないソフトフォークを実装する意欲の広がりをより詳しく知ることができるということです。これはおそらく誰にとっても利益のあるものだと言えます。
ソフトフォークに依存するレイヤー2のテスト
開発者は、実際にソフトフォークが起こるのを待つ必要はありません。Arkの開発者が使用している特に洗練されたアプローチの1つは、アイデアをテストするためのものです。契約なしのArkは、予め署名されたトランザクションを使用して必要な契約をシミュレートするためのものです。これにより、実際のBTCを使用してアイデアをテストし、Arkが契約を使用して達成することが期待される同じ信頼性を持つメインネット上で行うことができます。そのトレードオフは、契約を持たないArkはすべての当事者がオンラインでトランザクションに署名する必要があるということです。clArkは実際のBTCと連携するため、インタラクティブなトレードオフを許容できる特定のユースケースのために製品として使用するのに十分役立つことが証明されるかもしれません。
より単純なアプローチは、単に特定の当事者が契約が防止するアクションを行えないというふりをすることです。たとえば、提案されたプロトコルがCTVを使用して、トランザクションツリーでtxoutツリーが使用されることを強制する場合、CTVの各使用はNOPまたはCheckSigで置き換えることができます。実際にはtxoutツリーは実際には強制されていませんが、ツリーと各当事者との相互作用するコードのすべてと、NOPとCheckSigが標準スクリプトで許可されているため、プロトコルは実際の資金を使用して本番ネットでテストできます。
ソフトフォークの可能性
今後の方針は何ですか？ ここでは、私たちが分析したすべての主要なL2スキームと、これらのL2スキームを成功させるために有用なソフトフォーク（U）または必須（R）であるものを示します。 上記で説明したように、OP_CAT（およびOP_CATを含むScript Revival）は、OP_ExpireおよびFee Sponsorshipを除いて、このリストの他のすべてのソフトフォークをエミュレートできるため、プロジェクトのニーズが他のソフトフォークによって直接効率的に満たされる場合、OP_CATを含めません。
また、提案されているマークルツリー操作オペコードもすべて除外します。これらはすべてニッチで、ユースケースに特化しすぎているため、現時点では採用される可能性が高くありません。これらのオペコードが有用である限り、OP_CATやスクリプトリバイバルを介してその効果を実装することは、採用への道がはるかに高いです。
ここではCTVが明らかに勝者であり、SIGHASH_ANYPREVOUTがそれに続きます(OP_Expireは代替のサイクリング修正であるため、多くのことに役立ちますが、必須ではありません)。CTVが勝つのは、「支出トランザクションがこのテンプレートと一致することを確認する」というデザインパターンに多くのことが当てはまるからです。OP_CAT工事でもCTVを効率的に活用できます。
OP_CATとは異なり、CTVは特定の場合においてアウトオブバンドの手数料支払いを奨励するという意図しない結果のリスクをほとんど引き起こすことはありません。これは理想的ではありませんが、広く支持される代替案は誰も提案していません。
私の個人的なおすすめは、コンセンサスクリーンアップのソフトフォークを行い、その後にCTVを行うことです。
免責事項：
この記事は[から転載されました。ピータートッド], オリジナルタイトル『イーサリアムのロードマップはオフトラックですか？』を転送します。すべての著作権は元の著者[petertodd]に帰属します。この転載に異議がある場合は、お問い合わせください。Gate Learn(ゲート・ラーン)チームが迅速に対応します。
免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
記事の翻訳は、Gate Learnチームによって他の言語に翻訳されます。特に記載がない限り、翻訳された記事の複製、配布、または盗作は禁止されています。
บทความที่เกี่ยวข้อง
暗号通貨における完全に希釈された評価（FDV）とは何ですか？
スマートマネーコンセプトとICTトレーディング