Cosa sono gli zk-SNARK e come rendono possibile la privacy sulle blockchain?

Cosa sono gli zk-SNARK?

Gli zk-SNARK sono prove crittografiche che ti permettono di dimostrare che certe informazioni o un calcolo sono corretti, senza rendere pubbliche informazioni sensibili. Così una blockchain può, per esempio, verificare che un pagamento sia valido, mentre dati come l’importo o il destinatario restano nascosti. Una delle blockchain più conosciute che usa questa tecnologia è Zcash. Lì gli zk-SNARK vengono usati per verificare le transazioni mentre dati come l’importo o il destinatario possono restare nascosti.

Il nome zk-SNARK è l’abbreviazione di zero-knowledge succinct non-interactive argument of knowledge. Sembra complicato, ma puoi dividere facilmente le parti:

• Zero-knowledge: la prova dimostra che un’affermazione è vera, per esempio che una transazione è valida, senza rivelare informazioni sensibili come l’indirizzo di invio, l’indirizzo di ricezione o l’importo della transazione.
• Succinct: la prova è breve. Un nodo o uno smart contract può quindi verificarla in modo relativamente efficiente.
• Non-interactive: dopo aver creato la prova, chi la genera non deve comunicare avanti e indietro con chi la controlla. La prova può essere creata una volta e poi verificata.
• Argument of knowledge: chi la genera dimostra di avere le informazioni necessarie per rispettare le regole stabilite, per esempio i dati con cui si può creare una transazione valida. La sicurezza si basa su assunzioni crittografiche: un attaccante con potenza di calcolo limitata non può, in pratica, creare una prova falsa che venga accettata come valida. Le informazioni usate per creare la prova vengono spesso chiamate witness. Immagina di voler dimostrare di avere abbastanza saldo per un pagamento. La witness contiene allora, per esempio, i dati con cui puoi dimostrare di avere fondi sufficienti e di poterli spendere. La blockchain non deve vedere quei dati direttamente, ma può comunque controllare che la prova corrispondente sia valida.

Oltre alla witness privata, uno zk-SNARK può contenere anche input pubblici. Sono dati che possono essere visibili e che il verifier usa insieme alla prova per controllare se l’affermazione è corretta.

Importante da sapere: uno zk-SNARK non è un protocollo unico e fisso, ma un termine generico per diversi tipi di sistemi di prova con queste caratteristiche. Il funzionamento preciso può cambiare da un sistema all’altro. Alcuni sistemi, per esempio, richiedono un trusted setup, mentre altri possono funzionare senza.

In breve

• Gli zk-SNARK dimostrano che qualcosa è vero senza rivelare informazioni sensibili.
• I dati privati dietro una prova vengono spesso chiamati witness.
• Le prove sono brevi e possono essere verificate in modo relativamente efficiente.
• Una prova pubblicata può essere verificata senza contatti aggiuntivi con chi l’ha creata.
• Gli zk-SNARK sono una categoria di sistemi di prova, non un protocollo unico.

Come funzionano gli zk-SNARK?

In uno zk-SNARK, le regole che una transazione o un calcolo devono rispettare vengono prima trasformate in controlli che un computer può eseguire. Questo insieme di controlli viene chiamato circuito o sistema di vincoli. Dentro ci sono esattamente le condizioni che devono essere soddisfatte prima che qualcosa venga considerato valido.

Prendi come esempio un pagamento privato. Il circuito può controllare, per esempio, se qualcuno ha abbastanza saldo, se quel saldo non è già stato speso in precedenza e se è autorizzato a usarlo. I dati sensibili necessari per questi controlli, come il saldo o i dati che ne permettono la spesa, restano nascosti a chi verifica la prova.

In linea generale ci sono tre passaggi:

1. Setup In molti zk-SNARK classici, prima vengono creati dei parametri pubblici. Questi dati servono per generare e verificare le prove.

2. Generazione della prova Il prover, cioè la parte che vuole dimostrare qualcosa, usa la witness e le regole del circuito per creare una prova crittografica.

3. Verifica Il verifier, per esempio un nodo o uno smart contract, controlla la prova insieme agli input pubblici. Il verifier non vede la witness privata e non deve rifare da solo l’intero calcolo.

Un buon sistema zk-SNARK cerca di garantire tre proprietà importanti. Prima di tutto la completezza: se l’affermazione è vera e la prova viene creata correttamente, la prova viene accettata. Poi la soundness: un attaccante non può, in pratica, creare una prova valida per un’affermazione falsa. E infine la zero-knowledge: la prova non rivela informazioni sensibili, a parte il fatto che l’affermazione dimostrata è vera.

Esempio: immagina di dover dimostrare di avere più di 18 anni senza condividere la tua data di nascita. Uno zk-SNARK può, in teoria, dimostrare che soddisfi questa condizione senza che chi controlla veda la tua data di nascita o la tua età esatta.

C’è però un limite importante. Uno zk-SNARK controlla solo le regole definite nel circuito. Se c’è un errore in quelle regole, una prova può essere tecnicamente valida anche se il sistema permette qualcosa che in realtà non era previsto. La crittografia quindi non può correggere da sola un circuito progettato male.

A cosa servono gli zk-SNARK?

Gli zk-SNARK si usano quando qualcuno vuole dimostrare che un calcolo è stato eseguito correttamente, senza rendere pubblici tutti gli input o i passaggi intermedi. Questo rende la tecnica interessante per la privacy, ma anche per i casi in cui chi verifica la prova non deve rifare tutto il calcolo da zero.

Alcuni usi noti sono:

• pagamenti privati;
• applicazioni in cui gli input o parti del calcolo restano privati;
• prove di identità e credenziali, in cui dimostri una caratteristica senza condividere tutti i dati personali;
• proof-of-reserves, in cui una parte può dimostrare che certe riserve esistono senza rendere pubblici tutti i dati sottostanti;
• validity rollup, che elaborano molte transazioni fuori da Ethereum e poi pubblicano su Ethereum una prova dell’elaborazione corretta.

Aleo, per esempio, usa un modello in cui un programma viene eseguito localmente. Poi viene creata una prova zero-knowledge con cui si può dimostrare che l’esecuzione era corretta. I validator non devono quindi ricevere tutti gli input privati e i passaggi intermedi, ma possono verificare la prova.

La privacy non arriva automaticamente solo perché da qualche parte si usa “ZK”. Quali dati restano privati dipende dal protocollo e da ciò che nel circuito è stato definito come privato o pubblico. Se certi dati della transazione vengono resi pubblici di proposito, uno zk-SNARK non può nasconderli dopo.

Come gli zk-SNARK supportano la privacy?

Gli zk-SNARK supportano la privacy perché ti permettono di dimostrare che una transazione è valida senza rendere pubblici i dettagli sensibili. In un pagamento privato, per esempio, qualcuno può dimostrare di avere fondi validi, di essere autorizzato a spenderli e di non spendere due volte gli stessi soldi. Il mittente, il destinatario e l’importo non devono essere pubblici.

Zcash mostra bene come funziona un design del genere. Lì si usa una note per registrare privatamente una certa quantità di ZEC. Sulla blockchain non compare il contenuto completo di quella note, ma un commitment: una sua registrazione crittografica. Puoi immaginarlo come una busta chiusa e sigillata. Tutti possono vedere che la busta esiste, ma non cosa contiene.

Le informazioni sulla note vengono cifrate per il destinatario. Quando una note viene spesa, sulla blockchain appare una nullifier univoca. Questa nullifier non mostra direttamente quale note è stata spesa, ma i nodi possono controllare se la stessa nullifier è già stata usata prima. Così la rete può prevenire il double spending senza rendere pubblici i dati privati sottostanti.

Quindi, qui privacy non significa che sulla blockchain non resti alcuna traccia. Commitment e nullifier restano visibili. Anche dati come indirizzi IP, tempi, metadati di rete e informazioni che un utente rende pubbliche non vengono nascosti automaticamente da uno zk-SNARK.

Come vengono usati gli zk-SNARK per la scalabilità?

Per la scalabilità, gli zk-SNARK possono essere usati per riassumere una grande quantità di lavoro di calcolo in una sola prova compatta. Lo vedi per esempio nei validity rollup: le transazioni vengono elaborate fuori da Ethereum, raggruppate in batch e poi viene creata una prova che mostra che l’elaborazione è avvenuta correttamente.

L’operatore di un rollup elabora le transazioni e crea una validity proof con cui dimostra che il nuovo stato è stato calcolato secondo le regole del rollup. Un contratto verifier su Ethereum accetta quel nuovo stato solo se la prova è valida. Ethereum quindi non deve rifare tutti i calcoli di ogni singola transazione.

Con la ricorsione questo può essere riassunto ancora di più. In questo caso, una nuova prova può dimostrare che più prove precedenti sono valide. Alla fine, così, molti calcoli o molte prove separate possono essere rappresentati da una sola prova compatta.

Scroll usa prove zk per dimostrare la corretta esecuzione di batch di transazioni, dopo di che la prova può essere verificata su Ethereum.

Mina usa gli zk-SNARK ricorsivi in un altro modo. Invece di dover controllare tutta la storia della blockchain dall’inizio, un partecipante può dimostrare la validità dello stato attuale della blockchain con una prova crittografica compatta.

Verifica veloce non significa che l’intero processo sia economico. Creare una prova può invece richiedere molta potenza di calcolo e memoria. Inoltre, una validity proof non risolve automaticamente altri problemi, come la disponibilità dei dati, la censura da parte di un operatore o i rischi legati ai bridge tra blockchain.

Quali blockchain e criptovalute usano gli zk-SNARK?

Diversi progetti crypto usano gli zk-SNARK, ma spesso per obiettivi diversi. Quindi la tecnica non viene usata solo per le transazioni private.

• Zcash usa gli zk-SNARK per le transazioni shielded. Nel protocollo Orchard viene usato Halo 2 per dimostrare crittograficamente queste transazioni.
• Aleo usa gli zk-SNARK per applicazioni private e programmabili. I programmi possono essere eseguiti localmente, dopo di che i validator controllano la prova di esecuzione corretta senza dover vedere gli input privati o i passaggi intermedi.
• Mina usa zk-SNARK ricorsivi per dimostrare in modo compatto la validità dello stato della blockchain. L’obiettivo principale qui è la verifica compatta e non automaticamente la privacy delle transazioni.
• Scroll usa gli zk-SNARK nel suo zkEVM per dimostrare la corretta elaborazione di batch di transazioni. Queste prove possono poi essere verificate su Ethereum.
• Ethereum supporta la verifica di alcuni zk-SNARK basati su pairing tramite precompile. Così gli smart contract possono controllare le prove zk-SNARK. Ethereum però non usa gli zk-SNARK come meccanismo di consenso generale.

Fai attenzione alla differenza tra uno zk-SNARK e uno zk-STARK. Entrambi sono sistemi di prova crittografici che possono supportare la zero-knowledge, ma tecnicamente funzionano in modo diverso. Gli zk-STARK di solito non richiedono un trusted setup, ma spesso producono prove più grandi degli zk-SNARK. Un ZK-rollup quindi non deve per forza usare uno zk-SNARK.

Cos’è un trusted setup negli zk-SNARK?

Un trusted setup è un processo una tantum in cui, per alcuni zk-SNARK, vengono creati parametri pubblici necessari per generare e verificare le prove. Questi dati vengono spesso chiamati structured reference string (SRS) o common reference string (CRS).

La parte delicata è l’informazione segreta casuale usata durante questo setup. Questa viene chiamata anche toxic waste. Se qualcuno conserva o riesce a ricostruire quell’informazione, in certi sistemi, come Groth16, potrebbe in teoria usarla per creare prove false che vengono comunque accettate come valide.

Per questo i progetti a volte usano una cerimonia di multi-party computation. Più partecipanti aggiungono ciascuno la propria casualità segreta. Finché almeno un partecipante si comporta onestamente e distrugge davvero il proprio contributo segreto, l’intera informazione segreta del setup non può essere ricostruita.

Questo riduce molto il rischio, ma significa comunque che devi fidarti del fatto che almeno un partecipante non sia stato compromesso e abbia davvero eliminato il proprio contributo segreto.

Non tutti gli zk-SNARK hanno bisogno di un trusted setup. Zcash usava per i vecchi circuiti Sprout e Sapling Groth16, che richiedeva un trusted setup. Il successivo protocollo Orchard usa Halo 2 e non ha bisogno di un trusted setup con toxic waste.

Quali sono i vantaggi degli zk-SNARK?

Il grande vantaggio degli zk-SNARK è che privacy e verificabilità possono andare insieme. Puoi dimostrare di rispettare certe regole senza rendere pubblici i dati sensibili dietro quella prova.

I principali vantaggi in sintesi:

• Privacy con controllo: i dati sensibili possono restare nascosti, mentre i nodi possono comunque verificare se una transazione o un calcolo è valido.
• Prove brevi: le prove sono compatte rispetto al calcolo che rappresentano.
• Verifica veloce: un nodo o uno smart contract non deve rifare tutto il calcolo.
• Controllo pubblico: una prova può essere pubblicata e poi verificata in modo indipendente.
• Riassumere molti calcoli: con prove ricorsive, più transazioni, batch o prove precedenti possono essere riassunti in una nuova prova compatta.

Su Ethereum, alcuni zk-SNARK basati su pairing possono anche essere verificati negli smart contract. Così le applicazioni possono, per esempio, far verificare su Ethereum prove di calcoli offchain o controlli orientati alla privacy.

Però è importante ricordare che “breve” ed “efficiente” si riferiscono soprattutto alla dimensione della prova e alla sua verifica. Per il prover, creare una prova del genere può invece richiedere molta potenza di calcolo e memoria.

Quali sono i limiti e i rischi degli zk-SNARK?

Gli zk-SNARK sono potenti, ma non sono la soluzione per ogni problema di privacy o scalabilità. La sicurezza dipende dalla crittografia usata, dal circuito e dal modo in cui il sistema è integrato in una blockchain o in un’applicazione.

Un rischio importante nei sistemi che dipendono da un trusted setup è l’informazione segreta del setup. Se la toxic waste di un setup Groth16, per esempio, finisce nelle mani sbagliate, gli attaccanti potrebbero in teoria creare prove false che vengono comunque accettate come valide. In un sistema di pagamento privato, nel caso peggiore, questo potrebbe portare alla creazione di saldo che secondo le regole normali non avrebbe dovuto esistere.

Inoltre, uno zk-SNARK dimostra solo che le regole del circuito sono state rispettate. Errori nel circuito, nel codice del prover, nel codice del verifier, nei parametri usati o nel collegamento con una blockchain possono quindi avere conseguenze serie. Una prova crittograficamente corretta non aiuta se le regole di base sono state progettate male.

Anche la privacy ha dei limiti. Nelle transazioni shielded di Zcash, per esempio, sulla blockchain restano visibili commitment e nullifier, mentre le informazioni sulle note restano cifrate. Inoltre, dati pubblici, tempi, indirizzi IP e altri metadati di rete possono a volte comunque rivelare informazioni o rendere visibili dei collegamenti.

Con i zk-rollup c’è un altro problema. Una validity proof può dimostrare che un batch è stato elaborato correttamente, ma non impedisce automaticamente a un operatore di ritardare le transazioni o censurare gli utenti. Restano anche i rischi legati ai bridge e alla disponibilità dei dati.

Infine, zero-knowledge non significa automaticamente che un sistema sia resistente ai futuri attacchi quantistici. Dipende dalla costruzione crittografica concreta. Gli zk-SNARK classici basati su pairing usano assunzioni crittografiche diverse rispetto, per esempio, ai sistemi STARK trasparenti.

Conclusione

Gli zk-SNARK rendono possibile dimostrare che una transazione o un calcolo è corretto senza rivelare i dati sensibili dietro di esso. Per questo sono interessanti per i pagamenti privati, le applicazioni orientate alla privacy e la scalabilità tramite validity rollup. Zcash è uno degli esempi più noti di blockchain che usa gli zk-SNARK per rendere possibili le transazioni shielded.

Il punto centrale è abbastanza semplice: una blockchain o un altro verifier non deve vedere tutti i dati sottostanti né rifare l’intero calcolo, purché possa controllare una prova crittografica valida. Quanta privacy e quanta sicurezza ne derivino davvero dipende però dal design del sistema. Alla fine, uno zk-SNARK è affidabile solo quanto il circuito, la crittografia usata e l’integrazione attorno ad esso.