Na znanej stronie poprawek XRPL wymieniono fixCleanup3_1__3 jako aktywny od 27 maja, a zgodnie z założeniem wydarzenie to jest uaktualnieniem konserwacyjnym.
Wersja 3.1.3 rippled zawiera poprawki dla NFT, uprawnionych domen, skarbów i protokołu pożyczkowego, a blog XRPL ustawił domyślną decyzję „Tak” ze względu na ważność tych poprawek.
Proces poprawek wymaga ponad 80% wsparcia od zaufanych weryfikatorów utrzymywanych przez dwa tygodnie przed wprowadzeniem nowych zasad na stałe.
Co sprawia, że ten epizod jest wart rozpatrzenia poza terminem, to to, co powiedział współtwórca XRPL David Schwartz, o tym, czego naprawdę wymagałby prawdziwy fork, ponieważ jego odpowiedź pokazuje, jak działa legitymizacja protokołu na dowolnej blockchain.
Głównym punktem Schatzera jest to, że surowa liczba węzłów jest słabym proxy dla mocy konsensusu. System, w którym węzły głosują proporcjonalnie do ich liczby, tworzy powierzchnię ataku, gdzie każdy może uruchomić tysiące maszyn przy niskim koszcie.
W modelu XRPL każdy operator serwera prowadzi selekcjonowany zestaw weryfikatorów, którym serwer ufa, że nie będą się koordynować – Unikalną Listę Węzłów (UNL), która określa, które głosy weryfikacyjne serwer bierze pod uwagę podczas konsensusu.
Proces poprawek XRPL wymaga wsparcia od ponad 80% zaufanych weryfikatorów utrzymywanych przez dwa tygodnie przed wprowadzeniem nowych zasad na stałe, blokując serwery nieaktualizowane.
Serwer otrzymuje wiadomości weryfikacyjne od wielu węzłów w sieci, a weryfikatory w jego UNL decydują, które z tych wiadomości kształtują widok serwera na księgowość.
Schwartzer wyjaśnił, że legitymizacja konsensusu na XRPL przepływa przez listy zaufania i koordynację weryfikatorów, tworząc system, w którym zgodność UNL i ekonomiczna adopcja decydują, który księgowość przeżyje podział.
Dlaczego prawdziwy fork wymaga pełnej kampanii koordynacyjnej
W przypadku głosowania XRPL 27 maja serwery, które zostaną zablokowane poprawkami, tracą możliwość określania ważności księgowości, wysyłania lub przetwarzania transakcji, uczestniczenia w konsensusie czy głosowania nad przyszłymi poprawkami.
To czyni termin operacyjnie ważnym dla każdej giełdy, portfela, eksploratora czy operatora infrastruktury, który nadal używa oprogramowania przed 3.1.3, ponieważ te serwery staną się nieuczestnikami kanonicznej księgowości, dopóki operator nie zaktualizuje.
Infrastruktura zablokowana poprawkami traci dostęp do uaktualnionej sieci i brakuje infrastruktury koordynacyjnej, by zabezpieczyć funkcjonalnego rywala.
Aby wyprodukować wiarygodny fork, grupa sprzeciwiająca się potrzebowałaby weryfikatorów gotowych nadal produkować księgowości według starych zasad, a bez weryfikatorów nie ma strumienia księgowości do śledzenia.
Potem potrzebowaliby konkurencyjnej Unikalnej Listy Węzłów, którą serwery mogą skonfigurować albo oprogramowanie domyślnie, bo bez zaufanej listy weryfikatorów węzły nie mają mechanizmu koordynacji wokół starych zasad.
Do tego potrzebowałyby dystrybucji kodu, który zachowuje stare zasady i dostarcza domyślnie do konkurencyjnej UNL, oraz wsparcia infrastrukturalnego od portfeli, giełd, eksploratorów i aplikacji wystarczającego, by umożliwić dostęp i handel księgami według starych zasad.
Wiarygodny fork XRPL wymaga pięciu warstw poza nieaktualizowanymi węzłami: weryfikatory starych zasad, konkurencyjną UNL, kod starych zasad, wsparcie infrastrukturalne i uznanie rynkowe.
Dokumentacja XRPL przytacza badania pokazujące, że konkurencyjne UNL mogą potrzebować 90% nakładania się w najgorszym przypadku, by zapobiec forkowi, co oznacza, że każda konkurencyjna UNL musiałaby dzielić niemal cały zestaw zaufanych weryfikatorów z kanoniczną, by zachować wewnętrzną spójność.
Fork tworzony wokół radykalnie innego zestawu weryfikatorów grozi wytworzeniem księgowości, która nie będzie w stanie utrzymać własnego konsensusu, nie mówiąc już o przyciągnięciu rynkowej adopcji.
Proces poprawek faktycznie monitoruje wsparcie weryfikatorów, a próg 80% przez dwa tygodnie zapewnia, że podmioty, którym sieć ufa, osiągnęły trwałą zgodę przed wprowadzeniem nowych zasad na stałe.
Duża część nieaktualizowanych węzłów nie-weryfikatorów może odzwierciedlać opóźnienie infrastrukturalne bez implikacji dotyczących trajektorii kanonicznej księgowości.
Różnica między opóźnieniem infrastrukturalnym a konkurencyjną siecią
W scenariuszu negatywnym giełdy, portfele czy operatorzy infrastruktury, którzy pozostają w tyle po aktywacji 27 maja, zostaną zablokowane poprawkami i przestaną działać jako uczestnicy księgowości.
Użytkownicy korzystający z usług tych dostawców napotykają zakłócenia w obsłudze, takie jak transakcje, których nie można wysłać, eksploratory, które nie potwierdzają ważności księgowości, i aplikacje, które nie mogą przetwarzać płatności.
Taki koszt operacyjny spada na operatorów, którzy zaniedbali aktualizację, i warto go śledzić, szczególnie dla każdej dużej giełdy czy depozytariusza, który nadal używa węzłów przed 3.1.3 przy aktywacji.
Trwałe opóźnienie infrastrukturalne wśród wystarczającej liczby dostawców stworzy realne problemy dla użytkowników, nawet jeśli kanoniczna księgowość kontynuuje działanie według nowych zasad.
W scenariuszu pozytywnym fixCleanup3_1_3 aktywuje się zgodnie z planem, przy zachowaniu większości weryfikatorów, operatorzy infrastruktury aktualizują się bez większych incydentów, a epizod staje się rutynową aktywacją poprawek.
Poprawki dotyczące NFT, uprawnionych domen, skarbów i protokołu pożyczkowego wchodzą w życie, a sieć rusza dalej. Debata o zarządzaniu, która pojawiła się w wyniku uaktualnienia, przetrwa oba wyniki, ponieważ wyjaśnienie Schatzera, co wymagałby prawdziwy podział, dotyczy każdej przyszłej poprawki.
Utrzymanie starych zasad wymaga grupy sprzeciwiającej się, która używa starego oprogramowania, rekrutuje weryfikatorów wokół konkurencyjnej UNL i przekonuje portfele, giełdy i rynki do uznania ich księgowości za kanoniczną XRP Ledger, przeciwko domyślnej konfiguracji, która kieruje wszystkich innych do uaktualnionej sieci.
Wszystkie blockchain mają warstwę zarządzania
Schwartzer porównał to do Stellar, którego uaktualnienie Protokołu 24 samo w sobie jest poprawką stabilności dla błędu archiwizacji stanu w Stellar Core, co było wydarzeniem konserwacyjnym wymagającym tej samej koordynowanej adopcji weryfikatorów.
Ekwiwalentna warstwa legitymizacji Bitcoinu działa przez górników, węzły ekonomiczne, implementacje klientów i listy giełd. Ethereum działa przez weryfikatory, infrastrukturę stakingową, różnorodność klientów, deweloperów głównych i adopcję na poziomie aplikacji.
XRPL jasno wyraża to przez UNL, inne sieci wbudowują to w rozkład mocy górniczej, ekonomię stakingu czy społeczny konsensus, któremu deweloperzy oprogramowania klienta ufają.
Mechanizmy różnią się w Bitcoinie, Ethereum i XRPL, ale zależność od skoordynowanych decyzji ludzkich, by zmiany zasad stały się permanentne, przechodzi przez wszystkie trzy.
W XRPL, Bitcoinie, Ethereum i Stellar zmiany zasad stają się permanentne dzięki skoordynowanym decyzjom weryfikatorów, górników, deweloperów i rynków, a nie surowej liczbie węzłów.
Aktywacja 27 maja ilustruje, jak warstwa zarządzania XRPL przekształca zgodę weryfikatorów w trwałość księgowości, przy czym konfiguracja UNL decyduje, które zgody są liczone.
Operator, który nie zgadza się z fixCleanup3_1_3, ma techniczną swobodę uruchamiania starego oprogramowania i konfigurowania konkurencyjnej UNL.
Czy którakolwiek giełda wpisze powstały token, czy którykolwiek portfel go wspiera, czy którykolwiek makler zapewnia płynność, to pytanie, na które protokół nie może im odpowiedzieć.
Taka rozłączność koordynacji sprawia, że uaktualnienia protokołu w dobrze przyjętych sieciach rzadko produkuje trwałe fork: ekonomia śledzenia kanonicznej sieci prawie zawsze przewyższa ekonomię budowy równoległej sieci od podstaw, a kanoniczną siecią jest ta, którą rynek uzna za prawdziwą.
Artykuł Uaktualnienie XRPL 27 maja pokazuje, jak weryfikatory i rynki decydują o podziale blockchain pojawił się pierwszy raz na CryptoSlate.