---
title: "ZK rollup"
description: "Guida orientata alla verifica di batch, prove di validità, disponibilità dei dati, stati di regolamento, commissioni, prelievi e rischi specifici dei deployment ZK rollup."
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.
# ZK rollup
> Solo a scopo educativo; non è consulenza su investimenti, bridge o sicurezza. Un ZK rollup è affidabile solo quanto il programma provato, gli input pubblici, il percorso di disponibilità dei dati, i contratti, gli operatori, la governance e la catena di regolamento.
## Risposta diretta
Uno ZK rollup, più precisamente un rollup di validità, esegue transazioni fuori da una catena di regolamento, le raggruppa in batch e invia impegni sui dati, dichiarazioni di stato e prove di validità ai contratti su quella catena. Il verificatore controlla le regole di transizione codificate senza rieseguire ogni transazione. I costi di pubblicazione e verifica vengono così ripartiti su molte transazioni.
La garanzia è specifica, non assoluta. Una prova verificata sostiene solo l’affermazione codificata dal programma distribuito e vincolata dagli input pubblici. Non dimostra da sola che i dati siano recuperabili, il sequencer attivo o equo, il blocco finale, il bridge corretto o un aggiornamento sicuro. “ZK” non implica neppure privacy: molti rollup pubblicano transazioni o differenze di stato.
## Come funziona
1. Identificare il deployment: chain ID L1 e L2, contratti rollup e bridge, verificatore e versione della chiave, programma o circuiti provati, formato batch, modalità DA, sequencer, prover, amministratori, poteri di pausa e blocco osservato. Il nome dello stack non garantisce ogni deployment.
2. Separare ordinamento e prova. Il sequencer può fornire una ricevuta e blocchi L2 prima che impegno o prova raggiungano L1. Registrare il batch esatto e distinguere ordinato, impegnato, provato, accettato, sicuro sul regolamento, finalizzato e prelievo completato.
3. Ricostruire il batch. Ottenere transazioni, differenze di stato, blob sidecar o altro payload richiesto; verificare ordine e impegni; derivare radici precedente e nuova, radice di prelievi o messaggi e altri input pubblici. Una prova legata a catena, batch o radice errati prova un’altra affermazione.
4. Verificare il percorso della prova. Confermare che la transazione abbia chiamato il verificatore previsto con prova, chiave e input attesi, sia riuscita, abbia emesso l’evento corretto e aggiornato lo slot giusto. Quando possibile, riprodurre verifica ed esecuzione con software indipendente.
5. Verificare separatamente la disponibilità. I blob Ethereum offrono disponibilità nella finestra di protocollo e impegni, non archiviazione permanente. Un comitato esterno o livello DA alternativo aggiunge ipotesi proprie. Una prova valida non recupera dati mancanti necessari a ricostruire lo stato o uscire.
6. Seguire depositi e prelievi da capo a fondo. Conciliare token e messenger canonici, importo, destinazione, nonce, radice di inclusione, prova, regola di finalità e saldo eseguito. Un bridge rapido anticipa liquidità con prezzi, instradamento e rischio di controparte propri; non accorcia l’orologio canonico.
7. Monitorare operatività e controllo. Misurare arretrati di batch e prove, inclusione forzata e vie di uscita, diversità dei prover, upgrade, timelock, guardiani e modalità di emergenza. Ripetere dopo modifiche a contratto, circuito, chiave, DA o protocollo.
## Esempi calcolati
- **Compressione.** Un batch didattico contiene `10,000 transactions`; `1,200 KB` di input grezzo diventano `300 KB`. Rapporto: `1,200 / 300 = 4.0x`, riduzione: `1 - 300 / 1,200 = 75%`, media decimale: `300,000 / 10,000 = 30 bytes/transaction`. Non misurano solidità, crescita dello stato o archiviazione.
- **Ripartizione dei costi.** Gli utenti pagano `3.0 ETH`; dati L1 `1.4 ETH`, verifica `0.4 ETH`, esecuzione L2 `0.2 ETH`. Il residuo è `3.0 - 1.4 - 0.4 - 0.2 = 1.0 ETH` e la media `3.0 / 10,000 = 0.0003 ETH/transaction`. Non è profitto netto: esclude proving, hardware, errori, bridge, capitale e imposte.
- **Ciclo di vita.** Ricevuta a `minute 0`, impegno L1 a `minute 12`, prova accettata a `minute 50`, politica di finalità soddisfatta a `minute 64` e prelievo canonico a `minute 70`. Tempo sequenziale: `12 + 38 + 14 + 6 = 70 minutes`. Nessun istante precedente equivale al prelievo completato.
## Rischi
- Catena, deployment, contratto, batch, radice, verificatore, chiave o circuito errati.
- Programma provato incompleto o sbagliato, fedelmente provato da un sistema solido.
- Input pubblici, separatori di dominio, messaggi o parametri assenti o mal codificati.
- Vulnerabilità di verificatore, precompilato, bridge, messenger o contratto di stato.
- Materiale di setup compromesso o ipotesi crittografiche violate.
- Censura, riordino, equivoco, fermo o pubblicazione tardiva del sequencer.
- Fermo, centralizzazione, censura, scarsa capacità o arretrato crescente del prover.
- Transazioni, differenze di stato o blob sidecar indisponibili, malformati o non archiviati.
- Scambiare impegno o firma del comitato per recuperabilità attuale.
- Riorganizzazione L1 o fiducia prematura in un regolamento non sicuro.
- Upgrade privilegiati, timelock brevi, sostituzione, pause o bypass di emergenza.
- Inclusione forzata, recupero o uscita assenti, disabilitati o inutilizzabili.
- Bug del bridge canonico, mapping errato, replay, messaggi o prove di prelievo falliti.
- Rischi di liquidità, prezzo, routing, insolvenza e controparte dei bridge rapidi.
- Stime senza dati L1, proving, bridge, congestione o transazioni fallite.
- Applicare a un rollup compatibilità EVM, finalità, privacy o sicurezza di un altro.
## Errori comuni
- Ogni ZK rollup nasconde importi, indirizzi e attività applicativa.
- Una prova valida garantisce dati disponibili e ricostruzione dello stato.
- Ricevuta del sequencer, prova accettata su L1 e prelievo finale sono equivalenti.
- Le prove eliminano rischi di sequencer, prover, governance, upgrade e bridge.
- Il sistema più economico o rapido produce automaticamente l’esito più sicuro.
## Argomenti correlati
- [Prova di validità](/it/crypto/validity-proof/)
- [Disponibilità dei dati](/it/crypto/data-availability/)
- [Layer 2](/it/crypto/layer2/)
- [Rollup](/it/crypto/rollup/)
- [Prova a conoscenza zero](/it/crypto/zero-knowledge-proof/)
## Fonti
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (consultato: 2026-08-22)
- [Zero-knowledge proofs](https://ethereum.org/zero-knowledge-proofs/) - Ethereum.org (consultato: 2026-08-22)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato: 2026-08-22)
- [Rollup Process](https://docs.scroll.io/en/technology/chain/rollup/) - Scroll Documentation (consultato: 2026-08-22)
- [Data availability](https://docs.starknet.io/learn/protocol/data-availability) - Starknet Documentation (consultato: 2026-08-22)
Source: https://wiki.fcontext.com/it/crypto/zk-rollup/index.mdx