In breve
- Optimism ha rilasciato op-supernode v1.0.3 come aggiornamento operatore opzionale.
- Questa versione rafforza la convalida relativa ai tempi di attivazione degli hard fork e rifiuta gli ordini di fork post-genesi non validi nelle configurazioni di rollup personalizzate.
- Le blockchain già presenti nel registro Superchain non sono interessate dal problema di configurazione descritto nelle note di rilascio.
L'ultima versione del supernodo di Optimism è un piccolo aggiornamento con uno scopo ben preciso: impedire il caricamento di hard fork problematici.
op-supernode v1.0.3 è stato pubblicato il 1° ottobre come rilascio opzionale per gli operatori. Introduce una convalida più rigorosa dei tempi di attivazione dell'hard fork nelle configurazioni di rollup dei nodi virtuali.
Nelle note ufficiali non si parla di un nuovo motore di indicizzazione, di una revisione della sincronizzazione dello stato o di una correzione per la perdita di memoria. La modifica riguarda la correttezza della configurazione.
Due forcelle di replicazione post-genesi non possono condividere lo stesso tempo di attivazione
In base ai nuovi controlli, op-supernode si rifiuta di caricare una configurazione di nodo virtuale che attiva due hard fork contemporaneamente dopo la genesi.
La regola si applica da Jovian in poi, e ogni successiva biforcazione viene controllata per verificarne il corretto ordine. Le biforcazioni che si attivano al momento della genesi o prima possono comunque condividere lo stesso timestamp.
L'ottimismo suggerisce che le blockchain già presenti nel registro Superchain non saranno interessate. Il rischio risiede nelle configurazioni di rollup personalizzate che codificano una sequenza non valida.
Questo è un punto in cui è sensato che un software segnali un errore in modo evidente. Un operatore preferirebbe scoprire un programma di aggiornamento errato all'avvio del nodo piuttosto che dopo che diversi componenti iniziano a interpretare la catena in modo diverso.
Bitcoinist ha trattato la crescente complessità della Superchain attraverso test di interoperabilità su Sepolia e il lavoro di governance relativo ai giochi di disputa Super Root .
Più catene significano maggiore rischio di configurazione
Il successo dell'OP Stack crea una sfida operativa.
Quando un singolo codice sorgente supporta numerose catene indipendenti, i team possono personalizzare parametri, tempistiche di aggiornamento e infrastruttura. Questa flessibilità è preziosa, ma ogni ulteriore punto di configurazione rappresenta un'ulteriore fonte di errore umano.
Una validazione più rigorosa in fase di avvio è uno dei modi più semplici per contenere tale rischio.
La stessa filosofia si ritrova anche in altre parti dello stack. I recenti aggiornamenti di op-batcher hanno rafforzato la compatibilità con le imminenti modifiche di Ethereum, mentre le release di op-node stanno anche convalidando l'ordine degli hard fork in modo più rigoroso.
Opzionale non significa irrilevante
Il rilascio è facoltativo in quanto le catene di negozi già registrate non ne saranno interessate.
Per i team che utilizzano configurazioni personalizzate, tuttavia, i nuovi controlli possono rivelare errori che in precedenza passavano inosservati. Questi operatori devono correggere le pianificazioni non valide prima di procedere con l'aggiornamento.
Per tutti gli altri, la versione 1.0.3 è un buon esempio di come si presenta sempre più un'infrastruttura blockchain matura: meno hard fork drastici, più meccanismi di protezione progettati per impedire che piccoli errori di configurazione si trasformino in incidenti a livello di blockchain.
—
Questo articolo è stato scritto dalla redazione e curato da Samuel Rae.