In breve
- Optimism ha rilasciato i componenti Kona v1.8.0 con correzioni per la derivazione, l'esecuzione delle prove, TLS e la gestione della preimmagine.
- Questa release impedisce che un lotto non valido induca Kona a derivare una catena diversa dall'op-node in presenza di una specifica condizione di lotto difettoso.
- L'ottimismo raccomanda il rilascio per tutte le blockchain e afferma che kona-host dovrebbe essere eseguito con i pre-revisioni assolute di kona-client v1.8.0 corrispondenti.
Lo stack di Optimism basato su Rust per la verifica dei guasti ha ricevuto un importante aggiornamento di manutenzione incentrato sul mantenimento dell'allineamento tra derivazione ed esecuzione delle dimostrazioni e il resto dello stack OP.
La versione 1.8.0 dell'host Kona è stata pubblicata il 1° ottobre, contestualmente al rilascio del client corrispondente. Optimism consiglia l'aggiornamento per tutte le blockchain.
La release è di natura tecnica, ma il problema che affronta è facile da comprendere: due software di verifica non dovrebbero ricavare risultati diversi dagli stessi dati della catena.
I lotti difettosi ricevono un trattamento più severo.
Dopo l'aggiornamento Holocene, Kona ora controlla l'hash del genitore di ogni singolo batch rispetto all'head sicuro nello stesso modo in cui lo fa op-node.
L'ottimismo suggerisce che il controllo precedente sia sempre andato a buon fine. In un caso particolare in cui un dosatore difettoso producesse un lotto non conforme, Kona potrebbe quindi derivare una catena diversa dal nodo operativo.
Il team osserva che le prove di guasto non vengono influenzate a meno che il batcher non si comporti effettivamente in modo anomalo. Tuttavia, la coerenza del comportamento di derivazione tra i client è esattamente il tipo di requisito di coerenza su cui si basano i sistemi a prova di guasto.
Questa roadmap a prova di errore è visibile anche nella governance del gioco delle controversie di Super Root e nei test di interoperabilità di Superchain .
Gli errori di esecuzione vengono gestiti con maggiore attenzione
Kona v1.8.0 modifica anche il comportamento in caso di errori durante l'esecuzione della dimostrazione.
Ora un blocco viene sostituito con un blocco di solo deposito, o scartato nelle condizioni precedenti, solo quando il payload è effettivamente non valido. Errori come la mancanza di dati di preimmagine o di witness ora interrompono l'esecuzione invece di essere considerati la prova che il payload stesso era errato.
Può sembrare una sottigliezza, ma le dimostrazioni di errori devono distinguere tra "Non posso completare questo calcolo" e "Questo calcolo dimostra che il blocco non è valido".
Questa release aggiorna anche l'implementazione di EVM, corregge una dipendenza TLS e migliora la gestione degli errori del preimage-server.
Lo stack OP sta diventando sempre più diversificato in termini di client
L'infrastruttura dell'ottimismo comprende sempre più implementazioni e sistemi di verifica multipli, anziché un unico software canonico.
La diversità dei client può migliorare la resilienza, ma crea anche un nuovo requisito: le implementazioni indipendenti devono concordare con precisione sulle transizioni di stato e sui casi limite.
Lo stesso onere di manutenzione è visibile nelle release op-batch richieste da Optimism e negli altri aggiornamenti dell'operatore.
Kona v1.8.0 non si concentra quindi tanto su una nuova funzionalità appariscente, quanto piuttosto sulla garanzia che il livello di verifica si comporti in modo prevedibile anche in presenza di input non ottimali. In un'infrastruttura a prova di guasto, è proprio in questi casi che l'affidabilità è fondamentale.
—
Questo articolo è stato scritto dalla redazione e curato da Samuel Rae.