Lightning Routing

Anna chce zapłacić za kawę, ale nie ma kanału z kawiarnią. Ma kanał z Pawłem, a Paweł — kolejny z kawiarnią. Płatność może więc przejść przez niego: w pierwszym kanale część salda przechodzi od Anny do Pawła, a w drugim od Pawła do kawiarni. Nie oznacza to przesyłania tej samej monety między kanałami, lecz powiązane zmiany ich sald. Paweł potrzebuje zatem własnych dostępnych środków po stronie, z której płaci kawiarni. Portfel lub węzeł nadawcy wybiera drogę do odbiorcy i przygotowuje instrukcje dla kolejnych etapów. Odbiorca przekazuje potrzebne dane i obsługiwane funkcje, czasem także informacje o niepublicznym końcowym odcinku. Węzły po drodze przekazują płatność według instrukcji, zamiast za każdym razem samodzielnie szukać całej trasy. [1] [4]

Gossip to sposób rozpowszechniania informacji między węzłami. BOLT #7 opisuje ogłoszenia kanałów i aktualizacje dla poszczególnych kierunków: opłatę stałą i proporcjonalną, różnicę terminów CLTV, kwotę minimalną i maksymalną oraz oznaczenie dostępności. Ogłoszone warunki nie dowodzą, że drugi węzeł jest teraz online ani że ma dość środków. CLTV oznacza tu termin wyrażony jako wysokość bloku Bitcoina, czyli jego numer w łańcuchu, a nie dokładną godzinę. Różnica między terminami daje pośrednikowi czas na reakcję, gdy przekazywanie płatności utknie. [2]

Łączna pojemność kanału nie mówi, ile każda strona może teraz wysłać. Nadawca zna własne kanały, a dla pozostałych korzysta z szacunków i historii udanych oraz nieudanych prób. Program uwzględnia więc opłatę i prawdopodobieństwo powodzenia. Inna płatność może w międzyczasie zmienić płynność, czyli środki dostępne do wysłania we właściwym kierunku. [4] [5]

Etapy łączą HTLC, czyli płatności warunkowe: ich zakończenie wymaga ujawnienia odpowiedniego sekretu. Jeśli płatność nie zostanie ukończona, po upływie terminu można odzyskać środki. Obliczenia zaczynają się od kwoty dla odbiorcy i biegną wstecz. Każdy pośrednik musi otrzymać kwotę dla następnego węzła oraz własną opłatę. Przychodzący HTLC musi wygasać odpowiednio później niż wychodzący, zgodnie z wymaganą różnicą CLTV. Dłuższa droga może zwiększyć koszty i czas zablokowania środków w razie problemu. [1] [2]

Onion routing według BOLT #4 wykorzystuje konstrukcję Sphinx: każdy etap dostaje osobno zaszyfrowane instrukcje. Pośrednik zna poprzedniego i następnego partnera oraz własne polecenia. Sam pakiet nie ujawnia całej trasy, jej długości ani dokładnego miejsca węzła na niej. Analiza ruchu lub współpraca węzłów mogą jednak osłabić prywatność. [1]

Kanał może chwilowo zawieść, opłata być za niska, CLTV nieprawidłowe, a następny partner niedostępny lub nieznany. Nadawca otrzymuje tylko ograniczoną informację o błędzie. Jego program może obniżyć ocenę trasy, przeliczyć ją i ponowić płatność. To nie kara pieniężna płacona węzłowi, a pojedynczy wynik nie jest trwałą oceną niezawodności. [1] [4]

Same połączenia nie wystarczą: każdy etap musi przyjąć HTLC i dysponować odpowiednią ilością dostępnych środków we właściwym kierunku. Część salda może stanowić rezerwę albo być zablokowana w niezakończonych płatnościach. Pola techniczne htlc_minimum_msat i htlc_maximum_msat określają też dolną i górną granicę kwoty pojedynczego HTLC w danym kierunku. Jednostka msat oznacza tysięczną część satoshi; satoshi jest najmniejszą jednostką wartości na łańcuchu Bitcoina. Nawet wysoki ogłoszony limit nie dowodzi, że potrzebna płynność jest teraz dostępna. Jeden nieodpowiedni kanał może więc zablokować całą trasę. [2]

Jeśli odbiorca obsługuje basic MPP, czyli płatność podzieloną na kilka części, nadawca może rozdzielić łączną kwotę, oznaczoną w protokole jako total_msat, między kilka tras. Odbiorca czeka na potrzebne części i rozlicza je razem. Pozwala to wykorzystać płynność w różnych kanałach, lecz MPP nie tworzy nowej. Przybywa HTLC, prób i ewentualnie opłat. [1]

Route hints w BOLT #11 mogą dostarczyć nadawcy danych o ostatnich nieogłoszonych etapach. Route blinding, używany w BOLT #12, udostępnia zamiast tego zaszyfrowany koniec drogi przez węzeł wejściowy, introduction point. Nadawca wciąż musi znaleźć użyteczną drogę do tego punktu i spełnić łączne warunki opłat oraz CLTV. Lepsza prywatność nie gwarantuje dostarczenia płatności. [3] [6] [1]

Przy codziennych płatnościach szukaniem trasy zajmuje się portfel. Poniższe szczegóły przydają się głównie operatorom węzłów i przy ustalaniu przyczyn powtarzających się problemów. Zapisz program i wersję, kwotę, maksymalną opłatę i limit CLTV, liczbę prób, użyte trasy, czas zakończenia oraz dokładną przyczynę błędu. Porównuj tę samą parę węzłów w zbliżonym czasie. Powodzenie opisuje konkretną płatność w konkretnym stanie sieci, a nie stałą ogólną ocenę. [4] [5]