Fundacja Sui opublikowała w niedzielę swoją analizę awarii, które trzykrotnie wyłączyły jej blockchain w czwartek i piątek, przypisując zakłócenia dwóm odrębnym błędom wprowadzonym w wersji oprogramowania v1.72.

Sprawozdanie potwierdza trzecie zatrzymanie i odpowiada na pytanie pozostawione otwarte we wcześniejszych doniesieniach The Block, dotyczące tego, czy incydenty miały wspólną przyczynę.

Zgodnie z harmonogramem fundacji, pierwsze zatrzymanie rozpoczęło się około godziny 10:00 czasu ET w czwartek i trwało do około 16:30, czyli nieco dłużej niż 5 godzin i 55 minut, o których The Block informował na stronie statusu. Druga awaria nastąpiła wcześnie w piątek i została rozwiązana późnym rankiem, a trzecia rozpoczęła się około godziny 16:30 czasu ET w piątek i trwała do około 22:20.

Pierwsze dwa zatrzymania wynikały z tej samej wady w sposobie, w jaki Sui pobiera opłaty za gaz za transakcje, ujawnionej przez funkcję „bilansów adresów” wprowadzoną w v1.72. Fundacja stwierdziła, że transakcja mogła zostać anulowana z powodu niewystarczających środków, podczas gdy sieć nadal wydawała te same środki, tworząc ujemne saldo, co powodowało awarię etapu, na którym walidatorzy uzgadniają konta.

To, co zamieniło jedną awarię w dwie, to sama poprawka. Fundacja podała, że tymczasowa poprawka, którą pośpiesznie opublikowała w czwartek, zawierała „znany problem o niskim prawdopodobieństwie spowodowania zatrzymania”, ryzyko, które zespół zaakceptował, aby szybko przywrócić łańcuch do działania, podczas gdy budowano bardziej trwałe rozwiązanie. W piątek rano sieć napotkała wariant tego problemu i zatrzymała się po raz drugi.

Trzecie zatrzymanie miało inną i wcześniej nieujawnioną przyczynę. Zostało ono wywołane, gdy walidatorzy ponownie uruchomili się, aby zainstalować poprawkę z piątkowego poranka, co uruchomiło ukryty błąd w sposobie, w jaki sieć zachowuje swoje ustawienia losowości między restartami.

Na początku każdej epoki, walidatorzy Sui uruchamiają proces konfiguracji generatora liczb losowych, na którym polegają niektóre aplikacje. Fundacja podała, że zbyt mało walidatorów było gotowych do tego procesu po restarcie, więc losowość wyłączyła się zgodnie z projektem, ale błąd spowodował, że walidatorzy nie odnotowali tej decyzji i nie mogli zakończyć epoki, zamrażając sieć po raz trzeci.

Sui stwierdziło, że walidatorzy naprawili już zarówno błąd gazu, jak i błąd losowości, że środki użytkowników nigdy nie były zagrożone, a żadne rozliczone transakcje nie zostały cofnięte po przywróceniu sieci. Stwierdzono również, że zbudowano mechanizm do wymuszonego zamknięcia zablokowanej epoki, który został użyty raz podczas odzyskiwania.

„Na dzień dzisiejszy walidatorzy w pełni zajęli się znanymi problemami spowodowanymi zarówno przez pierwotny błąd pobierania opłat za gaz, jak i błąd stanu losowości, a aktywność sieciowa została wznowiona” — napisała fundacja w swoim raporcie.

Fundacja podała również, że agenci AI z dostępem do jej systemów produkcyjnych znacząco przyspieszyli diagnostykę, zapytując dzienniki walidatorów i gromadząc metryki na żądanie we wszystkich trzech incydentach.

Błędy pojawiły się również w częściach aktualizacji mających na celu ułatwienie korzystania z Sui. The Block wcześniej informował, że v1.72 dodało bilanse adresów, które odsuwają sieć od jej wcześniejszego modelu księgowego, oraz bezgazowe transfery stablecoinów. Te funkcje zmniejszają tarcia dla użytkowników, a także stworzyły nowe ścieżki płatności za gaz, gdzie pojawiła się usterka.

Awarie wydłużają serię przestojów związanych z aktualizacjami dla Sui. The Block informował o około sześciogodzinnym zatrzymaniu w styczniu, a sieć zatrzymała się również w listopadzie 2024 roku po błędzie awarii walidatora.

SUI handlowano w niedzielę po około 0,88 USD, co oznacza spadek o około 3,3% w ciągu ostatnich 24 godzin, zgodnie ze stroną cen Sui The Block. Sui to blockchain warstwy 1 zbudowany przez Mysten Labs, którego założyciele wywodzą się z odłożonego na półkę projektu kryptograficznego Diem firmy Meta.

Fundacja oświadczyła, że planuje inwestować w ograniczanie awarii, tak aby przyszły błąd tego typu spowodował odrzucenie wadliwej transakcji, a nie zatrzymanie całej sieci.