以前の科学普及記事では、支払いチャネル、マルチホップルーティング、HTLCなど、ライトニングネットワークに関連する核心概念について簡単に説明しました。
私たちは、ライトニングネットワークで送金を行うには、しばしば複数の中間ノードを経由してパスを構築する必要があり、中間ノードの可用残高が限られていることが多く、最終的に支払いの成功率に影響を与えることを指摘しました。パス内のノードに十分な資金があることを確保し、ユーザー体験を向上させるために、いくつかの流動性管理ソリューションを通じて調整を行う必要があります。 しかし、流動性管理の問題を深く理解するためには、まずいくつかの基本概念を導入する必要があります。たとえば、ローカルバランスとリモートバランス（Local and Remote Balance）、入金容量と出金容量（Inbound and Outbound Capacity）などです。
過去に私たちは、ライトニングネットワークの基本構成要素はノードとチャネルであり、後者はビットコインネットワークに基づいて構築されたオフチェーンの 1 対 1 送金施設であると述べました。チャネルが初期化されると、双方は初期残高としていくらかの資金を投入します。あなたの側の残高は「ローカルバランス」と呼ばれ、相手側の残高は「リモートバランス」と呼ばれます。 ローカルバランスは、あなたが相手にどれだけ送金できるかを決定し、あなたの支払い能力、すなわち「出金容量」を制限します。リモートバランスは、相手があなたにどれだけ送金できるかを決定し、あなたの「入金容量」、すなわち受け取り能力を制限します。
参加する双方の残高は、チャネルが閉じる前に頻繁に変わることができますが、二者の合計チャネル容量は変更できません。チャネルを完全に再起動するか、「チャネルスプライシング」を使用して資金を注入しない限り、変更はできません。
（この図は、あなたとロバートのそれぞれの残高を示しています。あなたのローカルバランスは 5、リモートバランスは 3、チャネルの全体容量は 8 です）
上記の基本概念を理解した後、ライトニングネットワークにおける流動性管理が解決すべき問題を見ていきましょう。下の図は簡略化されたノード接続図を示しており、あなた（左下隅）が LNTop の 1 つのノードにしか接続されていないことがわかります。リモートバランスが 3 であるため、最大で 3 ドルの送金を受け取ることができます。しかし、ソフィーがあなたに 1 ドルを送金しようとすると、中間ノードの LNTop に対する可用残高が不足しているため、失敗します（赤枠内、当該ノードの LNTop に対する出金容量は 0 です）。
チャネル容量は、ライトニングネットワークが初期段階で直面した深刻な問題の 1 つであると言えます。** もし流動性がネットワーク全体により均等に分布していれば、このような問題は効果的に軽減されます。この解決策は一般に「流動性管理」と呼ばれ、たとえば、レンタル市場（Lighting Pool）を通じてクライアントが流動性の豊富な複数のノードに接続できるようにしたり、必要に応じて新しいチャネルを開いたり閉じたりすること、またはチャネルスプライシングや再バランス（Channel Rebalancing）などの方法を導入し、オンチェーンまたはオフチェーンでチャネル内の残高を調整することが含まれます。
現在、一部のウォレットクライアントは自動化されたチャネル管理機能を提供しており、ユーザーの支払い行動やネットワーク状況に基づいてチャネルをスマートに管理し、送金に十分な流動性を確保しています。新しいユーザーがライトニングネットワークに接続したばかりのときは、「片方向注資」のモデルを採用することができ、これはチャネルの相手方にのみ資金を注入させ、自分はチャネル初期化時に資金を注入しないことで、ユーザーの経済的コストを軽減しますが、その代償として初期には外部への支払い能力 / 出金容量がありません。
以下では、ライトニングネットワークにおける流動性管理ソリューションの一般的な手法について、さらに詳しく説明します。まず、チャネルレンタルについて理解しましょう。このソリューションは主にノードの「入金容量」問題を解決します。 つまり、他の人があなたに送金したいとき、相手が成功裏に支払いパスを構築できるようにするためには、パスに含まれる各ノードに対して、十分な可用残高 / 出金容量を持つことが求められます。前述のパス失敗のシナリオは、特定の中間ノードが他のノードとのチャネルにおいて流動性が不足していることに起因しています。
チャネルを構築することはコストがかかります。なぜなら、参加者はしばしば一部の資金をロックする必要があり、機会コストが発生するからです。いわゆるチャネルレンタルは、市場的手段を通じてノードオペレーターが直接取引を行い、「レンタル」制度を通じて資金に余裕のあるノードが他のノードのためにチャネルを構築することを促進するという考え方です。 たとえば、あなたが商人であり、他の人から送金を受け取る必要があり、額面に高い要求がある場合、1 日の「受取能力」は 200BTC を超える必要があります。
そのため、あなたは Lighting Pool を通じて 4 つの大規模ノードと合意に達し、これらの 4 つのノードはそれぞれあなたのために 24 時間のチャネルを構築し、各々50BTC をロックし、あなたに 50BTC のリモートバランスを提供します。こうして、各チャネルであなたの受取能力は 50BTC に達します。誰かがあなたに送金する場合、これらの 4 つのノードの中から任意の 1 つを中間者として選んで支払いパスを構築できます。
（1ml.com では、複数の有名なライトニングネットワークノードオペレーターを見ることができます。これらのノードは資金に余裕があり、他のノードとの間に複数のチャネルを構築しており、流動性をレンタルすることで収益を得ることができます）
上記のレンタルプールに加えて、** 流動性広告（Liquidity Advertisement）** もあります。流動性提供者は、ライトニングノードのゴシップメッセージを使用して自分の価格やチャネルの持続時間を報告し、価格を受け入れるノードはそれに基づいてチャネルを開くことができます。このようなレンタルベースのソリューションは、通常、保証金制度と組み合わせて、一方が突然違約するのを防ぎます。
現在、Lighting Labs などのライトニングネットワーク開発者や Fiber は、片方向注資の下での流動性レンタルシナリオの最適化を試みています。 たとえば、Fiber は CKB のスマートコントラクト機能を基に流動性代付制度を導入する計画を立てており、指定された LSP サービスプロバイダーノードがユーザーとチャネルを構築し、一定期間ユーザーに無料で入金容量を提供してその受取ニーズを満たします。ユーザーがいくつかの資金を受け取った後、契約は自動的にコストを回収します。このようなシナリオに関連する流動性ステーキングメカニズムも議論されています。
一般的に、チャネルレンタルはノード間の接続を確立し、入金流動性を得る問題を解決するために使用されますが、次の ** チャネルスプライシング（Splicing）** ソリューションは、オンチェーン操作を通じて資金を注入 / 引き出し、チャネル内の双方の総残高を直接変更します。通常、チャネルの開設と閉鎖には 2/2 署名が必要で、参加者が共同で所有するオンチェーン資産を再分配しますが、初期のライトニングネットワークソリューションでは、チャネルが一度開かれると、閉じて再起動しない限り、チャネル内の総残高を変更することはできません。
チャネルスプライシングは後に提案された新しいソリューションで、既存のチャネルを閉じることなく、参加者の協力の下で、チャネル双方が共同で管理する UTXO をオンチェーンで再構成・更新することができます。たとえば、既存の資産に新しい資産を追加して参加者が共同で制御できるようにし、チャネル内の総残高を変更します。下の図はこの考え方を簡単に概説しており、左側は旧チャネルに対応するオンチェーン資産（UTXO1）で、アリスとボブがマルチシグで制御しています。その後、双方がチャネルスプライシングを開始し、別の資産（UTXO2）を追加して共同管理し、最終的にチャネル双方が共同で管理できる資産（UTXO3）の額が増加し、容量が増えます。
チャネルスプライシングは、チャネル内の過剰資金を減少させ、一時的に闲置されている資産をチャネルから移動させ、資金の利用効率を向上させるためにも使用できます。従来のチャネルを閉じて再起動する際には 2 回のオンチェーンインタラクションが必要ですが、チャネルスプライシングは 1 回のオンチェーン操作のみで済むため、コストを大幅に削減できます。チャネルスプライシングには明らかな利点がありますが、歴史的な理由からこのソリューションは完全には成熟しておらず、大規模な採用にはまだ時間がかかるでしょう。
チャネルスプライシングを理解した後、チャネル再バランス（Channel Rebalancing）の考え方を紹介します。これは、チャネルを閉じず、チャネル内の総容量を変更せずに（手数料を無視して）、異なるチャネル内のオフチェーン残高を調整する手段です。 あなたがライトニングネットワーククライアントを運営し、他のノードとの間に合計 3 つの支払いチャネルを構築したと仮定しましょう：
- チャネル 1：ノード X との間に構築、総容量は 1BTC
- チャネル 2：ノード Y との間に構築、総容量は 0.5BTC
- チャネル 3：ノード Z との間に構築、総容量は 0.5BTC
各チャネルの資金分布は次のとおりです：
- チャネル 1：あなたのローカルバランス：0.9BTC リモートバランス：0.1BTC
- チャネル 2：あなたのローカルバランス：0.1BTC リモートバランス：0.4BTC
- チャネル 3：あなたのローカルバランス：0.1BTC リモートバランス：0.4BTC
現在の問題は、チャネル 2 とチャネル 3 であなたの出金容量が不足しており、最大で相手に 0.1BTC しか送金できず、大きな送金のニーズを満たせないことです。一方で、チャネル 1 の出金容量は過剰で 0.9BTC に達していますが、短期間ではそのような多くの資金を使用することはできません。明らかに最善の方法は、チャネル 1 の余剰資金を他の 2 つのチャネルに移動させることです。したがって、あなたはチャネル 1 のローカルバランスから 0.4BTC をチャネル 2 に、0.4BTC をチャネル 3 に移動させることを計画しています。この効果を達成するには、2 つの ** 環状支払い（circular payment）** を完了する必要があります。
具体的な操作方法は上の図のようになります。あなたはノード X に 0.8BTC を直接送金し、ノード X はそれぞれ Y と Z に 0.4BTC を送金し、その後 Y と Z はそれぞれチャネル 2 とチャネル 3 であなたに 0.4BTC を送金し、あなたのローカルバランスを増加させます。こうして、あなたは十分な可用資金を持ち、将来の大きな送金ニーズを満たすことができます。
上の図を観察すると、環状支払いの本質は、あなたが自分自身に送金することです。異なるチャネル間で自分の残高を移動させ、最終的に全体の残高分配があなたの期待する結果に達することです。 しかし、この方法だけでは、任意のチャネル内の双方の総残高を増やすことはできません。また、実施には以下の仮定が必要です：X が Y、Z に対して十分な可用資金を持っていること、言い換えれば、環状支払いは関連ノードが事前に一定の流動性の備蓄を持っていることを要求します。
環状支払いはチャネル再バランスの考え方の実現手段の 1 つであり、再バランスのソリューションは実践の中で他の方法と組み合わせることもできます。たとえば、潜水艇スワップなどです。次に、** 潜水艇スワップ（Submarine Swaps）** を紹介します。このソリューションの核心的な考え方は、チャネルを閉じることなく、HTLC などの方法を利用してオンチェーンとオフチェーンの資金を交換することです。
最も単純な潜水艇スワップのシナリオは、オンチェーンでチャネルに資金を注入することです。アリスがボブとの間に 1 対 1 のチャネルを構築したと仮定しますが、しばらくするとアリスのローカルバランスはほぼ尽きてしまい、もはや外部に支払うことができなくなります。このとき、アリスはさらに資金を注入する必要があり、チャネルを閉じて再起動する必要がありますが、このチャネルはレンタルされたものであり、早期に閉じるのはあまり得策ではありません。では、どうすればよいでしょうか？
潜水艇スワップを利用すれば、プロセスは比較的簡単ですが、HTLC を利用する必要があります。まず、アリスはランダムな数 R を生成し、そのハッシュ H (R) を取得します。その後、アリスはオンチェーンでボブのアドレスに BTC を送信しますが、その解除条件は HTLC の制約を受けます。ボブはオンチェーンでこれらのビットコインを解除するために、H (R) に対応する原像 R を知っている必要があります。
ボブはオフチェーンのチャネル内でアリスと HTLC を通じて取引を行いますが、方向は逆になります：アリスは R を示さなければならず、その後にボブが支払ったお金を解除できます。アリスが R の値を示す限り、ボブはそれを使用してアリスがオンチェーンでロックした BTC を解除できます。その後、アリスのチャネル内のローカルバランスが増加し、オンチェーンの資産残高が等価に減少します（手数料を無視すれば）、基本的には 1 対 1 の置換です（上記では原理を説明するために、潜水艇スワップの通常の操作順序に厳密には従っていませんが、実際にはほとんどの場合、一方がオフチェーンで HTLC を作成し、もう一方がオンチェーンで対称的な HTLC を作成します）。
上記のシナリオは、オンチェーン資産をオフチェーン残高に置き換えるために主に使用されます。アリスとボブの操作方向を調整すれば、引き出し操作に切り替え、オフチェーン残高をオンチェーン資産に変えることができます。潜水艇スワップは HTLC と時間ロックなどの組み合わせ機能を利用して安全性を確保します。 たとえ相手が途中で放棄して協力しなくても、HTLC にロックされたお金は安全です。なぜなら、相手は HTLC を解除するための鍵を知らないからです。時間ロックが期限切れになると、あなたは元本を取り戻すことができます。
ただし、上記のシナリオでは、あなたの元本は盗まれませんが、一方がオンチェーンで HTLC を作成して資金をロックする必要があるため、必然的に手数料の損失が発生します。相手が放棄すれば、あなたに一定の影響を及ぼします。これらの問題を解決するために、潜水艇スワップには前払い金、評判システムなどの罰則手段がしばしば組み合わされます。
要約すると、潜水艇スワップの核心的な考え方は、オンチェーン / オフチェーン資産の柔軟な交換を実現することです。 チャネル再バランスの考え方に沿って、より優れた流動性調整手段を実現できます。ここで簡単な例を挙げます：
あなたがノードを運営し、複数のチャネルを開設していると仮定します。いくつかのチャネルのローカルバランスが余剰で、他のチャネルのローカルバランスが深刻に不足しており、あなたの支払い能力に影響を与えています。あなたはチャネルを閉じることなく、各チャネルの資金分布を平衡させたいと考えています。潜水艇スワップは良い解決策となる可能性があります。あなたはローカルバランスが過剰なチャネルを選択し、潜水艇スワップを通じて資金をオンチェーンに移動し、その後、潜水艇スワップを通じてオンチェーン資産を目標チャネルに注入します。このプロセス全体で、いかなるチャネルも閉じる必要はありません。
ただし、上記の知識点をまとめると、潜水艇スワップとチャネルスプライシング、チャネルレンタルなどの流動性調整操作はすべてオンチェーンで操作の痕跡を残し、手数料が発生します。このような操作を頻繁に行うと、ユーザーの経済的コストや UX に圧力がかかります。ビットコインのライトニングネットワークは BTC メインネットに依存しているため、頻繁にオンチェーンインタラクションを行うことは現実的ではありませんが、CKB に基づく Fiber はこのような圧力が相対的に少なく、流動性管理の体験がよりスムーズです。しかし、いずれにせよ、ライトニングネットワークと Fiber は新しい流動性解決策の深い研究を行っており、将来的には Mercury Layer などのプロジェクトチームとの積極的な協力のもと、より適切な道を模索することになるでしょう。
📖 おすすめの読書：