Base si ferma due volte in due giorni: un bug del sequencer mette in luce i rischi dell'architettura a punto unico di guasto

La rete Base, il Layer-2 di Ethereum sviluppato da Coinbase, ha subito due interruzioni della produzione di blocchi in 48 ore, il 25 e 26 giugno 2025, bloccando la catena per un totale di 136 minuti. Il rapporto ufficiale (post-mortem) ha ricondotto entrambi gli incidenti allo stesso bug nel sequencer della rete, riaccendendo il dibattito sui rischi strutturali della sua architettura a singolo sequencer.

Un bug nel costruttore di blocchi

La causa principale, secondo il post-mortem di Base, è stata una falla nella logica di costruzione dei blocchi del sequencer. Dopo il fallimento dell'esecuzione di una transazione, il sistema non puliva correttamente lo stato journal — il registro interno delle modifiche a conti e slot di archiviazione — lasciando uno stato "sporco" o "stale". Quando le successive transazioni legittime venivano eseguite, questo stato sporco causava calcoli anomali del gas, generando a sua volta un blocco con una transizione di stato non valida.

Questo blocco non valido ha innescato un guasto di consenso: il sequencer ha prodotto un blocco non valido dopo il blocco 47.806.542, impedendo alla rete di costruire ulteriori blocchi. Gli operatori dei nodi non potevano continuare la sincronizzazione normale finché il problema non fosse stato risolto.

Cronologia delle due interruzioni

Incidente	Data	Durata	Tempo di inattività totale (combinato)
Primo	25 giugno 2025	~116 minuti (quasi 2 ore)	~136 minuti
Secondo	26 giugno 2025	~20 minuti

Il secondo blackout del 26 giugno è stato descritto come la stessa classe di guasto alla produzione di blocchi, ripresentatasi poco dopo il primo incidente, anche se la rete si è ripresa più rapidamente la seconda volta.

Durante entrambi i periodi, la creazione di nuovi blocchi è stata congelata o interrotta, interrompendo l'elaborazione delle transazioni on-chain. Tuttavia, non sono stati segnalati rischi per i fondi degli utenti durante nessuno dei due incidenti.

La correzione implementata

Il team di ingegneri di Base ha applicato una patch al sequencer per garantire che lo stato journal venga aggiornato correttamente durante l'esecuzione dopo una transazione fallita. La correzione è tracciabile in una pull request pubblica su GitHub (#3806).

Dopo la patch, le operazioni normali sono riprese, ma Base ha consigliato agli operatori dei nodi validator di riavviare o risincronizzare i propri nodi per ripristinare lo stato di sincronizzazione. Il team ha sottolineato che entrambi i blackout hanno avuto origine dallo stesso bug e che un secondo problema correlato (PR #3805) ha causato la recidiva dell'incidente il giorno successivo.

Nelle ore seguenti, Base ha ritardato di un giorno il lancio del previsto aggiornamento della mainnet Beryl e dell'attivazione dello standard token B20 per stabilizzare la rete.

Architettura a singolo sequencer: una preoccupazione più ampia

I blackout consecutivi hanno riacceso il dibattito sulla resilienza del design a sequencer singolo di Base, comune a molti optimistic rollup ma che introduce un chiaro punto unico di guasto.

I punti chiave sollevati dal post-mortem e dalla copertura del settore includono:

• Punto unico di guasto: Un bug a livello di sequencer nella logica di costruzione dei blocchi può bloccare l'intera produzione di blocchi di Base, congelando la rete.
• Ripristino manuale: Il ripristino ha richiesto agli operatori dei nodi validator di riavviare o risincronizzare manualmente i propri nodi, invece di un auto-ripristino della rete.
• Rischio di affidabilità: I guasti consecutivi hanno sollevato nuovi interrogativi sull'affidabilità dell'ecosistema L2 in rapida espansione, specialmente durante periodi di alta attività o aggiornamenti programmati.
• Miglioramenti pianificati: Base ha dichiarato che rafforzerà i propri test con fuzz test, test di carico, monitoraggio e strumenti di recupero migliori per ridurre la probabilità di recidive.

L'incidente dimostra che anche le più grandi reti L2 di Ethereum possono essere messe offline da un caso limite di gestione dello stato in un singolo sequencer, e che i sistemi di failover e ripristino automatici sono ancora un lavoro in corso nell'ecosistema dei rollup.