Bitcoin Lightning a płatności on-chain: opłaty, potwierdzenia i kanały

Obie mogą przenosić wartość wyrażoną w bitcoinie, ale inaczej korzystają z warstwy bazowej. Płatność on-chain tworzy transakcję, którą węzły Bitcoin mogą rozgłaszać, a górnicy umieścić w bloku. Płatność Lightning przechodzi trasą kanałów płatniczych; każda płatność nie jest zapisywana w blockchainie jako osobna transakcja Bitcoin.

Różnica wpływa na opłaty, dostępność, prywatność i status pokazywany przez portfel. Lightning nie jest inną monetą, a „poza łańcuchem” nie oznacza braku zasad ani ryzyka. Uczestnicy używają transakcji Bitcoin do otwierania kanału i rozliczenia sald, gdy jest to potrzebne.

Portfel wybiera dostępne wyjścia, tworzy i podpisuje transakcję, a następnie rozgłasza ją do węzłów Bitcoin. Węzły mogą ją przekazywać i przechowywać we własnych mempoolach, dopóki górnik nie umieści jej w bloku. Opłata sieciowa zależy od rozmiaru transakcji i zaoferowanej stawki, a nie tylko od wysyłanej ilości bitcoinów. Opisuje to Bitcoin Developer Guide dotyczący przetwarzania płatności.

Identyfikator transakcji pozwala sprawdzić to, co rozgłoszono, ale widoczność nie oznacza potwierdzenia. Jedno potwierdzenie oznacza, że transakcja znajduje się w bloku; kolejne bloki zwiększają liczbę potwierdzeń. Odbiorca lub jego usługa ustala wymagany próg zależnie od kwoty i sytuacji. Czas tworzenia bloków ani cel potwierdzeń nie gwarantują dostępności środków w konkretnej minucie.

Odbiorca może przekazać fakturę Lightning, która koduje żądanie płatności, często z kwotą, celem, opisem i terminem ważności. Portfel nadawcy odczytuje ją i szuka trasy o odpowiedniej pojemności i limitach. Specyfikacja faktur BOLT 11 opisuje pola żądania, a BOLT 7 omawia ogłoszenia kanałów i aktualizacje tras.

Płatność przekazywana trasą używa transferów warunkowych określanych jako HTLC. Każdy węzeł pośredniczący otrzymuje kwotę i warunki czasowe potrzebne na kolejnym odcinku; końcowy odbiorca ujawnia sekret, który kończy płatność. Trasa może się nie powieść, gdy brakuje płynności w wymaganym kierunku, aktualizacja jest nieaktualna, osiągnięto limit albo węzeł jest niedostępny. Udana płatność Lightning może zakończyć się bez czekania na nowy blok, ale powodzenie każdej faktury nie jest gwarantowane.

Kanał płatniczy zaczyna się od transakcji finansującej on-chain i ma całkowitą pojemność. Gdy uczestnicy płacą sobie nawzajem, saldo przesuwa się bez publikowania osobnej transakcji Bitcoin dla każdej zmiany. Kwota, którą jedna strona może wysłać w danym momencie, zależy od salda w tym kierunku, rezerw, limitów płatności i wybranej trasy. Protokół komunikacji BOLT 2 opisuje parametry kanału i limity HTLC.

Kanał o wystarczającej całkowitej pojemności może nadal nie mieć płynności wychodzącej potrzebnej do konkretnej płatności. Odbiorcy również może brakować użytecznej ścieżki przychodzącej dla tej kwoty. Otwarcie kanału, zmiana płynności lub zamknięcie może wymagać transakcji i opłat on-chain. BOLT 5 dotyczący obsługi on-chain opisuje zamknięcie wspólne i jednostronne. Ilustracja oddziela powtarzane płatności kanałem od finansowania i zamknięcia rozliczanych w Bitcoinie.

Opłata on-chain pokrywa miejsce w bloku. Jej łączna wysokość zależy od rozmiaru transakcji i stawki wybranej dla obecnych warunków; większa transakcja może kosztować więcej, nawet jeśli wysyła mniej bitcoinów. Szacunek portfela się zmienia i nie rezerwuje miejsca w przyszłym bloku.

Opłaty za przekazywanie w Lightning ustalają operatorzy kanałów; mogą łączyć kwotę bazową z częścią proporcjonalną. Długość trasy, polityki, płynność i działanie portfela wpływają na sumę. Niektóre portfele mogą doliczać własne koszty usługi lub płynności. Lightning może być tańszy w konkretnej sytuacji, ale nie zawsze jest darmowy ani tańszy niż on-chain. Przed zatwierdzeniem sprawdź kwotę końcową, szczegóły opłat i wymagania trasy.

Portfel on-chain może pokazywać status rozgłoszenia, oczekiwania lub potwierdzenia. Transakcje i bloki są publiczne w blockchainie, a odbiorca może przyjąć próg potwierdzeń odpowiedni do kwoty i sytuacji. Transakcja może pozostać niepotwierdzona dłużej, niż oczekiwano; szacunek opłaty nie steruje wyborem górnika.

W Lightning faktura jest opłacona, gdy trasa się kończy, a portfel otrzymuje informację o sukcesie. Ta płatność nie jest osobno umieszczana w bloku Bitcoin. Nieudana próba nie jest potwierdzeniem, a niejasny ekran nie dowodzi, że ponowne wysłanie jest bezpieczne. Przed kolejną próbą sprawdź końcowy status portfela nadawcy oraz fakturę lub potwierdzenie odbioru u odbiorcy.

Dane on-chain są publiczne i można je analizować, choć sam adres nie ujawnia automatycznie nazwiska. Onion routing w Lightning ma ograniczać wiedzę węzła pośredniczącego o całej trasie, ale nie sprawia, że każda płatność jest anonimowa. Specyfikacja onion routingu BOLT 4 oraz publiczne aktualizacje kanałów w BOLT 7 opisują część tego modelu.

Portfele różnią się też tym, kto kontroluje klucze oraz jak kanały są monitorowane, archiwizowane i odzyskiwane. Portfel z samodzielną pieczą i powiernicze konto Lightning wiążą się z inną odpowiedzialnością i ryzykiem awarii. Znaczenie mogą mieć internet, dostępność partnerów, stan kanału, odzyskiwanie i warunki dostawcy. Sama nazwa Lightning nie mówi, kto przechowuje środki ani jak chroniona jest kopia zapasowa.

On-chain może pasować, gdy odbiorca podaje adres Bitcoin i chce transakcji możliwej do sprawdzenia w blockchainie. Lightning może działać między kompatybilnymi portfelami, jeśli dostępna jest faktura i trasa o wystarczającej płynności. Powtarzane małe płatności mogą korzystać z istniejącego kanału, ale otwarcie, utrzymanie i zamknięcie mają własne koszty i ograniczenia.

Przed wysłaniem sprawdź typ płatności, sieć, kwotę, termin faktury, odbiorcę, widoczną opłatę i limity. Nie wklejaj faktury Lightning w pole adresu on-chain ani nie korzystaj z trasy, o którą odbiorca nie prosił. Zastępczej drogi on-chain używaj tylko wtedy, gdy faktura i portfel wyraźnie ją obsługują. Zobacz też: opłaty transakcyjne Bitcoin, potwierdzenia wpłat i listę kontrolną transferu krypto.

Pierwotne źródła techniczne: Bitcoin Developer Guide: obsługa płatności; BOLT 2: protokół peer; BOLT 4: onion routing; BOLT 5: transakcje on-chain; BOLT 7: informacje o routingu; BOLT 11: format faktury.