Inbound Liquidity to płynność przychodząca: możliwość przyjmowania płatności przez kanały węzła Lightning. Lightning służy do szybkich płatności bitcoinem. Węzeł to program, który je przetwarza, a kanały łączą węzły z uzgodnionym podziałem środków. Możliwość odbioru opiera się na środkach po stronie partnerów, które podczas płatności mogą przejść na twoją stronę. Nie jest to twoje saldo do wydania. Rzeczywisty odbiór ograniczają też zasady kanałów, trwające płatności i dostępna trasa od nadawcy.
Petr prowadzi kawiarnię i przyjmuje płatności w Lightning Network. Jego węzeł, program obsługujący płatności, pokazuje środki, ale klient nie może zapłacić. Jedną z przyczyn może być brak płynności przychodzącej. Kanał płatniczy to umowa między węzłami o podziale zdeponowanych bitcoinów. Część Petra to local balance, część partnera — remote balance. Odbiór płatności przesuwa wartość od partnera do Petra. Po stronie partnera musi więc być co przesunąć. Remote balance nadal należy do partnera: uzyskanie możliwości odbioru nie jest prezentem w bitcoinach ani już zarobionym przychodem. [1] [6]
Wyobraźmy sobie kanał o pojemności 1000000 sat. Sat to skrót od satoshi, małej jednostki bitcoina. Petr ma local balance 800000 sat, a partner remote balance 200000 sat. Przed uwzględnieniem pozostałych ograniczeń Petr może więc odebrać 200000 sat. Jeśli Petr odbierze 100000 sat, jego strona wzrośnie do 900000 sat, a partnerowi zostanie 100000 sat. Petr dostał pieniądze, lecz ma mniej miejsca na kolejne wpłaty. Dla przejrzystości pomijamy rezerwy, opłaty i oczekujące płatności HTLC, wyjaśnione niżej. Gdy Petr sam finansuje nowy kanał bez początkowego przekazania środków partnerowi, zyskuje głównie możliwość wysyłania. Samo potwierdzenie otwarcia nie odwraca tego kierunku. [1] [2]
W udanym dniu przybywa pieniędzy po stronie Petra, a możliwość odbioru w użytych kanałach maleje. Większe saldo może zatem oznaczać mniejszą zdolność przyjęcia następnej płatności. Przy własnej infrastrukturze trzeba śledzić użyteczne kanały, oczekiwane kwoty, płatności w toku i koszt uzupełnienia płynności. Niektóre portfele wykonują część tej pracy za użytkownika, ale mechanizm pozostaje. Petr może nawet nie zauważyć nieudanej próby: płatność może zatrzymać się przed dotarciem do jego węzła. Wystawiona faktura czy stary odczyt pojemności nie potwierdzają zapłaty. [6]
Kiedy Petr płaci dostawcy przez Lightning, local balance użytych kanałów maleje, a remote balance rośnie. Może to zwolnić miejsce na przyszłe wpływy. Podobnie działa Loop Out: poprzez swap, wymianę między warstwami płatności, wysyła wartość z Lightning i otrzymuje bitcoiny na adresie w blockchainie. Nie trzeba zamykać kanałów. Loop In działa odwrotnie, zamieniając środki w blockchainie w saldo do wydania w Lightning. Żadna operacja nie tworzy bitcoinów. Oceniając wynik, trzeba uwzględnić opłaty za routing, usługę wymiany i transakcję w blockchainie oraz sprawdzić, czy operacja się zakończyła. [1] [4]
Partner może również sfinansować kanał do Petra. Petr zyskuje możliwość odbioru, ale nie dostaje pieniędzy partnera w prezencie. Dokumentacja Lightning Pool opisuje rynek takich umów: bid oznacza zapotrzebowanie na płynność, ask — ofertę jej dostarczenia. Najem ma okres liczony w blokach i obejmuje premię oraz inne opłaty. Blok to grupa transakcji dodana do blockchaina, publicznej historii transakcji Bitcoin. Okres najmu zależy więc od pojawiania się bloków, a nie od dokładnej liczby godzin. To nie zakup całego zdalnego salda. Uzgodniony czas nie oznacza też, że przez cały okres będzie można odebrać tę samą kwotę: płatności zmieniają podział. Nie należy zakładać stałej dostępności kanału po zakończeniu umowy. [1] [5]
Petr może mieć kilka kanałów i potrzebować możliwości odbioru u innego partnera. Circular rebalancing, czyli wyrównywanie sald przez płatność wracającą do nadawcy, wysyła jego płatność do sieci jednym kanałem i sprowadza ją innym własnym kanałem. Kanał wysyłający zyskuje miejsce na odbiór, a odbierający je zużywa. Środki przesuwają się między jego stronami kanałów; nie powstaje nowy kapitał, a routing kosztuje. Potrzebna jest działająca trasa. Jeżeli brakuje środków po wszystkich zdalnych stronach kanałów, płatność nie ma którędy wrócić. Samo przesuwanie środków w ten sposób tego nie rozwiąże. [1]
Część środków musi pozostać rezerwą dla bezpiecznego działania kanału. Inne środki mogą być czasowo zaangażowane w HTLC, warunkowe zobowiązania płatnicze. Odbiorca może je odebrać, ujawniając tajną wartość, z której oblicza się uzgodniony hash płatności, czyli skrót służący do weryfikacji. Jeśli płatność się nie powiedzie, strona wysyłająca ma możliwość odzyskania środków po upływie terminu. BOLT 2, specyfikacja zarządzania kanałami, ogranicza też kwotę minimalną, liczbę jednoczesnych HTLC i ich łączną wartość. Całe remote balance może więc nie być dostępne dla kolejnej płatności. Nie wystarczy zsumować zdalnych sald i odjąć uniwersalną rezerwę: liczą się poszczególne kanały i ich aktualny stan. [2]
Płatność zwykle przechodzi przez kilka węzłów. Choć Petr ma możliwość odbioru, wcześniejszy odcinek może być niedostępny lub pozbawiony środków. BOLT 7 opisuje komunikaty channel_update, w których węzły ogłaszają warunki routingu dla danego kierunku kanału. Obejmują opłaty i htlc_maximum_msat, górny limit pojedynczej warunkowej płatności w msat, tysięcznych częściach satoshi. Nie obiecują aktualnego salda na całej trasie. Suma miejsca na odbiór u Petra nie gwarantuje więc przyjęcia tej kwoty od każdego konkretnego nadawcy. Płynność odbiorcy jest potrzebną częścią rozwiązania, ale nie jedyną. [3]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. Do tego hasła prowadzą również odsyłacze z Płynność Lightning, Lightning Routing, Lightning Address, Submarine Swap.