Alle 09:24 UTC del 5 gennaio 2026 l’esecutore delle transazioni di Starknet, uno ZK rollup su Ethereum, ha gestito male una chiamata annullata: ha tenuto una modifica di stato che andava scartata. I blocchi hanno continuato ad arrivare per 18 minuti. Poi la rete si è fermata, i 18 minuti di attività sono stati eliminati e Starknet è rimasta ferma fino alle 14:17 UTC, secondo blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il rapporto sull’incidente di StarkWare. Lo stato errato non è mai arrivato su Ethereum. Il rapporto dice che l’esecuzione sbagliata «never saw L1 finality thanks to Starknet’s proving layer», cioè non ha mai raggiunto la finalità su L1 grazie al livello di prove. È proprio a questo che serve uno ZK rollup: Ethereum non accetta nulla che non possa verificare.
Lo stesso rapporto contiene una seconda lezione. Chi ha individuato l’errore ha anche deciso di fermare la catena, farla tornare indietro e riavviarla. Il 12 novembre 2026 ETHBEAT (ex L2BEAT) elenca ancora il sequencer di Starknet come cinque nodi con permessi gestiti da StarkWare, e i suoi contratti possono essere aggiornati subito da un Security Council con soglia 9 su 12. La documentazione di StarkWare sullo staking è altrettanto chiara: «While Starknet is currently still centralized», scrive, la rete procede per gradi verso i validatori.
Questa lezione parte dalla nostra lezione sugli optimistic rollup, che mette a confronto le due famiglie in una tabella e spiega perché Arbitrum o OP Mainnet fanno aspettare circa una settimana. La pipeline di un rollup (sequencer, batch, state root, bridge) e gli stage 0, 1 e 2 di ETHBEAT sono nella nostra guida ai layer 2. Qui si va più a fondo sul lato ZK: che cosa viene dimostrato, chi produce la prova e a che costo, quanto dura davvero un’uscita e che cosa è andato storto su ZKsync, Starknet, Scroll, Linea e Polygon zkEVM.
ZK rollup: Ethereum controlla una ricevuta invece di aspettare
Un rollup esegue le transazioni lontano da Ethereum e ne pubblica il risultato. Un optimistic rollup pubblica il nuovo stato dichiarato e lascia a chiunque diversi giorni per contestarlo. Uno ZK rollup pubblica il nuovo stato dichiarato insieme a una prova crittografica che la dichiarazione è corretta, e un contratto su Ethereum controlla quella prova prima di accettare qualsiasi cosa. Non serve alcuna finestra di contestazione, perché non resta nulla da contestare.
La prova è una prova a conoscenza zero: un prover convince un verifier che un’affermazione è vera senza che il verifier debba rifare il lavoro. Qui il nome è un po’ fuorviante. La maggior parte degli ZK rollup pubblica tutti i propri dati, quindi nulla viene nascosto; ciò che usano è l’altra proprietà di queste prove, la brevità. Verificare la prova di un batch di migliaia di transazioni costa a Ethereum una sola chiamata a un contratto, molto meno che rieseguirle.
ETHBEAT dà la stessa definizione in ogni pagina di progetto ZK: ogni aggiornamento dello stato del sistema deve essere accompagnato da una prova che il nuovo stato deriva dall’applicazione corretta di transazioni valide allo stato precedente, e uno smart contract su Ethereum verifica quelle prove. ethereum.org definisce questa prova un impegno sintetico sulla correttezza del batch. Nella pratica è la «validity proof» che si incontra nella documentazione dei rollup.
Quattro ruoli: sequencer, prover, proposer, verifier
Il sequencer ordina le transazioni e produce i blocchi del rollup, come in un optimistic rollup. Il prover è una macchina separata, o una flotta di GPU, che prende un batch di blocchi e calcola la prova; è la parte costosa. Il proposer pubblica su Ethereum la nuova state root insieme alla prova. Il verifier è un contratto su Ethereum (quello di Linea si chiama PlonkVerifierFull su ETHBEAT, quello di Scroll PlonkVerifierOpenVMv2) che accetta o rifiuta la prova. Se la prova non regge, la state root viene respinta.
Ciò che viene dimostrato è la funzione di transizione di stato: le regole che trasformano il vecchio stato più un elenco di transazioni nel nuovo stato. Su Starknet quel programma è lo Starknet OS, scritto in Cairo, e dal 19 ottobre 2025 le prove arrivano dal prover Stwo di StarkWare, secondo le tappe registrate da ETHBEAT. Sui rollup basati sulla EVM il programma è un’implementazione della Ethereum Virtual Machine.
Conta altrettanto ciò che non viene dimostrato. La prova non attesta che il sequencer abbia incluso la tua transazione: un operatore che censura produce prove perfettamente valide. Non attesta che chi detiene le chiavi di aggiornamento si comporterà bene. E non attesta che i dati dietro lo stato siano disponibili per te, ed è questa la differenza tra un rollup e un validium, trattata più avanti. Una prova vale quanto il programma che controlla: un bug nel circuito o nel verifier può far sembrare giusto uno stato sbagliato.
Ricorsione: molte prove ripiegate in una
Dimostrare un’intera giornata di attività in un colpo solo sarebbe lento, quindi i prover dividono il lavoro e poi dimostrano le prove stesse. Linea produce prove interne e le aggrega in un’unica prova PLONK finale che Ethereum controlla, secondo la descrizione del sistema di prove data da ETHBEAT. StarkWare va oltre con SHARP, un prover condiviso che raggruppa il lavoro di più catene in una sola prova. Anche il rischio è condiviso: ETHBEAT osserva che il verifier di SHARP può essere cambiato da un multisig 2 su 4 con un ritardo di 8 giorni, «affecting all rollups like Starknet that are sharing it», cioè con effetto su tutti i rollup che lo condividono, come Starknet.
State diff o transazioni: che cosa va su Ethereum
Poiché la prova garantisce già il calcolo, uno ZK rollup non è obbligato a pubblicare ogni transazione. Starknet, ZKsync Era e Lighter pubblicano gli state diff, cioè le modifiche finali a saldi e storage, che occupano meno spazio quando gli stessi conti operano molte volte. Linea fa eccezione: ETHBEAT sottolinea che, a differenza della maggior parte degli ZK rollup, pubblica i dati delle transazioni. In ogni caso i dati finiscono nei blob di Ethereum, tema della prossima lezione di questo percorso, quella sui blob e su EIP-4844.
SNARK e STARK: due modi di costruire la prova
Due famiglie di sistemi di prova alimentano quasi ogni ZK rollup. Gli SNARK sono arrivati per primi in produzione. Il più noto, Groth16, è stato pubblicato da Jens Groth nel 2016; nel suo articolo «On the Size of Pairing-based Non-interactive Arguments» una prova è composta da soli tre elementi di gruppo, qualche centinaio di byte, e la verifica è una singola equazione di accoppiamento. Su Ethereum costa poco. Il prezzo è un trusted setup: una cerimonia crea parametri segreti per ogni circuito, e se qualcuno li avesse conservati potrebbe falsificare le prove.
PLONK, pubblicato nel 2019 da Ariel Gabizon, Zachary Williamson e Oana Ciobotaru (IACR ePrint 2019/953), mantiene prove piccole ma usa un setup universale e aggiornabile: una sola cerimonia serve per tutti i circuiti fino a una certa dimensione, e resta sicura se anche un solo partecipante è stato onesto. La prova finale di Linea è una prova PLONK.
Gli STARK nascono da un articolo del 2018 di Eli Ben-Sasson, Iddo Bentov, Yinon Horesh e Michael Riabzev intitolato «Scalable, transparent, and post-quantum secure computational integrity». Trasparente significa impostato «with no reliance on any trusted party», cioè senza fare affidamento su alcuna parte fidata: nessuna cerimonia. Gli STARK si basano su funzioni hash invece che su curve ellittiche. Le loro prove sono molto più grandi, e per questo più care da verificare su Ethereum.
| SNARK (Groth16, PLONK) | STARK | ||
|---|---|---|---|
| Setup | Trusted setup, per circuito (Groth16) o universale (PLONK) | Trasparente, nessun trusted setup | |
| Dimensione della prova | Minima: Groth16 usa tre elementi di gruppo | Molto più grande | |
| Verifica su Ethereum | Economica, un controllo di accoppiamento | Più costosa, perciò spesso avvolta in uno SNARK | |
| Crittografia | Curve ellittiche e accoppiamenti | Funzioni hash | |
| Grande computer quantistico | Spezzerebbe le curve | Considerato post-quantistico | |
| Chi lo usa (ETHBEAT, 12 nov 2026) | Linea, Lighter; involucro finale di ZKsync Era, Scroll, Mantle | Starknet, verificato su Ethereum senza involucro |
Oggi la maggior parte dei progetti combina i due approcci. Dimostrano il lavoro pesante con un sistema di tipo STARK, poi dimostrano la verifica di quello STARK dentro un piccolo SNARK, e su Ethereum arriva solo lo SNARK. Le note di rischio di ETHBEAT per ZKsync Era, Scroll e Mantle dicono esattamente questo, e aggiungono il compromesso: lo SNARK esterno riporta in gioco un trusted setup. Starknet è l’eccezione principale: le sue prove STARK vengono verificate su Ethereum così come sono.
L’aspetto quantistico
Un grande computer quantistico che esegua l’algoritmo di Shor spezzerebbe le assunzioni sulle curve ellittiche alla base degli SNARK. Gli STARK, basati su hash, sono considerati al sicuro. StarkWare usa questo argomento, ma ammette anche, come abbiamo riferito nella nostra notizia sul voto post-quantistico di Starknet, che la piena sicurezza quantistica della rete dipende dalla transizione di Ethereum stesso. Il 22 ottobre 2026 un sondaggio non vincolante su Starknet ha dato il 93,52% dei consensi alla ricerca di un layer 1 post-quantistico. È ricerca, e nessuna mossa è stata decisa.
Tipi di zkEVM: la scala di Vitalik Buterin del 2022
Dimostrare la EVM è difficile perché la EVM non è stata progettata per questo: la sua funzione hash e il suo albero di stato sono costosi da esprimere in un circuito. Nell’agosto 2022 Vitalik Buterin ha ordinato i vari tentativi in tipi nell’articolo «The different types of ZK-EVMs». Il Tipo 1, scriveva, punta a essere «fully and uncompromisingly Ethereum-equivalent», cioè pienamente e senza compromessi equivalente a Ethereum: non cambia nulla, quindi può dimostrare blocchi reali di Ethereum, ma la dimostrazione è lenta.
Il Tipo 2 è esattamente equivalente alla EVM ma modifica alcune parti di Ethereum attorno ad essa, come l’albero di stato, per accelerare la dimostrazione. Il Tipo 2.5 cambia anche i costi del gas. Il Tipo 3 è quasi equivalente alla EVM e rinuncia ad alcune funzioni troppo difficili da dimostrare. Il Tipo 4 non dimostra affatto la EVM: compila il codice sorgente Solidity o Vyper in un linguaggio pensato per le prove. Nel 2022 collocava Scroll e Polygon al Tipo 3, entrambi attesi in miglioramento sul fronte della compatibilità, ZKSync al Tipo 4 e anche Warp di Nethermind, un compilatore da Solidity a Cairo per StarkNet, al Tipo 4.
Quelle etichette vanno lette come una fotografia del 2022. Scroll ha nel frattempo sostituito l’intero prover e ogni team ha preso la propria strada. Starknet non ha mai puntato alla EVM: ETHBEAT le assegna il badge di macchina virtuale «CairoVM» dove le altre mostrano «EVM», quindi i contratti si scrivono in Cairo e non in Solidity. Per un utente la domanda è più semplice del numero di tipo: il mio wallet funziona e i contratti si comportano come su Ethereum? Per uno sviluppatore, piccole differenze nel gas o nei precompilati possono comunque rompere codice che su Ethereum funziona.
Perché i prelievi richiedono ore e non una settimana
ethereum.org lo dice senza giri di parole: «There are no delays when moving funds from a ZK-rollup to Ethereum», non ci sono ritardi nello spostare fondi da uno ZK rollup a Ethereum, perché l’uscita viene eseguita non appena il contratto ha verificato la prova. Vero in linea di principio. Nella pratica il tuo prelievo aspetta tre cose: il prossimo batch che lo contiene, la prova di quel batch e l’eventuale ritardo che l’operatore ha aggiunto sopra. Su alcuni bridge nativi resta un ultimo passaggio, una transazione di claim che invii tu stesso su Ethereum e paghi in gas.
| Catena | Che cosa determina l’attesa | Fonte, data di lettura |
|---|---|---|
| Linea | Finalità definitiva mediana di circa 2 ore; «should never exceed 16 hours» (non dovrebbe mai superare le 16 ore) in condizioni normali; obiettivo sotto i 30 minuti | Documentazione Linea, pagina aggiornata il 5 nov 2026 |
| ZKsync Era | Dimostrazione, poi un ritardo di esecuzione di almeno 24 ore dal 7 ott 2026 (prima 3 ore) | Matter Labs (forum ZKsync); ETHBEAT, 12 nov 2026 |
| Starknet | Cadenza delle prove; nessun ritardo di finalizzazione aggiuntivo una volta che l’aggiornamento di stato arriva su Ethereum | ETHBEAT, 12 nov 2026 |
| Scroll | Cadenza delle prove; nessun ritardo di esecuzione | ETHBEAT, 12 nov 2026 |
| Taiko Alethia | Prove previste ogni 4 ore; nessun ritardo di esecuzione | ETHBEAT, 12 nov 2026 |
| Arbitrum One (optimistic, per confronto) | Periodo di contestazione di circa 6,4 giorni | Documentazione Arbitrum |
La pagina sulla finalità delle transazioni di Linea è la dichiarazione pubblica più precisa tra le quattro grandi: una mediana di circa due ore, un tetto di 16 ore in condizioni operative normali e un piano per scendere sotto i 30 minuti. Dice anche che la finalità definitiva è ciò che serve ai prelievi tra layer. Quelle cifre sono quelle della pagina nell’ultimo aggiornamento, il 5 novembre 2026; una mediana non è una promessa per il tuo prelievo.
ZKsync è il caso in cui domina un ritardo deliberato. Il suo validator timelock tiene i batch su Ethereum per un tempo stabilito prima di eseguirli, in modo che chi interviene possa farlo se qualcosa sembra sbagliato. Un precedente voto di governance aveva ridotto quel ritardo da 21 ore a 3 ore. A settembre 2026 Matter Labs ha proposto ZIP-17, che permette a ogni catena EraVM di portare il proprio ritardo a 24 ore. Il motivo dichiarato: gli strumenti assistiti dall’intelligenza artificiale potrebbero accorciare l’intervallo tra la scoperta di una vulnerabilità e il suo sfruttamento. Dopo il voto dei possessori del token, Matter Labs ha annunciato che ZKsync Era sarebbe passata a 24 ore il 7 ottobre 2026 alle 13:00 UTC; ETHBEAT ha registrato il cambiamento il giorno dopo e al 12 novembre 2026 mostra un ritardo di esecuzione di 1 giorno. I prelievi da Era richiedono ora almeno 24 ore per finalizzarsi su Ethereum, e Matter Labs precisa che si tratta di un minimo. Le altre catene ZK Stack mantengono le 3 ore predefinite, a meno che scelgano diversamente.
Starknet non ha alcun ritardo di esecuzione una volta che un aggiornamento di stato valido arriva su Ethereum, secondo ETHBEAT. Ha però un altro freno: ogni escrow del bridge StarkGate può attivare una limitazione dei prelievi pari al 5% dei fondi bloccati ogni 24 ore. Può attivarla un multisig; una minoranza di 3 membri su 12 del Security Council può toglierla sugli escrow principali di ETH e STRK. È una difesa contro uno svuotamento, e rallenterebbe anche le uscite oneste.
Esistono uscite più rapide tramite bridge di terze parti e protocolli a intenti, che ti pagano subito su Ethereum e aspettano loro il rollup, in cambio di una commissione. Così si scambia la garanzia del rollup con quella del bridge, un compromesso spiegato nella nostra guida a bridge e intenti.
Costi di dimostrazione e chi gestisce i prover
Ogni grande ZK rollup è dimostrato da un piccolo insieme di macchine con permessi. Le prove di Starknet arrivano da SHARP di StarkWare. ZKsync Era e Linea accettano state root solo da proposer in whitelist; se quelli di Linea si fermano, il verdetto di ETHBEAT è netto: gli utenti non possono prelevare, e il ruolo di operatore si apre a chiunque solo dopo sei mesi senza un blocco finalizzato. Taiko Alethia ha due prover in whitelist. Scroll è l’eccezione tra i nomi noti: se il suo proposer fallisce, secondo ETHBEAT gli utenti possono eseguire il prover con codice consultabile e inviare le prove da soli.
Il software di dimostrazione è cambiato in fretta. Le zkVM generiche dimostrano qualunque programma compilato per un semplice set di istruzioni, spesso RISC-V, invece di un circuito EVM costruito a mano: SP1 di Succinct, RISC Zero, OpenVM (che Scroll ha adottato con l’aggiornamento Euclid del 16 e 22 aprile 2025 e portato alla versione 2.0.0 il 28 settembre 2026), Stwo di StarkWare e Boojum di ZKsync. Taiko mostra dove porta tutto questo. Dall’aggiornamento Unzen del 3 agosto 2026 ogni intervallo dimostrato richiede due prove su quattro sistemi (due configurazioni Intel SGX, SP1 e RISC Zero), e almeno una deve essere una validity proof di SP1 o RISC Zero.
Anche le zkVM hanno bug. A ottobre 2026 Succinct ha reso noto un difetto che faceva passare prove non valide al verifier nativo in Rust di SP1, mentre i verifier on-chain non erano toccati, come abbiamo riferito nella nostra notizia sul bug di SP1. Usare due sistemi di prova diversi, come fa Taiko, è una risposta proprio a questo rischio.
L’Ethereum Foundation vuole abbassare il costo fino a poter dimostrare Ethereum stesso. In un post del 10 luglio 2025 ha definito il «realtime proving» come la dimostrazione del 99% dei blocchi della mainnet in 10 secondi o meno, su hardware che costi al massimo 100.000 dollari e consumi al massimo 10 kW, con sicurezza a 128 bit e prove sotto i 300 KiB senza trusted setup. L’obiettivo è che i validatori possano controllare una prova invece di rieseguire ogni blocco.
Gli utenti non vedono i costi di dimostrazione come una voce a parte. L’11 novembre 2026 (giornata UTC completa), i dati di growthepie indicano una commissione mediana per transazione di 0,0031 dollari su Starknet, su 76.363 transazioni, 0,0016 dollari su Scroll e 0,0153 dollari su Linea, contro 0,0253 dollari su Ethereum. Gli utenti dei quattro rollup hanno pagato meno di 2.100 dollari di commissioni in tutto quel giorno. Gli ZK rollup costano poco da usare e restano piccoli per attività: la sola Base ha elaborato circa 7,7 milioni di transazioni nello stesso giorno.
I principali ZK rollup al 12 novembre 2026
ETHBEAT contava 80 layer 2 attivi che mettevano al sicuro circa 35,9 miliardi di dollari il 12 novembre 2026, di cui 14 nella categoria «ZK Rollup». La sorpresa è in cima. Per valore protetto, i due più grandi non sono i nomi nel titolo di questa lezione.
| Progetto (ETHBEAT, 12 nov 2026) | Stage | Valore protetto | Prove | Se il proposer si ferma |
|---|---|---|---|---|
| Mantle (OP Stack con prove ZK) | 0 | 1.162 milioni di $ | STARK avvolto in SNARK | Impossibile prelevare |
| Lighter (catena di un exchange) | 0 | 1.031 milioni di $ | SNARK | Uscita di emergenza |
| Starknet | 1 | 314 milioni di $ | STARK | Minoranza del Security Council |
| Linea | 0 | 297 milioni di $ | SNARK (PLONK) | Impossibile prelevare |
| ZKsync Era | 0 | 211 milioni di $ | STARK avvolto in SNARK | La governance sostituisce il proposer |
| Scroll | 0 | 34 milioni di $ | STARK avvolto in SNARK | Gli utenti possono proporre |
| Taiko Alethia | 0 | 11,5 milioni di $ | 2 sistemi su 4 | Impossibile prelevare |
Mantle usa l’OP Stack ma dimostra i propri blocchi con le prove ZK di Succinct, quindi ETHBEAT la classifica come ZK rollup. Lighter è una singola applicazione, un exchange di futures perpetui, e ha l’uscita più comoda per l’utente della lista: se l’operatore sparisce, gli utenti possono uscire presentando «a zero knowledge proof of funds», una prova a conoscenza zero dei fondi, nelle parole di ETHBEAT. Tutte le catene in tabella condividono una debolezza. ETHBEAT assegna a tutte una finestra di uscita pari a «None»: i loro contratti possono essere aggiornati subito, prima che gli utenti facciano in tempo a uscire.
Starknet: l’unico allo Stage 1
Starknet, sviluppata da StarkWare, è l’unico ZK rollup di dimensioni rilevanti allo Stage 1; i dettagli sono nella nostra scheda del progetto Starknet. Gli aggiornamenti normali passano da un multisig 2 su 6 di StarkWare con un timelock di 8 giorni; il Security Council 9 su 12 può agire subito. Il sequencing gira su una configurazione Tendermint in cui tre dei cinque nodi gestiti da StarkWare devono concordare su un blocco, che ETHBEAT etichetta «Centralized 5-node Tendermint». I possessori di STRK possono fare staking: il protocollo è nella seconda delle quattro fasi, in cui i validatori attestano i blocchi, con un minimo di 20.000 STRK per far girare un validatore e il bitcoin wrapped contato con un peso di 0,25, secondo la documentazione sullo staking di Starknet. I token tolti dallo staking restano bloccati per 7 giorni sulla mainnet. La proposta dei blocchi da parte dei validatori è prevista solo in una fase successiva.
ZKsync Era e l’Elastic Network
ZKsync Era, di Matter Labs, è il cuore di una famiglia di catene costruite con lo ZK Stack, che ETHBEAT etichetta «Part of the Elastic Chain»: Abstract, Sophon, Lens e ADI Chain sono ZK rollup della stessa famiglia, mentre Cronos zkEVM e GRVT tengono i dati altrove. Era è allo Stage 0. Gli aggiornamenti di codice attendono da 5 a 9 giorni sul percorso normale, e nessun giorno quando interviene l’EmergencyUpgradeBoard.
Linea, Scroll e Taiko
Linea è il rollup di Consensys. Il suo sistema di prove copre il 100% della zkEVM dal 9 giugno 2024, secondo ETHBEAT, ma il suo sequencer non ha alcun meccanismo di riserva: se si ferma, non c’è modo di forzare una transazione. Scroll ha avuto un Security Council indipendente 9 su 12 fino al 1° giugno 2026, quando ETHBEAT ne ha registrato la sostituzione con un multisig del team 3 su 4 e ha riportato Scroll allo Stage 0. Taiko Alethia, gestita da Taiko Labs, è la catena a prove multiple descritta sopra, anch’essa allo Stage 0.
Polygon zkEVM: uno ZK rollup spento
Polygon zkEVM è l’esempio da non imitare. L’11 giugno 2025 Polygon ne ha annunciato la chiusura sul forum di Polygon, citando il ritardo nel supporto a EIP-4844, i «ZK counters» che rendevano impraticabili alcune transazioni DeFi e una differenza troppo piccola rispetto ad altre catene. «The zkEVM sequencer will run for the next 12 months», cioè il sequencer girerà per i prossimi 12 mesi, diceva il post, con le transazioni forzate mantenute in modo che gli utenti potessero uscire. Il 3 dicembre 2025 ETHBEAT ha registrato che la catena ha smesso di dimostrare l’intero stato ed è passata alle «pessimistic proofs», che contabilizzano solo il bridge. ETHBEAT ora la classifica tra gli «Others», senza validazione dello stato e con circa 8,5 milioni di dollari ancora conteggiati.
Validium: la stessa prova, i dati altrove
Un validium dimostra il proprio stato esattamente come uno ZK rollup ma tiene i dati delle transazioni fuori da Ethereum, spesso con un comitato per la disponibilità dei dati (DAC) formato da pochi membri noti. Costa meno. Cambia però ciò che la prova protegge. La pagina sui validium di ethereum.org avverte che «validium users can have their funds frozen and withdrawals restricted», cioè gli utenti di un validium possono vedersi congelare i fondi e limitare i prelievi, se chi detiene i dati li trattiene: senza i dati non si può costruire la prova di Merkle di cui l’uscita ha bisogno. Un volition lascia a ogni utente la scelta, per singola transazione, tra modalità rollup e modalità validium.
ETHBEAT tiene netta la linea. Il 12 novembre 2026 la sua API elencava 14 progetti come «ZK Rollup», 9 come «Optimistic Rollup», uno come «Optimium» e 66 come «Others». Le catene di tipo validium con denaro vero stanno tra gli Others: Cronos zkEVM (22,8 milioni di dollari), Paradex con il suo comitato per la disponibilità dei dati (21,6 milioni) e Immutable zkEVM (20,9 milioni).
zkLink Nova mostra che cosa significhi quell’etichetta. Il layer 3 costruito su Linea, che L2BEAT classificava come validium, è stato svuotato di circa 779.000 dollari il 28 ottobre 2026 da un attaccante che ha falsificato la root di un batch, come abbiamo riferito nella nostra notizia sull’exploit di zkLink Nova. La debolezza stava nel bridge e nei suoi controlli, non nella matematica di una prova verificata da Ethereum.
Incidenti: le prove hanno tenuto, sono intervenute le persone
Guardando gli ultimi due anni emerge uno schema. I sistemi di prova hanno per lo più fatto il loro lavoro, a volte perché gli operatori li hanno spenti in tempo. Perdite e blocchi sono venuti da chiavi, sequencer e bridge.
| Data | Catena | Che cosa è successo |
|---|---|---|
| 15 apr 2025 | ZKsync | Una chiave admin compromessa di tre contratti di airdrop conia circa 111 milioni di ZK non reclamati, circa 5 milioni di dollari |
| 30 lug 2025 | ZKsync Era | Sistema di prove sospeso a mano per una vulnerabilità; guasto parziale di operatività |
| 10 set 2025 | Linea | La catena si ferma per circa un’ora |
| 5 gen 2026 | Starknet | 18 minuti eliminati, rete ferma dalle 09:42 alle 14:17 UTC, nulla di errato è diventato definitivo su Ethereum |
| 23 feb 2026 | Scroll | Sostituzione d’emergenza del verifier dopo un bug nel programma guest del prover |
| 1 giu 2026 | Scroll | Security Council sostituito da un multisig del team, ritorno allo Stage 0 |
| 28 ott 2026 | zkLink Nova (validium) | Circa 779.000 dollari sottratti con una root di batch falsificata |
L’incidente del token ZKsync dell’aprile 2025 viene spesso frainteso. ZKsync l’ha definito «an isolated incident caused by a compromised key», un caso isolato dovuto a una chiave compromessa: l’account admin di tre contratti di distribuzione dell’airdrop, che l’attaccante ha usato per chiamare una funzione di sweep e coniare circa 111 milioni di ZK non reclamati. Il protocollo ZKsync e il contratto del token ZK non sono stati toccati, ha dichiarato il team nel suo thread sull’incidente. L’episodio di Scroll del febbraio 2026 è il caso opposto: un difetto dentro lo stack di dimostrazione, che il registro degli incidenti di ETHBEAT annota come sostituzione d’emergenza del verifier per un bug nel programma guest del prover. Quella correzione ha richiesto un potere di aggiornamento immediato, lo stesso potere che ETHBEAT conta a sfavore della catena.
Uno ZK rollup è più sicuro di un optimistic rollup?
Sulla domanda ristretta se possa essere accettato uno stato sbagliato, una validity proof funzionante è la garanzia più forte: non dipende da qualcuno che osservi e contesti in tempo. L’incidente di Starknet di gennaio ne è la dimostrazione pratica. Un optimistic rollup con un contestatore guasto o silenzioso avrebbe potuto finalizzare quello stato sbagliato dopo la sua finestra.
Tutto il resto dipende dalla catena, non dalla famiglia. Il 12 novembre 2026 ETHBEAT assegna a Starknet lo Stage 1 e a ogni altro ZK rollup con valore reale lo Stage 0, mentre Arbitrum One e Base, entrambi optimistic o ibridi, sono allo Stage 1. I circuiti sono codice complesso, e un bug può trasformare la garanzia più forte nel punto più debole, ed è per questo che le chiavi di aggiornamento restano al loro posto. Per una data catena, lo stage di ETHBEAT e la sua colonna «se il proposer si ferma» dicono sul tuo rischio più delle lettere ZK nel nome.
Per chi risiede in Italia, i token di queste reti (ZK, STRK, LINEA) sono arrivati a molti possessori tramite airdrop. Le plusvalenze da cripto-attività realizzate dal 1° gennaio 2026 sono tassate al 33%, senza soglia di esenzione, secondo la brochure dell’Agenzia delle Entrate sulla legge di bilancio 2025; il quadro completo è nella nostra guida alle tasse sulle crypto in Italia. Niente di tutto questo è un motivo per comprare o vendere: i token di governance danno diritto di voto, non una quota del rollup.
La prossima lezione di questo percorso, sui blob e su EIP-4844, segue i dati che questi rollup pubblicano: che cos’è un blob e perché dopo marzo 2024 ha fatto scendere le commissioni dei layer 2. Quella ancora successiva confronta sidechain e rollup: catene che a Ethereum non dimostrano proprio nulla. Per capire perché Ethereum abbia bisogno di tutto questo, si può tornare a perché le blockchain hanno bisogno di scalare.
