Uwaga

Ten artykuł prawdopodobnie nie jest najlepszym źródłem do nauki. Jest to raczej dokumentacja tego, w jaki sposób ja sam staram się zrozumieć Lightning Network. Gdy już upewnie się, że wszystko rozumiem jak należy, powstanie osobny bardziej dopracowany artykuł (prawdopodobnie publikowany z mojego konta głównego: @noisy)

---

Bardzo mnie ostatnio interesuje temat Lightning Network tworzony dla Bitcoin. Jestem już po lekturze The Bitcoin Lightning Network”: Paper, obejrzeniu kilku wykładów na jego temat... i skłamałbym, gdybym powiedział, że wszystko jest już dla mnie intuicyjne.

Ostatnimi czasy co tydzień mamy taki zwyczaj z żoną, że w weekend gramy sobie w planszówki. Ostatnio np. graliśmy w Monopoly :) Przyszedł mi więc pomysł... by poćwiczyć sobie teorię z Lightning Network za pomocą właśnie czegoś ala gry (zapewne bardzo nudnej :P)

Jest bardzo ciekawy artykuł, który zawiera bardzo dobrze tłumaczące grafiki na temat lightning network:

Przerobiłem je sobie na takie puste:

Tutaj znajdziesz więcej użytych przez nas wzorów: http://imgur.com/a/XFoE4 (zapewne da się jeszcze uprościć)

Wszystkie kartoniki wyciąłem i wspólnie z @lenka zaczęliśmy grać w ręczne tworzenie transakcji.

Przećwiczyliśmy najpierw podstawowe koncepty, takie jak:

• niepotwierdzone transakcje
• ochrona przed double-spend
• Multisig
• zamki czasowe (timelocks)
• transakcje z dodatkowym sekretem

A następnie wzięliśmy się za ręczne otwieranie kanału płatności w celu przeprowadzenia dwóch następujących po sobie płatności, a to wszystko w sposób całkowicie bezpieczny oraz nie wymagający zaufania... i z minimalnym użyciem blockchainu (tylko do zapisania otwierającej transakcji).

Cała zabawa miała na celu zrozumieć w jakiej kolejności wszystko musi być wykonywane. Na przykład:

• kto kiedy powinien przesłać podpisaną transakcje
• kiedy należy wymieniać się sekretami i w jakiej kolejności
• co się stanie, gdy nagle ktoś będzie offline
• i jak wygląda próba oszustwa poprzez wysłanie nienajnowszej transakcji do blockchaina

Wnioski

Większość rzeczy naprawdę nie była skomplikowana. To co sprawiło nam największą trudność to aktualizacja kanału, tj. stworzenie nowych commitment transaction i deaktualizacja starych wersji.

Wyszło nam między innymi, że osoba, która zyskuje w ostatniej transakcji, defakto nie musi ujawniać sekretu przedostatniej transakcji, bowiem ewentualne użycie statusu przedostatniej transakcji jest właśnie na rękę osobie, która płaci. Faktem jest natomiast, że w przypadku tworzenia kanału dwu-kierunkowego nie koniecznie musi być wiadomo kto otrzyma następny przelew... dlatego sekret muszą generować obie strony.

Zakładamy, że @lenka przesyła do @noisy (3 BTC), sama kolejność wymiany blankietami w przypadku aktualizacji kanału według nas może wyglądać następująco:

1. @lenka i @noisy wypełniają każdy swój kartonik (jeszcze ich nie podpisują)
2. @lenka przekazuje swój blankiet @noisy'emu (transakcja dalej ma status niezakończony)
3. @noisy następnie czeka na słowo sekret od @lenka, które było hashowane w poprzedniej transakcji. Chce mieć bowiem pewność, że nie użyje ona blankietu z korzystniejszym dla siebie bilansem albo, że on będzie miał sposób udowodnienia, że nastąpiła kolejna transakcja... skoro on poznał sekret poprzedniej. By to jednak nastąpiło, ta transakcja musi zostać dokończona
4. @noisy uzupełnia otrzymany blankiet o swój nowy zahashowany sekret oraz prosi @lenka o podpis tego blankietu
5. @noisy następnie przekazuje swój blankiet do @lenka
6. @lenka uzupełnia otrzymany blankiet o swój nowy zahashowany sekret oraz prosi @noisy o podpis tego blankietu
7. po podpisaniu przez @noisy blankietu w którego posiadaniu jest @lenka, @lenka może uznać transakcje za zakończoną z jej perspektywy. Jedyny bowiem sposób dla niej, by wypłacić sobie pieniądze (pomniejszony bilans), to skorzystanie z blankietu... który każe jej co prawda czekać 900 bloków, ale dzięki któremu noisy otrzyma prawo do wypłaty natychmiast
8. @lenka chąc jednak, by noisy także uznał transakcje za zakończoną przekazuje sekret do poprzedniej transakcji - neutralizuje tymsamym siebie jako potencjalnego atakującego
9. @noisy sprawdza, czy otrzymany sekret ma taki sam hash jaki podpisał w poprzedniej transakcji. Jeżeli tak, to może uznać transakcje za zakończoną.

Podkreślam, że nie mam pojęcia czy tak to faktycznie wygląda w rzeczywistości, chcieliśmy niejako sprawdzić jaka według nas może wyglądać przykładowa implementacja aktualizacji kanału :)

Co dalej?

Lightning Network umożliwia przeprowadzanie płatności za pomocą pośredniczących wezłów (z uzyciem kanałów innych osób) w sposób niewymagający zaufania do tychże pośredników. To właśnie tymi scenariuszami będziemy bawić się w dalszej kolejności.

A później przyjdzie czas na konfrontacje naszych wymyslów z tym jak to faktycznie jest zaimplementowane :)