name: Teoretyczne wprowadzenie do Lightning Network goal: Odkryj Lightning Network z technicznego punktu widzenia objectives:

Podróż do drugiego Layer Bitcoin

Zanurz się w sercu Lightning Network, niezbędnego systemu dla przyszłych transakcji Bitcoin. LNP201 to teoretyczny kurs na temat technicznego działania Lightning. Odkrywa podstawy i mechanizmy tej drugiej sieci Layer, zaprojektowanej tak, aby płatności Bitcoin były szybkie, ekonomiczne i skalowalne.

Dzięki sieci kanałów płatności Lightning umożliwia szybkie i bezpieczne transakcje bez konieczności rejestrowania każdego Exchange na Bitcoin Blockchain. W kolejnych rozdziałach dowiesz się, jak działa otwieranie, zarządzanie i zamykanie kanałów, w jaki sposób płatności są bezpiecznie kierowane przez węzły pośredniczące przy jednoczesnym zminimalizowaniu potrzeby zaufania oraz jak zarządzać płynnością. Dowiesz się, czym są transakcje Commitment, HTLC, klucze odwołania, mechanizmy karania, routing cebulowy i faktury.

Niezależnie od tego, czy jesteś początkującym, czy bardziej doświadczonym użytkownikiem Bitcoin, ten kurs dostarczy cennych informacji, aby zrozumieć i używać Lightning Network. Chociaż w pierwszych częściach omówimy niektóre podstawy działania Bitcoin, ważne jest, aby opanować podstawy wynalazku Satoshi przed zanurzeniem się w LNP201.

Miłego odkrywania!

Wprowadzenie

Przegląd kursu

Witamy w kursie LNP201!

Szkolenie to ma na celu zapewnienie dogłębnego technicznego zrozumienia Lightning Network, sieci nakładkowej zaprojektowanej w celu ułatwienia szybkich i często tanich transakcji Bitcoin. Stopniowo odkryjesz podstawowe koncepcje rządzące tym systemem, od otwierania kanałów płatności po techniki routingu i zarządzanie płynnością.

Sekcja 1: Podstawy

Zaczniemy od ogólnego wprowadzenia do Lightning Network, ustanawiając niezbędne podstawy dotyczące Bitcoin, jego adresów, UTXO i sposobu działania transakcji. Ten podstawowy przegląd jest niezbędny do zrozumienia, w jaki sposób Lightning Network opiera się na podstawowych mechanizmach Blockchain, aby działać bezpiecznie.

Sekcja 2: Otwieranie i zamykanie kanałów

W tej sekcji zbadamy proces otwierania kanału, który jest kamieniem węgielnym Lightning Network. Dowiesz się, w jaki sposób tworzone są transakcje Commitment, jaka jest rola kluczy odwołania dla bezpieczeństwa i w jaki sposób kanały mogą być zamykane wspólnie lub jednostronnie. Każdy krok zostanie wyjaśniony precyzyjnie i technicznie, aby pomóc ci zrozumieć wszystkie subtelności.

Sekcja 3: Sieć płynności

Lightning Network nie ogranicza się do pojedynczych kanałów; to prawdziwa sieć płatności. Zobaczymy, jak transakcje mogą być kierowane przez węzły pośredniczące za pomocą HTLC. W tej sekcji przedstawimy również wyzwania związane z płynnością przychodzącą i wychodzącą.

Sekcja 4: Narzędzia Lightning Network

W tej sekcji przedstawiono praktyczne narzędzia Lightning Network, takie jak Invoices, LNURL i Keysend. Dowiesz się również, jak zarządzać płynnością swoich kanałów, co jest istotnym aspektem zapewniającym płynne płatności i maksymalizującym wydajność transakcji na Lightning.

Sekcja 5: Dalej

Na koniec szkolenia podsumujemy omówione koncepcje i utorujemy drogę do bardziej zaawansowanych tematów dla tych, którzy chcą pogłębić swoją wiedzę na temat Lightning Network.

Gotowy do odkrycia technicznych mechanizmów Lightning Network? Zanurzmy się!

Podstawy

Zrozumienie Lightning Network

Lightning Network to sieć kanałów płatności zbudowana w oparciu o protokół Bitcoin, mająca na celu umożliwienie szybkich i tanich transakcji. Umożliwia tworzenie kanałów płatności między uczestnikami, w ramach których transakcje mogą być dokonywane niemal natychmiast i przy minimalnych opłatach, bez konieczności rejestrowania każdej transakcji indywidualnie na Blockchain. W ten sposób Lightning Network dąży do poprawy skalowalności Bitcoin i uczynienia go użytecznym dla płatności o niskiej wartości.

Przed zbadaniem aspektu "sieci" ważne jest, aby zrozumieć koncepcję kanału płatności na Lightning, jak to działa i jego specyfikę. Jest to temat tego pierwszego rozdziału.

Koncepcja kanału płatności

Kanał płatności pozwala dwóm stronom, tutaj Alice i Bob, na Exchange funduszy przez Lightning Network. Każdy bohater ma węzeł, symbolizowany przez okrąg, a kanał między nimi jest reprezentowany przez odcinek linii.

LNP201

W naszym przykładzie Alice ma 100 000 satoshi po swojej stronie kanału, a Bob ma 30 000 satoshi, co daje łącznie 130 000 satoshi, co stanowi przepustowość kanału.

**Ale czym jest Satoshi?

Satoshi (lub "sat") jest jednostką rozliczeniową na Bitcoin. Podobnie jak cent dla euro, Satoshi jest po prostu ułamkiem Bitcoin. Jeden Satoshi jest równy 0,00000001 Bitcoin, czyli jednej stumilionowej Bitcoin. Korzystanie z Satoshi staje się coraz bardziej praktyczne wraz ze wzrostem wartości Bitcoin.

Alokacja funduszy w kanale La Manche

Wróćmy do kanału płatności. Kluczowym pojęciem jest tutaj "strona kanału". Każdy uczestnik ma środki po swojej stronie kanału: Alicja 100 000 satoshi, a Bob 30 000. Jak widzieliśmy, suma tych środków reprezentuje całkowitą pojemność kanału, liczbę ustaloną w momencie jego otwarcia.

LNP201

Weźmy przykład transakcji Lightning. Jeśli Alicja chce wysłać 40 000 satoshi do Boba, jest to możliwe, ponieważ ma wystarczającą ilość środków (100 000 satoshi). Po tej transakcji Alicja będzie miała po swojej stronie 60 000 satoshi, a Bob 70 000.

LNP201

Pojemność kanału**, wynosząca 130 000 satoshi, pozostaje stała. To, co się zmienia, to alokacja środków. System ten nie pozwala na wysyłanie większej ilości środków niż się posiada. Na przykład, jeśli Bob chciałby odesłać Alicji 80 000 satoshi, nie mógłby, ponieważ ma tylko 70 000.

Innym sposobem na wyobrażenie sobie alokacji środków jest pomyślenie o suwaku, który wskazuje, gdzie znajdują się środki w kanale. Początkowo, przy 100 000 satoshis dla Alice i 30 000 dla Boba, suwak logicznie znajduje się po stronie Alice. Po transakcji 40 000 satoshi, suwak przesunie się nieco w stronę Boba, który ma teraz 70 000 satoshi.

LNP201

Ta reprezentacja może być przydatna do wyobrażenia sobie równowagi funduszy w kanale.

Podstawowe zasady kanału płatności

Pierwszą kwestią do zapamiętania jest to, że przepustowość kanału jest stała. Przypomina to nieco średnicę rury: określa maksymalną ilość środków, które można przesłać przez kanał jednocześnie.

Weźmy przykład: jeśli Alice ma 130 000 satoshi po swojej stronie, może wysłać maksymalnie 130 000 satoshi do Boba w pojedynczej transakcji. Bob może jednak odesłać te środki z powrotem do Alicji, częściowo lub w całości.

Ważne jest, aby zrozumieć, że stała przepustowość kanału ogranicza maksymalną kwotę pojedynczej transakcji, ale nie całkowitą liczbę możliwych transakcji ani ogólny wolumen środków wymienianych w kanale.

**Co powinieneś wynieść z tego rozdziału?

To koniec pierwszego rozdziału, w którym położyliśmy podwaliny pod Lightning Network. W kolejnych rozdziałach zobaczymy, jak otworzyć kanał i zagłębimy się w omawiane tutaj koncepcje.

Bitcoin, adresy, UTXO i transakcje

Ten rozdział jest nieco wyjątkowy, ponieważ nie będzie bezpośrednio poświęcony Lightning, ale Bitcoin. W rzeczywistości Lightning Network jest Layer nałożonym na Bitcoin. Dlatego ważne jest, aby zrozumieć pewne podstawowe koncepcje Bitcoin, aby właściwie zrozumieć działanie Lightning w kolejnych rozdziałach. W tym rozdziale dokonamy przeglądu podstaw adresów odbiorczych Bitcoin, UTXO, a także funkcjonowania transakcji Bitcoin.

Adresy Bitcoin, klucze prywatne i klucze publiczne

Bitcoin Address to seria znaków pochodzących z klucza publicznego, który jest obliczany na podstawie klucza prywatnego. Jak z pewnością wiesz, jest on używany do blokowania bitcoinów, co jest równoznaczne z otrzymaniem ich w naszym Wallet.

Klucz prywatny jest tajnym elementem, który nigdy nie powinien być udostępniany, podczas gdy klucz publiczny i Address mogą być udostępniane bez ryzyka dla bezpieczeństwa (ich ujawnienie stanowi jedynie ryzyko dla prywatności użytkownika). Oto wspólna reprezentacja, którą przyjmiemy podczas tego szkolenia:

Transakcje Bitcoin: Wysyłanie środków i skrypty

Na Bitcoin transakcja polega na wysłaniu środków z jednego Address do drugiego. Weźmy przykład Alicji wysyłającej 0,002 Bitcoin do Boba. Alicja używa klucza prywatnego powiązanego z jej Address, aby podpisać transakcję, udowadniając w ten sposób, że rzeczywiście jest w stanie wydać te środki. Ale co dokładnie dzieje się za tą transakcją? Środki na Bitcoin Address są zablokowane przez skrypt, rodzaj mini-programu, który narzuca pewne warunki do wydania środków.

Najpopularniejszy skrypt wymaga podpisu kluczem prywatnym powiązanym z Address. Kiedy Alice podpisuje transakcję swoim kluczem prywatnym, odblokowuje skrypt, który blokuje środki, a następnie można je przelać. Transfer środków polega na dodaniu nowego skryptu do tych środków, określającego, że tym razem do ich wydania wymagany będzie podpis kluczem prywatnym Boba.

LNP201

UTXOs: Niewykorzystane wyjścia transakcji

W Bitcoin to, co faktycznie Exchange, to nie bezpośrednio bitcoiny, ale UTXOs (Unspent Transaction Outputs), co oznacza "niewydane transakcje wyjściowe".

UTXO to kawałek Bitcoin, który może mieć dowolną wartość, na przykład 2 000 bitcoinów, 8 bitcoinów, a nawet 8 000 Sats. Każdy UTXO jest zablokowany przez skrypt i aby go wydać, należy spełnić warunki skryptu, często podpis z kluczem prywatnym odpowiadającym danemu otrzymanemu Address.

UTXO nie mogą być dzielone. Za każdym razem, gdy są używane do wydania kwoty w bitcoinach, które reprezentują, musi to być zrobione w całości. To trochę jak z banknotem: jeśli masz rachunek na 10 euro i jesteś winien piekarzowi 5 euro, nie możesz po prostu przeciąć rachunku na pół. Musisz dać mu banknot o nominale 10 euro, a on wyda ci 5 euro reszty. Jest to dokładnie ta sama zasada dla UTXO w Bitcoin! Na przykład, gdy Alice odblokowuje skrypt swoim kluczem prywatnym, odblokowuje cały UTXO. Jeśli chce wysłać tylko część środków reprezentowanych przez ten UTXO do Boba, może "pofragmentować" go na kilka mniejszych. Następnie wyśle 0,0015 BTC do Boba i wyśle pozostałą część, 0,0005 BTC, do zamienionego Address.

Oto przykład transakcji z 2 wyjściami:

LNP201

Adresy z wieloma podpisami

Oprócz prostych adresów generowanych z jednego klucza publicznego, możliwe jest tworzenie adresów wielopodpisowych z wielu kluczy publicznych. Szczególnie interesującym przypadkiem dla Lightning Network jest 2/2 wielopodpisowy Address, wygenerowany z dwóch kluczy publicznych:

LNP201

Aby wydać środki zablokowane za pomocą Address z wieloma podpisami 2/2, konieczne jest podpisanie za pomocą dwóch kluczy prywatnych powiązanych z kluczami publicznymi.

LNP201

Ten typ Address jest dokładnie odwzorowaniem na Bitcoin Blockchain kanałów płatności na Lightning Network.

**Co powinieneś wynieść z tego rozdziału?

Niniejszy rozdział poświęcony Bitcoin pozwolił nam zapoznać się z kilkoma istotnymi pojęciami. W następnym rozdziale dowiemy się, jak działa otwieranie kanałów na Lightning Network.

Otwieranie i zamykanie kanałów

Otwarcie kanału

W tym rozdziale zobaczymy dokładniej, jak otworzyć kanał płatności na Lightning Network i zrozumiemy związek między tą operacją a bazowym systemem Bitcoin.

Kanały błyskawic

Jak widzieliśmy w pierwszym rozdziale, kanał płatności na Lightning można porównać do "rury" do wymiany środków między dwoma uczestnikami (Alice i Bob w naszych przykładach). Przepustowość tego kanału odpowiada sumie dostępnych środków po każdej ze stron. W naszym przykładzie Alice ma 100 000 satoshis, a Bob ma 30 000 satoshis, co daje całkowitą przepustowość wynoszącą 130 000 satoshis.

LNP201

Poziomy informacji Exchange

Kluczowe jest wyraźne rozróżnienie różnych poziomów Exchange na Lightning Network:

LNP201

Warto zauważyć, że węzeł Lightning może komunikować się za pośrednictwem protokołu P2P bez otwierania kanału, ale do funduszy Exchange kanał jest niezbędny.

Kroki otwierania kanału Lightning Channel

LNP201 LNP201 LNP201 LNP201 LNP201 LNP201

Kiedy kanał jest otwarty?

Kanał uznaje się za otwarty, gdy transakcja depozytu zostanie uwzględniona w bloku Bitcoin i osiągnie określoną głębokość potwierdzeń (liczbę kolejnych bloków).

**Co powinieneś zapamiętać z tego rozdziału?

W następnym rozdziale zbadamy techniczne działanie transakcji Lightning w kanale.

Commitment Transaction

W tym rozdziale odkryjemy techniczne funkcjonowanie transakcji w kanale na Lightning Network, czyli gdy środki są przenoszone z jednej strony kanału na drugą.

Przypomnienie cyklu życia kanału

Jak widzieliśmy wcześniej, kanał Lightning rozpoczyna się od otwarcia za pośrednictwem transakcji Bitcoin. Kanał może zostać zamknięty w dowolnym momencie, również za pośrednictwem transakcji Bitcoin. Pomiędzy tymi dwoma momentami można wykonać prawie nieskończoną liczbę transakcji w kanale, bez przechodzenia przez Bitcoin Blockchain. Zobaczmy, co dzieje się podczas transakcji w kanale.

LNP201

Początkowy stan kanału

W momencie otwarcia kanału Alice zdeponowała 130 000 satoshi na wielopodpisowym Address kanału. Tak więc w stanie początkowym wszystkie środki są po stronie Alicji. Przed otwarciem kanału Alice poprosiła Boba o podpisanie transakcji wypłaty, która pozwoliłaby jej odzyskać środki, gdyby chciała zamknąć kanał.

LNP201

Niepublikowane transakcje: Transakcje Commitment

Kiedy Alicja dokonuje transakcji w kanale, aby wysłać środki do Boba, tworzona jest nowa transakcja Bitcoin, aby odzwierciedlić tę zmianę w dystrybucji środków. Transakcja ta, zwana Commitment Transaction, nie jest publikowana na Blockchain, ale reprezentuje nowy stan kanału po transakcji Lightning.

Weźmy przykład z Alicją wysyłającą 30 000 satoshi do Boba:

Aby zweryfikować ten transfer, Alice i Bob tworzą nową nieopublikowaną transakcję Bitcoin, która wysyła 100 000 satoshi do Alice i 30 000 satoshi do Boba z wielopodpisowego Address. Obie strony konstruują tę transakcję niezależnie, ale z tymi samymi danymi (kwoty i adresy). Po skonstruowaniu, każda ze stron podpisuje transakcję i wymienia swój podpis z drugą stroną. Pozwala to każdej ze stron na opublikowanie transakcji w dowolnym momencie, jeśli jest to konieczne, aby odzyskać swój udział w kanale na głównym Bitcoin Blockchain.

LNP201

Proces transferu: Invoice

Kiedy Bob chce otrzymać środki, wysyła Alice fakturę na 30 000 satoshi. Alice następnie płaci tym Invoice, rozpoczynając transfer w kanale. Jak widzieliśmy, proces ten opiera się na utworzeniu i podpisaniu nowego Commitment Transaction.

Każdy Commitment Transaction reprezentuje nowy podział środków w kanale po transferze. W tym przykładzie po transakcji Bob ma 30 000 satoshi, a Alicja 100 000 satoshi. Jeśli którykolwiek z dwóch uczestników zdecyduje się opublikować Commitment Transaction na Blockchain, spowoduje to zamknięcie kanału, a środki zostaną rozdzielone zgodnie z ostatnią dystrybucją.

LNP201

Nowy stan po drugiej transakcji

Weźmy inny przykład: po pierwszej transakcji, w której Alice wysłała 30 000 satoshis do Boba, Bob decyduje się wysłać 10 000 satoshis z powrotem do Alice. Tworzy to nowy stan kanału. Nowy Commitment Transaction będzie reprezentował tę zaktualizowaną dystrybucję:

LNP201

Ponownie, transakcja ta nie jest publikowana na Blockchain, ale może zostać opublikowana w dowolnym momencie w przypadku zamknięcia kanału.

Podsumowując, gdy środki są przesyłane w ramach kanału Lightning:

System ten ma jednak potencjalną wadę, którą Address omówi w następnym rozdziale. Zobaczymy, jak każdy uczestnik może zabezpieczyć się przed próbą oszustwa ze strony drugiej strony.

Klucz odwołania

W tym rozdziale zagłębimy się w to, jak transakcje działają na Lightning Network, omawiając mechanizmy ochrony przed oszustwami, zapewniając, że każda ze stron przestrzega zasad w kanale.

Przypomnienie: Transakcje Commitment

Jak wspomniano wcześniej, transakcje na Lightning opierają się na niepublikowanych ** transakcjach Commitment**. Transakcje te odzwierciedlają bieżącą dystrybucję środków w kanale. Kiedy dokonywana jest nowa transakcja Lightning, tworzony jest nowy Commitment Transaction i podpisywany przez obie strony, aby odzwierciedlić nowy stan kanału.

Weźmy prosty przykład:

LNP201

W dowolnym momencie obie strony mogą opublikować najnowszy Commitment Transaction podpisany w celu zamknięcia kanału i odzyskania środków.

Wada: oszukiwanie poprzez publikowanie starych transakcji

Potencjalny problem pojawia się, gdy jedna ze stron zdecyduje się oszukać, publikując stary Commitment Transaction. Na przykład, Alicja może opublikować starszy Commitment Transaction, w którym miała 100 000 satoshi, mimo że w rzeczywistości ma tylko 60 000. To pozwoliłoby jej ukraść 40 000 satoshi od Boba.

LNP201

Co gorsza, Alice mogła opublikować pierwszą transakcję wypłaty, tę przed otwarciem kanału, w której miała 130 000 satoshi, a tym samym ukraść wszystkie fundusze kanału.

LNP201

Rozwiązanie: Klucz odwołania i blokada czasowa

Aby zapobiec tego rodzaju oszustwom ze strony Alice, w Lightning Network, mechanizmy bezpieczeństwa są dodawane do transakcji Commitment:

Dzięki tym dwóm połączonym mechanizmom Bob ma czas na wykrycie próby oszustwa Alicji i ukaranie jej poprzez odzyskanie swoich danych wyjściowych za pomocą klucza unieważniającego, co dla Boba oznacza odzyskanie wszystkich środków z kanału. Nasz nowy Commitment Transaction będzie teraz wyglądał następująco:

LNP201

Prześledźmy razem działanie tego mechanizmu.

Proces aktualizacji transakcji

Kiedy Alicja i Bob aktualizują stan kanału za pomocą nowej transakcji Lightning, Exchange z wyprzedzeniem ich sekrety dla poprzedniego Commitment Transaction (tego, który stanie się nieaktualny i może pozwolić jednemu z nich oszukiwać). Oznacza to, że w nowym stanie kanału:

Weźmy przykład, aby dobrze zrozumieć ten proces:

LNP201 LNP201 LNP201

Nawet jeśli w tym przypadku Bob nie ma interesu ekonomicznego w próbach oszukiwania, jeśli i tak to robi, Alicja również korzysta z symetrycznej ochrony oferującej jej takie same gwarancje.

**Co powinieneś wynieść z tego rozdziału?

Transakcje Commitment na Lightning Network zawierają mechanizmy bezpieczeństwa, które zmniejszają zarówno ryzyko oszustwa, jak i zachęty do jego popełnienia. Przed podpisaniem nowego Commitment Transaction, Alicja i Bob Exchange swoje sekrety dla poprzednich transakcji Commitment. Jeśli Alicja spróbuje opublikować stary Commitment Transaction, Bob może użyć klucza odwołania, aby odzyskać wszystkie środki, zanim Alicja to zrobi (ponieważ jest zablokowana przez blokadę czasową), co karze ją za próbę oszustwa.

Ten system bezpieczeństwa zapewnia, że uczestnicy przestrzegają zasad Lightning Network i nie mogą czerpać korzyści z publikowania starych transakcji Commitment.

Na tym etapie szkolenia wiesz już, w jaki sposób otwierane są kanały Lightning i jak działają transakcje w tych kanałach. W następnym rozdziale odkryjemy różne sposoby zamknięcia kanału i odzyskania bitcoinów na głównym Blockchain.

Zamknięcie kanału

W tym rozdziale omówimy zamykanie kanału na Lightning Network, które odbywa się za pośrednictwem transakcji Bitcoin, podobnie jak otwieranie kanału. Po zapoznaniu się z działaniem transakcji w ramach kanału, nadszedł czas, aby zobaczyć, jak zamknąć kanał i odzyskać środki na Bitcoin Blockchain.

Przypomnienie cyklu życia kanału

Cykl życia kanału rozpoczyna się od jego otwarcia, poprzez transakcję Bitcoin, następnie dokonywane są w nim transakcje Lightning, a na koniec, gdy strony chcą odzyskać swoje środki, kanał jest zamykany poprzez drugą transakcję Bitcoin. Transakcje pośrednie dokonywane na Lightning są reprezentowane przez niepublikowane transakcje Commitment.

LNP201

Trzy rodzaje zamknięcia kanału

Istnieją trzy główne sposoby zamknięcia tego kanału, które można nazwać dobrym, brutalnym i wagarowiczem (zainspirowane przez Andreasa Antonopoulosa w Mastering the Lightning Network):

Weźmy przykład:

LNP201

Plusy: zamknięcie współpracy

W kooperatywnym zamknięciu Alice i Bob zgadzają się zamknąć kanał. Oto jak to przebiega:

LNP201

Na przykład, jeśli Alice posiada 100 000 satoshis, a Bob 30 000 satoshis, transakcja zamykająca wyśle 100 000 satoshis do Address Alice i 30 000 satoshis do Address Boba, bez ograniczeń czasowych. Po podpisaniu transakcji przez obie strony jest ona publikowana przez Alice. Gdy transakcja zostanie potwierdzona na Bitcoin Blockchain, kanał Lightning zostanie oficjalnie zamknięty.

LNP201

Współpracujące zamknięcie jest preferowaną metodą zamknięcia, ponieważ jest szybkie (bez blokady czasowej), a opłaty transakcyjne są dostosowywane do aktualnych warunków rynkowych Bitcoin. Pozwala to uniknąć płacenia zbyt małej kwoty, co mogłoby grozić zablokowaniem transakcji w mempoolach, lub niepotrzebnego przepłacania, co prowadzi do niepotrzebnych strat finansowych dla uczestników.

Złe: przymusowe zamknięcie

Gdy węzeł Alicji wyśle wiadomość do węzła Boba z prośbą o zamknięcie współpracy, jeśli ten nie odpowie (na przykład z powodu przerwy w dostępie do Internetu lub problemu technicznego), Alicja może przystąpić do wymuszonego zamknięcia, publikując ostatnio podpisany Commitment Transaction.

W tym przypadku Alice po prostu opublikuje ostatni Commitment Transaction, który odzwierciedla stan kanału w czasie, gdy miała miejsce ostatnia transakcja Lightning z prawidłową dystrybucją środków.

LNP201

Transakcja ta obejmuje timelock dla środków Alice, co spowalnia zamknięcie.

LNP201

Ponadto opłaty Commitment Transaction mogą być nieodpowiednie w momencie zamknięcia, ponieważ zostały ustalone w momencie tworzenia transakcji, czasami kilka miesięcy wcześniej. Ogólnie rzecz biorąc, klienci Lightning zawyżają opłaty, aby uniknąć przyszłych problemów, ale może to prowadzić do zbyt wysokich opłat lub odwrotnie, zbyt niskich.

Podsumowując, wymuszone zamknięcie jest opcją ostateczną, gdy partner przestaje odpowiadać. Jest ono wolniejsze i mniej ekonomiczne niż zamknięcie oparte na współpracy. Dlatego należy go unikać w miarę możliwości.

Oszustwo: oszukiwanie

Wreszcie, zamknięcie z oszustwem ma miejsce, gdy jedna ze stron próbuje opublikować stary Commitment Transaction, często wtedy, gdy posiadała więcej środków niż powinna. Na przykład Alice może opublikować starą transakcję, w której posiadała 120 000 satoshi, podczas gdy w rzeczywistości posiada tylko 100 000.

LNP201

Bob, aby zapobiec temu oszustwu, monitoruje Bitcoin Blockchain i jego Mempool, aby upewnić się, że Alicja nie opublikuje starej transakcji. Jeśli Bob wykryje próbę oszustwa, może użyć klucza odwołania, aby odzyskać środki Alice i ukarać ją, zabierając wszystkie środki z kanału. Ponieważ Alicja jest zablokowana przez blokadę czasową na swoim wyjściu, Bob ma czas, aby wydać go bez blokady czasowej po swojej stronie, aby odzyskać całą sumę na Address, którego jest właścicielem.

LNP201

Oczywiście oszustwo może potencjalnie zakończyć się sukcesem, jeśli Bob nie podejmie działania w czasie narzuconym przez blokadę czasową wyjścia Alicji. W takim przypadku dane wyjściowe Alicji są odblokowane, co pozwala jej wykorzystać je do utworzenia nowych danych wyjściowych dla kontrolowanego przez nią Address.

**Co powinieneś wynieść z tego rozdziału?

Istnieją trzy sposoby zamknięcia kanału:

W kolejnych rozdziałach zbadamy Lightning Network z szerszej perspektywy, koncentrując się na tym, jak działa jego sieć.

Sieć płynności

Lightning Network

W tym rozdziale zbadamy, w jaki sposób płatności na Lightning Network mogą dotrzeć do odbiorcy, nawet jeśli nie są oni bezpośrednio połączeni kanałem płatności. Lightning jest bowiem siecią kanałów płatności, która umożliwia wysyłanie środków do odległego węzła za pośrednictwem kanałów innych uczestników. Dowiemy się, w jaki sposób płatności są kierowane przez sieć, jak płynność przemieszcza się między kanałami i jak obliczane są opłaty transakcyjne.

Sieć kanałów płatności

W Lightning Network transakcja odpowiada transferowi środków między dwoma węzłami. Jak pokazano w poprzednich rozdziałach, konieczne jest otwarcie kanału z kimś, aby wykonać transakcje Lightning. Kanał ten pozwala na niemal nieskończoną liczbę transakcji off-chain przed jego zamknięciem w celu odzyskania salda On-Chain. Metoda ta ma jednak tę wadę, że wymaga bezpośredniego kanału z drugą osobą w celu otrzymania lub wysłania środków, co oznacza transakcję otwierającą i zamykającą dla każdego kanału. Jeśli planuję dokonać dużej liczby płatności z tą osobą, otwieranie i zamykanie kanału staje się opłacalne. I odwrotnie, jeśli muszę wykonać tylko kilka transakcji Lightning, otwarcie kanału bezpośredniego nie jest korzystne, ponieważ kosztowałoby mnie to 2 transakcje On-Chain dla ograniczonej liczby transakcji off-chain. Taki przypadek może wystąpić na przykład, gdy chcę zapłacić za pomocą Lightning u sprzedawcy, nie planując powrotu.

Aby rozwiązać ten problem, Lightning Network pozwala na przekierowanie płatności przez kilka kanałów i węzłów pośredniczących, umożliwiając w ten sposób transakcję bez bezpośredniego kanału z drugą osobą.

Wyobraźmy sobie na przykład taką sytuację:

LNP201

Jeśli Alice chce wysłać środki do Boba bez otwierania z nim bezpośredniego kanału, będzie musiała przejść przez Suzie, a każdy kanał będzie musiał dostosować płynność po obu stronach. Wysłane satoshis pozostają w obrębie swoich kanałów; w rzeczywistości nie "przekraczają" kanałów, ale transfer odbywa się poprzez dostosowanie wewnętrznej płynności w każdym kanale.

Załóżmy, że Alicja chce wysłać 50 000 satoshi do Boba:

LNP201

W ten sposób płatność jest kierowana do Boba poprzez ruch płynności w każdym kanale. Na koniec operacji Alice otrzymuje 50 000 Sats. Rzeczywiście przekazała 50 000 Sats, ponieważ początkowo miała 100 000. Bob, po swojej stronie, otrzymuje dodatkowe 50 000 Sats. Dla Suzie (węzła pośredniego) operacja ta jest neutralna: początkowo miała 30 000 Sats w swoim kanale z Alicją i 250 000 Sats w swoim kanale z Bobem, łącznie 280 000 Sats. Po operacji posiada 80 000 Sats w swoim kanale z Alicją i 200 000 Sats w swoim kanale z Bobem, co jest taką samą sumą jak na początku.

Transfer ten jest zatem ograniczony przez dostępną płynność w kierunku transferu.

Obliczanie limitów trasy i płynności

Weźmy teoretyczny przykład innej sieci:

LNP201

Maksymalna kwota, jaką Alice może wysłać do Boba w tej konfiguracji, wynosi 90 000 satoshi, ponieważ jest ona ograniczona przez najmniejszą płynność dostępną w kanale od Suzie do Carol. W przeciwnym kierunku (od Boba do Alicji) płatność nie jest możliwa, ponieważ strona Suzie w kanale z Alicją nie zawiera żadnych satoshi. W związku z tym nie ma żadnej trasy nadającej się do transferu w tym kierunku.

Alice wysyła kanałami 40 000 satoshi do Boba:

LNP201

Satoshi wysłane** w każdym kanale pozostają w kanale, więc satoshi wysłane przez Carol do Boba nie są takie same jak te wysłane przez Alice do Suzie. Transfer odbywa się tylko poprzez dostosowanie płynności wewnątrz każdego kanału. Co więcej, całkowita pojemność kanałów pozostaje niezmieniona.

LNP201

Podobnie jak w poprzednim przykładzie, po transakcji węzeł źródłowy (Alice) ma 40 000 satoshi mniej. Węzły pośrednie (Suzie i Carol) zachowują tę samą łączną kwotę, dzięki czemu operacja jest dla nich neutralna. Wreszcie, węzeł docelowy (Bob) otrzymuje dodatkowe 40 000 satoshi.

Rola węzłów pośrednich jest zatem bardzo ważna w funkcjonowaniu Lightning Network. Ułatwiają one transfery, oferując wiele ścieżek płatności. Aby zachęcić te węzły do zapewnienia płynności i uczestniczenia w routingu płatności, uiszczane są na ich rzecz opłaty routingowe.

Opłaty Routingowe

Węzły pośrednie stosują opłaty, aby umożliwić przekazywanie płatności przez ich kanały. Opłaty te są ustalane przez każdy węzeł dla każdego kanału. Opłaty składają się z 2 Elements:

Opłaty różnią się również w zależności od kierunku przelewu. Na przykład w przypadku przelewu z Alice do Suzie obowiązują opłaty Alice. I odwrotnie, z Suzie do Alice, stosowane są opłaty Suzie.

Na przykład, dla kanału między Alice i Suzie, możemy mieć:

LNP201

Aby lepiej zrozumieć, jak działają opłaty, przeanalizujmy ten sam Lightning Network, co poprzednio, ale teraz z następującymi opłatami za routing:

LNP201

Aby dokonać tej samej płatności w wysokości 40 000 satoshi na rzecz Boba, Alicja będzie musiała wysłać nieco więcej, ponieważ każdy węzeł pośredniczący potrąci swoje opłaty:

f*{\text{Carol-Bob}} = \text{opłata podstawowa} + \left(\frac{\text{ppm} \times \text{amount}}{10^6}\right)

f*{\text{Carol-Bob}} = 1 + \frac{1 \times 40000}{10^6} = 1 + 0.04 = 1.04 \text{ Sats}

f*{\text{Suzie-Carol}} = \text{opłata podstawowa} + \left(\frac{\text{ppm} \times \text{amount}}{10^6}\right)

f*{\text{Suzie-Carol}} = 0 + \frac{200 \times 40001.04}{10^6} = 0 + 8.0002 \approx 8 \text{ Sats}

Całkowite opłaty za tę płatność na tej ścieżce wynoszą zatem 9,04 satoshis. Zatem Alicja musi wysłać 40 009,04 satoshi, aby Bob otrzymał dokładnie 40 000 satoshi.

LNP201

Płynność jest zatem aktualizowana:

LNP201

Routing cebulowy

Aby skierować płatność od nadawcy do odbiorcy, Lightning Network wykorzystuje metodę zwaną "routingiem cebulowym". W przeciwieństwie do routingu klasycznych danych, gdzie każdy router decyduje o kierunku danych w oparciu o ich miejsce docelowe, routing cebulowy działa inaczej:

Aby zapewnić, że węzeł nadawczy może obliczyć pełną trasę do odbiorcy w routingu cebulowym, musi on utrzymywać graf sieciowy, aby znać swoją topologię i określić możliwe trasy.

**Co powinieneś wynieść z tego rozdziału?

W tym rozdziale zbadaliśmy routing płatności na Lightning Network. Pojawia się jednak pytanie: co uniemożliwia węzłom pośredniczącym akceptowanie płatności przychodzących bez przekazywania ich do następnego miejsca docelowego w celu przechwycenia transakcji? To jest właśnie rola HTLC, którą przeanalizujemy w następnym rozdziale.

HTLC - Blokada czasowa Contract

W tym rozdziale odkryjemy, w jaki sposób Lightning umożliwia przesyłanie płatności przez węzły pośredniczące bez konieczności ufania im, dzięki HTLC (Hashed Time-Locked Contracts). Te inteligentne kontrakty zapewniają, że każdy węzeł pośredniczący otrzyma środki ze swojego kanału tylko wtedy, gdy przekaże płatność ostatecznemu odbiorcy, w przeciwnym razie płatność nie zostanie zatwierdzona.

Kwestią, która pojawia się w przypadku routingu płatności, jest zatem niezbędne zaufanie do węzłów pośredniczących i między samymi węzłami pośredniczącymi. Aby to zilustrować, powróćmy do naszego uproszczonego przykładu Lightning Network z 3 węzłami i 2 kanałami:

Alice chce wysłać 40 000 Sats do Boba, ale nie ma z nim bezpośredniego kanału i nie chce go otwierać. Szuka trasy i decyduje się przejść przez węzeł Suzie.

LNP201

Jeśli Alice naiwnie wyśle 40 000 satoshi do Suzie, mając nadzieję, że Suzie przeleje tę sumę Bobowi, Suzie może zatrzymać środki dla siebie i nie przekaże niczego Bobowi.

LNP201

Aby uniknąć takiej sytuacji, w Lightning używamy HTLC (Hashed Time-Locked Contracts), które sprawiają, że płatność do węzła pośredniczącego jest warunkowa, co oznacza, że Suzie musi spełnić określone warunki, aby uzyskać dostęp do środków Alicji i przekazać je Bobowi.

Jak działają HTLC

HTLC jest specjalnym Contract opartym na dwóch zasadach:

Oto jak ten proces działa w naszym przykładzie z Alice, Suzie i Bobem:

LNP201

Tworzenie sekretu: Bob generuje losowy sekret oznaczony jako s (obraz wstępny) i oblicza jego Hash oznaczony jako r za pomocą funkcji Hash oznaczonej jako h. Mamy:

r = h(s)

Użycie funkcji Hash uniemożliwia znalezienie s tylko z h(s), ale jeśli s jest podane, łatwo jest zweryfikować, że odpowiada h(s).

LNP201

Wysłanie żądania płatności: Bob wysyła Invoice do Alicji z prośbą o płatność. Ten Invoice zawiera w szczególności Hash r.

LNP201

Wysłanie płatności warunkowej: Alicja wysyła HTLC w wysokości 40 000 satoshi do Suzie. Warunkiem otrzymania tych środków przez Suzie jest dostarczenie Alicji tajnego s' spełniającego następujące równanie:

h(s') = r
LNP201

Przekazanie HTLC ostatecznemu odbiorcy: Suzie, aby otrzymać 40 000 satoshi od Alicji, musi przekazać podobny HTLC o wartości 40 000 satoshi do Boba, który ma ten sam warunek, a mianowicie musi dostarczyć Suzie sekret s', który spełnia równanie:

h(s') = r
LNP201

Weryfikacja przez tajne s: Bob przekazuje s Suzie, aby otrzymać 40 000 satoshi obiecanych w HTLC. Dzięki temu sekretowi Suzie może odblokować HTLC Alice i otrzymać od niej 40 000 satoshi. Płatność jest następnie prawidłowo kierowana do Boba.

LNP201

Proces ten uniemożliwia Suzie zatrzymanie środków Alicji bez ukończenia transferu do Boba, ponieważ musi ona wysłać płatność do Boba, aby uzyskać tajne s, a tym samym odblokować HTLC Alicji. Operacja pozostaje taka sama, nawet jeśli trasa obejmuje kilka węzłów pośredniczących: jest to po prostu kwestia powtórzenia kroków Suzie dla każdego węzła pośredniczącego. Każdy węzeł jest chroniony przez warunki HTLC, ponieważ odblokowanie ostatniego HTLC przez odbiorcę automatycznie uruchamia odblokowanie wszystkich innych HTLC w kaskadzie.

Wygaśnięcie i zarządzanie HTLC w przypadku problemów

Jeśli podczas procesu płatności jeden z węzłów pośredniczących lub węzeł odbiorcy przestanie odpowiadać, szczególnie w przypadku awarii Internetu lub zasilania, wówczas płatność nie może zostać zakończona, ponieważ sekret potrzebny do odblokowania HTLC nie został przesłany. Biorąc pod uwagę nasz przykład z Alice, Suzie i Bobem, problem ten występuje na przykład, gdy Bob nie przesyła sekretu s do Suzie. W takim przypadku wszystkie HTLC znajdujące się przed ścieżką zostaną zablokowane, a zabezpieczone przez nie środki również.

LNP201

Aby tego uniknąć, HTLC na Lightning mają okres ważności, który pozwala na usunięcie HTLC, jeśli nie zostanie on ukończony po określonym czasie. Wygaśnięcie następuje w określonej kolejności, ponieważ zaczyna się najpierw od HTLC najbliższego odbiorcy, a następnie stopniowo przesuwa się w górę do emitenta transakcji. W naszym przykładzie, jeśli Bob nigdy nie przekaże tajemnicy s Suzie, spowoduje to wygaśnięcie HTLC Suzie wobec Boba.

LNP201

Następnie HTLC od Alice do Suzie.

LNP201

Gdyby kolejność wygaśnięcia została odwrócona, Alice mogłaby odzyskać swoją płatność, zanim Suzie zdołałaby uchronić się przed potencjalnym oszustwem. Rzeczywiście, jeśli Bob wróci, aby odebrać swój HTLC, podczas gdy Alice już usunęła swój, Suzie znalazłaby się w niekorzystnej sytuacji. Ta kaskadowa kolejność wygasania HTLC zapewnia zatem, że żaden węzeł pośredniczący nie ponosi nieuczciwych strat.

Reprezentacja HTLC w transakcjach Commitment

Transakcje Commitment reprezentują HTLC w taki sposób, że warunki, które nakładają na Lightning, mogą zostać przeniesione do Bitcoin w przypadku wymuszonego zamknięcia kanału w trakcie życia HTLC. Dla przypomnienia, transakcje Commitment reprezentują aktualny stan kanału między dwoma użytkownikami i pozwalają na jednostronne wymuszone zamknięcie w przypadku wystąpienia problemów. Z każdym nowym stanem kanału tworzone są 2 transakcje Commitment: po jednej dla każdej ze stron. Powróćmy do naszego przykładu z Alice, Suzie i Bobem, ale przyjrzyjmy się bliżej temu, co dzieje się na poziomie kanału między Alice i Suzie, gdy tworzony jest HTLC.

LNP201

Przed rozpoczęciem płatności 40 000 Sats między Alice i Bobem, Alice posiada 100 000 Sats w swoim kanale z Suzie, podczas gdy Suzie posiada 30 000. Ich transakcje Commitment wyglądają następująco:

LNP201

Alicja właśnie otrzymała Invoice Boba, który w szczególności zawiera r, Hash sekretu. Może więc skonstruować HTLC o wartości 40 000 satoshi z Suzie. Ten HTLC jest reprezentowany w ostatnich transakcjach Commitment jako wyjście o nazwie "HTLC Out" po stronie Alicji, ponieważ fundusze są wychodzące, i "HTLC In" po stronie Suzie, ponieważ fundusze są przychodzące.

LNP201

Te wyjścia powiązane z HTLC mają dokładnie takie same warunki, a mianowicie:

Warunki te mają zastosowanie tylko wtedy, gdy kanał zostanie zamknięty (tj. Commitment Transaction zostanie opublikowany On-Chain), podczas gdy HTLC jest nadal aktywny na Lightning, co oznacza, że płatność między Alice i Bobem nie została jeszcze sfinalizowana, a HTLC jeszcze nie wygasły. Dzięki tym warunkom Suzie może odzyskać należne jej 40 000 satoshi z HTLC poprzez dostarczenie s. W przeciwnym razie Alicja odzyska środki po wygaśnięciu blokady czasowej, ponieważ jeśli Suzie nie zna s, oznacza to, że nie przekazała 40 000 satoshi Bobowi, a zatem środki Alicji nie są jej należne.

Ponadto, jeśli kanał zostanie zamknięty, podczas gdy kilka HTLC jest w toku, będzie tyle dodatkowych wyjść, ile trwa HTLC.

Jeśli kanał nie zostanie zamknięty, to po wygaśnięciu lub powodzeniu płatności Lightning tworzone są nowe transakcje Commitment, aby odzwierciedlić nowy, teraz stabilny stan kanału, czyli bez żadnych oczekujących HTLC. Dane wyjściowe związane z HTLC można zatem usunąć z transakcji Commitment.

LNP201

Wreszcie, w przypadku zamknięcia kanału współpracy, gdy aktywny jest HTLC, Alice i Suzie przestają akceptować nowe płatności i czekają na rozwiązanie lub wygaśnięcie trwających HTLC. Pozwala im to opublikować lżejszą transakcję zamknięcia, bez danych wyjściowych związanych z HTLC, zmniejszając w ten sposób opłaty i unikając oczekiwania na ewentualną blokadę czasową.

**Co powinieneś wynieść z tego rozdziału?

HTLC umożliwiają kierowanie płatności Lightning przez wiele węzłów bez konieczności ufania im. Oto kluczowe punkty do zapamiętania:

W następnym rozdziale dowiemy się, w jaki sposób węzeł wydający transakcję Lightning znajduje i wybiera trasy dla swojej płatności, aby dotrzeć do węzła odbiorcy.

Znajdowanie drogi

W poprzednich rozdziałach widzieliśmy, jak korzystać z kanałów innych węzłów do kierowania płatności i docierania do węzła bez bezpośredniego połączenia z nim za pośrednictwem kanału. Omówiliśmy również, jak zapewnić bezpieczeństwo transferu bez ufania węzłom pośredniczącym. W tym rozdziale skupimy się na znalezieniu najlepszej możliwej trasy dotarcia do węzła docelowego.

Problem routingu w Lightning

Jak widzieliśmy, w Lightning to węzeł wysyłający płatność musi obliczyć pełną trasę do odbiorcy, ponieważ używamy systemu routingu cebulowego. Węzły pośredniczące nie znają ani punktu początkowego, ani ostatecznego miejsca docelowego. Wiedzą tylko, skąd pochodzi płatność i do którego węzła muszą ją następnie przesłać. Oznacza to, że węzeł wysyłający musi utrzymywać dynamiczną lokalną topologię sieci, z istniejącymi węzłami Lightning i kanałami między nimi, biorąc pod uwagę otwarcia, zamknięcia i aktualizacje stanu.

LNP201

Nawet przy takiej topologii Lightning Network, istnieją istotne informacje dla routingu, które pozostają niedostępne dla węzła wysyłającego, czyli dokładny rozkład płynności w kanałach w danym momencie. Rzeczywiście, każdy kanał wyświetla tylko swoją całkowitą pojemność, ale wewnętrzna dystrybucja środków jest znana tylko dwóm uczestniczącym węzłom. Stanowi to wyzwanie dla efektywnego routingu, ponieważ powodzenie płatności zależy w szczególności od tego, czy jej kwota jest mniejsza niż najniższa płynność na wybranej trasie. Płynności nie są jednak widoczne dla węzła wysyłającego.

LNP201

Aktualizacja mapy sieci

Aby mapa sieci była aktualna, węzły regularnie wysyłają wiadomości Exchange za pomocą algorytmu o nazwie "gossip". Jest to rozproszony algorytm używany do rozprzestrzeniania informacji w sposób epidemiczny do wszystkich węzłów w sieci, co pozwala na Exchange i synchronizację Global State kanałów w kilku cyklach komunikacyjnych. Każdy węzeł rozprzestrzenia informacje do jednego lub więcej sąsiadów wybranych losowo lub nie, ci z kolei rozprzestrzeniają informacje do innych sąsiadów i tak dalej, aż do osiągnięcia globalnie zsynchronizowanego stanu.

Dwie główne wiadomości wymieniane między węzłami Lightning są następujące:

Węzły Lightning monitorują również Bitcoin Blockchain w celu wykrycia transakcji zamknięcia kanału. Zamknięty kanał jest następnie usuwany z mapy, ponieważ nie może być już używany do kierowania naszych płatności.

Routing płatności

Weźmy przykład małej sieci Lightning Network z 7 węzłami: Alice, Bob, 1, 2, 3, 4 i 5. Wyobraźmy sobie, że Alicja chce wysłać płatność do Boba, ale musi przejść przez węzły pośredniczące.

LNP201

Oto rzeczywista dystrybucja środków w tych kanałach:

LNP201

Aby dokonać płatności w wysokości 100 000 Sats od Alicji do Boba, opcje routingu są ograniczone przez dostępną płynność w każdym kanale. Optymalną trasą dla Alicji, w oparciu o znane rozkłady płynności, może być sekwencja "Alicja → 1 → 2 → 4 → 5 → Bob":

LNP201

Ponieważ jednak Alice nie zna dokładnej dystrybucji środków w każdym kanale, musi oszacować optymalną trasę w sposób probabilistyczny, biorąc pod uwagę następujące kryteria:

Analizując te kryteria, węzeł wysyłający może przetestować najbardziej prawdopodobne trasy i spróbować je zoptymalizować. W naszym przykładzie Alice mogłaby uszeregować najlepsze trasy w następujący sposób:

Realizacja płatności

Alice postanawia przetestować swoją pierwszą trasę (Alice → 1 → 2 → 5 → Bob). W związku z tym wysyła HTLC w wysokości 100 000 Sats do węzła 1. Węzeł ten sprawdza, czy ma wystarczającą płynność z węzłem 2 i kontynuuje transmisję. Węzeł 2 odbiera następnie HTLC z węzła 1, ale zdaje sobie sprawę, że nie ma wystarczającej płynności w swoim kanale z węzłem 5, aby skierować płatność w wysokości 100 000 Sats. Następnie wysyła komunikat o błędzie z powrotem do węzła 1, który przesyła go do Alice. Ta trasa nie powiodła się.

LNP201

Następnie Alice próbuje skierować swoją płatność przy użyciu drugiej trasy (Alice → 1 → 2 → 4 → 5 → Bob). Wysyła HTLC o wartości 100 000 Sats do węzła 1, który przesyła go do węzła 2, następnie do węzła 4, do węzła 5 i wreszcie do Boba. Tym razem płynność jest wystarczająca, a trasa działa. Każdy węzeł odblokowuje swój HTLC kaskadowo przy użyciu obrazu wstępnego dostarczonego przez Boba (sekret s), co pozwala na pomyślne sfinalizowanie płatności Alicji na rzecz Boba.

LNP201

Poszukiwanie trasy odbywa się w następujący sposób: węzeł wysyłający rozpoczyna od zidentyfikowania najlepszych możliwych tras, a następnie próbuje kolejno dokonywać płatności, aż do znalezienia funkcjonalnej trasy.

Warto zauważyć, że Bob może dostarczyć Alicji informacje w Invoice, aby ułatwić routing. Na przykład może wskazać pobliskie kanały o wystarczającej płynności lub ujawnić istnienie kanałów prywatnych. Wskazówki te pozwalają Alicji unikać tras o niewielkich szansach powodzenia i najpierw wypróbować ścieżki zalecane przez Boba.

**Co powinieneś wynieść z tego rozdziału?

W następnym rozdziale zajmiemy się w szczególności funkcjonowaniem faktur, a także kilkoma innymi narzędziami używanymi w Lightning Network.

Narzędzia Lightning Network

Invoice, LNURL i Keysend

W tym rozdziale przyjrzymy się bliżej działaniu faktur Lightning, czyli żądań płatności wysyłanych przez węzeł odbiorcy do węzła nadawcy. Celem jest zrozumienie, jak płacić i otrzymywać płatności w Lightning. Omówimy również 2 alternatywy dla klasycznych faktur: LNURL i Keysend.

LNP201

Struktura faktur Lightning

Jak wyjaśniono w rozdziale dotyczącym HTLC, każda płatność rozpoczyna się od wygenerowania Invoice przez odbiorcę. Ten Invoice jest następnie przesyłany do płatnika (za pomocą kodu QR lub przez kopiowanie-wklejanie) w celu zainicjowania płatności. Invoice składa się z dwóch głównych części:

Typowa struktura Invoice zaczyna się od identyfikatora LN dla "Lightning", po którym następuje bc dla Bitcoin, a następnie ilość Invoice. Separator 1 odróżnia część czytelną dla człowieka od części danych (ładunku).

Weźmy następujący Invoice jako przykład:

lnbc100u1p0x7x7dpp5l7r9y50wrzz0lwnsqgxdks50lxtwkl0mhd9lslr4rcgdtt2n6lssp5l3pkhdx0cmc9gfsqvw5xjhph84my2frzjqxqyz5vq9qsp5k4mkzv5jd8u5n89d2yc50x7ptkl0zprx0dfjh3km7g0x98g70hsqq7sqqqgqqyqqqqlgqqvnv2k5ehwnylq3rhpd9g2y0sq9ujyxsqqypjqqyqqqqqqqqqqqsqqqqq9qsq3vql5f6e45xztgj7y6xw6ghrcz3vmh8msrz8myvhsarxg42ce9yyn53lgnryx0m6qqld8fql

Możemy już podzielić go na 2 części. Pierwsza to część czytelna dla człowieka:

lnbc100u

Następnie część przeznaczona na ładunek:


p0x7x7dpp5l7r9y50wrzz0lwnsqgxdks50lxtwkl0mhd9lslr4rcgdtt2n6lssp5l3pkhdx0cmc9gfsqvw5xjhph84my2frzjqxqyz5vq9qsp5k4mkzv5jd8u5n89d2yc50x7ptkl0zprx0dfjh3km7g0x98g70hsqq7sqqqgqqyqqqqlgqqvnv2k5ehwnylq3rhpd9g2y0sq9ujyxsqqypjqqyqqqqqqqqqqqsqqqqq9qsq3vql5f6e45xztgj7y6xw6ghrcz3vmh8msrz8myvhsarxg42ce9yyn53lgnryx0m6qqld8fql

Obie części są oddzielone znakiem 1. Separator ten został wybrany zamiast znaku specjalnego, aby umożliwić łatwe kopiowanie i wklejanie całego Invoice poprzez dwukrotne kliknięcie.

W pierwszej części możemy to zobaczyć:

Aby określić kwotę płatności, jest ona wyrażana w podjednostkach Bitcoin. Oto używane jednostki:

1 \, \text{mBTC} = 10^{-3} \, \text{BTC} = 10^5 \, \text{satoshis}
1 \, \mu\text{BTC} = 10^{-6} \, \text{BTC} = 100 \, \text{satoshis}
1 \, \text{nBTC} = 10^{-9} \, \text{BTC} = 0.1 \, \text{satoshis}
1 \, \text{pBTC} = 10^{-12} \, \text{BTC} = 0.0001 \, \text{satoshis}

Ładunek użyteczny Invoice

Ładunek Invoice zawiera kilka informacji niezbędnych do przetworzenia płatności:

Faktury są następnie kodowane w bech32, takim samym formacie jak dla adresów Bitcoin SegWit (format zaczynający się od bc1).

Wycofanie LNURL

W tradycyjnej transakcji, takiej jak zakup w sklepie, Invoice jest generowany dla całkowitej kwoty do zapłaty. Po przedstawieniu Invoice (w postaci kodu QR lub ciągu znaków) klient może go zeskanować i sfinalizować transakcję. Płatność przebiega następnie zgodnie z tradycyjnym procesem, który przeanalizowaliśmy w poprzedniej sekcji. Jednak proces ten może być czasami bardzo uciążliwy dla użytkownika, ponieważ wymaga od odbiorcy wysłania informacji do nadawcy za pośrednictwem Invoice.

W niektórych sytuacjach, takich jak wypłata bitcoinów z usługi online, tradycyjny proces jest zbyt uciążliwy. W takich przypadkach rozwiązanie do wypłat LNURL upraszcza ten proces, wyświetlając kod QR, który skanuje Wallet odbiorcy, aby automatycznie utworzyć Invoice. Następnie usługa płaci Invoice, a użytkownik po prostu widzi natychmiastową wypłatę.

LNP201

LNURL to protokół komunikacyjny, który określa zestaw funkcji zaprojektowanych w celu uproszczenia interakcji między węzłami Lightning i klientami, a także aplikacjami innych firm. Wycofanie LNURL, jak właśnie widzieliśmy, jest więc tylko jednym z przykładów wśród innych funkcjonalności.

Protokół ten opiera się na protokole HTTP i umożliwia tworzenie linków do różnych operacji, takich jak żądanie płatności, żądanie wypłaty lub inne funkcje, które poprawiają komfort użytkowania. Każdy LNURL to zakodowany w bech32 adres URL z prefiksem lnurl, który po zeskanowaniu uruchamia serię automatycznych działań na Lightning Wallet.

Na przykład funkcja LNURL-withdraw (LUD-03) umożliwia wypłacanie środków z usługi poprzez zeskanowanie kodu QR, bez konieczności ręcznego generate i Invoice. Podobnie, LNURL-auth (LUD-04) umożliwia logowanie się do usług online przy użyciu klucza prywatnego na urządzeniu Lightning Wallet zamiast hasła.

Wysyłanie płatności błyskawicznej bez Invoice: Keysend

Innym interesującym przypadkiem jest transfer środków bez wcześniejszego otrzymania Invoice, znany jako "Keysend". Protokół ten umożliwia wysyłanie środków poprzez dodanie obrazu wstępnego do zaszyfrowanych danych płatności, dostępnych tylko dla odbiorcy. Ten obraz wstępny umożliwia odbiorcy odblokowanie HTLC, a tym samym odzyskanie środków bez wcześniejszego wygenerowania Invoice.

Dla uproszczenia, w tym protokole to nadawca generuje sekret używany w HTLC, a nie odbiorca. W praktyce pozwala to nadawcy na dokonanie płatności bez konieczności wcześniejszej interakcji z odbiorcą.

LNP201

**Co powinieneś wynieść z tego rozdziału?

W następnym rozdziale zobaczymy, jak operator węzła może zarządzać płynnością w swoich kanałach, aby nigdy nie zostać zablokowanym i zawsze móc wysyłać i odbierać płatności na Lightning Network.

Zarządzanie płynnością

W tym rozdziale omówimy strategie skutecznego zarządzania płynnością na Lightning Network. Zarządzanie płynnością różni się w zależności od typu użytkownika i kontekstu. Przyjrzymy się głównym zasadom i istniejącym technikom, aby lepiej zrozumieć, jak zoptymalizować to zarządzanie.

Potrzeby w zakresie płynności

Istnieją trzy główne profile użytkowników Lightning, z których każdy ma określone potrzeby w zakresie płynności:

Profile te nie są oczywiście stałe; użytkownik może przełączać się między płatnikiem a odbiorcą w zależności od transakcji. Przykładowo, Bob może otrzymywać swoją pensję od swojego pracodawcy, co stawia go w pozycji "sprzedawcy" wymagającego płynności przychodzącej. Następnie, jeśli chce wykorzystać swoją pensję do zakupu żywności, staje się "płatnikiem" i musi mieć płynność wychodzącą.

Aby lepiej to zrozumieć, weźmy przykład prostej sieci składającej się z trzech węzłów: kupującego (Alice), routera (Suzie) i sprzedawcy (Bob).

LNP201

Wyobraźmy sobie, że kupujący chce wysłać 30 000 Sats do sprzedającego i że płatność przechodzi przez węzeł routera. Każda ze stron musi wtedy posiadać minimalną ilość płynności w kierunku płatności:

LNP201

Strategie zarządzania płynnością

Płatnicy muszą zapewnić utrzymanie wystarczającej płynności po swojej stronie kanałów, aby zagwarantować płynność wychodzącą. Okazuje się to stosunkowo proste, ponieważ wystarczy otworzyć nowe kanały Lightning, aby mieć tę płynność. Rzeczywiście, początkowe środki zablokowane w Multisig On-Chain są całkowicie po stronie płatnika w kanale Lightning na początku. Zdolność płatnicza jest zatem zapewniona tak długo, jak długo kanały są otwarte z wystarczającą ilością środków. Gdy płynność wychodząca zostanie wyczerpana, wystarczy otworzyć nowe kanały.

Z drugiej strony, dla sprzedawcy zadanie jest bardziej złożone. Aby móc otrzymywać płatności, muszą mieć płynność po przeciwnej stronie swoich kanałów. Dlatego otwarcie kanału nie wystarczy: muszą oni również dokonać płatności w tym kanale, aby przenieść płynność na drugą stronę, zanim będą mogli sami otrzymywać płatności. W przypadku niektórych profili użytkowników Lightning, takich jak handlowcy, istnieje wyraźna dysproporcja między tym, co ich węzeł wysyła, a tym, co otrzymuje, ponieważ celem firmy jest przede wszystkim zebranie więcej niż wydaje, aby generate przyniósł zysk. Na szczęście dla tych użytkowników z określonymi potrzebami w zakresie płynności przychodzącej istnieje kilka rozwiązań:

LNP201 LNP201

Wreszcie, routery, których celem jest maksymalizacja liczby przetwarzanych płatności i pobieranych opłat, muszą:

Usługa Loop Out

Usługa Loop Out, oferowana przez Lightning Labs, pozwala na przeniesienie płynności na przeciwną stronę kanału, jednocześnie odzyskując środki na Bitcoin Blockchain. Na przykład Alice wysyła 1 milion satoshi za pośrednictwem Lightning do węzła pętli, który następnie zwraca jej te środki w bitcoinach On-Chain. Równoważy to jej kanał z 1 milionem satoshi po każdej stronie, optymalizując jej zdolność do otrzymywania płatności.

LNP201

Dlatego usługa ta umożliwia przychodzącą płynność podczas odzyskiwania bitcoinów On-Chain, co pomaga ograniczyć unieruchomienie gotówki potrzebnej do akceptowania płatności za pomocą Lightning.

**Co powinieneś wynieść z tego rozdziału?

W następnym rozdziale proponuję przegląd najważniejszych koncepcji tego szkolenia.

Idź dalej

Podsumowanie kursu

W tym ostatnim rozdziale, oznaczającym koniec szkolenia LNP201, proponuję powrócić do ważnych koncepcji, które wspólnie omówiliśmy.

Celem tego szkolenia było zapewnienie kompleksowego i technicznego zrozumienia Lightning Network. Odkryliśmy, w jaki sposób Lightning Network opiera się na Bitcoin Blockchain w celu wykonywania transakcji off-chain, zachowując jednocześnie podstawowe cechy Bitcoin, w szczególności brak potrzeby ufania innym węzłom.

Kanały płatności

W początkowych rozdziałach zbadaliśmy, w jaki sposób dwie strony, otwierając kanał płatności, mogą przeprowadzać transakcje poza Bitcoin Blockchain. Oto omówione kroki:

LNP201 2. Transactions in the Channel: In this channel, it is then possible to carry out numerous transactions without having to publish them on the blockchain. Each Lightning transaction creates a new state of the channel reflected in a commitment transaction.

LNP201 LNP201

Sieć kanałów

Po zbadaniu izolowanych kanałów, rozszerzyliśmy naszą analizę na sieć kanałów:

LNP201 LNP201 LNP201

Zarządzanie płynnością

Widzieliśmy, że zarządzanie płynnością jest wyzwaniem dla Lightning, aby zapewnić płynny przepływ płatności. Wysyłanie płatności jest stosunkowo proste: wymaga jedynie otwarcia kanału. Jednak otrzymywanie płatności wymaga posiadania płynności po przeciwnej stronie swoich kanałów. Oto kilka omówionych strategii:

LNP201 LNP201 LNP201

Sekcja końcowa

Recenzje i oceny

true

Egzamin końcowy

true

Wnioski

true