TL;DR

Una prova a conoscenza zero consente a una parte (un verificatore) di determinare la validità di un’affermazione fornita da un’altra parte (il dimostratore) senza alcuna conoscenza del contenuto dell’affermazione. Ad esempio, Binance potrebbe voler dimostrare di aver coperto interamente i fondi dei suoi utenti in riserve senza rivelare tutti i saldi dei singoli utenti.

Una “Proof of Reserves” potrebbe essere costruita con un albero Merkle che protegge dalla falsificazione dei suoi dati interni, in questo caso i saldi netti totali dei clienti, che sono passività dell’exchange nei confronti dei suoi utenti. Questo può quindi essere combinato con zk-SNARK (un protocollo a prova di conoscenza zero) che garantisce che gli utenti possano verificare che il proprio saldo faccia parte del saldo patrimoniale netto totale dell'utente senza conoscere i singoli saldi.

Introduzione

Alla luce degli eventi di mercato, la sicurezza delle criptovalute in custodia è diventata un argomento critico. Gli utenti di blockchain attribuiscono grande importanza alla trasparenza e all'apertura, ma supportano anche la privacy e la riservatezza. Ciò crea un dilemma quando si dimostrano le riserve di fondi detenute dai depositari. Spesso, c'è un compromesso tra trasparenza, fiducia e riservatezza dei dati.

Tuttavia, non deve essere necessariamente così. Combinando protocolli di zero-knowledge proof come zk-SNARK con alberi Merkle, possiamo trovare una soluzione efficace per tutte le parti.

Che cosa si intende per dimostrazione a conoscenza zero?

Una dimostrazione a conoscenza zero consente a una parte (un verificatore) di determinare la validità di un'affermazione fornita da un'altra parte (il dimostratore) senza alcuna conoscenza del contenuto dell'affermazione. Diamo un'occhiata a un semplice esempio.

Hai una cassaforte chiusa a chiave di cui solo tu conosci la soluzione. La cassaforte, per il bene dell'esempio, non può essere forzata, forzata o aperta in nessun altro modo se non conoscendo la combinazione. Questo fatto è anche stabilito, verificato e noto al tuo amico che partecipa all'esperimento.

Dichiari di conoscere la combinazione al tuo amico, ma non vuoi rivelarla o aprire la scatola davanti a lui. In cima alla scatola c'è un buco in cui il tuo amico può infilare un biglietto. Per rendere questa una prova di conoscenza zero, il tuo amico non dovrebbe avere altre informazioni sul processo oltre alla dichiarazione data.

Puoi dimostrare al tuo amico che conosci la combinazione aprendo la scatola, dicendogli cosa c'era scritto sul biglietto e richiudendola. In nessun momento, tuttavia, hai rivelato la combinazione.

Per un esempio più avanzato, consulta il nostro articolo Cos'è la dimostrazione a conoscenza zero e come influisce sulla blockchain?.

Perché utilizziamo la dimostrazione a conoscenza zero?

Le prove a conoscenza zero sono adatte per dimostrare qualcosa senza rivelare informazioni o dettagli sensibili. Questo potrebbe essere il caso se non vuoi consegnare le tue informazioni finanziarie o personali che potrebbero essere utilizzate in modo inappropriato.

In criptovaluta, potresti dimostrare di possedere una chiave privata senza rivelarla o firmare digitalmente qualcosa. Un exchange di criptovaluta potrebbe anche voler dimostrare lo stato delle sue riserve senza rivelare informazioni riservate sui suoi utenti, inclusi i saldi dei loro singoli conti.

Per questi esempi (e molti altri), una dimostrazione a conoscenza zero utilizzerebbe algoritmi che prendono un input di dati e restituiscono "vero" o "falso" come output.

Definizione delle prove a conoscenza zero in termini tecnici

Una dimostrazione a conoscenza zero, in termini tecnici, segue una struttura specifica con determinati criteri. Abbiamo già trattato i ruoli di dimostratore e verificatore, ma ci sono anche tre criteri che una dimostrazione a conoscenza zero dovrebbe coprire:

  1. Completezza. Se l'affermazione è vera, un verificatore sarà convinto dalla prova fornita, senza la necessità di altre informazioni o verifiche.

  2. Solidità. Se l'affermazione è falsa, un verificatore non sarà convinto della verità di un'affermazione dalla prova fornita.

  3. Conoscenza zero. Se l'affermazione è vera, il verificatore non apprende altre informazioni oltre al fatto che l'affermazione è vera.

Cos'è uno zk-SNARK?

Uno zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) è un protocollo di prova che segue i principi di conoscenza zero precedentemente delineati. Con uno zk-SNARK, potresti dimostrare di conoscere il valore hash originale (discusso più avanti) senza rivelare di cosa si tratta. Potresti anche dimostrare la validità di una transazione senza rivelare alcuna informazione sugli importi, i valori o gli indirizzi specifici coinvolti.

Gli zk-SNARK sono comunemente usati e discussi nel mondo della blockchain e delle criptovalute. Ma potresti chiederti perché qualcuno si preoccuperebbe di usare uno zk-SNARK quando potrebbe usare un semplice metodo di coppia di chiavi pubbliche e private per proteggere le informazioni. Tuttavia, non saremmo in grado di implementare la prova matematica per garantire che non siano inclusi saldi negativi e la somma dell'albero di Merkle.

Nel caso delle riserve di uno scambio, vogliamo dimostrare il supporto 1:1 dei saldi dei clienti senza che gli identificatori e i saldi di ogni conto siano resi pubblici. Inoltre, la tecnologia zk-SNARK rende la falsificazione dei dati ancora più improbabile.

Cos'è un albero Merkle?

Presentare i fondi sommati degli account degli utenti di Binance richiede di lavorare con un ampio set di dati. Un modo per presentare questa grande quantità di dati in modo crittografico è usare un albero di Merkle. Una grande quantità di informazioni può essere efficientemente archiviata al suo interno e la sua natura crittografica rende la sua integrità facilmente verificabile.

Funzioni hash

Per codificare in modo succinto un input, un albero di Merkle dipende dall'uso di funzioni hash. In breve, l'hashing è il processo di generazione di un output di dimensione fissa da un input di dimensione variabile. In altre parole, quando un input di qualsiasi lunghezza viene sottoposto a hashing tramite un algoritmo, produrrà un output crittografato di lunghezza fissa.

Finché l'input rimane lo stesso, lo sarà anche l'output. Ciò significa che possiamo prendere enormi quantità di dati transazionali e trasformarli in un output gestibile. L'output sarà radicalmente diverso se qualsiasi informazione viene modificata nell'input.

Ad esempio, potremmo prendere il contenuto di 100 libri e inserirli nella funzione hash SHA-256. Ciò fornirebbe qualcosa di simile a questo come output:

801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea

Se poi modificassimo un singolo carattere dell'input (quei 100 libri), l'hash sarebbe completamente diverso, in questo modo:

abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410

Questa è una proprietà importante delle funzioni hash perché consente una facile verifica dell'accuratezza dei dati. Se qualcuno replica il processo di hashing di quegli stessi 100 libri usando l'algoritmo SHA-256, otterrà esattamente lo stesso hash dell'output. Se l'output è diverso, possiamo affermare con certezza che l'input è stato modificato. Ciò significa che non c'è bisogno di controllare individualmente o manualmente le differenze tra gli input, il che può richiedere molto lavoro.

Alberi di Merkle nel mondo delle criptovalute

Quando si archiviano dati di transazione su una blockchain, ogni nuova transazione viene inviata tramite una funzione hash, che genera valori hash univoci. Immagina di avere otto transazioni (da A a H) che sottoponiamo a hash individualmente per ottenere i loro output hash. Questi sono quelli che chiamiamo nodi foglia di Merkle. Nell'immagine sottostante, puoi vedere il valore hash univoco di ogni lettera: hA per A, hB per B, hC per C, ecc.

Possiamo quindi prendere coppie di output hash, combinarli e ricevere un nuovo output hash. Gli hash di hA e hB hash insieme, ad esempio, ci darebbero un nuovo output hash di hAB noto come ramo di Merkle. Nota che ogni volta che viene generato un nuovo output, questo ha una lunghezza e una dimensione fisse, in base alla funzione hash utilizzata.

Ora, abbiamo i dati di due transazioni (ad esempio, A e B) combinati in un hash (hAB). Nota che se cambiamo qualsiasi informazione da A o B e ripetiamo il processo, il nostro output hash hAB sarebbe completamente diverso.

Il processo continua mentre combiniamo nuove coppie di hash per sottoporli nuovamente a hash (vedi l'immagine qui sotto). Eseguiamo l'hash di hAB con hCD per ottenere un hash univoco hABCD e facciamo lo stesso con hEF e hGH per ottenere hEFGH. Alla fine, riceviamo un singolo hash che rappresenta gli output hash di tutti gli hash delle transazioni precedenti. In altre parole, l'output hash hABCDEFGH rappresenta tutte le informazioni che lo hanno preceduto.

Il grafico visualizzato sopra è chiamato albero di Merkle e l'output hash hABCDEFGH è la radice di Merkle. Utilizziamo le radici di Merkle nelle intestazioni dei blocchi, poiché riassumono crittograficamente tutti i dati delle transazioni in un blocco in modo succinto. Possiamo anche verificare rapidamente se alcuni dati sono stati manomessi o modificati all'interno del blocco.

I limiti degli alberi Merkle

Torniamo al nostro esempio di riserve CEX. Un CEX vuole dimostrare il supporto 1:1 di tutti gli asset dei suoi clienti e costruisce un albero Merkle che esegue l'hashing degli UID dei suoi clienti con le loro partecipazioni nette (compensando asset e passività) a livello di token. Una volta rilasciato (e firmato per dimostrare la proprietà sulla radice Merkle fornita), un singolo utente non avrebbe modo di verificare se l'albero Merkle è valido senza accedere a tutti i suoi input.

Uno scambio potrebbe aver saltato l'inclusione di alcuni input. Potrebbe anche creare conti falsi con saldi negativi per alterare la passività totale. Ad esempio, sebbene le attività dei clienti possano arrivare a un totale di $ 1.000.000, potrebbe essere aggiunto un conto falso con un saldo di -$ 500.000. Ciò creerebbe un obiettivo di riserve di soli $ 500.000.

Il caso della prova di riserve è diverso dalla radice Merkle di un blocco, poiché gli utenti possono vedere tutte le transazioni contenute in un blocco su un blockchain explorer. Un CEX, tuttavia, non vorrà divulgare ogni saldo del conto per motivi di sicurezza e riservatezza dei dati. Anche i clienti non sarebbero contenti che i saldi dei loro conti fossero resi pubblici. In questo caso, il CEX non può dimostrare che i saldi degli utenti sommano il totale corretto senza rendere visibili i saldi degli altri utenti.

Una soluzione che gli exchange potrebbero prendere in considerazione è quella di utilizzare un revisore terzo di fiducia. Il revisore può controllare i singoli conti e riserve prima di attestare definitivamente la validità della radice Merkle fornita. Tuttavia, per gli utenti, questo metodo richiede fiducia nel revisore e nei dati utilizzati per la verifica. Non è necessario affidarsi a una terza parte quando ci si può fidare dei dati.

Combinazione di zk-SNARK con alberi Merkle

Il problema di cui sopra è un caso perfetto per l'utilizzo di zk-SNARK. Vogliamo dimostrare che le riserve coprono completamente le passività degli utenti e non sono falsificate. Tuttavia, per motivi di privacy e sicurezza, non vogliamo mostrare al verificatore la composizione esatta dei saldi e delle riserve degli utenti.

Utilizzando uno zk-SNARK, un exchange di criptovalute può dimostrare che tutti i set di saldo dei nodi foglia dell'albero Merkle (ad esempio, i saldi dei conti utente) contribuiscono al saldo totale delle attività utente dichiarato dall'exchange. Ogni utente può facilmente accedere al proprio nodo foglia come se fosse stato incluso nel processo. Lo zk-SNARK assicura inoltre che qualsiasi albero Merkle generato non contenga utenti con un saldo netto totale delle attività negativo (il che implicherebbe la falsificazione dei dati, poiché tutti i prestiti sono sovra-collateralizzati). Viene anche utilizzato un calcolo dello stato globale di Binance, ovvero un elenco del saldo netto totale di ogni attività detenuta da ogni cliente Binance.

Diamo un'occhiata a come Binance affronta la situazione. Per iniziare, Binance definisce i vincoli del calcolo che desidera dimostrare e li definisce come un circuito programmabile. Di seguito è riportato il set di tre vincoli che Binance utilizza nel suo modello.

Per ogni set di saldo dell'utente (nodo foglia dell'albero di Merkle), il nostro circuito garantisce che:

  1. I saldi patrimoniali di un utente sono inclusi nel calcolo della somma dei saldi netti totali dell'utente con Binance.

  2. Il saldo netto totale dell'utente è maggiore o uguale a zero.

  3. La modifica della radice dell'albero Merkle è valida (ovvero non utilizza informazioni falsificate) dopo aver aggiornato le informazioni di un utente all'hash del nodo foglia.

Binance può quindi generare una prova zk-SNARK per la costruzione dell'albero Merkle in base al circuito. Ciò comporta che l'exchange esegua il pesante calcolo dell'hashing degli ID e dei saldi degli utenti, assicurandosi al contempo che la prova superi i vincoli.

Un verificatore esaminerà la dimostrazione (e il suo codice open source rilasciato pubblicamente) per convincersi che il calcolo sia eseguito con tutti i vincoli soddisfatti. Il calcolo di verifica richiede un tempo estremamente breve rispetto al tempo di dimostrazione.

Ad ogni rilascio della Prova di Riserva, la borsa pubblicherà:

1. La dimostrazione di Merkle per ciascun utente.

2. La prova zk-SNARK e l'input pubblico (un hash dell'elenco del saldo netto totale di ogni asset e della radice di Merkle) del circuito per tutti gli utenti.

Le parti interessate possono verificare la prova di Merkle, assicurandosi che i loro saldi individuali abbiano contribuito alla radice dell'albero di Merkle. Possono anche verificare la prova di zk-SNARK per assicurarsi che la costruzione dell'albero di Merkle soddisfi i vincoli definiti nel circuito. Per una spiegazione più dettagliata della soluzione zk-SNARK e delle sue prestazioni, fare riferimento al nostro blog Come gli zk-SNARK migliorano il sistema di Proof-of-Reserve di Binance.

Considerazioni finali

Gli zk-SNARK forniscono la tecnologia necessaria per garantire sia l'integrità dei dati che la privacy allo stesso tempo. La sua applicazione per dimostrare le riserve e aumentare la trasparenza CEX dovrebbe aiutare a creare fiducia nel settore blockchain. Per molti, uno sviluppo come questo è stato atteso a lungo e arriva in un momento cruciale per i CEX.

Questa è la prima versione del nostro zk-SNARK e non vediamo l'ora di ricevere il feedback della community per poter continuare a migliorare il sistema.

Ulteriori letture

  • (Blog) Come gli zk-SNARK migliorano il sistema Proof-of-Reserve di Binance

  • (Accademia) Prova di riserva (PoR)

  • (Academy) Cos'è la Proof of Reserves e come funziona su Binance

  • (Annuncio)Binance rilascia il sistema Proof of Reserves