Co dalej z LN? Ustalenia z Mediolanu.

milan

LN działa już od jakiegoś czasu, pozostało jednak jeszcze wiele do zrobienia. O tym, co robić dalej, dyskutowała niedawno w Mediolanie czołówka lightningowego developmentu. Dla zainteresowanych, krótka lista tego, co zaplanowali robić w najbliższym czasie:

  • AMP, czyli Atomic Multipath Payments – Dzięki temu rozwiązaniu, pojedyncza płatność może zostać rozbita na kilka mniejszych, z których każda pójdzie inną ścieżką. Powinno to znacząco poprawić procent udanych płatności zwłaszcza dla większych kwot.
  • Dual Funded Channels – Coś co powinno istnieć od początku i zostało opisane jako podstawa w whitepaperze LN  ze stycznia 2016 roku. Niestety, póki co cały czas możliwe jest jedynie zakładanie kanału przez jedną stronę. Jednak możliwość fundowania kanału przez obie strony jest bardzo istotna. Bez tego nie ma w chwili obecnej skutecznej metody, by otworzyć kanał nastawiony na odbierania (a nie wysyłanie środków). Mim zdaniem Dual Funded Channels jest w chwili obecnej najbardziej istotną funkcjonalnością do dodania.
  • Splicing – Umożliwia dodanie nowych środków do istniejącego kanału jak i wypłatę części środków na adres on-chain. Można więc powiedzieć, że jest to dynamiczne zmienianie pojemności kanału, lecz każda taka zmiana wymaga pojedynczej transakcji on-chain. Jest to lekkie usprawnienie, jednak mniej ważne od innych. W końcu zamiast powiększać istniejący kanał, można otworzyć kolejny. Użycie Splicingu byłoby jednak wydajniejsze.
  • Wumbo – Usunięcie limitu wielkości pojedynczego kanału, który w chwili obecnej wynosi nieco ponad 0.16 BTC. Niestety, nie wiadomo kogo obwiniać o wymyślenie takiej nazwy.
  • Hidden Destinantions – Zwany inaczej Rendez-vous Routing, pozwala ukryć odbiorcę nawet przed samym nadawcą płatności. Ma to działać w ten sposób, że odbiorca wybiera sobie jakiegoś noda z sieci, który działa jako pośrednik. Sam znajduje drogę płatności od tego pośrednika do siebie, a za to wysyłającemu płatność zleca znalezienie drogi od siebie do tego pośrednika. W takiej sytuacji nikt nie zna całej drogi, jaką dana płatność przeszła od nadawcy do odbiorcy. Główną przyczyną dla jakiej planuje się wprowadzić tą innowację jest zabezpieczenie się przed próbą narzucenia regulacji typu KyC na nody. W routingu można bowiem użyć prywatnych kanałów, które są znane tylko odbiorcy.

Jako efekt spotkania w Mediolanie stworzony został taki dokument:

https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States
Co z eltoo, watchtowers  oraz submarine swaps – nie wiem. Nie ma o nich wzmianki w dokumencie. Być może są traktowane jako oddzielna usługa a nie jako część protokołu LN.

Oczywiście do stworzenia tych wszystkich elementów jeszcze długa droga. Wymaga najpierw dokładnego określenia w jaki sposób zrealizować każdą z funkcjonalności, następnie jej precyzyjnego opisania w dokumencie BOLT 1.1, a na koniec development i testy.


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.