Płynność Lightning

Anna i Paweł mają kanał o pojemności 1 000 000 sat, czyli miliona satoshi — najmniejszych jednostek na łańcuchu Bitcoin. Wyobraźmy sobie uproszczony stan: Anna ma 800 000 sat, a Paweł 200 000 sat. Dla przejrzystości pomijamy na razie rezerwy, opłaty i płatności w toku. Anna może wysyłać Pawłowi środki ze swojej strony; odbierać od niego może tylko środki z jego strony. Paweł nie wyśle jej więc tym kanałem 300 000 sat, mimo że jego łączna pojemność wynosi milion. Pieniądze nie zniknęły. Są po prostu rozłożone w sposób, który nie pozwala na tę płatność. [1] [3]

Płynność wychodząca to kwota dostępna do wysłania od ciebie. W przykładzie jej podstawą jest saldo Anny wynoszące 800 000 sat, ale rzeczywiste maksimum zwykle obniżają rezerwy, opłaty i płatności w toku. Jeśli Anna płaci komuś innemu niż Paweł, pierwszy krok i tak prowadzi przez jeden z jej kanałów. Węzeł to program, który zarządza kanałami i przetwarza płatności Lightning. Kolejne węzły potrzebują własnych środków do dalszych kroków. Bitcoin trzymany poza kanałami nie zwiększa automatycznie jej płynności wychodzącej; portfel musi odpowiednim sposobem przenieść tę wartość do Lightning. [1] [3]

Płynność przychodząca to kwota, którą drugi uczestnik może wysłać do ciebie. Gdy Anna otwiera kanał i niemal wszystkie środki należą do niej, ma dobre warunki do wysyłania, ale niewielkie możliwości odbioru. Nowe żądanie płatności nie zmienia tego podziału. Potrzebuje kanału, w którym druga strona ma dostępne saldo. Niektóre portfele zapewniają to przez usługodawcę i ukrywają złożoność przed użytkownikiem, często za opłatą. Zdolność odbioru nie jest dodatkowym majątkiem Anny: oznacza możliwość przyjęcia przyszłej płatności. [1] [3] [5]

Anna płaci teraz Pawłowi 100 000 sat. W uproszczonym przykładzie salda zmieniają się na 700 000 sat u Anny i 300 000 sat u Pawła. Pojemność nadal wynosi 1 000 000 sat. Anna może mniej wysłać, ale więcej odebrać z powrotem; u Pawła jest odwrotnie. Jeśli portfel ma kilka kanałów, zmieniają się te rzeczywiście wykorzystane przez płatność. Kierunek jest więc zawsze ważny. Poranny odczyt płynności nie musi odpowiadać temu, co da się wysłać wieczorem. [1] [3]

Płatność do odległego odbiorcy przechodzi przez kolejne kanały. Każdy potrzebuje odpowiedniej dostępnej płynności we właściwym kierunku, także na opłaty dalszych kroków. Jeśli jeden krok nie może przenieść płatności, ta trasa zawiedzie mimo dużej pojemności pozostałych kanałów. Portfel może spróbować innej trasy lub podzielić płatność na części, jeśli jest to obsługiwane. Nie tworzy to jednak brakujących środków. Liczy się nie tylko kwota, lecz także terminy. HTLC to płatność warunkowa, którą można rozliczyć, wykazując znajomość określonego sekretu. Reguły związane z CLTV wyznaczają terminy w blokach; odstępy między nimi dają pośrednikom czas na rozliczenie w łańcuchu Bitcoina, gdy przekazywanie płatności utknie. [1] [2]

Pośrednik musi móc odebrać płatność jednym kanałem i wysłać powiązaną płatność innym. Duża suma wszystkich sald nie wystarczy. Jeśli jego pieniądze leżą po jego stronie niewłaściwego kanału, mogą być bezużyteczne na wybranej trasie. Do odbioru potrzebuje płynności przychodzącej w pierwszym kanale, a do przekazania — wychodzącej w drugim. Kroki łączą warunki HTLC: płatności zależą od znajomości konkretnego sekretu i reguł czasowych. Pośrednik nie polega więc wyłącznie na obietnicy, że poprzedni uczestnik zapłaci mu później. [1] [3]

Wpływy i płatności wychodzące naturalnie zmieniają płynność. Operator kilku kanałów może też zastosować równoważenie okrężne: wysłać płatność jedną trasą i odebrać ją z powrotem inną, przesuwając salda między własnymi kanałami. Swap wymienia środki na łańcuchu na środki Lightning lub odwrotnie. Splicing pozwala zmienić finansowanie obsługującego go kanału bez zwykłego zamykania i ponownego otwierania. Można też otworzyć inny kanał. Metody te różnią się opłatami, czasem, śladem na łańcuchu, wymaganym zaufaniem i ryzykiem niepowodzenia. Żadna nie tworzy nowych pieniędzy; wybierz według tego, czy potrzebujesz wysyłać, odbierać, czy robić jedno i drugie. [1] [4]

Najpierw ustal, czy chodzi o wysyłanie, czy odbiór, i czy portfel oraz drugi węzeł są online. Na własnym węźle porównaj lokalne i zdalne salda każdego kanału, rezerwy, płatności w toku i opłaty. W portfelu zarządzanym przez usługodawcę sprawdź znaczenie pokazywanej dostępnej kwoty. Jedna nieudana płatność sama w sobie nie dowodzi utraty pieniędzy. Może brakować płynności na którymś kroku, działać limit lub wystąpić chwilowa awaria. Mała płatność próbna sprawdza tylko tę kwotę w danej chwili, a nie gwarantuje przejścia wszystkich kolejnych płatności. [1] [3] [4]

Operatorzy muszą rozróżniać kilka ograniczeń. Wyjście transakcji określa kwotę i warunki jej wydania. channel_reserve_satoshis oznacza środki, które mają pozostać jako rezerwa. Część może być związana w oczekujących HTLC, czyli niedokończonych płatnościach warunkowych. Poniższe limity dotyczą HTLC oferowanych przez drugiego uczestnika. max_htlc_value_in_flight_msat ogranicza ich łączną wartość, a max_accepted_htlcs liczbę; msat to tysięczna część satoshi używana w rozliczeniach Lightning. Zależnie od typu kanału dochodzą opłaty commitment transaction, transakcji służącej do zamknięcia kanału, oraz ewentualne anchor outputs, czyli specjalne wyjścia pozwalające dołączyć kolejną transakcję i podnieść opłatę za potwierdzenie całego pakietu. Reguły Dust określają, które wyjścia są za małe, by trafić do tej transakcji. Dokładne dostępne maksimum obliczaj więc dla konkretnej implementacji i typu kanału, zamiast odejmować jedną uniwersalną rezerwę. [1] [6]

BOLT #7 opisuje ogłaszanie kanałów i zasady przekazywania płatności. Dla ogłoszonego kanału można odnaleźć na łańcuchu wyjście finansujące i jego pojemność. Nie ujawnia to bieżącego podziału między uczestników. Nadawca wybiera trasę na podstawie własnych informacji, wcześniejszych wyników i prób płatności, a nie kompletnej publicznej listy aktualnych sald. Eksplorator może więc pokazać duży kanał, ale nie potwierdzi tym, że twoja kwota właśnie teraz przejdzie nim we właściwym kierunku. [2]