To jest opinia redakcyjna autorstwa Shinobi, samouka w dziedzinie Bitcoina i zorientowanego na technologię gospodarza podcastów Bitcoin.
Zagłuszanie kanałów jest jednym z najbardziej groźnych problemów związanych z Lightning Network. Przedstawia otwarty mechanizm ataku typu „odmowa usługi” na węzły w sieci, aby uniemożliwić im kierowanie, utratę pieniędzy, podczas gdy ich płynność jest zablokowana i nie mogą przekazywać płatności, które przyniosą im opłaty. Atakujący może skierować płatność przez inne węzły od siebie do siebie i odmówić sfinalizowania płatności. To sprawia, że ta płynność jest bezużyteczna do przekazywania innych płatności, dopóki nie wygaśnie blokada czasowa umowy z blokadą czasową (HTLC), a płatność nie zostanie zwrócona.
W zeszłym miesiącu deweloper Lightning, Antoine Riard, zaproponował formalną specyfikację rozwiązania tego problemu. W sierpniu Riard i Gleb Naumenko opublikowali badania dotyczące samego problemu, a także szeregu różnych rozwiązań, które można wykorzystać do jego złagodzenia lub rozwiązania. Jednym z proponowanych rozwiązań była forma anonimowych danych uwierzytelniających, które węzły mogłyby wykorzystać do zbudowania pewnego rodzaju systemu oceny reputacji dla użytkowników kierujących przez nie płatności bez konieczności łączenia tej reputacji ze statycznym identyfikatorem, który negatywnie wpłynąłby na prywatność ludzi. To rozwiązanie stało się teraz formalną propozycją protokołu wykonane przez Riarda w zeszłym miesiącu.
Propozycja łagodzenia zakłóceń w kanałach
Podstawa pomysł jest tokenem ecash Chaumian. Są to scentralizowane tokeny emitowane przez organ menniczy w sposób, który uniemożliwia skorelowanie wydania tokena z późniejszym wykupem tokena. Odbywa się to poprzez podpisanie tokena w sposób ślepy, umożliwiając odbiorcy tokena odkrycie go bez unieważniania podpisu. Wystawca może następnie zweryfikować, czy token jest legalny, bez możliwości połączenia tego tokena z momentem jego wystawienia.
Propozycja sugeruje użycie tych tokenów Chaumian, wydanych przez każdy węzeł routingu w sieci, jako formy dowodu reputacji. Podczas kierowania płatności token Chaumian ecash wyemitowany przez każdy węzeł w przeskoku płatności byłby umieszczany w pakiecie cebuli dla tego węzła wzdłuż płatności. Jednostki tokenów reprezentowałyby zarówno dozwoloną wartość HTLC, jak i okres blokady zwrotu. Przed przekazaniem HTLC każdy węzeł sprawdza, czy token zawarty w jego cebulowym blobie jest ważny i nigdy wcześniej nie został wykorzystany, przesyłając HTLC tylko wtedy, gdy oba te warunki są spełnione.
Jeśli HTLC pomyślnie rozliczy się z ujawnieniem obrazu wstępnego, wówczas każdy węzeł na ścieżce płatności podpisuje i zawiera nowo wyemitowany token Chaumian, który ma zostać zwrócony z powrotem do nadawcy wraz z obrazem wstępnym HTLC. Jeśli HTLC nie zostanie pomyślnie rozliczone, wówczas węzły routingu „spalają” token, umieszczając go w swojej tabeli zużytych tokenów i nie wystawiają nowego tokena. Zmusza to nadawcę do pozyskiwania nowych tokenów z tych węzłów w celu ponownego kierowania przez nie płatności. Cała koncepcja polega na tym, że ataki zagłuszające zawsze kończą się niepowodzeniem, więc w tym schemacie te tokeny wydawane przez każdy węzeł, przez który przechodzisz, są spalane, jeśli wykonasz atak zagłuszający i generujesz koszt pozyskania większej liczby, aby zrobić to ponownie. W tej chwili ataki zagłuszające kosztują tylko czas, więc spowodowałoby to dodatkowy koszt ekonomiczny.
Czas więc przedyskutować sedno problemu: jak uruchomić emisję i obieg tych tokenów w sieci? Każdy węzeł, przez który chcesz kierować, wymagałby wystawionego przez niego tokena. Rozwiązanie: zapłacić za nie. Innym proponowanym rozwiązaniem problemu zagłuszania kanałów są opłaty z góry, tj. pobieranie opłaty za choćby próbę przekierowania płatności, niezależnie od tego, czy w ogóle się powiedzie. Tak więc nawet nieudane płatności wiązałyby się z opłatą dla nadawcy.
Propozycja Riarda polega na jednorazowym zakupie tych tokenów bezpośrednio z każdego węzła. Od tego momentu, zamiast uiszczania opłat z góry za każdą płatność, o ile poprzednia płatność została pomyślnie rozliczona, otrzymasz ponownie „tokeny routingu”, które umożliwią skierowanie kolejnej proponowanej płatności bez opłaty. W ten sposób udane płatności pokrywają tylko rzeczywistą opłatę za przekierowanie, a nieudane płatności tylko opłatę z góry, co zapobiega pewnego rodzaju „podwójnej opłacie” za pomyślne płatności. Przynajmniej z ekonomicznego punktu widzenia, pomyśl o tym jako o kompromisie między obecnym stanem rzeczy, w którym nieudane płatności nic nie kosztują i tylko udane płatności są płatne, a modelem pełnej opłaty z góry, w którym wszystkie płatności są uiszczane z góry i te, które odniosły sukces, również płacą opłatę za przekierowanie.
Wynosy z propozycji
Osobiście uważam, że tego rodzaju bezpośrednia płatność za tokeny z wyprzedzeniem może wprowadzić duży stopień tarć UX do proces korzystania z Lightning Network. Myślę jednak, że istnieje całkiem proste rozwiązanie tego tarcia, zmieniając nieco propozycję.
Zamiast konieczności wcześniejszego płacenia każdemu węzłowi bezpośrednio za tokeny Chaumian, propozycję można połączyć bardziej bezpośrednio z propozycją opłaty z góry. Jeśli masz tokeny dla węzła, umieść je w cebulowej kropli, jeśli nie po prostu wpłać opłatę z góry bezpośrednio w propozycji HTLC i jeśli płatność zostanie pomyślnie rozliczona, otrzymasz z powrotem tokeny Chaumian proporcjonalnie do tego, co masz-opłata wstępna była. W ten sposób, zamiast zbierać tokeny z wielu różnych węzłów z wyprzedzeniem, po prostu zdobywasz je w trakcie dokonywania początkowych płatności, aż będziesz mieć dobrą kolekcję z różnych węzłów, z których często korzystasz i bardzo rzadko musisz ponosić koszty opłat wstępnych, aby je osiągnąć.
Innym potencjalnym źródłem tarć są operatorzy węzłów i sprowadza się to do fundamentalnych problemów samego Chaumian ecash. Aby mieć pewność, że token zostanie wydany tylko raz, emitent musi utrzymywać bazę danych wszystkich wydanych tokenów. To rośnie w nieskończoność, przez co wyszukiwanie w celu sprawdzenia ważności tokena jest coraz droższe i czasochłonne, im większa jest baza danych. Z tego powodu Riard proponuje, aby te tokeny Chaumian wygasały okresowo, na wysokości bloku reklamowanej w protokole plotek dla każdego węzła. Oznacza to, że nadawcy muszą okresowo odkupywać te tokeny lub, jeśli implementacja ma to obsługiwać, wymieniać je na nowe tokeny podpisane nowym kluczem podpisu po wygaśnięciu poprzedniego.
Spowodowałoby to albo regularne koszty ekonomiczne dla nadawców płatności, albo wymagałoby od nich okresowego sprawdzania w celu zapewnienia ponownego wystawienia po wygaśnięciu starych tokenów. W praktyce można to zautomatyzować dla osób prowadzących własne węzły Lightning, a dla dowolnych portfeli zbudowanych wokół modelu dostawcy usług Lightning (LSP), sam LSP mógłby faktycznie obsługiwać nabywanie i utrzymywanie tokenów w imieniu swoich użytkowników, obsługując udostępnianie tokenów dla płatności użytkowników. Jednak na obrzeżach, bez pełnego węzła Lightning lub LSP, może to stać się trochę irytujące dla użytkowników lekkiego portfela.
Myślę, że ta propozycja może w rzeczywistości znacznie przyczynić się do złagodzenia zagłuszania kanałów jako wektora ataku, zwłaszcza w przypadku nieco ściślejszej hybrydyzacji z podstawowym schematem opłat z góry, a większość problemów związanych z UX można obsługiwane bardzo łatwo dla użytkowników LSP i osób, które obsługują własne węzły Lightning. I nawet jeśli opłaty z góry powodują duże tarcia, możliwe, że po prostu udowodnienie kontroli nad Bitcoin UTXO może być użyte zamiast faktycznego uiszczania opłat za nabycie tokenów.
To jest gościnny wpis autorstwa Shinobi. Wyrażone opinie są całkowicie ich własnymi i niekoniecznie odzwierciedlają opinie BTC Inc lub Bitcoin Magazine.
