Awarie sieci Base ujawniają ryzyko pojedynczego punktu awarii

Ten nieprawidłowy blok wywołał awarię konsensusu: po bloku 47 806 542 sekwencer wyprodukował nieprawidłowy blok, uniemożliwiając sieci tworzenie kolejnych bloków. Operatorzy węzłów nie mogli kontynuować normalnej synchronizacji do czasu rozwiązania problemu.

Kalendarium dwóch awarii

Druga awaria 26 czerwca została opisana jako ta sama klasa błędu produkcji bloków, która powtórzyła się wkrótce po pierwszym incydencie, choć sieć odzyskała sprawność znacznie szybciej.

W obu przypadkach nowe bloki zostały zamrożone lub wstrzymane, zakłócając normalne przetwarzanie transakcji w łańcuchu. Niemniej jednak nie zgłoszono zagrożenia dla środków użytkowników podczas żadnego z incydentów.

Wdrożona łatka

Zespół inżynierów Base zastosował łatkę sekwencera, która zapewnia prawidłową aktualizację stanu dziennika podczas wykonywania po nieudanej transakcji. Łatka jest dostępna w publicznym pull requeście GitHub (#3806).

Po zastosowaniu poprawki normalna praca została przywrócona, ale Base zalecił operatorom węzłów walidacyjnych ponowne uruchomienie lub resynchronizację węzłów w celu przywrócenia synchronizacji. Zespół zauważył, że obie awarie wynikały z tego samego błędu, a drugi, powiązany problem (PR #3805) spowodował powtórzenie się incydentu następnego dnia.

W konsekwencji Base opóźniło planowany upgrade mainnetu Beryl i aktywację standardu tokenów B20 o jeden dzień, aby ustabilizować sieć.

Architektura pojedynczego sekwencera: szersze obawy

Te dwie awarie z rzędu odnowiły debatę na temat odporności architektury Base z pojedynczym sekwencerem, która jest powszechna wśród wielu optymistycznych rollupów, ale wprowadza wyraźny pojedynczy punkt awarii.

Kluczowe obawy podniesione w raporcie powypadkowym i komentarzach branżowych obejmują:

• Pojedynczy punkt awarii: Błąd sekwencera na poziomie logiki budowania bloków może zatrzymać całą produkcję bloków Base, zamrażając nowe bloki w całej sieci.
• Ręczne odzyskiwanie: Przywrócenie sprawności wymagało ręcznego ponownego uruchomienia lub resynchronizacji węzłów przez operatorów węzłów walidacyjnych, zamiast automatycznego samonaprawiania się sieci.
• Ryzyko niezawodności: Awarie następujące po sobie wzbudziły nowe pytania o niezawodność szybko skalującego się ekosystemu L2, szczególnie w okresach dużej aktywności lub planowanych uaktualnień.
• Planowane ulepszenia: Base zapowiedział wzmocnienie testów za pomocą testów fuzz, testów obciążeniowych, monitorowania i lepszych narzędzi odzyskiwania, aby zmniejszyć ryzyko ponownego wystąpienia.

Incydent pokazuje, że nawet największe sieci Ethereum L2 mogą zostać wyłączone przez brzegowy przypadek zarządzania stanem w pojedynczym sekwencerze – i że zautomatyzowane systemy przełączania awaryjnego i odzyskiwania są wciąż w fazie rozwoju w całym ekosystemie rollupów.