--- title: "Prelievo forzato da L2" description: "Guida per protocollo a inclusione forzata, prelievo forzato e via di fuga: garanzie, dipendenze e verifica del percorso di uscita." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Prelievo forzato da L2 > Solo a scopo didattico; non è consulenza finanziaria o di sicurezza. Meccanismi di uscita, ritardi, commissioni, permessi dei contratti e ipotesi sulla disponibilità dei dati variano tra L2 e possono cambiare dopo un aggiornamento. ## Risposta diretta Un prelievo forzato da L2 è un percorso di protocollo che consente di avviare o completare un'uscita senza l'approvazione dell'operatore L2. Il termine non è standardizzato. In alcuni sistemi indica l'invio diretto di una richiesta di prelievo a un contratto L1; in altri, l'unica primitiva disponibile è l'inclusione forzata, che garantisce soltanto l'ingresso di una transazione originata su L1 nella coda di esecuzione L2. Poi occorre ancora seguire il normale flusso di prelievo e finalizzazione del bridge canonico. La via di fuga è un percorso di emergenza più forte per quando gli aggiornamenti di stato ordinari si arrestano. Può congelare l'applicazione e consentire agli utenti di provare i saldi rispetto a una radice di stato impegnata. Nessun meccanismo promette uscita immediata, un valore specifico dell'asset o immunità da bug e poteri di governance. La garanzia effettiva dipende dal codice distribuito, dalla configurazione corrente, dai dati di stato disponibili e dalla capacità di creare e inviare transazioni o prove richieste. ## Come funziona - **Identificare la primitiva.** Inclusione forzata, prelievo forzato e modalità di fuga risolvono problemi diversi. L'inclusione aggira un sequencer censorio o indisponibile. Una richiesta di prelievo obbliga protocollo o operatore a elaborare l'uscita o provarne l'invalidità. La modalità di fuga è in genere l'ultima risorsa: gli aggiornamenti ordinari si fermano e si preleva con prove di stato. - **Entrare tramite L1.** L'utente invia una transazione all'inbox, portale o contratto di regolamento L1 indicato dal protocollo. In OP Stack, i depositi L1 vengono derivati in blocchi L2 entro la finestra di sequenziamento. In Arbitrum Nitro, un messaggio può entrare nella Delayed Inbox e, dopo il ritardo configurato, essere forzato nell'inbox principale se il sequencer non lo include. - **Attendere l'elaborazione.** La conferma L1 è solo il primo controllo. La richiesta potrebbe dover entrare nella catena L2 canonica, essere eseguita, apparire in uno stato provato o confermato, superare un periodo di contestazione o tolleranza e finalizzarsi su L1. Anche una transazione forzata può fallire per nonce errato, Gas insufficiente, calldata sbagliata, restrizioni del token o stato L2 cambiato. - **Soddisfare le condizioni di uscita.** StarkEx Spot mostra un vero flusso di prelievo forzato e fuga. L'utente invia `fullWithdrawalRequest`; l'applicazione deve soddisfarla o provarla invalida. Se resta in sospeso dopo `FREEZE_GRACE_PERIOD`, si può chiedere il congelamento. La fuga richiede un percorso di Merkle rispetto alla radice del vault congelato, verifica della prova, chiamata `escape` e normale chiamata on-chain `withdraw`. - **Controllare la disponibilità dei dati.** Una radice di stato è un impegno, non i saldi o i percorsi di Merkle sottostanti. Se i dati per ricostruire lo stato sono pubblicati su L1, un soggetto indipendente può in linea di principio creare la prova di uscita. In Validium o altri modelli off-chain, l'utente può dipendere dal rilascio dei dati da parte di comitato o operatore. Validità della prova e disponibilità dei dati sono garanzie distinte. - **Controllare poteri e strumenti.** Esaminare poteri di pausa, congelamento, aggiornamento e governance; indirizzi esatti e implementazioni proxy; asset supportati; chiavi; Gas L1 e L2; software di prova; e interfacce indipendenti. Un meccanismo corretto sulla carta può essere impraticabile senza dati, strumenti o fondi L1 sufficienti. ## Esempio Supponiamo che sequencer e interfaccia ufficiale di un Rollup non siano disponibili, ma L1 continui a finalizzare. L'utente verifica prima chain ID e contratti L1 canonici nella documentazione ufficiale. Se esiste solo l'inclusione forzata, invia una transazione da L1 a L2 che chiama la funzione di prelievo L2 del bridge canonico. Poi segue separatamente invio L1, inclusione forzata, esecuzione L2, impegno di stato, fase di contestazione o prova e finalizzazione L1. Un invio L1 riuscito non prova che la chiamata di prelievo sia riuscita. In un sistema in stile StarkEx, la sequenza cambia: inviare la richiesta forzata documentata, attendere il periodo di tolleranza configurato, verificare se sia stata soddisfatta o provata invalida e usare congelamento e fuga solo quando le condizioni contrattuali sono rispettate. Identificatore del vault, chiave e percorso di Merkle devono combaciare con lo stato congelato. Copiare la procedura Arbitrum o OP Stack sarebbe errato, anche se tutte sono talvolta dette “prelievi forzati”. Prima di dipendere da un percorso, provarlo con un piccolo importo quando il sistema è sano. Registrare indirizzi, firme di funzione, eventi attesi, timer e hash delle transazioni. Verificare lo stato con un altro RPC o explorer fidato. Non inserire mai seed phrase o chiave privata in un sito di “prelievo d'emergenza” né inviare pagamenti extra di “sblocco” a supporto o messaggi diretti. ## Rischi - Il protocollo ha inclusione forzata ma non una funzione diretta di prelievo forzato. - La richiesta L1 è confermata, ma la chiamata L2 è fallita o non ancora eseguita. - Periodi di contestazione, prova, tolleranza o finalizzazione ritardano l'accesso. - Dati di stato o percorso di Merkle non sono disponibili, soprattutto con dati off-chain. - Si usano chain, contratto, proxy, funzione o identificatore del vault errati. - Il contratto di uscita è in pausa, aggiornato, congelato male o affetto da un bug. - Governance, consiglio di sicurezza o altro attore privilegiato può cambiare il percorso. - L'asset non è supportato, non standard, illiquido o soggetto a regole di margine. - Picchi del Gas L1 o mancanza di Gas nativo impediscono invio o finalizzazione. - Interfacce, RPC, indicizzatori o strumenti di prova non sono disponibili. - Interfaccia falsa, annuncio o falso supporto ruba credenziali o fondi. - Il valore può calare durante l'attesa; la possibilità di uscire non protegge il prezzo. ## Idee sbagliate comuni - **Il “prelievo forzato” ha un flusso universale.** Nomi e garanzie dipendono dal protocollo; leggere documenti e contratti della versione distribuita. - **L'inclusione forzata riporta subito i fondi su L1.** Di norma garantisce accesso all'ordinamento o esecuzione; il prelievo del bridge ha ancora un proprio ciclo. - **Un hash L1 prova che l'uscita è riuscita.** Prova solo l'inclusione L1; esecuzione L2 e finalizzazione L1 vanno controllate separatamente. - **Una prova di validità garantisce la disponibilità dei dati di uscita.** Correttezza della prova e disponibilità dei dati sono distinte; i dati off-chain aggiungono dipendenze. - **Il percorso di emergenza è trustless perché esiste una funzione.** L'uso dipende anche da permessi, configurazione, dati, software, Gas e chiavi. - **Una via di fuga elimina il rischio finanziario.** Gestisce guasti di operatività o censura, non rischi di prezzo, liquidità, contratti o compromissione delle chiavi. ## Argomenti correlati - [Bridge canonico](/it/crypto/canonical-bridge/) - [Optimistic Rollup](/it/crypto/optimistic-rollup/) - [Via di fuga del Rollup](/it/crypto/rollup-escape-hatch/) - [Sequencer](/it/crypto/sequencer/) - [ZK Rollup](/it/crypto/zk-rollup/) ## Fonti - [Panoramica del protocollo OP Stack](https://specs.optimism.io/protocol/overview.html) - OP Stack Specification (consultato: 2026-08-21) - [Arbitrum Nitro: un Optimistic Rollup di seconda generazione](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultato: 2026-08-21) - [Prelievo e fuga senza approvazione dell'applicazione](https://docs.starkware.co/starkex/spot/withdrawing_and_escaping_without_app_approval.html) - StarkEx Documentation (consultato: 2026-08-21) - [Disponibilità dei dati](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (consultato: 2026-08-21) Source: https://wiki.fcontext.com/it/crypto/l2-forced-withdrawal/index.mdx