Base-nettverket stoppet helt opp i 136 minutter – én enkel feil i sekvenseren skylden

Den ugyldige blokken utløste en konsensusfeil: sekvenseren produserte en ugyldig blokk etter blokk 47.806.542, og stoppet dermed nettverket fra å bygge flere blokker. Nodeoperatører kunne ikke fortsette normal synkronisering før feilen var løst.

Tidslinje for de to stansene

Den andre stansen 26. juni ble beskrevet som et tilbakefall av den samme typen blokkproduksjonsfeil like etter den første hendelsen, men nettverket kom seg raskere tilbake denne gangen.

I begge periodene ble nye blokker fryst eller stoppet, noe som forstyrret normal behandling av transaksjoner på kjeden. Imidlertid ble ingen brukermidler rapportert å være i fare under noen av hendelsene.

Feilrettingen som ble rullet ut

Bases ingeniørteam distribuerte en oppdatering til sekvenseren for å sikre at journal-tilstanden blir oppdatert på riktig måte under utføring etter en mislykket transaksjon. Rettelsen kan spores i et offentlig GitHub-pull request (#3806).

Etter oppdateringen gikk normal drift i gang igjen, men Base anbefalte validator-nodeoperatører å starte på nytt eller synkronisere nodene sine på nytt for å gjenopprette synkstatus. Teamet bemerket at begge stansene stammet fra samme feil, og at et annet, relatert problem (PR #3805) førte til hendelsen dagen etter.

I kjølvannet utsatte Base lanseringen av den planlagte Beryl-hovednettsoppgraderingen og B20-tokenstandardaktiveringen med én dag for å stabilisere nettverket.

Arkitektur med én sekvenserer: en bredere bekymring

De to stansene på rad har gjenopplivet debatten om robustheten til Bases design med én enkelt sekvenserer, som er vanlig blant mange optimistiske rollups, men som introduserer et klart enkelt feilpunkt.

Viktige bekymringer som er løftet frem i granskingen og bransjedekningen inkluderer:

• Enkelt feilpunkt: En feil på sekvenserernivå i blokkbyggingslogikken kan stoppe hele Bases blokkproduksjon og fryse nye blokker på tvers av nettverket.
• Manuell gjenoppretting: Gjenoppretting krevde at validator-nodeoperatører manuelt startet eller synkroniserte nodene sine på nytt, i stedet for at nettverket helbredet seg selv.
• Pålitelighetsrisiko: Feilene på rad har reist nye spørsmål om påliteligheten til det raskt voksende L2-økosystemet, spesielt i perioder med høy aktivitet eller planlagte oppgraderinger.
• Planlagte forbedringer: Base sa at de vil styrke testingen med fuzz-tester, lasttester, overvåking og bedre gjenopprettingsverktøy for å redusere sjansene for gjentakelse.

Hendelsen viser at selv de største Ethereum L2-nettverkene kan bli slått av nettverket av et kanttilfelle i tilstandshåndteringen i én enkelt sekvenserer – og at automatiserte overførings- og gjenopprettingssystemer fortsatt er et arbeid som pågår over hele rollup-økosystemet.