以前の科学普及記事では、支払いチャネル、マルチホップルーティング、HTLCなど、ライトニングネットワークに関連する核心概念について簡単に説明しました。
私たちは、ライトニングネットワークで送金を行うには、しばしば複数の中間ノードを経由してパスを構築する必要があり、中間ノードの可用残高は限られているため、最終的に支払いの成功率に影響を与えることを指摘しました。パス内のノードに十分な資金があることを確認し、ユーザー体験を向上させるために、いくつかの流動性管理ソリューションを通じて調整を行う必要があります。 しかし、流動性管理の問題を深く理解するためには、まずいくつかの基本概念を導入する必要があります。たとえば、ローカルバランスとリモートバランス（Local and Remote Balance）、入金容量と出金容量（Inbound and Outbound Capacity）などです。
過去に私たちは、ライトニングネットワークの基本構成要素はノードとチャネルであり、後者はビットコインネットワークに基づいて構築されたオフチェーンの 1 対 1 送金施設であると述べました。チャネルの初期化時に、双方は初期残高としていくらかのお金を転入します。あなたの側の残高は「ローカルバランス」と呼ばれ、相手方の残高は「リモートバランス」と呼ばれます。 ローカルバランスは、あなたが相手方に転送できる金額を決定し、あなたの支払い能力、つまり「出金容量」を制限します。リモートバランスは、相手方があなたに転送できる金額を決定し、あなたの「入金容量」、つまり受け取り能力を制限します。
参加する双方の残高はチャネルが閉じる前に頻繁に変わることができますが、二者の合計残高であるチャネルの総容量は変更できません。チャネルを完全に再起動するか、「チャネルスプライシング」を使用して資金を注入しない限り、変更できません。
（この図は、あなたとロバートのそれぞれの残高を示しています。あなたのローカルバランスは 5、リモートバランスは 3、チャネルの全体容量は 8 です）
上記の基本概念を理解した後、ライトニングネットワークにおける流動性管理が解決しようとしている問題を見てみましょう。下の図は簡略化されたノード接続図を示しており、あなた（左下隅）が LNTop というノードにのみ接続されていることがわかります。あなたのリモートバランスは 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 を直接転送し、後者は Y と Z にそれぞれ 0.4BTC を転送します。その後、Y と Z はそれぞれチャネル 2 とチャネル 3 であなたに 0.4BTC を転送し、あなたのローカルバランスを増加させます。こうして、あなたは十分な可転資金を持ち、大額の送金ニーズを満たすことができます。
上の図を観察すると、循環支払いの本質は、あなたが自分自身に送金し、異なるチャネル間で残高を移動させ、最終的に全体の残高配分をあなたの期待する結果に達成することです。 しかし、この方法だけでは、任意のチャネル内の双方の総残高を増やすことはできません。また、その実施には以下の仮定が必要です：X が Y、Z に対して十分な可転資金を持っていること。言い換えれば、循環支払いは通常、関連ノードが事前に一定の流動性を備えていることを要求します。
循環支払いはチャネル再バランスの考え方の一つの実現方法であり、再バランスのソリューションは実践の中で他の方法と組み合わせることもできます。たとえば、潜水艇スワップなどです。次に、** 潜水艇スワップ（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 などのプロジェクトチームとの積極的な協力の下、より適切な道を模索することになるでしょう。
📖 おすすめの読み物：