The Lightning Network to zdecydowanie jedna z najbardziej oczekiwanych nowinek technologicznych, które nałożone zostaną na protokół bitcoina. Poseph Poon oraz Tadge Dryja stworzyli TLN rok temu jako nakładkę płatniczą, która umożliwić ma praktycznie nieograniczoną ilość transakcji poza łańcuchem bloków – za darmo i w oparciu o bezpieczeństwo samego bitcoina

Poon oraz Dryja mają własną firmę, która zajmuje się wdrażaniem tej autorskiej technologii, ale jednocześnie nad wprowadzeniem jej pracują Blockstream i Blockchain. Poza tymi dwoma nader rozpoznawalnymi formacjami, mikropłatności oraz ich rewolucyjność zdają się jednak na razie nie docierać do szerszego grona zainteresowanych.

Budowa Bloku

1. Niepotwierdzone Transakcje

Protokół bitcoin w swojej istocie składa się z transakcji, które są połączone ze wszystkimi poprzednimi oraz przyszłymi. Wejście (ang. input) transakcji, to adres, na który bitcoiny są przesyłane, natomiast wyjściem (ang. output) określa się adres wyjściowy. Przy wejściu potrzebny jest dowód (podpis), który potwierdza, że środki z danego adresu rzeczywiście należą do konkretnej osoby, która zamierza przesłać bitcoiny. W momencie wyjścia dodawane są informacje, które muszą zostać zawarte w kolejnej transakcji.

Jednym z podstawowych założeń lighting network (błyskawicznej sieci) jest oparcie jej na niezmienionym mechanizmie bitcoina. Różnica bierze się z tego, że transakcje takie zwykle nie są rozgłaszane w tradycyjny sposób. To węzły (komputery z zainstalowanym oprogramowaniem Bitcoin Core) przechowują informacje o transakcjach, ale mogą być one udostępnione w sieci w dowolnej chwili.

2. Zabezpieczenie przed podwójnym wydaniem (ang. double spending)

Zabezpieczenie przed podwójnym wydaniem środków stanowi podstawę funkcjonowania sieci Bitcoin. W momencie, kiedy dwie transakcje wejścia (input) oparte są na tym samym (wyjściu), zatwierdzona zostanie tylko jedna z nich.

3. Wielopodpisowość (ang. Multisig)

Adresy z wieloma podpisami (również P2SH) wymagają więcej niż jednego klucza prywatnego, aby móc wydać bitcoiny przypisane do adresu. Ten sposób zabezpieczeń może być wam znany z BitGo – platformy wymiany takie jak Coinbase albo Bitfinex (niedawno zhakowany) korzystają z tego rozwiązania, głównie dlatego, że jest one wygodniejsze od zimnych portfeli. Adresy wielopodpisowe wymagają więcej, niż jednego klucza prywatnego, aby wydawać Bitcoiny zawarte na adresie. Adres taki może działać na najróżniejszych zasadach takich, jak np. wymaganie dwóch z trzech kluczy w celu uzyskania dostępu, 20 z 20 – kombinacje są niezliczone. Lightning Network zwykle wymaga dwóch z dwóch kombinacji. Odblokowanie Bitcoinów z takiego adresu wymaga dwóch podpisów z dwóch odpowiadających im kluczy. W przypadku giełdy Bitfinex były to dwa z trzech wygenerowanych kluczy.

4. Zamki Czasowe

Kolejnym – czwartym – elementem lighting network są zamki czasowe. Mają one możliwość zablokowania bitcoinów na poziomie wyjścia i opóźnienie ich wydania dopiero w określonej przyszłości. Można wyróżnić dwa różne rodzaje zamków:

  1. wariant absolutny – CheckLockTimeVerify (CLTV)
  2. wariant względny – CheckSequenceVerify (CVS)

CLTV blokuje Bitcony aż do określonego (bliżej lub dalej) momentu w przyszłości; dzień i godzina lub określona ilość bloków. CSV z kolei polega na czasie względnym. Kiedy wyjście CVS pojawi się w łańcuchu bloków, ilość bloków, które muszą „upłynąć” przed ponownym wydaniem bitcoinów liczy się od tego czasu.

5. Wartości hashowe i sekrety

Piątym i ostatnim elementem jest kryptografia. Jest to najważniejszy element samego bitcoina. 

W skrócie: „wartość” lub „sekret” składa się z długiego, niepowtarzalnego ciągu liczb, praktycznie niemożliwego do odgadnięcia – nawet przy zastosowaniu komputera do wykonania nieskończonej liczby prób. Wykorzystując określoną technikę, wartość ta może zostać przetworzona na inny ciąg liczb; „hash”. Każdy, kto zna wspomnianą wartość może bez przeszkód odtworzyć hash. Nie działa to jednak w drugą stronę – znając hash, nie można odgadnąć danych wejściowych. 

Przykładowo, hash może zostać zawarty w wyjściu i wymagać od następującego po nim wejścia, aby ten zawierał odpowiadającą hashowi wartość, by Bitcoiny mogły zostać wydane.

Wyzwanie Pierwsze: Dwukierunkowe kanały płatności

Już przed zaprezentowaniem światu Lightning Network, pojęcie kanałów płatności było znane. Znane rodzaje kanałów płatności są przydatne, ale ograniczone, przez bycie jednokierunkowymi. Adam może zapłacić Bartkowi, ale Bartek już nie zapłacić Adamowi.

Jednym z podstawowych elementów Lightning Network są właśnie niewymagające zaufania, dwukierunkowe kanały płatności.

Otwarcie kanału

Przy zakładaniu dwukierunkowego kanału płatności, obaj użytkowników musi ustalić, jaką kwotę każdy z nich zdeponuje w kanale – nazywane jest to transakcją otwierającą.

Jeśli Adam chce wysłać do Bartka jednego bitcoina i zapowiada się, że transakcje takie będą przebiegać regularnie, mogą się oni zdecydować na założenie dwukierunkowego kanału do ich osobistego użytku (jeden bitcoin to trochę sporo jak na rozwiązanie skupiające się na mikropłatnościach, ale wysłanie go nie jest w żadnym wypadku niemożliwe).

Otwierając kanał Adam i Bartek przesyłają po pięć bitcoinów na adres wielodpodpisowy, wymagający dwóch z dwóch kluczy. To właśnie będzie transakcja otwierająca. Bitcoiny mogą być z tego adresu przesyłane wyłącznie w przypadku, gdy zarówno Adam, jak i Bartek podpiszą kolejną transakcję.

Dodatkowo, Adam i Bartek tworzą sekretną wartość (ciąg numerów) i wymieniają się hashem (exchange the hash).

Adam tworzy natychmiastowo kolejną transakcję na podstawie tej otwierającej. To będzie tzw. transakcja zobowiązaniowa. W jej ramach Adam przesyła sobie cztery bitcoiny, a sześć na inny wielopodpisowy adres. Ten drugi adres jest nieco nietypowy. Może on zostać odblokowany przez Bartka bez niczyjej pomocy, ale wyłącznie po odczekaniu 1000 bloków od czasu umieszczenia adresu na blockchainie – zamek CSV. W drugim przypadku Adam może otworzyć go sam, ale tylko w przypadku, gdy on również poda sekretną wartość pochodzącą z hashu Bartka, który ten właśnie jej udostępnił. Jak już wcześniej mówiliśmy, Adam nie ma możliwości posłużyć się tą wartością, skoro posiada tylko hash. W tym momencie będzie musiał obejść się smakiem.

Adam podpisuje się pod transakcją zobowiązaniową ze swojej strony, ale nie udostępnia jej na Blockchainie. Adam przekazuje ją Bartkowi.

W międzyczasie Bartek robi to samo, ale w odwrotnej kolejności. Tworzy on również transakcję zobowiązaniową, gdzie przesyła sobie samemu sześć bitcoinów, a cztery na nowy „nietypowy” wielopodpisowy adres. Adam może odblokować ten adres po odczekaniu 1000 bloków. Bartek może go odblokować od razu przy użyciu jej sekretnej wartości.

Bartek podpisuje ze swojej strony i przekazuje transakcję do Adama.

W rezultacie, po tej wymianie „na wpół ważnych” transakcji zobowiązaniowych oraz zahashowanych sekretów, obaj podpisują się i udostępniają transakcję otwierającą umieszczając ją na blockchainie. Kanał jest wówczas otwarty.

W tym momencie, zarówno Adam, jak i Bartek mogliby podpisać i wyświetlić również „na wpół ważne” transakcje zobowiązaniowe, które dostali od siebie nawzajem. Jeśli Adam to zrobi, Bartek dostanie automatycznie sześć bitcoinów. Jeśli to Bartek się na to zdecyduje, Adam dostanie automatycznie cztery. Ktokolwiek jednak podpisze i udostępni transakcję, będzie musiał poczekać 1000 bloków, aby odblokować następny adres wielopodpisowy i uzyskać pozostałe bitcoiny.

Żadne z nich nie publikuje jednak swojej połowy transakcji – na tym polega cała magia.

Aktualizowanie Kanału

Jakiś czas później, Bartek chce oddać Adamowi jeden bitcoin. Obaj chcą zaktualizować stan kanału, aby dystrybucja środków wróciła do poziomu 5-5. Aby do tego doprowadzić, potrzebne są dwa działania.

Po pierwsze, obaj powtarzają cały proces opisany powyżej (poza umieszczeniem transakcji otwierającej na Blockchainie, bo ta już tam jest). Tym razem i Adam i Bartek przypisują sobie pięć bitcoinów. Obaj przypisują też pięć bitcoinów „nietypowym adresom wielopodpisowym”. Adresy te wymagają nowych sekretnych wartości. Stąd Adam i Bartek przekazują sobie nawzajem nowe hashe. Obaj podpisują swoje „na wpół ważne” transakcje oraz wymieniają się nimi.

Po drugie, Adam i Bartek wymieniają się również swoimi „pierwotnymi” sekretami, które powstały u zarania całego kanału.

Teraz również zarówno Adam, jak i Bartek mogliby podpisać i udostępnić nowe „na wpół ważne” transakcje zobowiązaniowe, które właśnie otrzymali. Druga strona transakcji dostałaby wówczas automatycznie pięć bitcoinów, a strona udostępniająca musiałaby czekać 1000 bloków.

Kanał jest zaktualizowany

Dlaczego jednak Bartek nie miałby udostępnić wcześniejszej transakcji zobowiązaniowej? Tej, która sprawiłaby, że dostanie sześć bitcoinów zamiast pięciu?

Powstrzyma go jego „pierwotna” sekretna wartość, którą teraz ma Adam.

Bartek nie może po prostu podpisać i udostępnić starszej transakcji zobowiązaniowej, ponieważ Adam zna teraz jego pierwotny sekret. Jeśli Bartek miałby zdecydować się na ten krok, automatycznie przesłałby do Adama cztery bitcoiny, a na swoje sześć musiałby czekać 1000 bloków. Jeśli tego by było mało, Adam znając sekretną wartość Bartka mógłby wyprzedzić go również w przypadku jego sześciu bitcoinów!

Wiedząc, że Bartek ma również sekretną wartość Adama, cały mechanizm może też zadziałać w drugą stronę. Jeśli Adam spróbuje udostępnić wcześniejszą transakcję zobowiązaniową, Bartek może zgarnąć wszystkie bitcoiny z kanału.

Zasady te motywują Bartka i Adama do grania uczciwie, skłaniając ich do publikowania wyłącznie najnowszych statusów kanału.

W następnej kolejności powyższy dwukierunkowy kanał będzie musiał rozwinąć się na tyle, by umożliwiać transakcję za pośrednictwem sieci.

Tworzenie sieci

W momencie, kiedy Adam i Bartek nawiązali już dwukierunkową relację poprzez kanał płatniczy, Adam chce zapłacić jeden bitcoin osobie spoza dotychczasowej pary: Czesławowi.

Aby stało to się możliwe, Adam oraz Czesław mogliby nawiązać łączący ich nowy kanał. Nie jest to jednak konieczne. Okazuje się, że Bartek i Czesław dysponują już wspólnym kanałem, więc Adam może zwyczajnie zapłacić Czesławowi poprzez Bartka.

Polega to na tym, że Adam zapłaci Bartkowi jeden bitcoin, a Bartek przekaże go do Czesława.

Adam jednak nie ufa Bartkowi – albo Czesławowi. Sam nie wie, komu ufa. Obawia się, że przy zapłaceniu Bartkowi, nie przekaże on pieniędzy do Czesława. Może Bartek jednak zapłaci, ale Czesław powie mu, że nie dostał kasy. Wówczas Adam byłby w kropce.

Aby uniknąć tej sytuacji, Adam będzie chciał upewnić się, że do Bartka trafi jeden bitcoin wyłącznie w przypadku, gdy on sam wyśle jednego bitcoina do Czesława. Ku uciesze Adama, takie coś jest do zrobienia i wymaga zastosowania (m.in.) prostego kryptograficznego rozwiązania.

Kiedy Adam zechce wysłać Czesławowi bitcoina, powie Czesławowi, żeby utworzył wartość (losowy ciąg cyfr) i przesłał mu hash. Adam mówi również Czesławowi, aby ten wymienił wartość pierwotną za jednego bitcoina z Bartkiem.

Adam jednocześnie pobiera hash Czesława i mówi Bartkowi, że da mu bitcoina, jeśli ten poda mu przypisaną hashowi (który dostał od Czesława) wartość.

Bartek wówczas zwraca się do Czesława i daje mu jednego bitcoina w zamian za wspomnianą wartość.

Następnie Bartek podaje uzyskaną od Czesława wartość Adama i Adam już wie, że ma wszystko pod kontrolą i że może dać Bartkowi bitcoina.

Wszystko kończy się szczęśliwie.

Ale czy na pewno?

Bartek jako pośrednik musi ufać zarówno Adamowi, jak i Czesławowi. Bartek musi ufać, że Czesław wyśle mu sekretną wartość po otrzymaniu bitcoina i że Adam da mu bitcoina w zamian za wartość Czesława.

Bartek byłby w niezłych tarapatach, gdyby nie fakt, że wymiany bitcoinów za wartości są zagwarantowane w sieci. Stąd, jeśli Bartek da bitcoina Czesławowi, ma on go zagwarantowanego od Adama.

Ratunek Bartka zwie się Hash Time-Locked Contracts (HTLCs).

Kontrakty Hash Time-Locked (HTLCs)

Adam i Bartek pragną wymienić bitcoina na wartość poprzez HTLC (Bartek i Czesław chcą tej samej wymiany, ale na razie mniejsza o to).

Aby się to stało Adam nie wysyła Bartkowi bitcoina bezpośrednio, a raczej do nowego („nietypowego”) adresu wielopodpisowego. Bitcoiny zablokowane na tym adresie mogą zostać odblokowane na dwa różne sposoby.

Pierwszy sposób polega na wykorzystaniu przez Bartka swojego podpisu oraz wartości.

W ramach drugiego sposobu to Adam używa swojego podpisu. Ta opcja jest jednak objęta zamkiem czasowym CLTV. Adam może podpisać i upublicznić transakcję tylko po – powiedzmy – dwóch tygodniach.

Ten czas może zostać wykorzystany przez Bartka na stworzenie późniejszej transakcji, do której dołączy on swój podpis oraz wartość i którą upubliczni, aby przesłać bitcoina z „nietypowego” wielopodpisowego adresu do siebie. Wymiana jest zagwarantowana. Bartek może pozyskać bitcoina od Adama wyłącznie, gdy poda wartość. Upublicznienie jej na łamach sieci bitcoin podaje ją Adamowi.

Jeśli zaś Bartek nie poda wartości na czas, zaczyna się odliczanie do czasu, gdy Adam odzyska swojego Bitcoina.

Wszystko gra

Odnośnie do sieci, to właśnie system HTLC umożliwia jej funkcjonowanie.

Istotne jest, aby Bartek otrzymał wartość od Czesława, zanim Adam zdoła odzyskać swojego bitcoina od Bartka. Jeśli okaże się, że Bartek otrzyma wartość od Czesława po tym, jak Adam wycofa bitcoina, potwierdzą się najgorsze obawy Bartka. Odliczanie w ramach HTLC Bartka i Czesława musi zakończyć się przed tym Adama i Bartka – przykładowo po 10 dniach w stosunku do dwóch tygodni Adama i Bartka. Wyjaśnia to dlaczego HTLC wymagają tu CheckLockTimeVerify (CLTV), a nie CheckSequenceVerify (CSV).

Pozostał już do rozważenia tylko jeden problem: Jak uczynić Lightning Network użyteczną bez łączności z łańcuchem bloków?

Rozwiązywanie układanki i zamykanie kanału

Adam i Bartek mają swój własny dwukierunkowy kanał płatności, w który do tej pory obaj zainwestowali 5 bitcoinów. Na kanale odbyły się dwie przeciwstawne transakcje i w obecnej chwili obaj mogą uzyskać z kanału 5 bitcoinów poprzez „zrzucenie kanału” na łańcuch bloków.

Przy zastosowaniu w kanale HTLC, Bartek ma pewność, że w chwili uzyskania przez Czesława jednego bitcoina, sam Bartek otrzyma w zamian bitcoina od Adama.

Analogicznie do poprzedniego kroku, Adam oraz Bartek  zakładają transakcję zobowiązaniową. Są to transakcje nieróżniące się wiele od wcześniejszych takich transakcji. Mają one zarówno standardowy output, jak i niestandardowy prowadzący do adresu wielopodpisowego wyposażonego w zamek czasowy CSV (CheckSequenceVerify) oraz zamek hash-lock. Również, podobnie do poprzednich kroków, Adam i Bartek wymieniają się starymi poufnymi informacjami, aby unieważnić stary kanał. Po tej wymianie obaj mogą podpisać się na swoich połowach transakcji zobowiązaniowych i zrzucić je na blockchain, kiedy zechcą.

Wszystko przebiega standardowo poza jednym „szczegółem”. Transakcje zobowiązaniowe Bartka i Adama dostają nowy output, wart jeden bitcoin (równowaga jest tym samym zaburzona – Adam ma cztery btc, Bartek pięć, a nowy output jeden).

Wspomniany nowy output = HTLC. Jest on o tyle ciekawy, że można go odblokować na trzy sposoby.

Pierwszy sposób to udostępnienie przez nowy output jego Bitcoina pod warunkiem, że podpis Bartek oraz jego wartość zawarte są w kolejnej transakcji (ma to miejsce dla transakcji zobowiązaniowej zarówno Adama, jak i Bartka). W tej sytuacji tylko Bartek ma moc sprawczą, by odblokować output, niezależnie od tego, który z naszych bohaterów składa podpis. Wszystko zależy od zawarcia wartości Bartka w kolejnej transakcji. Różnica polega na tym, że jeśli to Bartek porzuci kanał, załączy się zamek czasowy CSV, który każe mu czekać na bitcoiny 1000 bloków. Adam może uzyskać swoje Bitcoiny natychmiastowo, gdy to on porzuci kanał.

Dlaczego Bartek musi czekać? Sytuacja ta pozwala Adamowi na zajęcie bitcoina w przypadku, gdy Bartek zdecyduje się na podpisanie i udostępnienie minionego statusu kanału. Należy w tym miejscu powiedzieć o drugim sposobie na odblokowanie outputu. Adam ma szansę przejąć kwotę, gdy udostępni najnowsze poufne dane Bartkowi.

Działa to też oczywiście w drugą stronę; gdy to Adam spróbuje niecnych sztuczek i udostępni kanał, który nie jest zaktualizowany, Bartek może przejąć Bitcoina przy użyciu poufnych danych Adama (bez konieczności podania wartości).

Trzecia metoda: na podstawie HTLC, obie transakcje zobowiązaniowe zawierają standardowe zabezpieczenia CLTV dla Adama. Jeśli przykładowo Bartek nie podał wartości od dwóch tygodni, ponieważ np. nie dostał jej od Czesława, Adam może odzyskać swojego bitcoina. Również tutaj nie ma znaczenia, kto porzuci kanał, Adam, czy Bartek.

Oznacza to, że zarówno Bartek, jak i Adam mają połowicznie ważną transakcję zobowiązaniową. Jeśli Adam zrzuci swoją transakcję na Blockchain, automatycznie wyśle tym samym pięć Bitcoinów do Bartka. Może też poczekać przez 1000 bloków i wziąć sobie cztery bitcoiny. Bartek ma wówczas dwa tygodnie na podanie wartości, kiedy to otrzyma bitcoina od outputu HTLC. Jeśli nic nie zrobi przez dwa tygodnie, Adam może odzyskać tego bitcoina.

Bartek może również w każdej chwili porzucić swoją transakcję zobowiązaniową oraz natychmiastowo wysłać Adamowi cztery bitcoiny. Musi następnie poczekać przez 1000 bloków, aby uzyskać pięć bitcoinów, a następnie kolejny bitcoin z outputu HTLC, jeśli poda wartość (jeśli tak się nie stanie, Adam może odzyskać swój 1btc).

Jeśli Adam albo Bartek spróbują kiedykolwiek oszukać drugą stronę, podpisując i publikując niezaktualizowany kanał, obaj mogą się nawzajem zablokować i ukraść wszystkie bitcoiny z kanału.

Ustanawianie statusu

Bartek ma zagwarantowany jeden bitcoin w zamian za podanie wartości (zakładając, że ją ma). Musi jedynie podpisać i opublikować transakcję zobowiązaniową, którą otrzymał od Adama, zawrzeć wartość w kolejnej transakcji, podpisać i wyświetlić to ostatnie.

Adam wie, że nie ma możliwości oszukania Bartka, nawet jeśli określi wartość w inny sposób.

Może między nimi dojść do porozumienia „w realu”, kiedy to Bartek przekaże wartość Adamowi, a Adam zgodzi się przywrócić kanałowi standardowy stan pozbawiony HTLC oraz limitu czasowego.

Zakładając, że obie strony chcą zachować kanał, prawdopodobnie tak by się to skończyło: rozwiązanie to obejmuje mniej zamieszania, niż zrzucanie kanału na blockchain.

Zamykanie kanału

Oto potęga Lightning Network

Opisane w artykule sytuacje prawdopodobnie nigdy nie będą musiały zetknąć się z łańcuchem bloków.

Przy „polubownym” zamknięciu kanału, Adam i Bartek mogą po prostu ustanowić transakcję na poziomie pierwszej transakcji, aby „nadpisać” wszystko, co zdarzyło się od czasu tej pierwszej transakcji. W ramach „transakcji wieńczącej” przesyłają sobie z powrotem swoje środki na podstawie najnowszego stanu kanału.

W praktyce, jeśli Adam stwierdzi, że chce zamknąć kanał, może on stworzyć transakcję, w której zapłaci sobie cztery bitcoiny, a Bartek sześć prosząc go przy tym, aby podpisał i udostępnił transakcję. Można założyć, że Bartek nie będzie protestował i kanał zostanie tym samym zamknięty.

W rezultacie, w łańcuchu bloków pojawią się tylko otwierająca i zamykająca transakcja niezależnie od tego, ile transakcji będzie miało miejsce w międzyczasie – łańcuch bloków zostanie w ten sposób znacznie odciążony.