[PL] Zrozumieć ⚡️ Lightning Network - czyli ręczne budowanie transakcji na papierze

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:

https://fs.bitcoinmagazine.com/img/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-76.jpg

Przerobiłem je sobie na takie puste:

http://i.imgur.com/r7Wq7M9.jpg http://i.imgur.com/l6xu2qf.jpg

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

http://i.imgsafe.org/0d18a83aac.jpg

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 :)