Nowo zgłoszony raport o błędzie pokazuje, że oprogramowanie XRP Ledger w wersji v3.2.0 zapisuje w logach jeden klucz walidatora, a uruchamia inny, gdy około 30% węzłów korzysta już z przeprojektowanego serwera.
Kluczowe punkty:
- Operator węzła zgłosił, że v3.2.0 zapisuje w logach nowy klucz zmigrowanego walidatora, podczas gdy serwer nadal działa na starym.
- Usterka pojawia się na Ubuntu 22.04, gdy istniejący token walidatora zostaje dodany do działającego węzła RPC.
- Adopcja aktualizacji wynosi około 30%, a większość operatorów nadal korzysta z poprzedniej wersji.
Błąd w XRP Ledger ujawnia niedopasowanie kluczy
Usterka, zgłoszona jako issue #7581 w trackerze GitHub projektu, pojawia się po tym, jak operator migruje istniejącego walidatora na już działający węzeł RPC, a następnie restartuje usługę. Log serwera raportuje nową tożsamość zmigrowanego walidatora, podczas gdy endpoint server_info wciąż zwraca starszy klucz zapisany w lokalnym pliku wallet.db. Te dwa rekordy przestają być ze sobą zgodne.
Odtworzenie rozjazdu wymaga niewielkiego wysiłku. Operator podaje, że dodanie istniejącego tokena walidatora do aktywnego węzła i restart serwera wywołują błąd na Ubuntu 22.04, co jest typową procedurą podczas rutynowych migracji.
Przeczytaj także: Czy wyprzedaż kontraktów perpetual na Anthropic jest ostrzeżeniem dla krypto-inwestycji przed IPO?
Tożsamość walidatora kotwicą konsensusu sieci
Tożsamość walidatora leży w centrum sposobu, w jaki XRP Ledger uzgadnia każdy nowy ledger. Propozycje węzła mają znaczenie tylko wtedy, gdy inne serwery ufają jego kluczowi poprzez swoje unikalne listy węzłów, więc przestarzała lub niespójna tożsamość może wprowadzić w błąd każdego, kto analizuje tę maszynę. Niespójne logi mogą spowolnić budowę zaufania.
Do tej pory niedopasowanie nie spowodowało awarii sieci. Mimo to wydłuża listę usterek, które deweloperzy oznaczyli od czasu wydania w połowie miesiąca – od problemów z synchronizacją po awarię parsera konfiguracji.
Zgłaszający zaproponował poprawkę, prosząc, aby logi usługi drukowały klucz, którego serwer faktycznie używa, lub prezentowały razem klucz pochodny i aktywny. Do zgłoszenia nie przypisano jeszcze żadnego maintainer’a. Kilka wcześniejszych raportów zostało już potwierdzonych jako błędy i trafiło do kolejki przeglądu, podczas gdy inne pozostają otwarte, gdy współtwórcy je analizują.
Adopcja spowalnia, gdy głosowanie nad poprawką trwa
Wdrażanie nowej wersji postępuje powoli. Około 30% węzłów działa obecnie na wersji 3.2.0, podczas gdy większość operatorów pozostaje przy poprzednim wydaniu 3.1.3, według publicznych danych sieciowych.
Wdrożenie rozpoczęło się 15 czerwca, gdy aktualizacja zmieniła nazwę bazowego oprogramowania z rippled na xrpld i obiecała oszczędności pamięci rzędu 30%–40%. Od tego czasu operatorzy zgłaszają problemy z synchronizacją, błędne wyliczenia relay oraz teraz niedopasowanie kluczy w nowej wersji, przy braku wydanej poprawki. Spóźniające się węzły ryzykują także stan blokowania poprawek, gdy walidatorzy zatwierdzą fixCleanup3_2_0 – zmianę porządkującą, którą Ripple już poparło w trwającym głosowaniu.
Następnie przeczytaj: Mane City Mobile trafia na iOS i Android w ponad 100 krajach