Awaria techniczna w sieci XRP Ledger (XRPL), która spowolniła przetwarzanie transakcji, przerodziła się w otwartą analizę architektury protokołu. David Schwartz, były dyrektor ds. technologii Ripple i współtwórca systemu, publicznie wskazał słabe punkty blockchaina, na które zwrócił uwagę incydent.
Problemy zaczęły się po tym, jak zespół XRP Ledger Operations odnotował anomalię: księgi sieci zaczęły zamykać się znacznie wolniej niż zwykle. Podczas gdy inżynierowie szukali przyczyny opóźnień, w społeczności pojawiły się pytania o niezawodność zdecentralizowanego systemu. Użytkownicy obawiali się, czy sieć może zawieść z powodu przeciążenia kilku kluczowych hubów. Schwartz włączył się do dyskusji, aby wyjaśnić rzeczywiste granice odporności XRPL.
Według oceny Schwartza oprogramowanie XRP Ledger jest chronione przez wielowarstwowy system bezpieczeństwa. Niemniej jednak teoretycznie istnieją tylko dwa scenariusze zdolne do całkowitego sparaliżowania całej sieci:
Masowa awaria infrastruktury: sytuacja, w której ogromna liczba serwerów walidatorów na całym świecie ulega jednoczesnej awarii. Taki wynik jest możliwy tylko w przypadku globalnej katastrofy naturalnej, więc deweloperzy uważają go za mało prawdopodobny.
Awaria algorytmu konsensusu: błąd w samym mechanizmie osiągania porozumienia między węzłami lub awaria innej podstawowej funkcji protokołu na poziomie kodu.
Odnotowane spowolnienie rund jest bezpośrednim dowodem na to, że technologiczne marginesy bezpieczeństwa systemu zmniejszyły się. Schwartz przyznał, że jest to wskaźnik, iż sieć znajduje się albo pod ukierunkowanym atakiem, albo wewnątrz kodu aktywował się ukryty błąd.
Jednocześnie architekt zaprzeczył plotkom o podatności blockchaina na pojedyncze punkty awarii. Sieć jest w pełni zdecentralizowana, więc wyłączenie lub przeciążenie nawet dużego huba (w tym jego własnego węzła) nie ma wpływu na ogólną operacyjność i czas działania XRPL.
Jak twórca sieci został bez logów
Głównym problemem praktycznym okazała się podatność systemów monitorowania sieci podczas szczytowych obciążeń. Gdy rundy konsensusu zwolniły, walidatory gwałtownie przeszły na maksymalne obciążenie. Własny węzeł Schwartza nie wytrzymał napływu żądań, powodując zawieszenie lokalnych połączeń RPC w stanie CLOSE_WAIT.
Z powodu tego zawieszenia wewnętrzny system monitorowania Schwartza nie był w stanie zarejestrować i przesłać danych diagnostycznych w najbardziej krytycznym momencie. W rezultacie inżynier musiał zrestartować serwer, nie rozumiejąc dokładnej przyczyny awarii.
Podczas dyskusji wyszło na jaw, że hub współtwórcy XRPL wysyłał logi do przestarzałego hosta testowego XRP Ledger Foundation (XRPLF).
Obecnie zespół inżynierów i operatorów społeczności ręcznie analizuje ocalałe logi, aby wyizolować i całkowicie wyeliminować defekt. Schwartz podsumował, że pomimo tymczasowego zmniejszenia marginesów bezpieczeństwa, zespół nie ma powodu do paniki. Deweloperzy w pełni kontrolują sytuację, a architektura kodu ma wystarczający rezerwę technologiczną, aby utrzymać sieć w działaniu.
