---
title: "Prova di validità"
description: "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."
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.
# Prova di validità
> 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.
## 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
- [Disponibilità dei dati](/it/crypto/data-availability/)
- [Prova di errore](/it/crypto/fraud-proof/)
- [Rollup](/it/crypto/rollup/)
- [Prova a conoscenza zero](/it/crypto/zero-knowledge-proof/)
- [ZK Rollup](/it/crypto/zk-rollup/)
## Fonti
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (consultato: 2026-08-22)
- [Zero-knowledge proofs](https://ethereum.org/zero-knowledge-proofs/) - Ethereum.org (consultato: 2026-08-22)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato: 2026-08-22)
- [Sequencing and verification flows](https://docs.polygon.technology/tools/zkevm/architecture/unified-LxLy/ulxly-sequence-verify) - Polygon Documentation (consultato: 2026-08-22)
- [Data availability](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (consultato: 2026-08-22)
Source: https://wiki.fcontext.com/it/crypto/validity-proof/index.mdx