LN.zone, czyli jak przyjmować płatności

 

ln-accepted-here

 

Byłem niedawno na spotkaniu “Reckless club: Lightning Installation Party”. Pojechałem tam między innymi po to, żeby poznać na żywo tych wszystkich ciekawych ludzi, z którymi znałem się tylko przez Internet oraz poznać nowych. Rozmawiając z osobami, nawet mocno zaawansowanymi w temacie LN zauważyłem, że funkcjonalność i cel dla jakich tworzymy ln.zone (https://ln.zone) nie jest do końca zrozumiały i wymaga szerszego opisu. Być może dlatego, że nie do końca oczywisty jest problem, który staramy się rozwiązać.

Problem

Wyobraźmy sobie sytuację, że ktoś (np. kawiarnia) chciałaby teraz zacząć przyjmować płatności przez LN za swoje usługi. W jaki sposób miałby zacząć? Dla uproszczenia złóżmy, że cała sieć LN wygląda na razie tak (kwoty w kanałach płatności podane są w satoshich):

ln-node-01

Mamy więc dość standardową sytuację znaną z różnych opisów LN. W powyższym przykładzie każdy każedmu może przesłac jakąś ilość BTC. Przykładowo Adam może wysłać płatność Cezaremu za pośrednictwem Beaty. Załóżmy teraz, że otwieramy kawiarnię i chcieli byśmy przyjmować płatności od użytkowników. Kawiarnia stawia swojego noda LN i co dalej?

 

ln-node-02

W takiej sytuacji kawiarnia nie może w praktyce zrobić nic, by zacząć natychmiastowo przyjmować płatności. Choćby otworzyła kanał do dowolnego  innego noda, to nic to nie da dopóki całość srodków będzie w kanałach po stronie kawiarni:

ln-node-05

Po otworzeniu kanału do Beaty kawiania może wysłać płatność do dowolnej osoby, ale nie może żadnej płatności odebrać. W związku z tym problemem kawiarnia może po prostu czekać na pierwszego klienta, który otworzy z nia kanał płatności celem zapłaty za kawę:

ln-node-06

Na powyższym przykładzie Cezary przyszedł do Kawiarni i ze smutkiem stwierdził, że nie może kupić kawy przez LN dopóki nie utworzy kanału płatności z kawiarnią. Otworzył więc kanał płatności z kawiarnią, jednak nie miał ochoty czekać w kawiarni kilkudziesięciu minut na potwierdzenie otwarcia kanału. Z obrzydzeniem zapłacił więc za kawę przestarzałymi złotówkami, ale kanał płatności pozostawił na przyszłość. Tym ruchem Cezary niejako przez przypadek umożliwił każdemu wysłanie płatności do kawiarni. Gdyby teraz do kawiarni przyszedł Adam, mógłby opłacić kawę za np. 10 satoshich, co zmieniłoby stany kanałów w następujący sposób:

ln-node-07

Dla uproszczenia pominąłem opłaty transakcyjne, które Beata jak i Cezary najpewniej pobraliby za zroutowanie tej przykładowej płatności. Cezary mógłby więc czuć się zadowolony, jako że zarabia na płatności dokonywanych przez klientów kawiarni. Adam jest takim miłośnikiem kawy, że w krótkim czasie kupił łącznie 100 kaw, na które wydał łącznie 1000 satoshich. Wówczas kanały płatności wyglądałyby następująco:

 

ln-node-08

Po jakimś czasie do kawiarni wraca Cezary. Cieszy się, że wreszcie kupi kawę korzystając z LN, a tu zonk! Cezary nie może zapłacić za kawę, bo po swojej stronie kanału ma zero. Fajnie, zarobił jakieś grosze na routowaniu transakcji, ale Cezary chciał przede wszystkim móc kupić kawę.

Próby rozwiązania:

By rozwiązać ten problem, to kawiarnia powinna aktywnie podłączyć się do sieci LN tak, by umożliwić od razu użytkownikom tej sieci płacenie za kawę. Musi więc namówić kogoś, by umieścił środki po swojej stronie w kanale płatności. Kawiarnia mogłaby wysłać do wielu ludzi z okolicy e-mail tej treści:

Cześć. Otwieramy kawiarnię i przyjmujemy płatności w LN. W razie gdybyś chciał skorzystać z naszych usług, już dziś otwórz z nami kanał płatności.

Dość oczywiste jest, że to co najmniej kiepski sposób, bo skąd kawiarnia ma wiedzieć do kogo wysłać maila i kto będzie zainteresowany kupnem u nich kawy? Może łatwiej byłoby namówić kogoś do otworzenia kanału i działania jako pośrednik w routowaie transakcji? Wówczas kawiarnia mogłaby rozsyłać do użytkowników LN maile następującej treści:

Cześć. Otwieramy kawiarnię i przyjmujemy płatności w LN. Może chciałbyś otworzyć z nami kanał płatnośći i wrzucić tam z milion satoshi? Ludzie będą do nas walić drzwami i oknami. Szybko zarobisz na routingu i Ci się opłaci.

Taki mail wydaje się już rozsądniejszy, jednak pytanie czy faktycznie odbiorca maila faktycznie wrzuci ten milion satoshi w kanał do kogoś, kto twierdzi że jest kawiarnią. Skąd wiadomo, czy to w ogóle kawiarnia, a nawet jeśli to czy ta kawiarnia nie przecenie swoich możliwości. A może jest gdzieś na uboczu i starczyłoby wrzuć 100 tysięcy satoshi? Kawiarnia oczekuje więc, że ktoś zamrozi dla niej część kapitału na piękne oczy licząc na zarobek w przyszłości, który może przecież nigdy nie nadejść.

Rozważmy jeszcze kolejną opcję. Najpierw kawiarnia sama otwiera kanał płatności z kimś, kto ma potencjalnie niskie opłaty za routing i wrzuca tam tyle środków, ile zechce:

 

ln-node-09

Następnie Kawiarnia pisze maila do Beaty:

Cześć Beata. Chcieli byśmy przyjmować płatności w LN, i fajnie by było routować je przez Ciebie. W tym celu musimy umieścić bitcoiny po Twojej stronie kanału. Wyślemy Ci w tym celu 503000 satoshi naszym nowym kanałem płatności. Ty byś nam oddała 500000 satoshi, on-chain na adres <tu_zwykly adres_bitcoin>. Pozostałe 30000 satoshi weź sobie na pokrycie kosztów transakcji on-chain oraz za fatygę.

Załóżmy, że Beata zgadza się na taką propozycję. Wystawia Invoice na kwotę 503000 satoshi i gdy tylko przychodzi do niej płatność, oddaje tą prawie całą kwotę on-chain. Pozostałe 3000 satoshi, może być użyte np. na opłatę celem wykonania transakcji on-chain. A co się stanie gdy klienci wydadzą wszystkie środki i znów całość znajdzie się po stronie kawiarni? Wówczas Beata ponownie wystawia Invoice kawiarni i otrzymaną przez LN kwotę zwraca on-chain.

Jak widać, problem dało się rozwiązać, ale czy na tym ma polegać sieć, LN że co chwilę doładowujemy kanały metodą on-chain? Na szczęście kawiarnia namówiła na korzystanie z sieci LN hurtownię. Hurtownia również otworzyła kanał z Beatą na tej samej zasadzie jak opisałem wcześniej:

 

ln-node-10

Jak widzimy na powyższym diagramie, do sieci LN podłączyła się hurtownia kawy. Kawiarnia znów musi przesłać środki do Beaty, żeby móc przyjmować płatności od klientów, jednak potrzebuje akurat zakupić kawę na kwotę 500000 satoshi od hurtowni. Po zakupie kawy siec wyglądałaby następująco:

ln-node-11

Jak widzimy wysłanie płatności za kawę z użyciem sieci LN korzystnie zbalansowało kanały płatności. Tym razem odbyło się to bez konieczności wysłania transakcji on-chain! Dla transakcji korzystne było, że hurtownia zgodziła się na przyjmowanie płatności. Kawiarnia chciałaby więc, by jak najwięcej jej wydatków szło kanałami płatności bo dzięki temu jak najrzadziej musi korzystać z pomocy Beaty, która środki odsyła on-chain co jest kłopotliwe i nieco kosztowne z uwagi na wysokie koszty on-chain  w porównaniu do płatności LN.

Problem ma teraz hurtownia. Hurtownia jest teraz na takiej samej pozycji na jakiej wcześniej była Kawiarnia. Przyjmując ciągle środki w końcu całość znajdzie się w kanale płatności po stronie hurtowni i hurtownia nie może już więcej odebrać. W takim przypadku hurtownia musi prosić Beatę o to, by wystawiła invoice, a otrzymane środki oddała w formie transakcji on-chain.

Na czym w związku z tym zależy hurtowni? Na tym by wciągać kolejne podmioty do sieci LN! Nagle okazało się, że Adam – miłośnik kawy to przecież pracownik hurtowni. To czemu by mu nie płacić przez LN? Powstaje nagle zamknięte kółko – Adam otrzymuje pensję od Hurtowni, którą wydaje na kawę w Kawiarni, a Kawiarnia płaci Hurtowni, która znowu płaci Adamowi. Wraz z rozwojem sieci LN, wysyłanie płatności on-chain jest coraz rzadziej potrzebne. Beata jednak cały czas zarabia na opłatach transakcyjnych, choć oczywiście nie można wykluczyć, że za jakiś czas Kawiarnia otworzy bezpośrednio kanał płatności z Hurtownią. Beata musi więc utrzymywać opłaty transakcyjne na niskim poziomie.

Gdy do sieci podłączy się teraz sklepik osiedlowy “Stonoga”, nie musi już pisać maila do Beaty z pytaniem o zwrot środków on-chain. Stonoga otwiera kanał płatności i od razu dokonuje zakupu w Hurtowni. Po zakupie produktów w hurtowni, część środków Stonogi znajdzie się po tej drugiej stronie kanału co umożliwi jej przyjmowanie płatności w sieci LN.

Taka sytuacja to jednak jeszcze daleka przyszłość liczona raczej w latach. Póki co, nowe podmioty chcące korzystać z LN potrzebują Beaty, dzięki której mogą umieścić część środków po jej stronie kanału płatności. Taką Beatą jest właśnie ln.zone, a w przyszłości bardzo łatwo będzie mógł nią zostać każdy.

ln.zone

Ln zone to szeroki projekt w którym chcemy każdemu dać możliwość zostania tą przykładową Beatą, a każdej kawiarni dać możliwość łatwego wyszukania takiej Beaty oraz automatycznego skorzystania z jej usług. To ważne, by mechanizm działa w sposób automatyczny. W naszym przykładzie Beata mogłaby nie zwrócić pieniędzy on-chain po otrzymaniu płatości w LN. W ln.zone dzięki użyciu atomic swap, nie będzie wymagane zaufanie. LN.zone będzie projektem open source i ma umożliwić każdemu zostanie (niewymagająca zaufania) Beatą.

Stworzenie tego w sposób naprawdę porządny wymaga miesięcy pracy. Chcieli byśmy jednak, by już dzisiaj użytkownicy zrozumieli o co nam chodzi, oraz by już dzisiaj umożliwić podmiotom łatwe wejście w LN. Dlatego na stronie ln.zone umieściliśmy pierwszy (działający) zalążek naszej “Beaty”:

ln-node-12

Wystarczy wpisać adres bitcoin oraz ilość środków na jaki ma zostać wystawiony Invoice. W kolejnym kroku wystawiamy invoice, po którego opłaceniu automatycznie zwracamy środki na podany adres. Zabieramy sobie 3000 satoshi (około 1zł) na pokrycie kosztu transakcji on-chain. Zakładamy, że w najbliższym czasie raczej koszt transakcji nie wzrośnie powyżej tego poziomu.

Z pewnością dla wielu z Was strona wygląda zbyt prymitywnie. Z pewnością przydałyby się też opcje, by to np. użytkownik określił jakie fee transakcyjne powinna mieć płatność on-chain w której zwracamy środki. W końcu od tego zależy jak długo będzie czekał na potwierdzenie. My po prostu bierzemy 3000 satoshi i domyślne fee transakcyjne licząc, że nie przekroczy kwoty pobranej kwoty 3000 satoshi. Strona wymaga również Waszego zaufania do nas. Trochę potrwa zanim zdrożymy atomic swap.

Strona jest jak jest, a jest taka dlatego, że nie traktujemy jej jako priorytet. Priorytetem jest dla nas stworzenie tej funkcjonalności jako protokołu open-source. Nasz priorytet w tej chwili to umożliwić zostanie Betą każdemu kto tylko będzie miął na to ochotę.


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.