Una Prova a conoscenza zero, o Zero Knowledge Proof (ZKP), è uno straordinario sistema attraverso cui un prover è in grado di dimostrare a un verifier il possesso di un’informazione, definita witness, che soddisfi una specifica relazione, senza rivelare il witness al verifier o a chiunque altro.
In altri termini con un sistema basato su Prova a conoscenza zero, una persona può dimostrare di possedere una certa conoscenza senza rivelare alcuna informazione riguardo alla conoscenza stessa.
Avevamo trattato in precedenza le Prove a conoscenza zero in un precedente articolo introduttivo, senza però entrare nel merito, cosa che invece faremo oggi.
Devi sapere che esistono differenti versioni di Zero Knowledge Proof (ZKP) e con questo post inizieremo a esaminare le non-interactive zero knwowledge proofs, in cui il witness è un Data Blob (i.e. Dati di grandi dimensioni in formato binario) che può essere verificato senza alcuna interazione dal prover.
Zero Knowledge Proof di tipo Zk-SNARK
Zk-SNARK è acronimo di Zero Knowledge Succint Non-Interactive Argument of Knowledge.
Ora comprendiamo il significato di ciascuna di queste parole.
La prima, succint, è molto importante. Significa che le prove sono di piccole dimensioni, alcune centinaia di bytes anche per dichiarazioni su programmi molto grandi, e possono essere verificate velocemente, nell’ordine dei millisecondi.
Mentre Non-Interactive indica l’interazione nulla o comunque minima tra prover e verifier.
Teniamo infatti a mente che versioni precedenti di Zero Knowledge Proof richiedevano un’intensa comunicazione tra le due entità, ed erano pertanto definite Interactive.
Zk-SNARK richiede invece lo scambio di una sola prova.
Attualmente le prove zero knowledge proof di tipo Zk-SNARK dipendono da una configurazione iniziale che richiede una serie di parametri pubblici per elaborare le prove a conoscenza zero. Questo è il punto più delicato del protocollo, e per assicurarne l’integrità sono spesso adottate delle operazioni apparentemente stravaganti, ma necessarie a ragion veduta.
Tra poco potrò spiegarti meglio questo particolare.
Continuando l’analisi dell’acronimo, la parola Arguments si differenzia dalla Proof per alcuni aspetti tecnici su cui sorvoliamo per il momento.
Infine la parola of Knowledge allude all’impossibilità del prover di generare una proof (i.e. Argument in questo caso) senza essere effettivamente in possesso del witness, ovvero dell’informazione.
Cerchiamo di capire ora come funzioni questo tipo di protocollo a zero knowledge proof
Come funziona Zk-SNARK?
Il funzionamento del protocollo di Zk-SNARK si basa essenzialmente su tre algoritmi, che possiamo chiamare G, P e V e definiti come segue.
Key Generator G
L’algoritmo G e un key generator, che richiede un parametro segreto lambda 🤐 e un programma C 📑, generando due chiavi pubbliche:
- 🔑 proving key, o pk
- 🗝 verification key, vk
Queste due chiavi pubbliche devono essere generate una sola volta per ogni programma C 📑
Prover P
L’algoritmo P richiede la proving key 🔑, un numero pubblico x 🔓 e un witness w 🕵️♂️, per generare una proof 🧪
prf = P(pk, x, w) | 🧪 = P(🔑,🔓, 🕵️♂️)
La prova 🧪 indica che il prover conosce l’informazione 🕵️♂️ e che questa soddisfi il programma 📑.
Verifier V
Infine l’algoritmo verifier V richiede la prova 🧪 e il numero pubblico 🔓 per validare con la verification key 🗝 che la prova 🧪 sia effettivamente corretta restituendo true o false.
V(vk, x, prf ) | V(🗝, 🔓, 🧪) = true | false
Il parametro lambda
In questa danza di operazioni per assicurare il corretto funzionamento del protocollo di zero knowledge proof, il parametro lambda 🤐 è di cruciale importanza.
Infatti la sicurezza di Zk-SNARK si riduce al sistema con cui il parametro lambda è generato.
Chiunque sia in possesso di questo valore, sarebbe in grado di generare false prove 🧪 che all’atto della verifica risulterebbero valide. (e.g. Certificare che sia stata fatta una transazione di 1mld sul mio conto).
Questo perché dato un qualsiasi programma C 📑, e un numero pubblico x 🔓 una persona con lambda nota 🤐 potrebbe generare una falsa prova tale che V(vk, x, fake_prf) risulti vera senza conoscere il segreto w 🕵️♂️.
Ecco perché la generazione del segreto lambda, chiamato Common Reference String (CRS), richiede un processo altamente sicuro che garantisca che nessuno sia in possesso dell’informazione e la salvi da qualche parte.
Ancora meglio, una volta creato il CRS, le informazioni usate per la sua generazione, definite toxic waste, andrebbero eliminate assicurando l’impossibilità di ricreare lambda.
Ecco perché, nel tentativo di ovviare al problema, è possibile fare ricorso al Secure Multiparty computation.
La generazione dei parametri pubblici, le due chiavi, a partire da un parametro lambda creato partendo da una serie di informazione è chiamata setup cerymony.
In questo articolo puoi trovare un approfondimento tecnico e di qualità sulla setup cerymony per Zk-SNARK.
Applicazione di Zero knowledge proof in Zcash
Zcash è certamente l’applicazione meglio riuscita e diffusa di un protocollo Zk-SNARK. Contrariamente ad altre reti decentralizzate come blockchain, in cui le transazioni sono pubbliche, all’interno della rete Zcash i trasferimenti possono rimanere criptati.
A questo punto, la verifica della validità deve necessariamente passare da un sistema che consenta di validare la transazione assicurando che l’informazione criptata risulti corretta senza tuttavia decriptarla. E cioè che il witness 🕵️♂️ dietro la cifratura sia corretto senza che questa venga corrotta.
Anche qui, la sicura generazione delle chiavi pubbliche è cruciale per la sicurezza del sistema, ecco perché gli sviluppatori di Zcash hanno elaborato una complessa setup cerymony che puoi trovare qui.
Una cerimonia caratterizzata da persone con identità tutt’oggi sconosciuta, computer smontati per rimuovere antenne e trasformarli in air gapped pc, DVD-R non riscrivibili per il trasferimento da un PC all’altro e hash dei programmi per assicurare che nulla sia stato compromesso, con bonus di pubblicazione di stringe alfanumeriche su twitter.
Infine, per comprendere come Zk-SNARK sia effettivamente usato in Zcash ti esorterei a leggere questa paper.
Angolo sviluppatori
Chiudiamo il discorso Zk-SNARK con una nota pratica che da sempre caratterizza il blog. Propongo infatti Zokrates, un toolbox per creare Zk-SNARK su rete Ethereum.
Zero Knowledge Proof di tipo Zk-STARK
Le Prove a conoscenza zero di tipo Zk-STARK sono state create come variante migliorativa delle Zk-SNARK, e offrono maggiori velocità implementative nonché un’elevata trasparenza (T, Transaprent nell’acronimo) evitando la necessità di una configurazione iniziale fidata.
Tale vantaggio è ottenuto sfruttando una configurazione basata su crittografia simmetrica con funzioni di hash resistenti alla collisione, e più sicure in un epoca post-quant.
In definitiva, a fronte di un costo computazionale costante anziché crescente all’aumentare della dimensione del programma C iniziale, come rilevato per le Zero Knowledge Proof tipo Zk-SNARK, quelle Zk-STARK garantiscono prestazioni migliori e inferiori comunicazioni tra prover e verifier.
Per il momento è tutto.
Per aspera, ad astra.
Un caldo abbraccio, Andrea
