Inbound Liquidity は、Lightning ノードが自分のチャネルを通じて支払いを受け取る余力です。Lightningはビットコインを素早く送るための仕組みです。ノードは支払いを処理するソフトウェアで、チャネルは資金の配分を取り決めたノードどうしの接続です。受取余力の基礎になるのは、支払いによって自分側に移せる相手側の資金です。自分がすでに使える残高ではありません。チャネルの規則、処理中の支払い、送信者からの利用可能な経路によっても、実際の受取額は制限されます。
ペトルはカフェを営み、Lightning Network で支払いを受け付けています。支払いを処理するソフトウェアであるノードに残高が表示されているのに、客が支払えません。原因の一つに、受取側の流動性不足があります。支払いチャネルは、預けたビットコインの配分について二つのノードが結ぶ取り決めです。ペトル側の残高を local balance、相手側を remote balance と呼びます。受け取りでは相手側からペトル側に価値が移るため、相手側に移せる資金が必要です。ただし remote balance は相手のものです。受取能力を確保しても、ビットコインを贈られたわけでも、売上を得たわけでもありません。 [1] [6]
容量が 1000000 sat のチャネルを考えます。Sat はビットコインの小さな単位 satoshi の略です。ペトルの local balance が 800000 sat、相手の remote balance が 200000 sat なら、大まかな受取余力は 200000 sat です。ペトルが 100000 sat を受け取ると、自分側は 900000 sat、相手側の残りは 100000 sat になります。入金で資金は増えても、次の受取余力は減ります。分かりやすくするため、ここでは準備金、手数料、後で説明する処理待ちの HTLC 支払いを省いています。ペトルが相手への初期移転なしに新しいチャネルを全額出資した場合、主に得られるのは送信能力です。開設が承認されても、この向きは逆転しません。 [1] [2]
売上の多い日にはペトル側の資金が増える一方、使ったチャネルの受取余力は減ります。残高が増えるほど、次の支払いを受けにくくなる場合もあるのです。自分で運用するなら、使えるチャネル、想定金額、処理中の支払い、流動性を補う費用を確認する必要があります。一部のウォレットは作業を代行しますが、仕組み自体は変わりません。失敗した支払いがノードに届く前に止まり、ペトルが試行に気づかないこともあります。発行済みインボイスや過去の容量表示は、着金の証明にはなりません。 [6]
ペトルが Lightning で仕入先に支払うと、使ったチャネルの local balance が減り、remote balance が増えます。これにより、将来の受け取りの余力を作れます。Loop Out も似た働きをします。支払い層をまたぐ交換であるスワップを使い、Lightning から価値を送り、オンチェーンのアドレスでビットコインを受け取ります。チャネルを閉じる必要はありません。Loop In は逆に、オンチェーンの資金を使える Lightning 残高に変えます。いずれもビットコインを新たに作りません。結果を比較する際は、ルーティング、スワップサービス、オンチェーン取引の手数料を含め、操作の完了も確認します。 [1] [4]
相手がペトルへのチャネルを出資して開く方法もあります。ペトルは受取余力を得ますが、相手の資金を贈られるわけではありません。Lightning Pool の文書では、こうした契約の市場を説明しています。bid は流動性を求める注文、ask は提供する注文です。リース期間はブロック数で表され、対価となるプレミアムやほかの手数料がかかります。ブロックは、ビットコインの公開取引履歴であるブロックチェーンに追加される取引のまとまりです。そのため期間はブロックの追加に応じて進み、正確な時間数が決まっているわけではありません。遠隔側の残高全体を購入するのではありません。また、期間中ずっと同じ額を受け取れるとも限りません。支払いで配分が変わるからです。契約終了後もチャネルが永続的に利用できるとは想定できません。 [1] [5]
ペトルが複数のチャネルを持ち、別の相手との間に受取余力を必要とすることもあります。Circular rebalancing、つまり循環型の再調整は、一つのチャネルからネットワークへ送り、別の自分のチャネルで同じ支払いを受け戻す方法です。送信側のチャネルは受取余力を増やし、受信側はそれを消費します。自分側の資金がチャネル間を移るだけで新しい資本は生まれず、ルーティング手数料もかかります。通れる経路が必要です。すべてのチャネルの相手側に資金がなければ、戻る支払いの入口がありません。循環型の再調整だけでは解決できません。 [1]
安全なチャネル運用のため、一部の資金は準備金として残す必要があります。また、HTLCという条件付きの支払い約束に、一時的に資金が充てられている場合があります。受取人は、合意された支払いハッシュが計算できる秘密値を提示することで資金を受け取れます。ハッシュはここでは条件を照合するための値です。支払いが失敗した場合、送った側は期限経過後に資金を取り戻す経路を利用できます。チャネル管理の仕様 BOLT 2 は、最小金額、同時に扱える HTLC の数、合計額も制限します。そのため remote balance 全体を次の支払いに使えるとは限りません。相手側残高をすべて足し、一律の準備金を引くだけでは不十分で、各チャネルの現在の状態が重要です。 [2]
支払いは通常、複数のノードを通ります。ペトルに受取余力があっても、その前の区間がオフラインだったり、資金不足だったりすれば届きません。BOLT 7 は、チャネルのある方向の転送条件を知らせる channel_update メッセージを定めています。手数料や htlc_maximum_msat、つまり個々の条件付き支払いの上限額が含まれます。単位の msat は satoshi の千分の一です。これは経路全体の現在の残高を保証しません。したがってペトルの受取余力の合計が、その額をどの送信者からでも受け取れる保証にはなりません。受取側の流動性は必要な条件の一つですが、それだけでは足りないのです。 [3]
理解を深めるには、この項目とあわせて次もお読みください Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. 次の項目からも参照されています Lightningの流動性, Lightning Routing, Lightning Address, Submarine Swap.