Quando un rollup smette di funzionare: spiegazione della chiusura di Polygon zkEVM

3 luglio 2026

10 minuti di lettura

Riassumere con l'intelligenza artificiale

Polygon zkEVM è ufficialmente entrato nella fase di dismissione. Su 1° luglio 2026, Polygon Labs ha disattivato il sequencer della versione beta della mainnet Polygon zkEVM, con i saldi dei wallet trasferiti su Ethereum L1 tramite una procedura di richiesta. A onor del vero, la chiusura è stata gestita in modo impeccabile: gli utenti hanno avuto un anno intero per prepararsi, il bridge è rimasto aperto fino all’ultimo giorno e le richieste rimangono disponibili fino alla fine del 2027.

Il problema è che le blockchain non si limitano a custodire le monete nei portafogli. Quando una rete smette di funzionare, parte della liquidità è già sepolta a diversi livelli di profondità: in pool, vault, mercati di prestito, posizioni di garanzia e altri contratti che Polygon non controlla. Riportarla su L1 non è più una semplice operazione di bridge.

Abbiamo quindi posto al nostro esperto, Andrew Nalichaev, le domande che probabilmente molti nel settore si stanno ponendo in questo momento: Chi è responsabile della liquidità bloccata, cosa succede alle stablecoin su una rete in declino e quali insegnamenti dovrebbero trarne gli altri rollup prima di trovarsi ad affrontare lo stesso problema?

Andrew Nalichaev

Esperto di Blockchain e analista DeFi

Andrew traduce concetti decentralizzati in strumenti finanziari sicuri e funzionali. Naviga nel volatile panorama della DeFi per costruire infrastrutture blockchain scalabili che rispondano all'utilità del mondo reale, andando oltre le parole d'ordine per fornire valore tecnico.

Visualizza il profilo

- Se consideriamo Polygon zkEVM come un caso di studio sulla chiusura di una rete L2, cosa è stato gestito bene e cosa avrebbe dovuto essere previsto fin dall’inizio?

La cosa migliore che Polygon ha fatto in questo caso è stata concedere agli utenti tempo e definire una procedura chiara. La chiusura di zkEVM è stata annunciata con circa un anno di anticipo, il bridge è rimasto attivo fino all’ultimo giorno, è stata effettuata una snapshot dei saldi e agli utenti è stata offerta la possibilità di recuperare i propri fondi su Ethereum L1. Per quanto riguarda le chiusure, questo è un modo piuttosto ordinato di gestire la situazione.

L’aspetto che avrebbe dovuto essere integrato fin dal primo giorno è il piano di uscita dalla DeFi. Spostare i saldi dei wallet è una cosa, perché tali saldi corrispondono perfettamente alle risorse presenti nel deposito a garanzia del bridge. La DeFi è tutta un’altra storia. I token LP, le quote dei vault, le posizioni di garanzia e i crediti necessitano tutti di proprie vie di fuga di emergenza a livello di protocollo. In assenza di ciò, una volta che il sequencer si arresta, la liquidità depositata all’interno di contratti di terze parti può diventare molto difficile, o talvolta impossibile, da raggiungere.

- Quanto è realistico smantellare “in modo pulito” una rete L2 una volta che su di essa sono già presenti protocolli DeFi, posizioni LP, vault, garanzie e token derivati?

È possibile effettuare una chiusura ordinata, ma solo fino a un certo punto. Se parliamo di semplici saldi di wallet o di asset che corrispondono direttamente al deposito a garanzia del bridge, allora sì, è possibile rendere il processo abbastanza ordinato. Nel momento in cui entra in gioco la componibilità della DeFi, le cose si complicano notevolmente.

Prendiamo un pool AMM di base. In teoria, si potrebbe verificare chi detiene i token LP, calcolare la loro quota nel pool e distribuire le attività sottostanti. Deve trattarsi del detentore attuale, non di chi ha effettuato il deposito originario; altrimenti, si rischia di pagare due volte la stessa persona. Ma nella realtà della DeFi le cose raramente sono così semplici. I token LP possono essere depositati in vault, messi in staking, utilizzati come garanzia o integrati in un altro prodotto. Improvvisamente, non si ha più a che fare con un singolo diritto, ma con un’intera catena di diritti, e non esiste un modo universale per individuare chi sia il “vero” proprietario in ogni possibile contratto.

Quindi la risposta sincera è: un L2 può chiudersi in modo ordinato solo se i protocolli che vi si appoggiano hanno previsto fin dall’inizio tale scenario. Altrimenti, lo spegnimento a livello di rete potrebbe sembrare organizzato, ma il livello DeFi potrebbe comunque essere un caos.

- Come valuteresti il rischio di doppia spesa nel tentativo di chiudere manualmente le posizioni DeFi dopo un'interruzione della rete? Si tratta principalmente di un problema tecnico, giuridico o economico?

È un mix di tutte e tre le cose, ma in fondo si tratta di un problema economico.

Il conto di garanzia (escrow) su L1 contiene solo le attività effettive che sono state immesse nel sistema. La DeFi costruisce poi ulteriori livelli su questa base: token LP, quote di vault, posizioni di prestito, token di debito e altri diritti di credito. In un mercato del credito, ad esempio, ci si può ritrovare rapidamente con un numero di diritti di credito superiore alle attività presenti nel deposito a garanzia, almeno se si cerca di soddisfare tutti contemporaneamente.

È qui che entra in gioco il problema della doppia spesa. Non è possibile pagare il depositante, il mutuatario e tutti i detentori di strumenti derivati attingendo dallo stesso pool di attività sottostanti, se tale pool non è sufficientemente ampio da coprire tutte queste richieste.

C'è anche una trappola legata alla tempistica. Alcune posizioni non hanno nemmeno un valore definito nel momento in cui vengono congelate: un prestito “underwater” richiede una liquidazione, gli interessi devono maturare, un oracolo deve essere aggiornato. Se si interrompe la catena nel bel mezzo del processo, la quota "equa" di quelle posizioni diventa indefinita, non semplicemente difficile da calcolare.

Dal punto di vista tecnico, si può provare a chiarire chi possiede cosa. Dal punto di vista giuridico, potrebbe essere necessario stabilire quale diritto abbia la precedenza. Ma dal punto di vista economico, il limite è molto semplice: non è possibile distribuire più beni di quanti ne esistano effettivamente.

- Le squadre L2 dovrebbero essere tenute ad adottare protocolli che prevedano una via d'uscita prima di poter immettere liquidità sulla rete?

Sì, soprattutto se un protocollo ha intenzione di custodire il denaro degli utenti. Non si può accettare depositi, creare liquidità e poi iniziare a chiedersi “come facciamo a far uscire tutti?” solo quando la rete sta già per essere disattivata.

La L2 stessa può aiutare solo nella parte chiara e semplice: saldi che corrispondano a quanto si trova nel conto di garanzia del bridge. Non può realisticamente addentrarsi in ogni protocollo DeFi e districare i conti. A quel punto, il team della L2 dovrebbe decidere chi possiede cosa, come valutare le posizioni e chi venga pagato per primo. Si tratta di una grande responsabilità, e in realtà non è compito loro.

Quindi sì, i protocolli DeFi devono disporre di proprie procedure di prelievo di emergenza, di una logica di regolamento o di piani di chiusura prima che gli utenti inizino a investire ingenti quantità di liquidità al loro interno.

- In che modo l'arresto di un sequencer modifica il modello di fiducia per gli L2? Gli utenti dovrebbero ora valutare non solo il rischio legato al bridge, ma anche quello legato all'arresto?

È qui che l’idea del “basta fare un bridge” comincia a vacillare. Funziona se i tuoi fondi sono semplicemente depositati in un wallet. Non funziona così bene se sono vincolati in un mercato di prestiti, in una posizione LP, in un vault o in un contratto che richiede ancora un’ulteriore transazione per consentirti di uscirne.

Quando il sequencer si ferma, la catena smette di ricevere istruzioni. Potresti ancora avere una richiesta valida da qualche parte, ma potresti non avere più un percorso funzionante per darvi seguito. È questa la parte scomoda: l’asset potrebbe non essere sparito, ma il percorso per raggiungerlo può scomparire.

Gli utenti devono guardare oltre la sicurezza della rete. Per le L2 più piccole, specialmente quelle con scarsa liquidità o ecosistemi ancora in fase sperimentale, la domanda dovrebbe essere anche: cosa succede se questa rete cessa di funzionare, e riesco davvero a uscirne prima che ciò accada?

- Cosa succede alle riserve delle stablecoin su una rete in via di estinzione, in particolare quando si confrontano gli USDC.e trasferiti tramite bridge con l'emissione nativa attraverso un modello simile al CCTP?

Nel caso delle stablecoin “bridged” come l’USDC.e, l’USDC reale è depositato in un conto di garanzia su Ethereum L1. Se il tuo USDC.e è semplicemente nel tuo wallet, può essere migrato o riscattato. Se invece è bloccato all’interno di un contratto con cui nessuno può più interagire, l’USDC sottostante è ancora lì, ma l’utente non ha alcun modo pratico per accedervi. L’emittente non ricava alcun guadagno “aggiuntivo” da questa situazione. La copertura è ancora presente, ma il valore è sostanzialmente intrappolato.

Le stablecoin native funzionano in modo diverso. In una configurazione di tipo CCTP, il token viene coniato direttamente sulla L2 e la riserva fiat rimane presso l’emittente. Per uscire in modo pulito, è necessario bruciare il token sulla L2 prima della chiusura e coniarlo altrove. Se il token è bloccato in un contratto inattivo, non è più possibile bruciarlo on-chain. Pertanto, l’emittente si ritrova a detenere riserve reali per token che esistono ancora, ma su una rete che non funziona più.

A quel punto, l'emittente deve decidere come procedere: conservare le riserve, accettare richieste fuori catena corredate di prove oppure, in ultima istanza, considerare quei token come abbandonati.

Non lasciate che il rischio legato alle infrastrutture si trasformi in un rischio legato al prodotto

Innowise contribuisce alla progettazione di infrastrutture Web3 con meno punti ciechi

- Quali insegnamenti dovrebbero trarre i team impegnati nella creazione di nuovi ecosistemi rollup dalla chiusura di Polygon zkEVM?

Polygon zkEVM ci ricorda che ogni rollup ha bisogno di due roadmap: una per la crescita e una per la chiusura in sicurezza. Attirare liquidità è solo metà del lavoro. I team devono anche disporre di un modo chiaro per prelevare quella liquidità nel caso in cui la rete dovesse mai chiudere.

Ciò significa avvisare tempestivamente gli utenti, mantenere il bridge attivo il più a lungo possibile, garantire alle persone una procedura chiara per la richiesta di rimborso dei saldi dei portafogli e dialogare con i protocolli DeFi con largo anticipo rispetto alla data di chiusura. Significa inoltre spiegare chiaramente cosa accadrà alle risorse trasferite tramite il bridge, alle risorse native e alle stablecoin.

Soprattutto, i team dovrebbero smettere di considerare il TVL come qualcosa che si può semplicemente mettere da parte e trasferire in un secondo momento. Una volta che il sequencer smette di funzionare, la vera domanda diventa: quanta liquidità deve ancora uscire attraverso una transazione?

C'è anche una lezione di progettazione da trarre da tutto questo. Se smantellare un sistema è così complicato, vale la pena chiedersi onestamente, prima del lancio, se il carico di lavoro avesse davvero bisogno di una propria catena. Molti casi d’uso che richiedono “inviolabilità” trovano una soluzione migliore in un database verificabile o in un registro di trasparenza con un punto di riferimento esterno. In questi casi non c’è alcun sequenziatore da disattivare.

- Quali dovrebbero essere gli elementi minimi da includere nel piano di chiusura di qualsiasi L2 prima del lancio sulla mainnet: comunicazione, richieste di bridge, coordinamento DeFi, politica sulle stablecoin o altro?

Un piano di chiusura di L2 ben strutturato dovrebbe illustrare l'intero processo, dal primo avviso fino alla scadenza del termine per la richiesta di risarcimento. I team devono decidere tempestivamente quando avvisare gli utenti, per quanto tempo rimarrà aperto il "ponte", quando verrà effettuato lo snapshot finale, come funzioneranno le richieste di risarcimento su L1 e cosa accadrà ai fondi non reclamati.

La DeFi merita un piano a sé stante. I protocolli dovrebbero chiarire se gli utenti possano effettuare prelievi in caso di emergenza, come possano essere liquidate le posizioni e cosa accada ai token LP, alle quote dei vault, alle garanzie e al debito qualora la rete smettesse di elaborare le transazioni.

Anche le stablecoin richiedono la stessa chiarezza. Gli asset collegati tramite bridge e quelli emessi nativamente si comportano in modo molto diverso quando una rete smette di funzionare, quindi gli utenti dovrebbero sapere esattamente quali regole si applicano a ciascun token.

- In queste situazioni, qual è solitamente la parte più difficile: bloccare tecnicamente la rete, attribuire legalmente le responsabilità o risolvere economicamente il problema della liquidità congelata?

Disattivare la rete è probabilmente la parte più semplice dell’intero processo. I veri problemi iniziano quando si inizia a verificare chi ha ancora dei fondi immobilizzati, dove si trovano tali fondi e chi ha il diritto di prendere decisioni al riguardo.

Dal punto di vista giuridico, la responsabilità diventa molto rapidamente poco chiara. Il team di L2 gestisce l’infrastruttura, ma non è proprietario di tutti i protocolli DeFi costruiti su di essa. Dal punto di vista economico, la situazione si complica ulteriormente, poiché la DeFi può creare diversi livelli di diritti sulla stessa liquidità sottostante. Se tale liquidità è limitata, bloccata o già impegnata in diverse forme, alcuni diritti semplicemente non possono essere onorati per intero.

Il compito più arduo, quindi, è trovare un modo equo per gestire la liquidità congelata senza pagare due volte lo stesso asset sottostante, senza creare nuove passività e senza costringere il team responsabile dell’infrastruttura a fungere da giudice per ogni protocollo dell’ecosistema.

- Come pensi che questo caso influenzerà la fiducia nei L2 più piccoli e negli ecosistemi zk-rollup con TVL basso?

Questo caso farà sì che le L2 più piccole sembrino molto meno “sicure di default”. Un TVL già basso suscita perplessità. Ora gli utenti hanno un altro dubbio: se questa rete dovesse chiudere, riuscirei davvero a uscirne?

Per gli zk-rollup, la fiducia non dipenderà solo dalla tecnologia, dalle commissioni e dalla velocità. La dipendenza dal sequencer, le richieste di risarcimento relative ai bridge, le vie di fuga dalla DeFi e la gestione delle stablecoin stanno entrando a far parte della lista dei controlli. Un rollup deve ora dimostrare che gli utenti possano uscirne con la stessa facilità con cui vi sono entrati.

L'esperienza di Andrew al lavoro

Per saperne di più

Blog

Come spostare USDT da Tron a EVM senza rimanere intrappolati dalla liquidità

Blog

Top Layer 2 blockchain: trova la soluzione giusta per il tuo progetto

Blog

Che cos’è un DID? Una guida all’identità digitale

Contattateci

Prenota una chiamata oppure compilate il modulo sottostante e sarete ricontattati una volta elaborata la vostra richiesta.

Nome

Azienda

Telefono

Messaggio

Inviaci un messaggio vocale

Allegare i documenti

Caricare il file

È possibile allegare 1 file di dimensioni massime di 2 MB. Formati di file validi: pdf, jpg, jpeg, png.

Facendo clic su Invia, l'utente acconsente al trattamento dei propri dati personali da parte di Innowise in base alla nostra Informativa sulla privacy per fornirvi informazioni pertinenti. Inviando il vostro numero di telefono, accettate che possiamo contattarvi tramite chiamate vocali, SMS e applicazioni di messaggistica. Potrebbero essere applicate tariffe per chiamate, messaggi e dati.

Potete anche inviarci la vostra richiesta
a contact@innowise.com

Cosa succede dopo?

Una volta ricevuta ed elaborata la vostra richiesta, vi contatteremo per illustrarvi le esigenze del vostro progetto. Progetto e firmare un NDA per garantire la riservatezza.

Dopo aver esaminato i vostri desideri, le vostre esigenze e le vostre aspettative, il nostro team elaborerà una proposta di progetto con l'ambito di lavoro, le dimensioni del team, i tempi e le stime dei costi stimati.

Organizzeremo un incontro con voi per discutere l'offerta e definire i dettagli.

Infine, firmeremo un contratto e inizieremo subito a lavorare sul vostro progetto.