Kanał Lightning ma dwa salda, których suma jest ograniczona pojemnością kanału. Dostępne saldo lokalne tworzy płynność wychodzącą, a dostępne saldo zdalne — przychodzącą. Rezerwy, opłaty transakcji commitment, oczekujące HTLC, reguły kanałów i dostępna pojemność każdego przeskoku decydują, czy konkretna kwota rzeczywiście przejdzie trasą.
Pojemność kanału to bitcoin zablokowany w wyjściu finansującym. Płynność stanowi tylko część dostępną obecnie w jednym kierunku. Kanał o pojemności 1 000 000 sats może zatem mieć niemal wszystko po jednej stronie i nie przenieść dużej płatności w przeciwnym kierunku. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Płynność wychodząca to kwota, którą lokalny węzeł może wysłać kanałem po uwzględnieniu rezerw protokołu, obowiązku pokrycia opłaty transakcji commitment i oczekujących HTLC. Maleje przy płatności lub przekazywaniu na zewnątrz, a rośnie, gdy wartość napływa od partnera. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Płynność przychodząca to kwota, którą partner może wysłać do lokalnego węzła. Jest niezbędna do odbioru przez ten kanał, ale zmiana żądania płatności jej nie tworzy. Musi znajdować się w saldzie zdalnym albo pochodzić z operacji zarządzania płynnością. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Płatność trasowana udaje się tylko wtedy, gdy każdy wybrany przeskok ma wystarczającą dostępną płynność we właściwym kierunku i akceptuje HTLC zgodnie z regułami opłat, kwotą minimalną i maksymalną oraz ograniczeniem czasu CLTV. Jeden wyczerpany kanał może zablokować trasę, która poza tym ma dobre połączenia. [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]
channel_reserve_satoshis, opłaty transakcji commitment, anchor outputs, reguły dust, max_htlc_value_in_flight_msat, max_accepted_htlcs i już oczekujące HTLC mogą zmniejszyć kwotę dostępną dla nowej płatności. Saldo portfela, pojemność kanału i kwota możliwa do natychmiastowego przesłania trasą są więc trzema różnymi liczbami. [BOLT #2 — Peer Protocol for Channel Management]
BOLT #7 pozwala ogłosić kanał i jego reguły przekazywania. Pojemność można ustalić z wyjścia finansującego zidentyfikowanego w łańcuchu; nie ujawnia to prywatnego podziału sald. Nadawca szacuje trasę na podstawie własnych informacji, wcześniejszych wyników i prób płatności. Publiczny eksplorator nie potwierdzi, że wybrana trasa właśnie teraz przeniesie konkretną kwotę. [BOLT #7 — P2P Node and Channel Discovery]
Rozliczona płatność przesuwa saldo w każdym użytym kanale: po stronie nadawcy płynność wychodząca maleje, a przychodząca rośnie; na drugim końcu zmiana jest odwrotna. Płatność rozdziela istniejącą pojemność, lecz nie zwiększa jej sumy. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Węzeł przekazujący potrzebuje dla tego samego HTLC płynności przychodzącej w jednym kanale i wychodzącej w kolejnym. Duża łączna liczba sats nie wystarcza, jeśli znajdują się w niewłaściwych kanałach lub po niewłaściwych stronach. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Otrzymane płatności, równoważenie okrężne, otwieranie lub zamykanie kanałów, swapy i splicing mogą przesuwać płynność. Różnią się opłatami, śladem w łańcuchu, czasem, zaufaniem do kontrahenta i ryzykiem niepowodzenia; żadna metoda nie tworzy darmowej płynności. Płatność wieloczęściowa może połączyć trasy, ale nadal wymaga wystarczającej łącznej pojemności kierunkowej. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]
Na własnym węźle sprawdź lokalne i zdalne salda każdego kanału, rezerwy, oczekujące HTLC i zapas na opłaty, a potem przetestuj planowaną kwotę. Zapisz kierunek, wielkość, czas i implementację: płynność zmienia się po każdej płatności i nie jest trwałą oceną całej sieci. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. Do tego hasła prowadzą również odsyłacze z Payment Channel, Lightning Routing, Zmienność, Kapitalizacja rynkowa.