Base zatrzymane dwukrotnie w 24 godziny: Jeden błąd, opóźniony hard fork i dyskusja o pojedynczym sekwencerze

Sieć warstwy 2 (Layer 2) Coinbase, Base, doświadczyła dwóch przestojów w produkcji bloków w ciągu 24 godzin, 25–26 czerwca 2026 r. Oba były spowodowane tym samym błędem w logice budowania bloków . Incydenty opóźniły hard fork Beryl, wywołały ostrą reakcję twórcy Jessego Pollaka oraz wznowiły krytykę projektu z pojedynczym sekwencerem jako pojedynczego punktu awarii.

Co spowodowało przestoje? Ten sam błąd, dwa razy

Oba przestoje zostały wywołane przez pojedynczy błąd w logice budowania bloków sekwencera . Oficjalne konto Base na platformie X potwierdziło, że przyczyna została zidentyfikowana i naprawiona, a wnioski przekazano innym łańcuchom OP Stack jako informację zwrotną . W szczegółowym raporcie z analizy (post-mortem) inżynierowie Base wyjaśnili, że sekwencer otrzymał nieprawidłową transakcję, która podczas wykonywania została odrzucona, ale system błędnie nie wyczyścił stanu dziennika (journal state) zawierającego konta i sloty pamięci, które zostały wcześniej użyte . Gdy natychmiast po niej wykonano prawidłową transakcję, wykorzystała ona nieaktualny stan dziennika, co doprowadziło do błędnych obliczeń gazu i wyprodukowania bloku z nieprawidłowym przejściem stanu (invalid state-transition block) [40, 45]. Ten nieprawidłowy blok zablokował potok sekwencjonowania, zatrzymując całą produkcję bloków.

Ta sama sekwencja – nieprawidłowe wyczyszczenie stanu połączone z błędnymi obliczeniami gazu – spowodowała oba przestoje [45, 47]. Podczas żadnego z incydentów środki użytkowników nie były zagrożone .

Oś czasu awarii

• 25 czerwca, ~16:03 UTC: Produkcja bloków zatrzymała się na wysokości 47 806 542 po tym, jak sekwencer wyprodukował nieprawidłowy blok, wywołując błąd konsensusu [22, 44]. Łańcuch był zatrzymany przez około dwie godziny. Inżynierowie zidentyfikowali problem o 16:52 UTC, wznowili wstępne sekwencjonowanie o 17:51 UTC, a o 17:58 UTC potwierdzili normalną produkcję bloków [22, 37].
• 26 czerwca, ~15:33 UTC: Drugi przestój, który trwał około 14 minut, zanim przywrócono działanie [21, 38].

Jesse Pollak: „Zatrzymanie nie jest w porządku”

Twórca Base, Jesse Pollak, odpowiedział publicznie na X, przyznając się do obu incydentów. Stwierdził, że środki użytkowników były bezpieczne, ale dodał wprost, że „zatrzymanie (halt) nie jest w porządku” dla platformy, która aspiruje do wspierania globalnych finansów [19, 23]. Opisał te przestoje jako niedopuszczalne dla ambicji Base i zapowiedział, że zespół wykorzysta je jako okazję do poprawy stabilności i niezawodności platformy .

Hard fork Beryl opóźniony o jeden dzień

Hard fork Beryl – druga samodzielna aktualizacja sieci Base – był pierwotnie zaplanowany na 25 czerwca o 18:00 UTC [12, 14]. Po pierwszym przestoju Base przesunął aktualizację na 26 czerwca, godz. 18:00 UTC, aby zapewnić pełną operacyjność Rejestru Aktywacji B20 przed aktywacją [15, 16]. Zespół podkreślił, że awaria i aktualizacja nie były ze sobą powiązane [16, 20].

Co wprowadza Beryl

Beryl łączy trzy główne zmiany :

• Standard tokenów B20: Natywny standard tokenów Base dla stablecoinów, aktywów ze świata rzeczywistego (RWA) i emitentów tokenów długiego ogona (long-tail), zaimplementowany jako prekompilowany w języku Rust, kompatybilny z ERC-20, wbudowany bezpośrednio w oprogramowanie węzła [1, 14, 11].
• Krótszy okres wypłat: Finalizacja wypłat z pojedynczym dowodem skrócona z 7 dni do 5 dni [1, 12].
• Integracja Reth V2: Kompleksowa modernizacja klienta wykonawczego, która zmniejsza wykorzystanie dysku o około 50% i zwiększa przepustowość o około 33% [1, 10, 14].

Odnowiona krytyka architektury z pojedynczym sekwencerem

Przestoje odnowiły długotrwałą krytykę, że projekt z pojedynczym sekwencerem (single-sequencer) w Base stwarza pojedynczy punkt awarii [33, 36]. Ponieważ Base działa z jednym sekwencerem obsługiwanym przez Coinbase w ramach stosu OP Stack, nie było zapasowych sekwencerów ani węzłów walidacyjnych, które mogłyby przejąć działanie, gdy nieprawidłowy blok zablokował potok . Wielu analityków i członków społeczności wskazało na tę architekturę jako źródło systemowego ryzyka, argumentując, że model z pojedynczym sekwencerem jest z natury nieodporny na awarie w sieci dążącej do obsługi globalnej infrastruktury finansowej [33, 36].

Co dalej

Base opublikował pełny raport z analizy (post-mortem) dotyczący awarii z 25 czerwca, a zespół poinformował, że przekazał wnioski innym łańcuchom OP Stack jako informację zwrotną [45, 47]. Hard fork Beryl został pomyślnie aktywowany 26 czerwca, ale incydenty pozostawiły otwarte pytanie: czy łańcuch oparty na jednym sekwencerze może wiarygodnie twierdzić, że obsługuje globalne finanse?