Vai al contenuto
Financial Context Wiki

Prova di validità

Guida orientata alla verifica di prove di validità, input pubblici, witness, ipotesi del sistema di prova, transizioni di stato dei rollup, disponibilità dei dati, finalità e guasti operativi.

Aggiornato

Solo a scopo educativo; non è consulenza finanziaria o di sicurezza. Una prova di validità è affidabile quanto la sua affermazione, il legame degli input pubblici, il sistema di prova, il verificatore, la disponibilità dei dati, i contratti, gli operatori, la governance e la catena di regolamento.

Risposta diretta

Una prova di validità è evidenza crittografica che un calcolo dichiarato soddisfa una relazione definita con precisione. Un verificatore controlla la prova con una chiave di verifica e input pubblici. In un rollup tali input legano in genere la radice di stato precedente, quella nuova proposta e gli impegni di un batch. Se la verifica riesce, il contratto di regolamento può accettare la nuova radice senza rieseguire ogni transazione.

La garanzia è più ristretta di “il sistema è corretto”. Dipende da crittografia solida, programma o circuito previsto, corretta codifica degli input, chiave autentica e contratti corretti. La verifica da sola non prova accesso ai dati, attività futura del prover, finalità del blocco, bontà di un upgrade o funzionamento del prelievo. Può usare zero knowledge, ma validità non implica privacy.

1
Eseguire

Il prover esegue un batch o un calcolo e registra la transizione di stato risultante.

Come funziona

  1. Fissare il deployment esatto: ID L1 e L2, versione, contratto di stato, indirizzo e bytecode del verificatore, hash della chiave, sistema, circuito o programma, modalità dati, poteri admin, pausa e politica di finalità. validity proof non è una specifica universale.
  2. Definire la relazione prima di interpretare. Date le ipotesi di solidità, Verify(vk, x, proof) = 1 deve implicare un witness w con R(x, w) = 1. vk è la chiave, x l’input pubblico completo e R le regole codificate. La prova copre solo questa relazione.
  3. Ricostruire gli input pubblici in modo indipendente. Confermare la radice precedente accettata; derivare commitment, identificatori, radice successiva, radici di messaggi o prelievi e parametri da dati canonici. Una prova legata all’oggetto sbagliato prova l’affermazione sbagliata.
  4. Verificare prova e percorso contrattuale. Eseguire un verificatore indipendente, poi controllare chiamata onchain, ricevuta, evento, batch accettato e storage. Confermare che il contratto abbia usato il verificatore previsto senza bypass, simulazioni o sostituzioni privilegiate.
  5. Verificare separatamente la disponibilità dei dati. Recuperare transazioni, differenze di stato, blob sidecar o dati attestati richiesti; controllare commitment e riprodurre transizione o witness di uscita. Prova valida e dati indisponibili possono coesistere, soprattutto in validium.
  6. Separare gli stati: generata, inviata, inclusa, verificata, stato accettato, regolamento sicuro, finalizzato e prelievo completato. Misurare coda, costi, liveness, inclusione L1, reorg, ritardi del bridge, inclusione forzata e uscita.
  7. Conservare evidenze riproducibili: indirizzi e hash del codice, hash di chiave e programma, input completi, byte o riferimento della prova, dati batch, comando e versione, ricevuta, blocco finalizzato e test di uscita. Ricontrollare dopo ogni upgrade.

Esempi calcolati

  • Affermazione batch. Un rollup elabora 8,192 transfers. La prova lega R0, R1 e B7. La verifica sostiene l’esistenza di un witness dal R0 a R1 per B7; non prova recuperabilità di B7, inclusione completa o finalità di R1.
  • Aggregazione ricorsiva. Un aggregatore verifica 16 child proofs in un circuito padre e invia una prova padre. Vanno comunque controllati ogni figlio, ordine e mappatura degli input; il numero non crea il legame.
  • Registro gas ipotetico. Rieseguire costa 24,000,000 gas, verificare 600,000 gas e pubblicare dati 180,000 gas. Totale 600,000 + 180,000 = 780,000 gas, riduzione modellata (24,000,000 - 780,000) / 24,000,000 = 96.75%. Hardware, aggregazione, errori, storage, bridge e conservazione sono esclusi.

Rischi

  • Verificare catena, deployment, batch, verificatore, chiave o circuito errati.
  • Un sistema solido dimostra fedelmente un circuito incompleto o sbagliato.
  • Gli input pubblici omettono o codificano male ID, radice, batch, dominio o parametro.
  • Bug nel verificatore, precompilato, libreria non sicura o implementazione incompatibile.
  • Materiale di setup compromesso o ipotesi crittografiche violate.
  • Contratti aggiornabili o governance sostituiscono verificatore, chiave, programma o regola.
  • Bypass privilegiati, emergenze, pause o allowlist indeboliscono il percorso dichiarato.
  • Bug di generazione, non determinismo o witness diversi fra client.
  • Centralizzazione, censura, guasto, coda o hardware del prover fermano gli aggiornamenti.
  • Dati di transazione, differenze di stato, blob, preimmagini o archivi mancanti.
  • Scambiare firme del comitato o commitment per disponibilità attuale dei dati.
  • Accettare una prova da un blocco non sicuro, riorganizzato o non canonico.
  • Scambiare accettazione della prova per prelievo immediato o finalità economica.
  • Non riprodurre indipendentemente transizione, saldo, messaggio o witness di uscita.
  • Sottostimare gas, costi dati, latenza, ritardi del bridge o recupero.
  • Applicare a un deployment il modello di prova, disponibilità e upgrade di un altro.

Errori comuni

  • Una prova verificata garantisce ogni dettaglio e saldo mostrato.
  • Ogni prova di validità è zero knowledge e nasconde le transazioni.
  • Le prove eliminano rischi di dati, liveness del sequencer e censura.
  • La verifica rende il regolamento subito finale e prelevabile.
  • Prova più piccola o verificatore più rapido significa automaticamente più sicurezza o minor costo.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...