David Schwartz wyjaśnił ryzyka sieci po spowolnieniu w XRPL

Spowolnienie transakcji w sieci XRP Ledger spowodowane techniczną awarią doprowadziło do szerszej analizy architektury protokołu. David Schwartz, były dyrektor technologiczny Ripple i jeden z twórców systemu, w publicznej ocenie po incydencie opisał wrażliwe punkty sieci.

Spowolnienie zamknięć ksiąg rozpoczęło dochodzenie

Problem pojawił się, gdy zespół XRP Ledger Operations zarejestrował anomalię w sieci. Wyraźnie wolniejsze zamykanie ksiąg w sieci skłoniło inżynierów do zbadania źródła opóźnienia. W tym procesie pojawiły się również pytania dotyczące odporności zdecentralizowanej struktury w społeczności.

Schwartz powiedział, że oprogramowanie XRPL jest chronione przez wielowarstwową strukturę bezpieczeństwa. Niemniej jednak wskazał na dwa podstawowe scenariusze, które mogłyby całkowicie zatrzymać sieć. Pierwszym z nich jest jednoczesne wyłączenie wielu serwerów walidacyjnych na całym świecie. Schwartz stwierdził, że taki scenariusz byłby możliwy tylko w przypadku dużej katastrofy naturalnej na skalę globalną.

Drugim scenariuszem jest błąd w algorytmie konsensusu lub uszkodzenie jednego z podstawowych funkcji protokołu na poziomie kodu. Schwartz wyraził, że zarejestrowane spowolnienie tur w ostatnim incydencie wskazuje na zmniejszenie marginesu bezpieczeństwa technologii systemu, co może sugerować celowy atak lub ukrytą usterkę wywołaną w kodzie.

David Schwartz podkreślił, że możliwości, które mogłyby sparaliżować całą sieć, ograniczają się do masowej utraty infrastruktury lub uszkodzenia mechanizmu konsensusu, a ostatnie spowolnienie wskazuje na zmniejszenie marginesu bezpieczeństwa.

Odpowiedź na zarzuty dotyczące pojedynczego punktu awarii

Schwartz odrzucił również twierdzenia, że sieć jest uzależniona od jednego węzła lub centrum. Podkreślił, że XRPL działa w całkowicie zdecentralizowanej strukturze, a zamknięcie dużego centrum, a nawet własnego węzła, lub przeciążenie nie wpłynie bezpośrednio na ogólną funkcjonalność sieci.

Ripple, jako jedna z wiodących firm w ekosystemie XRP, rozwija infrastruktury płatnicze i rozwiązania finansowe oparte na blockchainie. XRP Ledger jest znany jako otwarta sieć blockchain działająca niezależnie od Ripple.

Systemy monitorujące zawiodły pod dużym obciążeniem

Podczas incydentu ujawniono, że najbardziej oczywistym problemem było osłabienie systemów monitorowania sieci pod dużym obciążeniem. Gdy tury konsensusu zwolniły, walidatory nagle przeszły na maksymalne obciążenie. Węzeł Schwartza również nie wytrzymał intensywnego ruchu żądań i lokalne połączenia RPC utknęły w stanie CLOSE_WAIT.

Mini słownik: RPC to metoda komunikacji, która pozwala oprogramowaniu na zdalne żądanie danych i wykonywanie poleceń z innego systemu. CLOSE_WAIT oznacza stan, w którym połączenie otrzymało sygnał zamknięcia z drugiej strony, ale proces po stronie lokalnej nie został jeszcze zakończony.

Z powodu tego zablokowania system monitorowania Schwartza nie był w stanie zarejestrować i przesłać danych diagnostycznych w najważniejszym momencie. Inżynier musiał zrestartować serwer, nie wyjaśniając dokładnie przyczyny awarii.

Schwartz poinformował, że z powodu zablokowania połączeń w swoim węźle dane diagnostyczne zostały utracone w najważniejszym momencie, a serwer został zrestartowany bez pełnego zrozumienia, dlaczego dokładnie wystąpił problem.

Badane są rejestry z dawnego serwera testowego

W trakcie dochodzenia ustalono również, że centralne logi jednego z deweloperów XRPL zostały wysłane do starego serwera testowego XRP Ledger Foundation. To dodatkowo utrudniło zbieranie danych w momencie incydentu.

Zespół inżynieryjny oraz operatorzy społeczności próbują ręcznie przeanalizować pozostałe logi, aby zidentyfikować błąd. Schwartz zauważył, że mimo tymczasowego zmniejszenia marginesu bezpieczeństwa, zespół kontroluje sytuację i architektura sieci ma wystarczające techniczne rezerwy, aby kontynuować działanie.