チャンネルスプライシングの簡単な説明

「スプライシング」の核心は単純な概念であり、ライトニング チャネルのサイズを変更する機能です。しかし、時間が経つにつれて、Lightning チャネルのサイズを変更できるこの機能により、多くの場合予期せぬ追加の利点がもたらされ、Lightning ネットワークのパフォーマンスが根本的に向上することがますます明らかになりました。

チャネル スプライシングは、次の 2 つの側面で改善をもたらします。

ユーザー指向の改善

最初の側面は比較的簡単に説明できます。ビットコイン ウォレット アプリはたくさんありますが、それは確かに優れています。しかし、これらの開発者が独自のアプリを開発する場合、問題に遭遇します。このアプリはビットコインウォレットにするべきか、ライトニングウォレットにするべきか?

ほとんどのウォレットはどちらかを選択しますが、より野心的なウォレットは両方を選択する場合もあります。より根本的な観点から言えば、もちろん両方を行うことが最善の解決策です。

しかし、これには問題が生じます。これらのウォレットには「2 セットの残高」があり、1 つは (「オンチェーン」) ビットコイン残高、もう 1 つはライトニング チャネルのビットコイン残高です。あなたが初心者をビットコインに誘導したことがあるかどうかは知りませんが、言えるのは、2 セットの残高があると、初心者ユーザーは混乱する可能性があるということです。経験豊富なビットコイナーにとっては問題ありませんが、私たちは誰もがビットコインを使用できるようにしたいと考えています。

この「2 セットの残高」問題は設計上の問題ではなく、2 つのモデル (オンチェーン ファンドとライトニング チャネル) は根本的に異なるため、「1 セット」にすることはできません。そうしないと、ユーザーに新たな問題が発生します。 : 更新 長い支払い遅延や法外な手数料。

そして、チャネルスプライシングがネットワークに実装できれば、秘密兵器となり、「残高セット」ウォレットが可能になります。チャンネルスプライシングにより、これら 2 つのバランスを低コストで相互運用可能 (相互に変換) できるからです。

バックエンドの流動性の向上

2 番目の側面であるバックエンドの流動性の増加は理解するのが難しいかもしれませんが、ライトニング ネットワークに対してより重大な影響を及ぼします (「残高セット」アプリと比較して)。

ライトニング ネットワークは、ネットワーク上に点在する多くの「マイクロ」バンクで実行されます。これらの銀行が提供するサービスは 1 つだけです。それは、特定の方向にお金を移動することです。

従来の銀行業務には、少数の「本物の」銀行を信頼できるネットワークに承認する巨大な「ハブ」銀行が必要です。しかし、ライトニング ネットワークはその逆です。なぜ誰もが自分の銀行を開設できるようにしないのでしょうか?相互に通信できる多数の小規模銀行は「分散型銀行」になれるでしょうか?十分な数の人々がこれを実行すれば、最終的には中央銀行と同じくらい信頼できるもの、あるいはそれ以上に信頼できるものを作成できるでしょう。

これは実際に起こりました。ライトニング ネットワーク内の「マイクロバンク」の数は常に増加しており、まもなく米国の 5,000 をはるかに上回る 100,000 のマイクロバンクが存在することになります。

これらのマイクロバンクは、取引をルーティングするために互いに競合するため、最も安価なサービスを提供します。このような銀行が支払いをルーティングするには、ビットコインの「ライトニング アカウント」のいずれかにある程度の資金が保管されている必要があります。

これらのマイクロバンクは、取引をルーティングするために互いに競合するため、最も安価なサービスを提供します。このような銀行が支払いをルーティングするには、ビットコインの「ライトニング アカウント」のいずれかにある程度の資金が保管されている必要があります。

具体的な数字をいくつか挙げてみましょう: 成功しているライトニング バンクは通常、100 個のライトニング アカウントを維持しています。TA はこれらのアカウント間で継続的に資金を移動し、次のユーザーがどの方向に支払いを開始する必要があるかを予測する必要があります。彼らがたまたま口座残高が 100,000 サトシの「サリーのサンドイッチ ショップ」に向かう途中にいた場合、あなたがサリーからサンドイッチを購入したいときに、支払いのルーティング先として彼らが選ばれる可能性があります。

さて、これらのマイクロバンクの 1 つが 100 の口座を管理し、消費者の行動を推測するために常に口座間でお金を移動していると想像してください。これはなかなか難しいですね！なぜなら、実際のところ、人々の行動は非常に予測不可能であり、あなたと同じことをしようとする競争相手がたくさんいるからです。

では、チャネルのスプライシングはこれとどのような関係があるのでしょうか?そうですね、これらの口座間での資金の移動には費用がかかります。実際には、これらの電光石火銀行は定期的に口座を閉鎖したり開設したりする必要があります。また、予期せぬ需要が生じた場合にライトニング ネットワークに展開できる「予備」として資金を保持しておく必要もあります。

チャネルのスプライシングにより、費用のかかる口座の閉鎖と開設の必要性と、使用されていない「準備金」資金を維持する必要性の両方が排除されます。これにより、これらのマイクロバンクの運営コスト、複雑さ、遊休資本の課題が大幅に軽減されます。チャネル スプライシングは、（可能な限りコスト効率を高めながら）「Lightning アカウント」間で資金を直接転送できるようにすることで、これらすべてを実現します。さらに良いことに、チャネルのスプライシングにより、これらのマイクロバンクが独立した状態を維持できるようになり、いわゆる「集中流動性プロバイダー」に依存しなくなるため、ネットワーク全体が強化されます。

これは、Lightning マイクロバンクを運営している人々にとって非常にエキサイティングなことであり、もちろん、あなたのような Lightning Network ユーザーにとっても同じはずです。これらのマイクロバンクがより効率的に運営できれば、コスト削減は当然、より安価な手数料とより確実な支払いという形でユーザーに還元されることになる。

チャネルスプライシング技術の概要

チャネルのスプライシングとは、ライトニング チャネル (チャネルの資金調達 UTXO) 内の資金を新しい「スプライスされた」UTXO に移動することを指します。具体的な操作は非常に簡単です。2-of-2 マルチ署名トランザクションに署名して、資金を新しい場所に移動します。ただし、このプロセスをトラストレスに保つのはそれほど簡単ではありません。

元の資金提供された UTXO および子 HTLC トランザクションを実際に移動する前に、新しい「接続された」UTXO 用にコミットメント トランザクションを再構築する必要があります。

ただし、コピーしたプロミス状態を新しいチャネルに再作成する前に、現在のチャネルの状態がオンザフライで変更されないことを確認する必要があります。そこで、「SomeThing Fundamental is Underway」（略称「STFU」）と呼ばれる新しいライトニング状態を導入しました。

STFU は、現在のチャネルのコミットメント ステータスの変更を一定期間禁止します。

次に、チャネルに参加している 2 つのノードは、interactive-tx プロトコルを使用してトランザクション ネゴシエーションを開始します。各当事者は、自分の順番が来たときに入力と出力の両方を追加できます。現在のチャネルの資金調達 UTXO は、交渉されたトランザクションへの入力として追加されます。

双方とも、別のチャネルを開いたり、別のチャネルのスプライシングを処理したりするなど、無関係なアクティビティのために追加の入力と出力を自由に追加できます。これらすべてのアクティビティが 1 つのトランザクションに結合されます。

トランザクションの交渉と構築が完了した後、両当事者は最終的なトランザクションを検証し、トランザクションの残高が期待どおりであることを確認し、マイナーに妥当な金額の手数料を支払います。次に、取引に署名し、相手方に署名を渡します。

トランザクションの交渉と構築が完了した後、両当事者は最終的なトランザクションを検証し、トランザクションの残高が期待どおりであることを確認し、マイナーに妥当な金額の手数料を支払います。次に、取引に署名し、相手方に署名を渡します。

トランザクションがブロードキャストされた後、双方はトランザクションが 6 つのブロック確認を受信するのを待ち、その後スプライシングは「完了」したとみなされます。現時点では、元のチャネルのステータスを削除し、結合されたチャネルのステータスのみを考慮することができます。これにより、データベース容量を大幅に節約できます。

(翻訳者注: ここでの説明は大まかすぎます。両当事者の既存のチャネル UTXO が UTXO A であり、形成したい接続されたチャネル UTXO が UTXO B であると仮定します。まず、両当事者は UTXO 用のチャネル UTXO を構築する必要があります) B. コミットされたトランザクションは、新しいチャネルの最初の状態として使用され、これはトラストフリーの保証でもあり、その後、双方が署名して UTXO B のトランザクションを生成し、それをブロードキャストします。UTXO B が十分なブロック確認を取得する前に、元のトランザクションは、チャネルは引き続き実行され、各当事者は元のチャネルのステータスを更新する場合、新しいチャネルのステータスも更新する必要があります。UTXO B が十分なブロック確認を取得すると、元のチャネルのステータスを更新できなくなります。元のチャンネルに関連するデータを削除します。これにより、チャンネルの通常の動作に影響を与えることなくチャンネル サイズを変更できます。)

チャネルスプライシングの実装方法

Lightning 実装をスプライシングをサポートしていない状態からスプライシングをサポートする状態に移行するには、多くの手順があります。

まず、チャネル状態で資金詳細の上書きを許可するか、または結合されたチャネル状態を完全に新しい状態として扱うかを決定する必要があります。どちらのアプローチも機能しますが、どちらがより理想的かは、実装がチャネル状態をどのように構築するかによって異なります。

複製されたチャネル状態の 2 セットの利点は次のとおりです。

複製されたチャネル状態の 2 セットの欠点は次のとおりです。

チャネル状態を 1 つだけ持つことの利点:

チャネル状態が 1 つだけあることの欠点は次のとおりです。

どちらのアプローチを採用する場合でも、チャネル ID と短いチャネル ID を管理するには、特にそれらをキーとして使用する場合、コード全体で処理する必要がある追加の作業が必要になります。

特定のコード ベースについて、それぞれのアプローチの長所と短所、つまりリファクタリングの難しさとバグが混入するリスクの両方を考慮する必要があります。

次に、再利用可能な対話型トランザクションのビルディング ブロックが必要になります。このモジュールは、すべての TX_ADD_INPUT/TX_ADD_OUTPUT タイプのメッセージを処理します。このモジュールは二重資金調達をサポートするためにも必要です。そのため、多くの実装では二重資金調達用にこのようなモジュールを開発しています。

このモジュールは、将来の「閉じるためのスプライス」や、場合によっては他の Lightning Network 仕様の追加にも役立ちます。

インタラクティブ取引プロトコルは双方向の資金調達バリアントと非常に似ていますが、いくつかの違いがあります。このようなモジュールをさまざまなシナリオで実行できるように、開発時にはこれらの違いに留意してください。

次の自然なステップは、「STFU」ロジックを実装することです。多くの人は、STFU プロトコルが想像よりも複雑であると感じています。これは、STFU メッセージが実際には STFU モードの要求であるためです。 「STFU」が返されない限りアクティブになりません。

次の自然なステップは、「STFU」ロジックを実装することです。多くの人は、STFU プロトコルが想像よりも複雑であると感じています。これは、STFU メッセージが実際には STFU モードの要求であるためです。 「STFU」が返されない限りアクティブになりません。

相手が HTLC の追加やコミットされたトランザクションの更新など、他の作業で忙しい場合は、現在の操作が完了するまで STFU に応答しません。

この記事の執筆時点では、チャネル スプライシングのみが STFU モードを使用していますが、これは将来変更される可能性があります。したがって、STFU モジュールを開発するときは、その将来の用途について検討することをお勧めします。

STFU モードに関しては、特別な考慮事項がいくつかあります。双方が同時にチャネル スプライシングを初期化したいという状況はまれです。このような複雑な状況に正しく対処することを忘れないでください。

初期化では、一般的に、入力と出力から構成される PSBT (Partially Signed Bitcoin Transaction) を処理する必要があります。ユーザーは、相対的なチャネル サイズの変更量だけでなく、このトランザクションに入力と出力を追加することもできます。 splice と splice_ack を送信するには、相対的な量の変更を送信する必要があります。両方の当事者が変動量を提供できるため、受信側に PSBT 変動を警告するプラグインを必ず開発してください。