Dlaczego LN nie działa błyskawicznie

turtle

Lightning Network to (jak sama nazwa wskazuje) sieć w której płatności odbywać się miały błyskawicznie. Snuto nawet wizję automatycznych płatności wysyłanych co sekundę np. za oglądanie video. Niestety, jak widzimy w praktyce, płatności nie są aż tak szybkie. Zazwyczaj na płatność trzeba czekać powyżej sekundy, a w skrajnych przypadkach może to być nawet kilkadziesiąt sekund. Jestem tym nieco zawiedziony i prawdopodobnie nie jestem sam. 2 lub 3 sekundy są jeszcze w porządku, ale kilkadziesiąt sekund, to zbyt wolno. I to wszystko w sytuacji w której mamy dopiero nieco ponad 30 tysięcy kanałów. Co będzie jak ta liczba wzrośnie do 300 tysięcy lub więcej? Czy wówczas LN stanie się w praktyce bezużyteczny? Chciałbym podzielić się z Wami swoimi przemyśleniami na ten temat.

Jak to działa, że tak muli?

Skąd się biorą tak rozbieżne czasy w dokonywaniu płatności? Dlaczego czasami są to dwie sekundy, a czasem pół minuty? Płatność w LN działa w pętli. Gdy portfel wie już do kogo chce wysłać płatności i w jakiej wysokości, wyszukuje ścieżkę do odbiorcy. Gdy ją znajdzie próbuje dokonać płatności po ustalonej ścieżce. Nie ma jednak gwarancji, że płatność zakończy się sukcesem. Być może któryś z nodów w ścieżce jest akurat offline? Może być też tak, że w którymś miejscu bilans kanałów uniemożliwia pchnięcie płatności. Jeśli nie uda mu się dokonać płatności, portfel wie co było przyczyną. Stara się wówczas znaleźć nową ścieżkę z pominięciem noda, lub kanału, który płatności nie przepchnął. Dla nowej ścieżki, ponownie stara się pchnąć płatność. Jeśli nie przejdzie, wyszukuje kolejną ścieżkę. I tak dalej.

Powtarzane są więc w kółko procedury znalezienia ścieżki i próby płatności. W przypadku najpopularniejszej implementacji o nazwie LND, każde wyszukanie ścieżki trwa około 2 sekund. Nie wiem ile czasu trwa próba płatności, ale raczej o wiele mniej. Jeśli więc nasz portfel od razu da radę wysłać płatność po pierwszej znalezionej ścieżce, to płatność ta przejdzie w 2 sekundy. Jeśli uda mu się dopiero za drugim razem, to płatności idzie 4 sekundy. Itd.

I Podejrzanie długie 2 sekundy

Jak wspomniałem, w implementacji o nazwie LND pojedyncze wyszukanie ścieżki na przeciętnej klasy komputerze trwa około 2 sekund i to przy zaledwie 30 tysiącach kanałów. To jest potwornie wolno! Nie mam pojęcia, co takiego musi robić ten algorytm, żeby trwało to aż 2 sekundy. Zirytowany tą sytuacją rozpocząłem eksperymenty z własnym algorytmem wyszukiwania ścieżki. Mój algorytm daje radę znaleźć ścieżkę w jakieś 6 milisekund. Czasem, przy bardziej skomplikowanych trasach jest to 80 milisekund. Jest więc kilkaset razy szybszy od domyślnego algorytmu w LND! Czy w związku z tym algorytm w LND jest do niczego a ja stworzyłem jakieś cudo? No nie do końca. Mój algorytm ma tez swoje wady no i przede wszystkim, nie został jeszcze solidnie sprawdzony.

Z moich obserwacji wynika, że LND jako priorytet traktuje koszt transakcji. Stara się koniecznie wyszukać ścieżkę jak najtańszą. LND robi to kosztem wszystkich innych parametrów. Ja natomiast uznałem, że koszty transakcyjne nie są najważniejsze. O ile czytałem w Internecie narzekania na długi czas wykonywania transakcji w LN, to nigdy nie czytałem, by ktoś lamentował, że jego transakcja kosztowała np. 3 satoshi zamiast jednego. O ile więc domyślny algorytm znajdowania ścieżki w LND stawia przede wszystkim na zminimalizowanie fee, mój algorytm stawia na jak najszybsze wyszukanie ścieżki oraz by ścieżka dawała jak największe szanse na powodzenie transakcji. Mój algorytm stawia przede wszystkim na duże kanały. Im większa pojemność kanału, tym większa szansa, że uda się nim przeprowadzić płatność. To jednak może powodować do nadmiernego faworyzowania zbyt dużych kanałów co mogłoby prowadzić do centralizacji sieci.

Nie sądzę, bym te swoje wypociny upubliczniał. ten algorytm to tylko taki eksperyment. Można ten algorytm potraktować jako dowód, że w LN bardzo wiele można jeszcze poprawić. Ponadto algorytm wyszukiwania ścieżki jest indywidualną kwestią i nie ma problemu by istniało bardzo wiele, konkurujących ze sobą rozwiązań. LN ma w tym względzie dużą przewagę nad blockchainem. Przykładowo w Bitcoinie blok wydobywany jest średnio co 10 minut i podlega to zasadzie konsesusu. Gdybyśmy chcieli np. skrócić ten czas o połowę, wymaga to akceptacji większości sieci. Jest niezwykle problematyczne. Zwiększenie szybkości transakcji w LN jest natomiast przede wszystkim kwestią samego portfela. Spodziewam się więc sporej konkurencji na tym polu. Jestem przekonany, że powstaną lepsze, szybsze algorytmy.

Dlaczego developerzy LND sami nie napiszą szybszego algorytmu? W chwili obecnej na githubie LND ma otwarte ponad 200 “issues”, czyli różnych problemów, błędów i ulepszeń zgłoszonych przez użytkowników. Oni po prostu są zawaleni innymi problemami. Jednak ten ich wolny algorytm staje się obecnie na tyle problematyczny, że spodziewam się sporych usprawnień z ich strony.

II Shitchannels

Równie ważne (a może nawet ważniejsze) od algorytmu wyszukującego ścieżkę są same kanały płatności. W chwili obecnej w LN mamy wiele kanałów, które spokojnie mógłbym nazwać “shitchannels”. Kanały tworzone ot tak dla eksperymentów, z  małą pojemnością, często z dziwnym balansem w stylu “wszystkie środki po jednej stronie”. Taka sytuacja bardzo wydłuża proces płatności. Bardzo często jest tak, że gdy nasz portfel znajdzie ścieżkę, po której płatność raczej powinna przejść, to często po drodze są kanały o które mówiąc kolokwialnie “właściciel nie dba”. Tzn. założył je kiedyś i nie wnika np. w to, by środki były zbilansowane. Jak więc powinny być utworzone kanały?

III Precz z małymi kanałami!

Małe kanały na potrzeby wysyłania i odbierania swoich płatności można tworzyć jako kanały prywatne. Kanały publiczne natomiast służyć mają do routingu płatności i powinny być raczej duże. Nody rozpowszechniają informacje o kanałach miedzy sobą. Moim zdaniem kanałów o pewnej pojemności np. poniżej 0.01 BTC w ogóle nie powinny rozsyłać.

IV Solidne nody

Jeśli ktoś chce świadczyć “usługę” routowania transakcji to oprócz tego, że powinien tworzyć odpowiednio duże kanały, powinien również dbać by jego node był stabilny. Mowa tu o jakimś dobrym serwerze, potencjalnie zabezpieczonym choćby częściowo przed atakami DDOS, z dobrym łączem, z UPSem. Krótko mówiąc właściciel noda powinien mieć motywację, żeby być zawsze w gotowości gdy tylko ktoś postanowi użyć go do przeprowadzenia płatności. Tutaj z pomocą przychodzi prosty mechanizm, który jest już zaimplementowany. Gdy dany node nawali, zostaje wykluczony z kolejnych płatności na jakiś czas. Krótko mówiąc, nasz portfel może przechowywać czarną listę nodów, które nie przeprowadziły transakcji prawidłowo. Może się strać nie używać ich np. przez kolejny tydzień po takiej “wpadce”. Później znowu może dać mu szansę. Taki mechanizm będzie wywierał bardzo skuteczną presję na właścicielach nodów, żeby po prostu działały. Zawsze.

V Zbalansowane kanały

Nasz portfel zna łączną pojemność każdego z kanałów publicznych. Nie wie jednak jaki jest ich balans – jaka część środków znajduje się po jednej a jaka po drugiej stronie. Wyszukuje ścieżką z kanałami o pojemności na tyle dużej, by płatność miała szanse przejść. Nie daje to jednak żadnej gwarancji, że płatność przejdzie.

Od jakiegoś czasu, twórca kanału płatności może określić również maksymalną kwotę, jaką chce routować danym kanałem. Wyobrażam sobie więc, że w przyszłości ktoś założy kanał np. na 0.2 BTC, jednak zgodzi się routować kwoty maksymalnie do  0.01 BTC. Po utworzeniu kanału zbalansuje go tak, że po każdej stronie mieć będzie 0.1 BTC. Dzięki temu może pozwolić sobie na natychmiastowe zroutowanie kilku płatności pod rząd. Po 5 płatnościach na kwotę 0.1 BTC w tą sama stronę, jego balans będzie wynosił 0.15 BTC z jednej strony kanału i 0.5 BTC z drugiej strony kanału. To się powoli robi niebezpieczne, bo jeszcze 5 płatności w tą samą stronę i za chwilę z jednej strony kanału nie będzie miał nic. Gdy tak się stanie kolejnych płatności nie będzie mógł zrealizować i portfele, które “zawiódł” wpiszą go na czarną listę na kolejny tydzień. W związku z tym, taki node stara się ponownie przywrócić w swoim kanale balans w postaci 0.1 BTC po jednej i 0.1 BTC po drugiej stronie kanału. W takim celu może starać się dokonać odpowiedniej płatności w sieci LN od siebie do siebie. Jeśli w jednym kanale ma po swojej stronie za mało, a w drugim za dużo, to dokonując sprytnie spreparowanej płatności od siebie do siebie, przechodząc przez odpowiednie kanały, może zbalansować za jednym zamachem dwa ze swoich kanałow. Drugą opcją będzie użycie submarine swaps. Druga strona kanału pomoże mu zbalansować środki po prostu wysyłając do niego odpowiednią ilość BTC. W zamian otrzyma odpowiednia ilość środków na standardowy adres on-chain.

Podsumowanie

Tak więc wymieniłem 5 kwestii, które należy poprawić. Jest to zasadzie algorytm wyszukiwania oraz 4 aspekty związane z tym, żeby szansa na zroutowanie płatności już za pierwszym razem była jak największa. Uważam, że z czasem aspekty te będą ulegać poprawie i że czas wykonywania płatności zacznie spadać (nawet jeśli w tym samym czasie ilość węzłów i kanałów będzie rosła).


Chcesz wiedzieć więcej o Lightning Network? Zapraszam na grupę Lightning Network Polska na facebooku.

Leave a Reply

Your email address will not be published.