Base utsatt för dubbla avbrott – så orsakades avbrotten och varför arkitekturen är i fokus

Det ogiltiga blocket utlöste ett konsensusfel: sequencern producerade ett felaktigt block efter block 47.806.542, vilket blockerade nätverket från att bygga ytterligare block. Nodeoperatörer kunde inte fortsätta normal synkronisering förrän problemet var åtgärdat.

Tidslinje för de två stoppen

Det andra stoppet den 26 juni beskrevs som samma underliggande klass av blockproduktionsfel som återkom kort efter den första incidenten, även om nätverket återhämtade sig snabbare andra gången.

Under båda perioderna frystes eller stoppades nya block, vilket störde normal transaktionshantering på kedjan. Däremot rapporterades inga användarmedel vara i riskzonen under någon av incidenterna.

Fixen som distribuerades

Bases ingenjörsteam tillämpade en patch på sequencern för att säkerställa att journal state uppdateras korrekt under exekvering efter en misslyckad transaktion. Fixen kan följas i en offentlig GitHub-pull request (#3806).

Efter patchen återgick normal drift, men Base rekommenderade validator-nodeoperatörer att starta om eller synkronisera om sina noder för att återställa synkstatus. Teamet noterade att båda avbrotten härrörde från samma bugg, och att ett andra relaterat problem (PR #3805) orsakade att incidenten inträffade igen nästa dag.

I efterdyningarna sköt Base upp lanseringen av den planerade Beryl mainnet-uppgraderingen och B20-tokenstandarden med en dag för att stabilisera nätverket.

Singel-sequencer-arkitektur: en bredare oro

De back-to-back-stoppen återuppväckte debatten om motståndskraften i Bases singel-sequencer-design, som är vanlig bland många optimistiska rollups men introducerar en tydlig enskild felpunkt.

Viktiga farhågor som lyfts fram i post-mortem-rapporten och branschbevakningen inkluderar:

• Enskild felpunkt: En bugg på sequencernivå i blockbyggarlogiken kan stoppa all blockproduktion på Base, vilket fryser nya block över hela nätverket.
• Manuell återställning: Återställning krävde att validator-nodeoperatörer manuellt startade om eller synkroniserade om sina noder, snarare än att nätverket självläkte.
• Tillförlitlighetsrisk: De back-to-back-felen väckte nya frågor om tillförlitligheten hos det snabbt växande L2-ekosystemet, särskilt under perioder med hög aktivitet eller planerade uppgraderingar.
• Planerade förbättringar: Base sade att man skulle stärka testningen med fuzz-tester, lasttester, övervakning och bättre återställningsverktyg för att minska risken för återfall.

Händelsen visar att även de största Ethereum L2-nätverken kan slås offline av ett kantfall i state-hantering i en enda sequencer – och att automatiska redundans- och återställningssystem fortfarande är ett pågående arbete inom rollup-ekosystemet.