---
title: "Rollup"
description: "Come i rollup eseguono transazioni, pubblicano dati e impegni, verificano transizioni di stato, regolano su un livello base e introducono rischi operativi specifici."
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.
# Rollup
> Solo a scopo educativo; non è consulenza finanziaria, d'investimento, sui bridge o di sicurezza. Le garanzie di un rollup dipendono dai contratti distribuiti, dal sistema di prova, dalla disponibilità dei dati, dai permessi dell'operatore, dalla governance e dal livello base, tutti soggetti a modifiche.
## Risposta diretta
Un rollup è un modello di scalabilità blockchain che esegue transazioni fuori da un livello base, usando quel livello per pubblicare dati o impegni definiti dal protocollo e regolare transizioni di stato contestate o provate. Molte transazioni condividono il costo dei dati e del regolamento sul livello base. Un rollup è quindi più della compressione e una state root da sola non fornisce i dati per ricostruire la catena.
I rollup ottimistici accettano in genere le dichiarazioni di stato salvo che una contestazione con prova di errore dimostri una transizione non valida. I rollup ZK inviano prove di validità verificate dal contratto di regolamento. Questi nomi descrivono l'accettazione delle transizioni, non una garanzia universale su decentralizzazione del sequencer, archiviazione, controllo degli aggiornamenti, commissioni o tempi di prelievo.
## Come funziona
- **Ordinare ed eseguire.** Un sequencer o altro meccanismo seleziona e ordina le transazioni e calcola lo stato risultante. L'utente può ricevere una ricevuta rapida prima della conferma sul livello base.
- **Pubblicare i dati.** Il sistema pubblica dati di input sufficienti, spesso come calldata o blob, sul livello base oppure usa un'altra disponibilità dati. Questa determina se nodi indipendenti possono ricostruire e verificare lo stato.
- **Impegnare lo stato.** Il rollup pubblica state root o altri impegni che lo vincolano a un risultato. L'impegno è compatto, ma non è la cronologia delle transazioni sottostante.
- **Verificare le transizioni.** Il modello ottimistico dipende da una finestra di contestazione e un processo di prove di errore distribuito; quello ZK da una prova di validità e un verificatore on-chain. Errori, permessi e operatività contano in entrambi.
- **Regolare e prelevare.** I contratti del livello base determinano accettazione e finalizzazione di messaggi e asset. I prelievi canonici possono subire ritardi di prova, contestazione o finalità; un bridge rapido aggiunge un fornitore di liquidità e rischio di controparte.
- **Aggiornare e recuperare.** Governance, consigli di sicurezza, guardiani o amministratori possono sospendere o aggiornare contratti. Timelock, via di fuga e inclusione forzata vanno verificati sulla specifica distribuzione.
## Esempio
Si supponga un batch di `1,000` transazioni. Gli utenti pagano insieme `0.8 ETH`, i dati sul livello base costano `0.5 ETH` e l'esecuzione del rollup `0.2 ETH`. Il residuo non spiegato è `0.8 - 0.5 - 0.2 = 0.1 ETH`, cioè `0.1 / 1,000 = 0.0001 ETH` per transazione prima di generazione delle prove, infrastruttura, batch falliti, costo del capitale e rimborsi. È una riconciliazione dei costi, non profitto dell'operatore.
Prima di considerare finale il batch, verificare se la ricevuta proviene solo dal sequencer, se dati e impegno hanno raggiunto il livello base, se la finestra di prova di errore è terminata o la prova di validità è stata accettata e se il messaggio di prelievo è diventato separatamente eseguibile.
## Rischi
- Un sequencer centralizzato può censurare, riordinare o interrompere temporaneamente le transazioni.
- Dati del batch mancanti o indisponibili possono impedire ricostruzione e uscite indipendenti.
- Programmi di prova di errore, circuiti di validità, verificatori o client possono contenere bug.
- Contestatori o produttori di prove possono essere offline, censurati, senza fondi o autorizzati male.
- Congestione, riorganizzazione o guasto del livello base può ritardare pubblicazione, prova e regolamento.
- Chiavi di aggiornamento, guardiani o governance possono cambiare codice, parametri o bridge.
- Bridge canonici e mappature dei token possono fallire nonostante l'esecuzione corretta.
- Commissioni, tempi di prova e ritardi di prelievo variano e possono cambiare dopo aggiornamenti.
## Idee sbagliate comuni
- **Tutti i rollup conservano tutto per sempre sul livello base.** Formati di pubblicazione e garanzie di archivio variano; i blob non sono memoria permanente.
- **Una ricevuta del sequencer è regolamento finale.** Può essere solo una promessa iniziale di ordinamento.
- **ZK significa privato.** Le prove di validità attestano il calcolo corretto; la privacy è una scelta separata.
- **Ottimistico significa senza verifica.** La correttezza richiede dati riproducibili, un sistema di prove di errore funzionante e partecipanti capaci di contestare.
- **Commissioni medie inferiori eliminano il rischio operativo.** Il regolamento condiviso può ridurre i costi, ma restano dipendenze da sequencer, prove, governance, bridge e dati.
## Argomenti correlati
- [Ethereum](/it/crypto/ethereum/)
- [Layer 2](/it/crypto/layer2/)
- [Rollup ottimistici](/it/crypto/optimistic-rollup/)
- [Rollup ZK](/it/crypto/zk-rollup/)
- [Disponibilità dei dati](/it/crypto/data-availability/)
## Fonti
- [Scalabilità](https://ethereum.org/en/developers/docs/scaling/) - Ethereum.org (consultato: 2026-08-21)
- [Rollup ottimistici](https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (consultato: 2026-08-21)
- [Rollup a conoscenza zero](https://ethereum.org/en/developers/docs/scaling/zk-rollups/) - Ethereum.org (consultato: 2026-08-21)
- [EIP-4844: transazioni con blob di shard](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato: 2026-08-21)
Source: https://wiki.fcontext.com/it/crypto/rollup/index.mdx