Vai al contenuto
Financial Context Wiki

Fault proof (prova di esecuzione errata)

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.

Aggiornato

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.

1
Sequenza

Il sequenziatore ordina le transazioni L2 e pubblica i dati delle transazioni o gli impegni.

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

Fonti

Navigazione

Cerca nella wiki...