TL;DR

O dovadă de zero cunoștințe permite unei părți (un verificator) să determine validitatea unei declarații date de o altă parte (dovatorul) fără nicio cunoaștere a conținutului declarației. De exemplu, Binance poate dori să demonstreze că a susținut în totalitate fondurile utilizatorilor săi în rezerve fără a dezvălui toate soldurile individuale ale utilizatorilor.

O „Dovadă a rezervelor” ar putea fi construită cu un arbore Merkle care protejează împotriva falsificării datelor sale interne, în acest caz, soldurile sale totale nete ale clienților, fiind pasive ale schimbului față de utilizatorii săi. Acest lucru poate fi apoi combinat cu un zk-SNARK (un protocol de dovadă a cunoștințelor zero) care asigură utilizatorilor să își verifice soldul ca parte a soldului total al activelor nete ale utilizatorilor fără a cunoaște soldurile individuale.

Introducere

În lumina evenimentelor de pe piață, securitatea activelor cripto în custodie a devenit un subiect critic. Utilizatorii blockchain apreciază foarte mult transparența și deschiderea, dar susțin și confidențialitatea și confidențialitatea. Acest lucru creează o dilemă atunci când se dovedește rezervele de fonduri deținute de custozi. Adesea, există un compromis între transparență, încredere și confidențialitatea datelor.

Cu toate acestea, acest lucru nu trebuie să fie cazul. Prin combinarea protocoalelor fără cunoștințe precum zk-SNARK-uri cu arbori Merkle, putem găsi o soluție eficientă pentru toate părțile.

Ce este dovada zero-cunoștințe?

O dovadă de zero cunoștințe permite unei părți (un verificator) să determine validitatea unei declarații date de o altă parte (dovatorul) fără nicio cunoaștere a conținutului declarației. Să ne uităm la un exemplu simplu.

Ai un seif încuiat la care numai tu știi soluția. Seiful, de dragul exemplului, nu poate fi ales, forțat sau deschis în alt mod decât prin cunoașterea combinației. Acest fapt este stabilit, verificat și cunoscut și de prietenul tău care participă la experiment.

Declari că cunoști combinația prietenului tău, dar nu vrei să o dai sau să deschizi cutia din fața lui. În partea de sus a cutiei este o gaură prin care prietenul tău poate pune un bilet. Pentru a face din aceasta o dovadă de zero cunoștințe, prietenul tău nu ar trebui să aibă informații suplimentare despre proces, în afară de declarația dată.

Îi poți dovedi prietenului tău că știi combinația deschizând cutia, spunându-i ce a fost scris pe bilet și închizând-o din nou. În niciun moment nu ai dezvăluit însă combinația.

Pentru un exemplu mai avansat, consultați Ce este dovada cunoștințelor zero și cum afectează Blockchain-ul? articol.

De ce folosim Zero Knowledge Proof?

Dovezile cu cunoștințe zero sunt potrivite pentru a dovedi ceva fără a dezvălui informații sau detalii sensibile. Acesta ar putea fi cazul dacă nu doriți să predați informațiile dvs. financiare sau personale care ar putea fi utilizate în mod necorespunzător.

În cripto, puteți dovedi că dețineți o cheie privată fără a o dezvălui sau a semna digital ceva. Un schimb de criptomonede poate dori, de asemenea, să dovedească starea rezervelor sale fără a dezvălui informații confidențiale despre utilizatorii săi, inclusiv soldurile contului lor individual. 

Pentru aceste exemple (și multe altele), o dovadă cu cunoștințe zero ar folosi algoritmi care preiau o intrare de date și returnează „adevărat” sau „fals” ca rezultat. 

Definirea dovezilor cu cunoștințe zero în termeni tehnici

O dovadă de zero cunoștințe, în termeni tehnici, urmează o structură specifică cu anumite criterii. Am acoperit deja rolurile de demonstrat și de verificator, dar există și trei criterii pe care ar trebui să le acopere o dovadă fără cunoștințe:

  1. Completitudine. Dacă afirmația este adevărată, un verificator va fi convins de dovada furnizată, fără a fi nevoie de alte informații sau verificări.

  2. Soliditatea. Dacă afirmația este falsă, un verificator nu va fi convins de adevărul unei afirmații prin dovada furnizată.

  3. Zero-cunoaștere. Dacă afirmația este adevărată, verificatorul nu învață nicio altă informație decât afirmația fiind adevărată.

Ce este un zk-SNARK?

Un zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) este un protocol de demonstrare care urmează principiile zero-cunoștințe prezentate anterior. Cu un zk-SNARK, puteți dovedi că cunoașteți valoarea hashed inițială (discută mai jos) fără a dezvălui care este aceasta. De asemenea, puteți dovedi validitatea unei tranzacții fără a dezvălui informații despre sumele, valorile sau adresele specifice implicate.

zk-SNARK-urile sunt utilizate și discutate în mod obișnuit în lumea blockchain-ului și a criptomonedei. Dar s-ar putea să vă întrebați de ce cineva s-ar deranja să folosească un zk-SNARK când ar putea folosi o metodă simplă de pereche de chei publice și private pentru a securiza informațiile. Cu toate acestea, nu am putea implementa demonstrația matematică pentru a ne asigura că nu sunt incluse solduri negative și suma arborelui Merkle. 

În cazul rezervelor unei burse, dorim să dovedim suportul 1:1 a soldurilor clienților fără ca identificatorii și soldurile fiecărui cont să fie făcute publice. În plus, tehnologia zk-SNARK face falsificarea datelor și mai puțin probabilă.

Ce este un arbore Merkle?

Prezentarea fondurilor însumate ale conturilor utilizatorilor Binance necesită lucrul cu un set mare de date. O modalitate de a prezenta această cantitate mare de date criptografic este utilizarea unui arbore Merkle. O cantitate mare de informații poate fi stocată eficient în ea, iar natura sa criptografică face ca integritatea acesteia să fie ușor de verificat.

Funcții hash

Pentru a codifica succint o intrare, un arbore Merkle depinde de utilizarea funcțiilor hash. Pe scurt, hashing este procesul de generare a unei ieșiri de dimensiune fixă ​​dintr-o intrare de dimensiune variabilă. Cu alte cuvinte, atunci când o intrare de orice lungime este hashing printr-un algoritm, va produce o ieșire criptată cu lungime fixă.

Atâta timp cât intrarea rămâne aceeași, și ieșirea va rămâne. Aceasta înseamnă că putem prelua cantități uriașe de date tranzacționale și le putem transforma într-o ieșire gestionabilă. Ieșirea va fi radical diferită dacă orice informație este modificată în intrare.

De exemplu, am putea lua conținutul a 100 de cărți și le-am introduce în funcția hash SHA-256. Ar oferi apoi ceva de genul acesta ca rezultat:

801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea

Dacă am schimbat apoi un singur caracter al intrării (cele 100 de cărți), hash-ul ar fi complet diferit, așa:

abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410

Aceasta este o proprietate importantă a funcțiilor hash, deoarece permite verificarea ușoară a acurateței datelor. Dacă cineva repetă procesul de hashing a acelorași 100 de cărți folosind algoritmul SHA-256, va obține exact același hash ca rezultatul. Dacă rezultatul este diferit, putem afirma cu certitudine că intrarea a fost modificată. Acest lucru înseamnă că nu este nevoie să verificați individual sau manual diferențele dintre intrări, care pot necesita forță de muncă.

Arborii Merkle în lumea criptomonedei

La stocarea datelor de tranzacție pe un blockchain, fiecare nouă tranzacție este transmisă printr-o funcție hash, care generează valori hash unice. Imaginați-vă că avem opt tranzacții (de la A la H) pe care le hașăm individual pentru a obține rezultatele lor. Acestea sunt ceea ce numim nodurile frunzelor Merkle. În imaginea de mai jos, puteți vedea valoarea hash unică a fiecărei litere: hA pentru A, hB pentru B, hC pentru C etc.

Apoi putem lua perechi de ieșiri hashed, le putem combina și primi o nouă ieșire hashed. Hashurile hA și hB împărțite împreună, de exemplu, ne-ar oferi o nouă ieșire hashing a hAB cunoscută sub numele de ramură Merkle. Rețineți că de fiecare dată când este generată o nouă ieșire, aceasta vine cu o lungime și o dimensiune fixă, în funcție de funcția hash utilizată.

Acum, avem datele a două tranzacții (de exemplu, A și B) combinate într-un singur hash (hAB). Rețineți că dacă schimbăm orice informație din A sau B și repetăm ​​procesul, rezultatul nostru hashed hAB ar fi complet diferit.

Procesul continuă pe măsură ce combinăm noi perechi de hashuri pentru a le hash din nou (vezi imaginea de mai jos). Hash hAB cu hCD pentru a obține un hash hABCD unic și facem același lucru cu hEF și hGH pentru a obține hEFGH. În cele din urmă, primim un singur hash reprezentând ieșirile hash ale tuturor hash-urilor tranzacțiilor anterioare. Cu alte cuvinte, ieșirea hashed hABCDEFGH reprezintă toate informațiile care au venit înainte.

Graficul afișat mai sus se numește arbore Merkle, iar rezultatul hashed hABCDEFGH este rădăcina Merkle. Folosim rădăcinile Merkle în anteturile blocurilor, deoarece acestea rezumă criptografic toate datele tranzacției într-un bloc într-un mod succint. De asemenea, putem verifica rapid dacă date au fost modificate sau modificate în cadrul blocului.

Limitările arborilor Merkle

Să revenim la exemplul nostru de rezerve CEX. Un CEX dorește să demonstreze sprijinul 1:1 al tuturor activelor clienților săi și construiește un arbore Merkle care unește UID-urile clienților săi cu deținerile lor nete de active (compensarea activelor și pasivelor) la nivel de simbol. Odată eliberat (și semnat pentru a dovedi proprietatea asupra rădăcinii Merkle furnizate), un utilizator individual nu ar avea cum să verifice dacă arborele Merkle este valid fără a accesa toate intrările sale.

Este posibil să fi ratat un schimb, inclusiv unele intrări. De asemenea, ar putea crea conturi false cu solduri negative pentru a modifica pasivul total. De exemplu, deși activele clienților pot totaliza 1.000.000 USD, ar putea fi adăugat un cont fals cu un sold de -500.000 USD. Acest lucru ar crea o țintă de rezerve de doar 500.000 USD.

Cazul pentru dovada rezervelor este diferit de rădăcina Merkle a unui bloc, deoarece utilizatorii pot vedea toate tranzacțiile pe care le conține un bloc într-un explorator blockchain. Cu toate acestea, un CEX nu va dori să dezvăluie soldul fiecărui cont din motive de securitate și confidențialitate a datelor. Nici clienții nu ar fi mulțumiți de faptul că soldurile contului lor sunt făcute publice. În acest caz, CEX nu poate dovedi că soldurile utilizatorilor se adună la totalul corect fără a face vizibile soldurile altor utilizatori.

O soluție pe care bursele o pot lua în considerare este utilizarea unui auditor terț de încredere. Auditorul poate verifica conturile individuale și rezervele înainte de a atesta în final valabilitatea rădăcinii Merkle furnizate. Cu toate acestea, pentru utilizatori, această metodă necesită încredere în auditor și în datele utilizate pentru audit. Nu trebuie să vă bazați pe o terță parte atunci când puteți avea încredere în date.

Combinând zk-SNARK-uri cu Merkle Trees

Problema de mai sus este un caz perfect pentru utilizarea zk-SNARK-urilor. Dorim să demonstrăm că rezervele acoperă în totalitate obligațiile utilizatorilor și nu sunt falsificate. Cu toate acestea, din motive de confidențialitate și securitate, nu dorim să arătăm verificatorului componența exactă a soldurilor și rezervelor utilizatorilor. 

Folosind un zk-SNARK, un schimb cripto poate dovedi că toate seturile de solduri ale nodurilor arborelui Merkle (adică soldurile conturilor de utilizator) contribuie la soldul total revendicat al activelor utilizatorului. Fiecare utilizator își poate accesa cu ușurință nodul frunză ca fiind inclus în proces. zk-SNARK asigură, de asemenea, că orice arbore Merkle generat nu conține utilizatori cu un sold negativ total al activelor nete (ceea ce ar implica falsificarea datelor, deoarece toate împrumuturile sunt supracolateralizate). De asemenea, este folosit un calcul al stării globale a Binance, adică o listă a soldului net total al fiecărui activ pe care fiecare client Binance îl deține.

Să aruncăm o privire la modul în care Binance abordează situația. Pentru început, Binance definește constrângerile calculului pe care dorește să-l demonstreze și le definește ca un circuit programabil. Mai jos este setul de trei constrângeri pe care Binance le folosește în modelul său. 

Pentru setul de sold al fiecărui utilizator (nodul frunzelor arborelui Merkle), circuitul nostru asigură că:

  1. Soldurile activelor unui utilizator sunt incluse în calculul sumei soldurilor totale nete ale utilizatorilor cu Binance.

  2. Soldul net total al utilizatorului este mai mare sau egal cu zero.

  3. Modificarea rădăcinii arborelui Merkle este validă (adică, nu se utilizează informații falsificate) după actualizarea informațiilor unui utilizator la hash-ul nodului frunză.

Binance poate genera apoi o dovadă zk-SNARK pentru construcția arborelui Merkle conform circuitului. Acest lucru presupune ca schimbul să execute calculul greu de hashing ID-urile și soldurile utilizatorilor, asigurându-se în același timp că dovada trece de constrângeri.

Un verificator va examina dovada (și codul său open source lansat public) pentru a se convinge că calculul este executat cu toate constrângerile îndeplinite. Calculul de verificare durează un timp extrem de scurt în comparație cu timpul de probă.

La fiecare lansare Proof of Reserves, schimbul va publica:

1. Dovada Merkle pentru fiecare utilizator.

2. Dovada zk-SNARK și intrarea publică (un hash al listei soldului net total al fiecărui activ și rădăcină Merkle) a circuitului pentru toți utilizatorii.

Părțile interesate pot verifica dovada Merkle, asigurându-se că soldurile lor individuale au contribuit la rădăcina arborelui Merkle. Ei pot verifica, de asemenea, dovada zk-SNARK pentru a se asigura că construcția arborelui Merkle îndeplinește constrângerile definite în circuit. Pentru o explicație mai detaliată a soluției zk-SNARK și a performanței acesteia, consultați blogul nostru Cum zk-SNARK-urile îmbunătățesc sistemul Binance Proof-of-Reserves.

Gânduri de închidere

Zk-SNARK oferă tehnologia necesară pentru a asigura atât integritatea datelor, cât și confidențialitatea în același timp. Aplicația sa pentru dovedirea rezervelor și creșterea transparenței CEX ar trebui să contribuie la construirea încrederii în industria blockchain. Pentru mulți, o astfel de dezvoltare a fost mult așteptată și vine într-un moment esențial pentru CEX.

Aceasta este prima versiune a zk-SNARK-ului nostru și așteptăm cu nerăbdare să primim feedbackul comunității, astfel încât să putem continua să îmbunătățim sistemul.

Lectură suplimentară

  • (Blog) Cum zk-SNARK-urile îmbunătățesc sistemul de dovezi a rezervelor Binance

  • (Academie) Dovada rezervelor (PoR)

  • (Academie) Ce este dovada rezervelor și cum funcționează pe Binance

  • (Anunţ) Binance lansează sistemul de dovadă a rezervelor