Vai al contenuto
Financial Context Wiki

Cosa fare quando un sequenziatore L2 non funziona

Piano pratico per il fermo di un sequenziatore L2: verificare il guasto, evitare transazioni duplicate, controllare il percorso alternativo su L1 del rollup e considerare i rischi di ripristino e liquidazione.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Tratta il fermo del sequenziatore come una perdita del normale accesso a L2, non come prova che il rollup o gli asset siano compromessi. Ferma le azioni sensibili al tempo, verifica l’incidente sulla pagina di stato ufficiale della chain e tramite dati RPC o explorer indipendenti, e individua l’esatto percorso alternativo su L1 del rollup prima di firmare.

  1. Registra chain, indirizzo del wallet, hash delle transazioni in sospeso, ultimo blocco osservato e ora del guasto.
  2. Non inviare ripetutamente la transazione né aumentare le commissioni finché lo stato è ignoto.
  3. Controlla se l’unsafe head avanza mentre il safe o finalized head è fermo; può indicare un guasto di pubblicazione dei batch invece di un arresto totale.
  4. Usa un percorso di transazione forzata o prelievo su L1 solo da documentazione ufficiale e indirizzi di contratto verificati.
  5. Dopo il ripristino, attendi che coda, stato dell’oracolo, stato del bridge e periodo di grazia dell’applicazione si normalizzino prima di aumentare la leva o considerare finale una transazione.

Come funziona

Normalmente il sequenziatore riceve, ordina e conferma rapidamente le transazioni L2, quindi pubblica sul livello di disponibilità dei dati le informazioni necessarie a derivare la chain. Un fermo può impedire l’invio RPC ordinario. In un distinto guasto di pubblicazione, il sequenziatore può continuare a produrre blocchi unsafe mentre si arrestano la pubblicazione su L1 e quindi gli head safe e finalized. I rischi di riorganizzazione e ripristino sono diversi.

Il percorso alternativo dipende dall’implementazione. Sulle chain OP Stack, un utente può inviare una transazione L2 tramite l’OptimismPortal verificato della chain su L1; la finestra di sequenziamento predefinita è 12 ore, ma può variare. Arbitrum Nitro usa una Delayed Inbox su L1 e il suo progetto pubblicato descrive l’inclusione forzata dopo una soglia di 24 ore. Questi meccanismi garantiscono l’inclusione futura, non un’uscita immediata o universale, e richiedono ancora Gas su L1 e i contratti corretti della chain.

Anche le applicazioni necessitano di controlli propri. Un feed di disponibilità del sequenziatore può segnalare il fermo, ma è distinto da un feed di prezzo. I protocolli di prestito e derivati possono sospendere le operazioni sensibili durante il guasto e imporre un periodo di grazia al ripristino, evitando che aggiornamenti dell’oracolo e transazioni in coda causino subito liquidazioni ingiuste.

Esempio

Un debitore ha ETH in garanzia in un protocollo di prestito L2. Il sequenziatore non è disponibile per 2 ore mentre ETH scende del 15%, quindi non può aggiungere garanzia tramite il normale RPC. Il protocollo rileva il fermo, sospende le liquidazioni e le mantiene sospese per un periodo di grazia configurato di 1 ora dopo che il feed di disponibilità segnala il ripristino.

Il debitore registra l’hash in sospeso, verifica l’avviso ufficiale e il safe head del rollup, e non si fida di un messaggio di assistenza con un link di «sblocco». Se deve ancora agire, segue il percorso L1 ufficiale del rollup e verifica l’indirizzo del portal o dell’inbox. Dopo il ripristino attende che transazione forzata, feed di prezzo e salute del conto compaiano in un blocco safe prima di fare affidamento sul risultato.

Rischi

  • Liquidazioni al ripristino: transazioni e prezzi in coda possono essere elaborati quasi insieme; senza periodo di grazia, chi non poteva operare durante il fermo può essere liquidato subito.
  • Riorganizzazione dello stato unsafe: un RPC può mostrare blocchi recenti non ancora pubblicati su L1, riorganizzabili se scade la finestra di pubblicazione.
  • Segnali obsoleti o discordanti: un feed di prezzo in movimento non prova che gli utenti possano operare, e un feed di disponibilità non prova che il prezzo sia aggiornato.
  • Rischio di esecuzione del percorso forzato: le chiamate dirette su L1 sono più tecniche e costose; rete, contratto, calldata, nonce o limite Gas errati possono fallire o bloccare fondi.
  • Ritardi dei sistemi dipendenti: bridge, exchange, keeper, indicizzatori e frontend possono riprendersi in tempi diversi anche dopo il ritorno del sequenziatore.

Errori comuni

  • «Il sequenziatore è fermo, quindi gli asset sono spariti.» Lo stato del rollup imposto da L1 può restare intatto anche se l’accesso normale non è disponibile.
  • «Ogni rollup ha lo stesso ritardo di inclusione forzata.» Finestre, contratti e azioni supportate variano per implementazione e configurazione.
  • «Una transazione forzata viene eseguita subito.» L’invio su L1 crea un percorso verso l’inclusione futura, senza eliminare i ritardi di sequenziamento, prova o prelievo.
  • «Quando riprendono i blocchi, il rischio di liquidazione è finito.» Code, aggiornamenti dell’oracolo e keeper possono rendere il ripristino la fase più rischiosa.
  • «Un link alla pagina di stato inviato dall’assistenza è sicuro.» Verifica separatamente dominio e contratto; non rivelare mai seed phrase o chiave privata.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...