---
title: "Fault proof (prova di esecuzione errata)"
description: "Guida sensibile al deployment su fault proof ottimistici, claim contestati, bisezione delle trace, verifica single-step, clock, cauzioni, disponibilità dei dati, finalità dei prelievi e verifica operativa."
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.
# Fault proof (prova di esecuzione errata)
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Un fault proof, spesso chiamato fraud proof, è il processo protocollare con cui si contesta un claim ottimistico su un calcolo o uno stato. Il proponente non prova ogni transizione prima dell’accettazione: un challenger idoneo può presentare una trace incompatibile entro i clock previsti e il contratto di settlement decide con il verifier specificato. Molti sistemi interattivi restringono una lunga trace fino a una singola istruzione controversa, quindi eseguono on-chain quel caso base.
Il nome non dimostra che il deployment sia permissionless, operativo o sicuro. Servono dati di derivazione disponibili, almeno un challenger corretto che ricostruisca il claim e agisca in tempo, accesso e gas sulla chain di settlement, programmi e contratti corretti e governance incapace di aggirare l’esito. Un claim sopravvissuto al gioco può autorizzare un prelievo secondo quelle regole; non prova retroattivamente ogni transazione L2 o risultato economico.
## Come funziona
1. Fissare il deployment: chain ID L1/L2, versioni, hash, factory, portal o bridge, proof program, VM, game type, implementazioni e admin, permessi, cauzioni, profondità, clock, ritardi, pause e finalità. `fraud proof` non è una specifica comune a tutti i rollup.
2. Ricostruire il claim da input autenticati: anchor state, L1 head, blocco L2 o output root contestato, batch e blob, configurazione, pre-stato, withdrawal root e regole di derivazione. Una state root non basta; dati assenti possono rendere impraticabile la contestazione.
3. Verificare creazione e rilevanza del gioco: root claim, proponente, blocco e ora, tipo, stato respected o blacklisted, cauzione, idoneità e regola del portal. Distinguere claim pending, esito del gioco e output utilizzabile per il prelievo.
4. Rieseguire con nodo e implementazione indipendenti. Confrontare la trace corretta e conservare preimage, witness e versioni. Nel gioco interattivo attaccare o difendere l’intervallo corretto fino a isolare un’istruzione, poi inviare il witness base al verifier VM on-chain.
5. Seguire clock e transazioni di ogni squadra: tempo, estensioni, inclusione e reorg L1, calldata, gas, sostituzioni, cauzioni, claim paralleli e soggetto tenuto a rispondere. Non esiste necessariamente un unico conto alla rovescia; una posizione corretta può perdere per ritardo o censura.
6. Collegare la risoluzione alle conseguenze: claim confutati, vincitore, distribuzione di cauzioni e costi, esclusione dell’output invalido e ricostruzione di output, proof o prelievi dipendenti. Lo slashing incentiva, ma non risarcisce ogni perdita del bridge.
7. Riconciliare separatamente finalità e prelievi: risoluzione, ritardi di maturazione e post-risoluzione, tipo respected, blacklist e pause, prova di inclusione, ricevuta e finalità L1. Archiviare le prove e testare contestazione, forced inclusion, nuova prova e uscita d’emergenza.
## Esempi svolti
- **Bisezione della trace.** Una trace didattica contiene `1,048,576 = 2^20 instructions`. Se ogni round dimezza l’intervallo, `20 bisections` isolano un’istruzione perché `2^20 / 2^20 = 1`. Giochi reali possono dividere trace diverse, ramificarsi in un DAG o richiedere mosse ulteriori.
- **Clock indipendenti.** Un gioco ipotetico assegna `84 hours` a ciascuna squadra. Il defender usa `30 hours` e il challenger `22 hours`, lasciando `54 hours` e `62 hours`. Il tempo trascorso non è semplicemente `84 hours`: avanza solo il clock applicabile e estensioni, inclusioni e claim paralleli cambiano la scadenza.
- **Registro cauzione e gas.** Per una regola esplicitamente ipotetica, una root invalida ha cauzione `2 ETH`. Il vincitore ha versato `0.5 ETH`, recupera il capitale più `1.4 ETH`, spendendo `0.08 ETH` di gas L1; `0.6 ETH` va alla tesoreria. Guadagno netto: `1.4 - 0.08 = 1.32 ETH`; i `0.5 ETH` restituiti non sono profitto e `1.4 + 0.6 = 2 ETH`. Le regole reali dipendono dal contratto.
- **Clock del prelievo.** Prova il `2026-08-01 12:00 UTC`, maturazione `7 days`, risoluzione il `2026-08-06 18:00 UTC`, air gap `1 day`. Le soglie terminano il `2026-08-08 12:00 UTC` e il `2026-08-07 18:00 UTC`; il primo istante valido è `2026-08-08 12:00 UTC`. Con `20 minutes` di finalità L1, il completamento è `2026-08-08 12:20 UTC`, salvo pause, blacklist, nuova prova o reorg.
## Rischi
- Verificare L1, L2, deployment, game type o versione sbagliati.
- Ricostruire da anchor o L1 head obsoleti, non canonici o errati.
- Perdere batch, blob, preimage, state witness o configurazione.
- Confondere un commitment con disponibilità di tutti i dati.
- Ottenere una trace diversa per un bug del client challenger.
- Bug in proof program, VM, preimage oracle o step verifier.
- Proponente, challenger o creazione permissioned indisponibili o catturati.
- Nessun watcher onesto apre la disputa entro la scadenza.
- Censura, congestione, reorg o gas L1 impediscono una mossa.
- Leggere male clock, estensioni, profondità o inclusione.
- Attaccare claim, intervallo, posizione o istruzione sbagliati.
- Cauzioni o capitale rendono impraticabile la partecipazione.
- Distribuzione, freeloader o incentivi divergono dalle ipotesi.
- Giochi multipli, claim duplicati o implementazioni confliggono.
- La governance cambia game type, verifier, soglia o ritardo.
- Pause o blacklist del Guardian bloccano prelievi validi.
- Confondere risoluzione del gioco e finalità immediata.
- Provare contro un gioco invalidato senza ripetere la prova.
- Supporre che escludere un output ripari ogni effetto a valle.
- Estendere il modello di un rollup ottimistico a un altro.
## Errori comuni
- Un claim ottimistico non contestato è provato crittograficamente.
- Chiunque può contestare ogni deployment senza permessi, capitale o infrastruttura.
- Un fault proof funziona senza dati di derivazione disponibili.
- Vincere finalizza subito ogni prelievo e rimborsa ogni perdita.
- Sette giorni, gioco binario e un osservatore onesto sono costanti universali.
## Argomenti correlati
- [Disponibilità dei dati](/it/crypto/data-availability/)
- [Rollup ottimistico](/it/crypto/optimistic-rollup/)
- [Validity proof](/it/crypto/validity-proof/)
## Fonti
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (consultato: 2026-08-12)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (consultato: 2026-08-12)
- [Fault Dispute Game](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html) - OP Stack Specification (consultato: 2026-08-12)
- [Honest Challenger (Fault Dispute Game)](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html) - OP Stack Specification (consultato: 2026-08-12)
- [Bridge Integration](https://specs.optimism.io/fault-proof/stage-one/bridge-integration.html) - OP Stack Specification (consultato: 2026-08-12)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (consultato: 2026-08-12)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultato: 2026-08-12)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultato: 2026-08-12)
Source: https://wiki.fcontext.com/it/crypto/fraud-proof/index.mdx