Mały sprośny sekrecik Lightning Network, o którym wie bardzo mało ludzi

2 126

Od Redakcji: Na dzień dobry proponujemy Wam lekturę niezwykle interesującego i inspirującego tekstu autorstwa Petera R. Rizun pt. Wizualizacja zahaszowanych zamrożonych w czasie kontraktów i sprośne małe sekreciki Lightning Network w tłumaczeniu ShadowOfHarbringer. Tylko na łamach bithub.pl jako pierwsi przeczytacie pełną, rzetelnie przetłumaczoną na język polski wersję artykułu. Czy Lightning Network to dumpster fire? Mam wrażenie, że po lekturze niniejszego tekstu będziecie mieć sporo do powiedzenia. Dziękujemy serdecznie ShadowOfHarbringer za możliwość opublikowania jego tłumaczenia. Zapraszamy do lektury.

Wizualizacja zahaszowanych zamrożonych w czasie kontraktów i sprośne małe sekreciki Lightning Network

Peter R. Rizun

Kanał przesyłowy środków w sieci Lightning Network można sobie wyobrazić jako linkę z koralikami rozciągniętą pomiędzy dwoma osobami. Odnosząc się do Fig. 1, Sebastian może zapłacić Januszowi, operatorowi węzła Lightning, przepychając jeden z jego koralików na jego stronę. Jeżeli Janusz ma także kanał Lightning do Karyny, prowadzącej sklep monopolowy, Sebastian może zapłacić Karynie za zgrzewkę piwa, poprzez Janusza: Wysyła on koralik do Janusza, który dalej przesyła koralik Karynie. Fundamentalną zasadą i przyczyną stojącą za problemami płynnościowymi Lightning Network jest niemożność opuszczenia przez koraliki nitki na której się znajdują. Mogą one poruszać się tylko w lewo i w prawo, ale nigdy z niej nie uciekną [a właściwie nie uciekną z niej aż do momentu zamknięcia otwartych kanałów – przyp. tłum].

To  jest właściwie wszystko, co potrzebujesz aby zrozumieć dopływ pieniędzy do Lightning Network. Ale ten model nie mówi nam wszystkiego o tym, czy płacenie przez Lightning jest bezpieczne. Przykładowo, co powstrzymuje Janusza przed zwyczajnym zatrzymaniem koralika wysłanego do niego przez Sebastiana i nie wysyłaniem żadnego koralika do Karyny? Celem stworzenia tego artykułu było odpowiedzenie na to pytanie: „Co czyni płatności Lightning Network nie wymagającymi zaufania [bezzaufaniowymi]?”.

Na końcu artykułu, ujawnimy ten sprośny mały sekrecik Lightning Network: Małe płatności nie są tak naprawdę w ogóle bezzaufaniowe – węzły przekazujące środki tak naprawdę mogą te, należące do klientów, środki stracić.

Zahaszowane & Zamrożone w Czasie Kontrakty (z ang. HTLC)

Aby wyjaśnić co powstrzymuje Janusza przed zatrzymaniem koralika od Sebastiana dla siebie bez wysyłania swojego koralika do Karyny, musimy wprowadzić „kłódki” do naszej fizycznej analogii kanałów Lightning Network. Kłódki mogą zostać umieszczone na linkach przez co będą blokować przepływ koralików, a otwarte mogą zostać tylko wówczas gdy określone warunki zostaną spełnione. Te Haszujące i Czaso-Zamrażające Kontrakty (zwane po angielsku skrótowo HTLC) wykorzystywane w płatnościach Lightning używają dwóch typów kłódek (patrz Fig. 2): pierwsza to kłódka, która otwiera się w momencie przedstawienia odpowiedniego hasła (nazwijmy ją „kłodką na hasło”) a druga otwiera się automatycznie po ustalonym opóźnieniu czasowym (nazwiemy ją „kłódką z wyzwalaczem czasowym”).

Powróćmy teraz do płatności jednym koralikiem od Sebastiana do Karyny poprzez Janusza. Aby uczynić płatność „bezzaufaniową”, Sebastian, Janusz  i Karyna muszą być jednocześnie online i razem uczestniczyć w złożonym rytuale.

Najpierw Sebastian prosi Karynę aby wymyśliła sekretne hasło i powiedziała mu hasz [sumę kontrolną] stworzonego hasła. Umówmy się, że hasło brzmiało „patologia” a jego hasz wyniósł  „45f8”. Następnie Sebastian umieszcza kłódkę na hasło pomiędzy nim a Januszem, kłódka jest tak skonfigurowana aby otworzyła się po podaniu hasła, które daje sumę kontrolną/hasz „45f8”. W tym momencie ani Sebastian ani Janusz nie mogą otworzyć kłódki, ponieważ żadne z nich nie zna hasła [ponieważ odwrócenie procesu haszowania nie jest możliwe – przyp. tłum]. Sebastian następnie przesyła koralik po lince do kłódki na hasło. Ostatecznie umieszcza on drugą kłódkę – z wyzwalaczem – po lewej stronie koralika. Kłódka jest ustawiona na automatyczne otwarcie po 48 godzinach (Fig. 3).

W tej sytuacji Janusz widzi, że koralik będzie jego, jeżeli odgadnie lub uzyska w inny sposób hasło zanim upłynie 48 godzin. Wie on także (ponieważ Sebastian mu powiedział) że Karyna ujawni mu hasło w zamian za jeden z jego koralików. Aby zachęcić Karynę do akcji, Janusz umieszcza taką samą kłódkę na hasło pomiędzy nim a Karyną, przepycha po lince aż do kłódki swój koralik a następnie zablokowuje koralik w miejscu za pomocą kolejnej kłódki z wyzwalaczem, ustawionym na 44 godziny (Fig. 4). Janusz wie, że w celu otworzenia kłódki na hasło i przejęcia koralika, Karyna będzie musiała wprowadzić hasło – na widoku – które to hasło jest także tym samym hasłem, którego Janusz potrzebuje aby otworzyć kłódkę na hasło pomiędzy nim a Sebastianem.

Karyna, skoro ujrzy swymi oczyma, iż koralik jest już praktycznie jej, wprowadza hasło „patologia” do kłódki (w sposób widoczny dla Janusza oczywiście – pamiętajmy o tym). „Procesor” kłódki potwierdza, że hasz(„patologia”) == „45f8” i otwiera się automatycznie. Karyna może dzięki temu przesunąć koralik na swoją stronę i nareszcie stać się jego szczęśliwą posiadaczką (Fig. 5).

Znając hasło Karyny, Janusz odblokowuje koralik przesłany przez Sebastiana w ten sam sposób (Fig 6.). Płatność zostaje dokonana.

Możesz się zastanawiać że właściwie to dlaczego w ogóle Janusz miałby się fatygować i uczestniczyć w tym rytuale? Jeżeli Karyna nie zechciałaby współpracować, jego koralik mógłby zostać zamrożony zanim kłódka z wyzwalaczem nie zakończyłaby odliczania. W praktyce jednak Sebastian wyśle Januszowi odrobinę więcej niż chce on przesłać do Karyny, jako opłatę aby skompensować powyższe ryzyko oraz za wykonaną przez niego usługę przekazywania koralików. Gdy płatność zostanie dokonana, Janusz będzie miał troszkę więcej niż miał na początku, co daje mu motywację aby zakończyć cały proces.

Możesz się także zastanawiać do czego dokładnie służą kłódki z wyzwalaczem. Te kłódki pozwalają uczestniczącym odzyskać swoje środki, jeżeli płatność nie dojdzie do skutku. Przykładowo, wyobraź sobie że Janusz w stanie upojenia alkoholowego resetuje swój komputer z uruchomionym węzłem Lightning, przez co przestaje kooperować po przesunięciu przez Sebastiana jego koralików i dodaniu dwóch kłódek. Kłódka z wyzwalaczem czasowym jest tym, co umożliwia Sebastianowi odzyskanie środków. Musi on tylko poczekać na zakończenie odliczania w wyzwalaczu.  Nie ma możliwości aby Janusz ukradł koralik w międzyczasie, ponieważ potrzebuje do tego hasła od Karyny, którego nie dostanie bez oddania Karynie jednego ze swoich koralików, co sfinalizowałoby całą płatność.

Bardziej zainteresowani czytelnicy będą też zapewne ciekawi tego co się stanie gdy któryś z uczestników przestaje współpracować podczas wykonywania różnych etapów procesu płatności Lightning Network; Mogę od razu zdradzić iż żadne z nich – Sebastian, Janusz czy Karyna – nie ryzykują stratą pieniędzy z powodu zachowania pozostałych uczestników.

Sprośny Mały Sekrecik Lightning Network

Sieć Lightning Network ma jeden mały sprośny sekrecik, o którym bardzo mało osób wie. Aby zrozumieć czym ten sekrecik jest oraz jakie są jego konsekwencje dla płatności Lightning Network, musimy kopać nieco głębiej.

Przypomnijmy sobie moment wysłania przez Sebastiana płatności do Karyny poprzez Janusza, istniał wtedy następujący stan pośredni pokazany na Fig. 7. Kiedy wyrazimy ten stan jako transakcję Bitcoin, kanał zawiera trzy „wypływy z rachunku” [wyjścia]: Monety Sebastiana, Monety Janusza oraz „Monety w locie”.

Problem jest następujący: Jeżeli wartość monet-w-locie jest poniżej progu pyłu sieci BTC [jest to ilość monet tak mała, że minerom i węzłom nie opłaca się nią zajmować – przyp. tłum.], wtedy nie może ona zostać wkomponowana w transakcję stanu kanału! Nie jest więc możliwe aby użyć kłódki na hasło oraz kłódki z wyzwalaczem aby zabezpieczyć płatność, jeżeli jest ona zbyt mała.

Aby wyjaśnić w jaki sposób LN radzi sobie z tym problemem, najpierw muszę się do czegoś przyznać. Nie do końca jest prawdą, że liczba koralików na sznurku jest stała. Tak naprawdę, to do każdego sznurka przypisane jest wiaderko podpisane „opłaty dla minerów”, które zawiera  niewielką część koralików. Zawartość tego wiaderka jest przejmowana przez minera, który potwierdzi transakcję stanu kanału, jeżeli stan kanału zostałby wypchnięty do łańcucha bloków [blockchaina]. Fragmenty koralików mogą przesuwać się z linki prosto do wiaderka lub też z wiaderka z powrotem na linkę, ale tylko jeżeli obydwie strony kanału [biorące udział w transakcji – przyp. tłum] wyrażają na to zgodę.

Zamiast blokować te „Monety w locie„ używając kłódek na hasło oraz kłódek z wyzwalaczem, dla małych płatności Sebastian i Janusz po prostu wkładają monety w locie do wiaderka z opłatami dla minerów (Fig. 8). Janusz ufa, że Sebastian będzie chciał współpracować z nim aby odebrać monety w locie z wiaderka gdy Janusz ujawni tajne hasło Karyny.

Następnie Janusz wrzuca monety-w-locie do drugiego wiaderka, które współdzieli z Karyną, obiecując dać jej te monety jeżeli powie Januszowi swoje tajne hasło. Karyna odkrywa przed Januszem swe hasło po czym Janusz oraz Karyna razem przesuwają płatność z wiaderka na opłaty na stronę Karyny. W kolejnym kroku Janusz udaje się do Sebastiana, przekazuje mu tajne hasło Karyny i jeżeli wszystko pójdzie dobrze, Sebastian współpracuje z nim aby zabrać monety w locie z wiaderka na opłaty a następnie umieścić je na sznurku po stronie Janusza.

W przeciwieństwie do Zahaszowanych i Zamrożonych w Czasie Kontraktów (HTLC), ten schemat działa w oparciu o zaufanie. Przykładowo, Karyna mogłaby ujawnić hasło Januszowi, który mógłby potem zostawić płatność w wiaderku bez ruszania jej a następnie wciąż pójść do Sebastiana i dostarczyć hasło w zamian za zapłatę.

Karyna mało może poradzić na tą sytuację: Albo nie zrobi nic i zaakceptuje stratę lub też zamknie kanał z Januszem. Ale zamknięcie kanału z Januszem wcale nie pokrywa jej strat, ponieważ wartościowe monety, które powinna była otrzymać, zamiast tego są przesłane do minera!

Pomimo tego jak zepsuty wydaje się być ten schemat, działa on względnie dobrze w praktyce. Janusz nie ma tak naprawdę powodu aby nie oddać pieniędzy Karynie. Jeżeli ich nie odda, wcale nic na tym nie zyska (miner zatrzyma dodatkowe fundusze, a nie on) a nawet prawdopodobnie na tym straci (Karyna może zamknąć kanał, jeżeli Janusz okaże się niegodny zaufania). Szkody których Janusz może dokonać wydają się ograniczone do wartości płatności plus kosztu otwarcia nowego kanału Lightning.

Czemu to jest ważne

Mały sprośny sekret Lightning jest ważny ponieważ ujawnia w jaki sposób problemy i tarcia z warstwy pierwszej L1 [czyli transakcji na łańcuchu Bitcoina – przyp. tłum.] przeciekają do warstwy drugiej L2 [LN], wymuszając tworzenie złożonych i słabo rozumianych obejść specjalnie dla protokołu L2. Obejście w tym przypadku zmieniło bezzaufaniową strukturę płatności Lightning: dla płatności powyżej progu pyłu, ani Sebastian, ani Janusz ani Karyna nie mogą stracić pieniędzy z powodu złych akcji innych uczestników. Dla płatności poniżej progu pyłu, Sebastian, Janusz i Karyna mogą stracić środki bez ich winy. To jest fundamentalnie różny model bezpieczeństwa od tego co rozumieją ludzie.

Można by argumentować, że przecież to nic istotnego, bo rozmawiamy tylko o drobnych płatnościach. Ale nie kupuję tego argumentu z dwóch powodów:

  • Plan skalowania sieci Bitcoin stworzony przez developerów Bitcoin Core jako wysoko-opłatowej sieci dla rozliczeń dużych sum zwiększy próg pyłu oraz to, co określamy jako „pył”. Ogólnie rzecz biorąc „pyłem” nazywamy wyjścia transakcji [przypływy monet na adres BTC – przyp. tłum.], które nie mogą zostać wydane bez strat z powodu opłat za transakcję na łańcuchu [„on chain”], które przekraczają wartość przesyłanych monet. Z opłatami rzędu równowartości 400 złotych, większość zarobków pracowniczych na świecie staje się takim „pyłem”.
  • Utracenie kilku małych płatności jedną po drugiej w małych odstępach czasowych (przykładowo z powodu ataku na routing w sieci Lightning Network) mogłoby prowadzić do już odczuwalnej w portfelu większej straty.

Wyobraź sobie przyszłość w której większość płatności jest wykonywana poprzez Lightning Network a opłaty transakcyjne na poziomie pierwszym L1 wynoszą stale ponad 400 złotych. Wyjścia pełne pyłu poniżej 400PLN na głównym łańcuchu nie mają żadnej wartości, ponieważ ich wydanie czy przesłanie dalej kosztuje więcej niż są warte.

W takim scenariuszu Lightning Network generuje sytuację w której nawet płatności rzędu 200 PLN nie są bezzaufaniowe gdyż znajdują się poniżej progu pyłu (co byłoby rozsądną polityką gdyby 200 PLN stało się ekonomicznie niewydawalne na warstwie pierwszej L1), więc kłódki protokołu HTLC nie mogą zostać użyte do zabezpieczenia przesyłu płatności o wartości tych dwustu złotych [i mniejszych]. Klienci mogą stracić dwieście złotych płacąc za towar zupełnie nie ze swojej winy.

Nawet jeżeli developerzy chcieliby stworzyć obejście dla tej „dziury prawnej” poprzez ustawienie progu pyłu na 4 PLN aby kłódki protokołu HTLC mogły zostać użyte, efekt będzie taki, że klient nadal traci 200 złotych ponieważ wyjście [przychodząca na adres transakcja] nie będzie mogła zostać wydana w sposób ekonomiczny (bez strat)! Klienci nadal mogą stracić płatności rzędu 200 PLN bez ich własnej winy.

Ktoś mógłby argumentować, „OK – no dobra, węzły routingowe mogą stracić środki klientów i te  środki mogą być znaczne w przyszłości gdzie królować będą wysokie opłaty, ale węzły routingowe są współuczestnikami sieci, nie biznesami.” Tego także nie kupuję ponieważ cała przyczyna routingu płatności Lightning to zarabianie pieniędzy na opłatach transakcyjnych w zamian za wypożyczanie płynności [swoich koralików na sznurku – przyp. tłum]. Nawet już dzisiaj, developerzy Lightning opuścili ideę że wszyscy użytkownicy mieliby routować transakcje; obecnie jest zalecanym aby zwykli użytkownicy używali niepublikowanych kanałów i nigdy nie routowali.

W przyszłości pełnej wysokich opłat, węzeł będący hubem płatnościowym ma efektywną kontrolę powierniczą/kustodialną nad pieniędzmi swoich użytkowników. Użytkownik nie może sam rozładować środków z kanału bezpośrednio na łańcuch bloków[blockchain] aby wynagrodzić sobie stratę spowodowaną płatnościami nie chronionymi przez kłódki protokołu HTLC. Idąc dalej, jeżeli stan konta użytkownika jest na w tym samym rzędzie wielkości co opłaty transakcyjne, użytkownik jest dodatkowo złapany w pułapkę przez hub. Zwyczajnie nie jest warte świeczki uciekanie ze złego kanału, ponieważ robiąc to użytkownik straciłby cały stan swojego konta [na tym hubie przyp. tłum.]. Huby mogą także zablokować fundusze użytkownika bez ograniczeń czasowych do czasu spełnienia jakichś żądań (przykładowo: rozwinięcia warstw anonymizującego trasowania cebulowego w celu ujawnienia do kogo są przekazywane pieniądze z powodu AML/KYC [prawa zapobiegającego praniu brudnych pieniędzy – przyp. tłum.]). Jedynym wyjściem z tej sytuacji dla użytkownika jest rozładowanie środków z powrotem na blockchain, ale przecież to nie jest żaden wybór! Huby mogą także kraść od swoich użytkowników w formie pobierania ogromnych opłat. Po raz kolejny, użytkownik jest w pułapce i nie ma wyboru innego niż zapłacić, jeżeli chce uzyskać dostęp do swoich pieniędzy.

Dobrze-połączone huby sieci Lightning w przyszłości w której opłaty on-chain są wysokie, powinny podlegać prawnej regulacji ponieważ mają efektywną kustodialną/powierniczą kontrolę nad funduszami finansowymi swoich klientów.

Stawiam hipotezę, że następujące prawo istnieje:

Płatności na warstwie drugiej L2 dla sum poniżej poziomu ekonomicznie możliwego do rozładowania na warstwę pierwszą L1 nie mogą być bezzaufaniowe.

Lightning będzie działać tak jak tego oczekują ludzie tylko wtedy, gdy leżąca pod nim warstwa blockchainowa nie jest skrępowana.

Co więcej

To jest tylko jedna z wielu przyczyn dlaczego przyszłość gdzie większość transakcji jest przeprowadzana na Lightning Network a Blockchain ma bardzo wysokie opłaty będzie zupełnie inna niż ludzie oczekują. Inne przyczyny to między in.:

  • Lightning skaluje transakcje, nie użytkowników. Koszt utrzymania pełnego węzła walidacyjnego będzie wciąż wysoki.
  • Tarcia z warstwy pierwszej L1 mają wpływ na interwymienialność i prywatność na warstwie drugiej L2; monety mają wartość-zależną-od-pozycji [wartość monet na dużym hubie o dużej płynności jest większa od wartości monet na małym hubie – przyp. tłum.]
  • Płynność: Większość „dużych zgrupowań bogactwa” [nieprzetłumaczalne – przyp. tłum] nie jest osiągalna poprzez transakcje Lightning. Błędy w płatnościach są przez to nie do uniknięcia.
  • Routing jest trudny jeżeli graf sieci jest duży: Huby Lightning będą się centralizować aby redukować problemy z płynnością i routingiem.
  • Typowe doświadczenie użytkownika w związku z utrzymywaniem portfela nie-kustodialnego/powierniczego będzie zawsze ssać: użytkownicy muszą być zawsze online aby otrzymać płatność, zatrudniać „wieże strażnicze”[watchtowers] aby monitorować kanały w celu obrony przed oszustwami kanałowymi, wynajmować się do usługi routingu-źródłowego aby wysłać płatności oraz nieustannie robić kopie zapasowe stanów swoich kanałów aby zapobiec uszkodzeniu/zanieczyszczeniu danych błędami.
  • Ryzyko systemowe: Bardzo duża ilość monet będzie musiała zostać zamrożona w kanałach Lightning (w tak zwanych gorących portfelach) aby zapewnić wymaganą płynność
  • Zebrane razem opłaty dla minerów na warstwie pierwszej L1 nie będą wystarczające aby zabezpieczyć blockchain gdy nagroda za wykopanie bloku się wyczerpie.

________________________________________________________________________________

Dodatkowe przypisy tłumacza:

Bezzaufaniowość (ang. „trustless”): Podstawowa cecha transakcji w sieci Bitcoin i innych wiodących kryptowalut. Umożliwia ona przesłanie środków innemu użytkownikowi na warstwie pierwszej L1 (czyli na samym blockchainie) bez potrzeby ufania innym uczestnikom systemu.

Transakcja on-chain (ang. „on chain tx”, „on-chain transaction”): Inaczej transakcja przeprowadzona bezpośrednio na samym łańcuchu bloków (blockchainie), bez użycia dodatkowych warstw i mechanizmów

Interwymienialność: tłumaczenie własne z angielskiego „fungibility”. W tej chwili język polski nie oferuje słowa, które w pełni oddawałoby sens odpowiednika angielskiego, więc tworzę nowe.

„Fungibility” oznacza że każda jednostka waluty o takim samym nominale jest taka sama, tak samo traktowana i tyle samo warta dla każdego uczestnika systemu. Różnorakie prawa z kategorii prania brudnych pieniędzy znacznie ograniczają interwymienialność pieniądza, bo niektóre pieniądze są uznane np. za „brudne” czyli gorsze od innych.

________________________________________________________________________________

Oryginalny autor:                              Peter R. Rizun

Tłumaczenie:                                     ShadowOfHarbringer

Adres oryginalnego artykułu:            tutaj

Komentarze