Lightningの流動性

AnnaとPavelは、容量1,000,000 satのチャネルを持っています。satはsatoshiの略で、Bitcoinのチェーン上での最小単位です。単純化して、Annaの持ち分を800,000 sat、Pavelの持ち分を200,000 satとしましょう。まずは仕組みを理解するため、予備資金、手数料、処理中の支払いは考えません。AnnaがPavelへ送るときは自分側の資金を使い、Pavelから受け取るときは彼の側の資金を使います。そのため、総容量が100万でも、PavelはこのチャネルでAnnaに300,000 satを送れません。お金が消えたのではなく、その支払いに合う配分になっていないのです。 [1] [3]

送金側の流動性は、自分から外へ支払うために使える金額です。この例ではAnnaの800,000 satが出発点ですが、実際の上限は予備資金、手数料、処理中の支払いによって通常はもっと低くなります。Pavel以外へ送る場合も、最初はAnna自身のいずれかのチャネルを通ります。ノードはチャネルを管理し、Lightning決済を処理するプログラムです。その先のノードは、それぞれ次の段階に使う資金を持っている必要があります。チャネル外にbitcoinを持っていても、送金側の流動性が自動で増えるわけではありません。ウォレットは適切な方法で、その価値をLightningへ移す必要があります。 [1] [3]

受取側の流動性は、相手がこちらへ送れる金額です。Annaがチャネルを開き、ほぼ全額を自分が持っているなら、送りやすい一方で受け取れる余地はわずかです。新しい支払い請求を作っても配分は変わりません。相手側に使える残高があるチャネルが必要です。ウォレットによってはサービス提供者を通じてこれを用意し、複雑な処理を利用者に見せませんが、手数料がかかることもあります。受け取れる容量は、Annaがすでに持っている追加の財産ではありません。これから支払いを受け取れる余地です。 [1] [3] [5]

AnnaがPavelへ100,000 satを支払うとします。単純化した例では、残高はAnnaが700,000 sat、Pavelが300,000 satになります。容量は1,000,000 satのままです。Annaは送れる額が減る代わりに、受け取れる額が増えます。Pavelはその逆です。複数のチャネルがある場合、変わるのはその支払いが実際に使ったチャネルです。方向は常に重要であり、朝の流動性の数値が、夜にも送れる金額を示すとは限りません。 [1] [3]

離れた相手への支払いは、複数のチャネルを順に通ります。それぞれに、正しい方向の十分な流動性が必要です。後続の段階で払う手数料分も含まれます。一か所でも通せなければ、ほかの容量が大きくてもその経路は失敗します。ウォレットは別の経路を試したり、対応していれば支払いを分割したりできますが、不足する資金が生まれるわけではありません。金額だけでなく、期限も確認されます。HTLCは、特定の秘密を知っていることを示すと成立する条件付き支払いです。CLTVに関係するルールは期限をブロックで定めます。各段階の期限に差を設けることで、中継が止まっても、中継者がBitcoinのチェーン上で決済する時間を確保します。 [1] [2]

中継者は一つのチャネルで受け取り、別のチャネルで対応する支払いを送れなければなりません。残高の合計が大きいだけでは不十分です。資金が自分のものであっても、必要な経路とは別のチャネルにあれば使えないことがあります。最初のチャネルには受取側、次のチャネルには送金側の流動性が必要です。この二つを結び付けるのがHTLCの条件です。支払いの成立は特定の秘密の提示と時間のルールに従うため、中継者は前の参加者が後で払うという約束だけに頼るわけではありません。 [1] [3]

送金と受け取りは自然に流動性を変えます。複数チャネルの運営者は循環的なリバランスも使えます。自分からある経路へ送り、別の経路で自分に戻すことで、自分のチャネル間の残高を調整します。Swapはチェーン上の資金とLightningの資金を交換する方法で、逆方向もあります。Splicingは、対応するチャネルの資金を、通常の閉鎖と再開設を経ずに変更する仕組みです。別のチャネルを開く選択肢もあります。手数料、時間、チェーン上の記録、信頼の要件、失敗リスクは方法によって異なります。どれも新しいお金を作るものではありません。送りたいのか、受け取りたいのか、両方なのかに合わせて選びます。 [1] [4]

まず送金と受け取りのどちらの問題かを分け、ウォレットと相手ノードがオンラインか確認します。自分のノードでは、各チャネルの自分側と相手側の残高、予備資金、処理中の支払い、手数料を比べます。サービス側が管理するウォレットなら、表示される利用可能額の意味を確認しましょう。一度の失敗だけで資金を失ったとは言えません。途中の流動性不足、上限、一時的な障害かもしれません。少額の試験送金で分かるのは、その瞬間にその金額が通ったことだけで、以後すべての支払いを保証するものではありません。 [1] [3] [4]

ノード運営者は複数の制限を区別する必要があります。トランザクションの出力には、金額と、そのお金を使うための条件が記されています。channel_reserve_satoshisは予備として残す資金を表します。また、まだ完了していない条件付き支払いであるHTLCに資金が拘束されている場合もあります。以下の上限は、相手側から提示されるHTLCに適用されます。max_htlc_value_in_flight_msatはその合計額、max_accepted_htlcsは件数の上限です。msatはsatoshiの1,000分の1で、Lightning内部の計算に使われます。チャネルの種類によっては、閉鎖に使うcommitment transactionの手数料や、anchor outputsも関係します。これは、後続のトランザクションをつなぎ、取引のまとまり全体の確認手数料を引き上げるための特別な出力です。Dustのルールは、小さすぎてその取引に含めない出力を決めます。実際の上限は実装とチャネルの種類に即して計算し、共通の予備額を一律に引けばよいとは考えないでください。 [1] [6]

BOLT #7はチャネルの告知と支払い転送の方針を定めています。告知されたチャネルなら、資金を入れたチェーン上の出力と容量を調べられます。しかし、参加者間の現在の配分は分かりません。送信者は自分の情報、過去の結果、支払いの試行をもとに経路を選びます。現在の全残高を網羅した公開一覧があるわけではありません。そのため、エクスプローラーに大きなチャネルが表示されても、今その方向に自分の金額が通る証明にはなりません。 [2]