﻿---
title: "Prova a conoscenza zero"
description: "Guida precisa alle prove a conoscenza zero: completezza, solidità, simulazione, testimoni, ipotesi di configurazione, usi blockchain e rischi di verifica."
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 a conoscenza zero

> Solo a scopo educativo; non è consulenza finanziaria o di sicurezza. Una prova valida garantisce soltanto l'enunciato codificato, date le ipotesi del sistema di prova.

<a id="answer"></a>

## Risposta diretta

Una prova a conoscenza zero (ZKP) consente a un prover di convincere un verificatore che un enunciato è vero senza rivelare il testimone segreto usato per dimostrarlo. La garanzia formale non significa che la trascrizione non contenga letteralmente informazioni. Significa che ciò che apprende un verificatore ammesso può essere simulato senza il testimone, salvo quanto deriva dall'enunciato pubblico.

Un sistema di prova si valuta con tre proprietà separate: **completezza**, per cui un prover onesto con un testimone valido viene accettato; **solidità**, per cui un enunciato falso è accettato solo con probabilità trascurabile; e **conoscenza zero**, per cui il testimone resta nascosto nel modello di minaccia definito. Molti sistemi pratici sono argomenti computazionali: la solidità vale contro avversari con calcolo limitato e dipende da ipotesi crittografiche dichiarate.

La conoscenza zero è inoltre distinta da concisione e validità. Una prova può essere ZK ma costosa da verificare, concisa ma mostrare dati pubblici, oppure provare correttamente una relazione codificata che non corrisponde alla regola voluta dall'applicazione.

<a id="mechanism"></a>

## Come funziona

Si parte da un enunciato pubblico `x`, un testimone privato `w` e una relazione precisa `R`. Il prover genera la prova e il verificatore la valuta con parametri pubblici o una chiave di verifica. La solidità prevista si riassume così:

`Verify(vk, x, proof) = 1 => exists w: R(x, w) = 1`

L'equazione afferma solo che esiste un testimone adatto alla relazione codificata. Non lo rivela, non autentica input offchain e non dimostra che `R` comprenda tutte le regole operative previste.

- **Interattiva e non interattiva.** I primi protocolli ZK scambiano sfide e risposte. I sistemi non interattivi racchiudono l'evidenza in una prova e dipendono in genere da materiale di configurazione, un modello random oracle o entrambi.
- **Modello di configurazione.** Groth16 offre prove molto piccole ma usa una configurazione strutturata specifica del circuito. I sistemi tipo PLONK possono usare una stringa di riferimento strutturata universale e aggiornabile. STARK evita il trusted setup strutturato, ma di norma produce prove più grandi e dipende da hash e test di basso grado.
- **Aritmetizzazione e commitment.** Le implementazioni trasformano il programma in vincoli algebrici, vincolano valori derivati dal testimone e usano controlli casuali affinché il verificatore testi il calcolo senza rifarlo né vedere il testimone.
- **Prova di conoscenza.** Alcuni sistemi affermano anche che un prover accettato conosce un testimone, formalizzato tramite un estrattore. È una proprietà distinta e non deriva dall'etichetta “conoscenza zero”.

<a id="example"></a>

## Esempio

Supponiamo che `x` contenga un commitment e una soglia di `100 units`, mentre `w` contiene il saldo vincolato e il fattore di mascheramento. La relazione verifica l'apertura corretta del commitment e che il saldo sia almeno `100 units`. Una ZKP valida dimostra la relazione senza rivelare il saldo esatto.

Il risultato non dimostra da solo che il prover possieda il conto, che i fondi siano liberi o che lo stesso commitment non sia stato riutilizzato. Queste affermazioni richiedono ulteriori vincoli e input pubblici.

In una criptovaluta schermata, un circuito può imporre autorizzazione, conservazione del valore e non duplicazione nascondendo alcuni dettagli. In un validity rollup, una prova può certificare una transizione di stato in batch; i dati possono comunque essere pubblici, quindi “ZK Rollup” non significa automaticamente transazioni private.

<a id="risks"></a>

## Rischi

- Un circuito incompleto o errato può provare perfettamente la regola sbagliata.
- La mancanza di separazione dei domini, identificatori di chain, root o commitment può legare una prova al contesto errato.
- Una configurazione compromessa o toxic waste conservato può rompere la solidità nei sistemi che richiedono trusted setup.
- Bug in prover, verificatore, trascrizione, curva, hash, compilatore o smart contract possono annullare la garanzia teorica.
- Input pubblici, tempi, grafi delle transazioni, commissioni e metadati di rete possono rivelare informazioni fuori dall'enunciato ZK.
- Canali laterali nella generazione del testimone, browser, hardware o servizi remoti possono esporre i segreti prima della prova.
- Verificare la prova non offre disponibilità dei dati, attività del sequencer, finalità, resistenza alla censura o aggiornamenti sicuri.
- Ipotesi e margini concreti di sicurezza variano; dimensione o velocità di verifica non bastano a classificare la sicurezza.

<a id="misconceptions"></a>

## Idee sbagliate comuni

- **“Conoscenza zero significa che non si rivela alcun dato.”** L'enunciato pubblico e gli output volutamente esposti restano visibili, e i metadati possono trapelare fuori dal modello.
- **“Una prova valida significa che l'applicazione è corretta.”** È stata accettata la relazione codificata; restano possibili errori di circuito, integrazione e policy.
- **“Tutti i sistemi ZK hanno le stesse ipotesi di fiducia.”** Cerimonie, curve, hash, modelli di trascrizione e controlli di aggiornamento differiscono sostanzialmente.
- **“ZK è cifratura.”** La cifratura nasconde dati perché un soggetto autorizzato possa decifrarli; una ZKP dimostra un'affermazione senza inviare il testimone da decifrare.

<a id="related"></a>

## Argomenti correlati

- [Hash crittografico](/it/crypto/cryptographic-hash/)
- [Privacy coin](/it/crypto/privacy-coin/)
- [Prova di validità](/it/crypto/validity-proof/)
- [ZK Rollup](/it/crypto/zk-rollup/)

<a id="sources"></a>

## Fonti

- [The Knowledge Complexity of Interactive Proof Systems](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Zero%20Knowledge/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf) - SIAM Journal on Computing (consultato: 2026-08-22)
- [On the Size of Pairing-based Non-interactive Arguments](https://eprint.iacr.org/2016/260.pdf) - IACR Cryptology ePrint Archive (consultato: 2026-08-22)
- [Scalable, transparent, and post-quantum secure computational integrity](https://eprint.iacr.org/2018/046.pdf) - IACR Cryptology ePrint Archive (consultato: 2026-08-22)
- [PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge](https://eprint.iacr.org/2019/953.pdf) - IACR Cryptology ePrint Archive (consultato: 2026-08-22)
- [Zcash Protocol Specification](https://zips.z.cash/protocol/protocol.pdf) - Zcash Protocol Specification (consultato: 2026-08-22)

Source: https://wiki.fcontext.com/it/crypto/zero-knowledge-proof/index.mdx
