---
title: "Optimistic rollup"
description: "Guida specifica per deployment a ricevute del sequencer, dati di derivazione su L1, head unsafe/safe/finalized, giochi di fault proof, prelievi canonici, governance e fast exit."
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.
# Optimistic rollup
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Un optimistic rollup esegue un flusso ordinato di transazioni e pubblica dati di derivazione e state claim definiti dal protocollo senza allegare una prova di validità a ogni batch. “Optimistic” significa che un claim ammissibile può avanzare secondo le regole implementate, salvo che una disputa di fault proof risolta con successo ne dimostri l'errore. Non significa che un messaggio del sequencer provi la correttezza, né che ogni implementazione offra contestazioni permissionless o lo stesso ritardo di prelievo.
I nodi del rollup derivano autonomamente i blocchi L2 dagli input L1 canonici e dalla configurazione esatta del protocollo. Il percorso di sicurezza comprende quindi disponibilità dei dati, derivazione ed esecuzione corrette, un sistema di fault proof attivo e solido, accesso e finalità di L1, governance e contratti del bridge. Una state root da sola non basta per ricostruire la chain o contestare una transizione non valida.
## Come funziona
1. Fissare il deployment: chain ID di L1 e L2, configurazione e fork del rollup, contratti inbox e bridge, formato dei batch e modalità DA, contratti di state claim e dispute game, versione del portal, amministratori, guardian e blocco di osservazione. La documentazione di uno stack non dimostra che ogni funzione sia attiva su una determinata chain.
2. Classificare lo stato osservato. Una ricevuta del sequencer o un blocco unsafe è un rapido impegno locale sull'ordinamento; un batch pubblicato su L1 può sostenere un head derivato safe; la finalità di L1 può sostenere un head derivato finalized. Uno state o output claim, una disputa risolta e un prelievo eseguibile sono oggetti e tempi separati.
3. Ricostruire la pipeline di derivazione da L1 a L2. Verificare depositi e input sequenziati, canali e batch, origini L1, modifiche di configurazione e transizioni di stato dai dati L1 canonici. Per i dati su blob, distinguere la disponibilità nella finestra del protocollo dalla successiva reperibilità archivistica.
4. Mappare liveness e controllo. Separare sequencer, batcher, proposer, challenger, relayer, guardian e autorità di upgrade; verificare se esistono percorsi forced inclusion o delayed inbox, i relativi ritardi e condizioni di pausa, e se gli utenti ordinari dispongono di software funzionante per usarli.
5. Verificare il percorso di fault proof implementato. Registrare il game type rispettato, i permessi di proposer e challenger, i bond, il prestate assoluto, il programma di prova e la VM, il preimage oracle, la profondità dei claim, gli orologi e le estensioni, le regole di risoluzione, i poteri di blacklist o pausa e il ritardo di upgrade. Non trasferire la meccanica di OP Stack ad Arbitrum o ad altri rollup.
6. Tracciare separatamente prelievi ed economia. Seguire avvio su L2, prova su L1, dipendenza dal claim o dal gioco, ritardo di maturità e finalità, nuova prova, controlli del portal ed esecuzione su L1. Trattare un fast exit come operazione di liquidità o credito prezzata con una controparte distinta, non come abbreviazione del periodo canonico di contestazione.
7. Riconciliare continuamente. Confrontare hash dei blocchi unsafe, safe e finalized, transazioni batch su L1, state claim, esiti dei giochi, messaggi del bridge, ricevute, contratti dei token e saldi finali. Riaprire l'analisi dopo una riorganizzazione L1 o L2, un batch mancante, una disputa, una pausa, un upgrade contrattuale o una migrazione DA.
## Esempi svolti
- **Payload di derivazione.** Un batch contiene `10,000` transazioni, `1,200 KB` di input grezzi del protocollo e `300 KB` dopo la compressione. Il rapporto è `1,200 / 300 = 4.0x`, la riduzione è `1 - 300 / 1,200 = 75%` e la media decimale è `300,000 / 10,000 = 30 bytes/tx`. Questi numeri descrivono solo il payload di input codificato, non il gas L1, la correttezza dell'esecuzione, la dimensione dello stato o le garanzie di archiviazione.
- **Contributo prima dei costi omessi.** Gli utenti pagano `2.4 ETH`; l'esecuzione L2 misurata costa `0.3 ETH`; la DA su L1 costa `1.2 ETH`. Il residuo è `2.4 - 0.3 - 1.2 = 0.9 ETH`, ossia `0.9 / 10,000 = 0.00009 ETH/tx`. Non è utile netto perché omette infrastruttura dell'operatore, esecuzione L1, giochi di prova, rimborsi, capitale, guasti e imposte.
- **Localizzazione della disputa.** Una traccia didattica di esecuzione ha `2^20 = 1,048,576` passaggi. Un restringimento binario ideale richiede `log2(2^20) = 20` scelte per isolare un passaggio. Se ogni round didattico avesse un massimo separato di `3-hour`, un limite seriale ingenuo sarebbe `20 * 3 = 60 hours`; i protocolli reali usano propri chess clock, concorrenza, estensioni e calendario delle transazioni.
- **Tempi di prelievo e liquidità rapida.** Un batch didattico raggiunge L1 dopo `10 minutes`, un claim riconosciuto arriva dopo altri `30 minutes`, un ipotetico periodo di contestazione dura `7 days` e il relay finale richiede `2 hours`. Il tempo sequenziale è `10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes`. Un bridge di liquidità che anticipa `4.97 ETH` su un claim di `5 ETH` addebita `0.03 ETH`, cioè `0.03 / 5 = 0.6%`, mentre il claim canonico resta soggetto ai tempi e ai rischi originari.
## Rischi
- L1, L2, chain ID, configurazione o contratti di deployment errati.
- Trattare una ricevuta unsafe del sequencer come safe o finale.
- Equivocazione, censura, riordinamento o indisponibilità del sequencer.
- Pubblicazione del batch su L1 ritardata, assente, malformata o non valida.
- Dati blob o alternative DA indisponibili o non archiviati.
- Incompatibilità di client di derivazione, configurazione o fork.
- Riorganizzazione L1 che invalida input di derivazione prima considerati safe.
- Indisponibilità di batcher, state proposer o partecipante alla prova.
- Percorso forced inclusion o delayed inbox assente, in pausa o frainteso.
- Fault proof non implementati, inattivi o legati al game type errato.
- Ruoli di proposer o challenger permissioned o in allowlist.
- Challenger offline, censurato, senza fondi o oltre la scadenza.
- Bug nel programma di prova, VM, prestate assoluto, oracle o verifier.
- Errore di orologio, estensione, posizione del claim, bond o contabilità della risoluzione.
- Intervento di guardian, security council, pausa o blacklist.
- Upgrade immediato, timelock breve o chiavi amministrative compromesse.
- Vulnerabilità di bridge canonico, messenger, replay o mapping degli asset.
- Errore di prova, maturità, nuova prova, finalizzazione o relay del prelievo.
- Rischio di liquidità, prezzo, routing, insolvenza o controparte del fast exit.
- Confondere finalità L1, finalità L2 derivata, risoluzione del claim e ricezione dell'asset.
## Errori comuni
- Optimistic significa fidarsi incondizionatamente del risultato mostrato dal sequencer.
- Pubblicare una sola state root fornisce disponibilità dei dati e derivazione indipendente.
- Ogni optimistic rollup ha fault proof permissionless attivi e un periodo universale di sette giorni.
- Un blocco L2 safe o finalized implica che il suo prelievo da L2 a L1 sia già eseguibile.
- Un fast bridge accorcia il periodo canonico di contestazione o comporta solo rischio del rollup.
## Argomenti correlati
- [Fault proof](/it/crypto/fraud-proof/)
- [Disponibilità dei dati](/it/crypto/data-availability/)
- [Rollup](/it/crypto/rollup/)
## Fonti
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (consultato: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (consultato: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (consultato: 2026-08-13)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (consultato: 2026-08-13)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (consultato: 2026-08-13)
- [Stage 1 Roles and Requirements](https://specs.optimism.io/protocol/stage-1.html) - OP Stack Specification (consultato: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultato: 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/optimistic-rollup/index.mdx