blogul 1NewsDevelopersEnterpriseBlockchain Explained Evenimente și conferințe ApăsațiBuletine informative

Aboneaza-te la newsletter-ul nostru.

Adresa de email

Vă respectăm confidențialitatea

AcasăBlogDezvoltare blockchain

Introducere în zk-SNARKs

O prezentare generală a dovezilor de cunoaștere zero și a modului de integrare a zk-SNARK în Ethereum. de ConsenSys 27 martie 2017 Postat pe 27 martie 2017

erou de acasă

În această postare ne propunem să oferim o imagine de ansamblu asupra zk-SNARK-urilor dintr-un punct de vedere practic. Vom trata matematica reală ca pe o cutie neagră și vom încerca să dezvoltăm câteva intuiții în legătură cu modul în care le putem folosi. De asemenea, vă vom oferi o simplă aplicație a lucrărilor recente despre integrarea zk-SNARK-urilor în Ethereum.

Dovezi fără cunoștințe

Scopul probelor de cunoaștere zero este ca un verificator să se poată convinge că un proverd posedă cunoașterea unui parametru secret, numit martor, satisfăcând o anumită relație, fără a dezvălui martorul verificatorului sau altcuiva..

Ne putem gândi mai concret la acest lucru ca având un program, notat C, luând două intrări: C (x, w). Intrarea x este intrarea publică și w este intrarea secretă a martorului. Rezultatul programului este boolean, adică fie adevărat, fie fals. Scopul este apoi dat cu o intrare publică specifică x, demonstrează că proverul cunoaște o intrare secretă w astfel încât C (x, w) == adevărat.

Vom discuta în mod specific dovezi non-interactive de cunoaștere zero. Aceasta înseamnă că dovada în sine este o pâlcâie de date care poate fi verificată fără nicio interacțiune de la prover.

Program de exemplu

Să presupunem că lui Bob i se dă un hash H de o anumită valoare și dorește să aibă o dovadă că Alice știe valoarea s care hash la H. În mod normal, Alice ar demonstra acest lucru dându-i lui Bob, după care Bob ar calcula hash-ul și va verifica dacă este egal cu H.

Cu toate acestea, să presupunem că Alice nu vrea să-i dezvăluie valoarea lui Bob, ci în schimb vrea doar să demonstreze că știe valoarea. Pentru aceasta poate folosi un zk-SNARK.

Putem descrie scenariul lui Alice folosind următorul program, scris aici ca o funcție Javascript:

funcția C (x, w) {return (sha256 (w) == x);} Limbajul codului: JavaScript (javascript)

Cu alte cuvinte: programul include un hash public x și o valoare secretă w și returnează adevărat dacă SHA-256 hash de w este egal cu x.

Traducând problema lui Alice folosind funcția C (x, w), vedem că Alice trebuie să creeze o dovadă că posedă s astfel încât C (H, s) == adevărat, fără a fi nevoie să dezvăluie s. Aceasta este problema generală pe care zk-SNARK o rezolvă.

Definiția a zk-SNARK

Un zk-SNARK constă din trei algoritmi G, P, V definiți după cum urmează:

Generatorul de chei G ia un parametru secret lambda și un program C și generează două chei disponibile public, o cheie de verificare pk și o cheie de verificare vk. Aceste chei sunt parametri publici care trebuie generați o singură dată pentru un anumit program C.

Proverul P ia ca intrare cheia de probă pk, o intrare publică x și un martor privat w. Algoritmul generează o dovadă prf = P (pk, x, w) că proverul cunoaște un martor w și că martorul îndeplinește programul.

Verificatorul V calculează V (vk, x, prf) care returnează adevărat dacă dovada este corectă și fals în caz contrar. Astfel, această funcție returnează adevărat dacă proverul cunoaște un martor care satisface C (x, w) == adevărat.

Rețineți aici parametrul secret lambda utilizat în generator. Acest parametru uneori face dificilă utilizarea zk-SNARK-urilor în aplicații din lumea reală. Motivul este că oricine cunoaște acest parametru poate genera dovezi false. Mai exact, având în vedere orice program C și contribuție publică x, o persoană care știe lambda poate genera o dovadă fake_prf astfel încât V (vk, x, fake_prf) să evalueze la adevărat fără știința secretului w.

Astfel, de fapt, rularea generatorului necesită un proces foarte sigur pentru a vă asigura că nimeni nu învață și salvează parametrul oriunde. Acesta a fost motivul pentru ceremonie extrem de elaborată echipa Zcash a efectuat pentru a genera cheia de verificare și cheia de verificare, asigurându-se totodată că parametrul lambda „deșeuri toxice” a fost distrus în proces.

Un zk-SNARK pentru programul nostru de exemplu

Cum ar folosi Alice și Bob un zk-SNARK în practică pentru ca Alice să demonstreze că știe valoarea secretă din exemplul de mai sus??

În primul rând, așa cum am discutat mai sus, vom folosi un program definit de următoarea funcție:

funcția C (x, w) {return (sha256 (w) == x); } Limba codului: JavaScript (javascript)

Primul pas este ca Bob să ruleze generatorul G pentru a crea cheia de verificare pk și cheia de verificare vk. În primul rând, generați în mod aleatoriu lambda și folosiți-o ca intrare:

(pk, vk) = G (C, lambda)

Manipulați parametrul lambda cu grijă, deoarece dacă Alice află valoarea lambda, va putea crea dovezi false. Bob va împărți pk și vk cu Alice.

Alice va juca acum rolul proverbului. Trebuie să demonstreze că cunoaște valoarea s care se hashează la hash-ul cunoscut H. Ea rulează algoritmul de probă P folosind intrările pk, H și s pentru a genera dovada prf:

prf = P (pk, H, s)

Apoi, Alice îi prezintă dovada prf lui Bob, care rulează funcția de verificare V (vk, H, prf), care ar reveni adevărat în acest caz, deoarece Alice știa corect secretele. Bob poate avea încredere că Alice știa secretul, dar Alice nu avea nevoie să-i dezvăluie secretul lui Bob.

Chei de verificare și verificare reutilizabile

În exemplul nostru de mai sus, zk-SNARK nu poate fi utilizat dacă Bob vrea să-i demonstreze lui Alice că știe un secret, deoarece Alice nu poate ști că Bob nu a salvat parametrul lambda. În mod plauzibil, Bob ar putea să facă dovezi false.

Dacă un program este util pentru mulți oameni (cum ar fi exemplul lui Zcash), un grup independent de încredere separat de Alice și Bob ar putea rula generatorul și ar putea crea cheia de verificare pk și cheia de verificare vk în așa fel încât nimeni să nu învețe despre lambda.

Oricine are încredere că grupul nu a înșelat poate folosi aceste chei pentru interacțiuni viitoare.

zk-SNARKs în Ethereum

Dezvoltatorii au început deja să integreze zk-SNARK în Ethereum. Cum arată asta? Concret, puteți adăuga elementele de bază ale algoritmului de verificare la Ethereum sub formă de contracte precompilate. Iată cum: rulați generatorul în afara lanțului pentru a produce cheia de verificare și cheia de verificare. Orice prover poate utiliza apoi cheia de probă pentru a crea o dovadă, de asemenea, în afara lanțului. Puteți rula apoi algoritmul general de verificare în cadrul unui contract inteligent, utilizând dovada, cheia de verificare și intrarea publică ca parametri de intrare. Puteți utiliza apoi rezultatul algoritmului de verificare pentru a declanșa alte activități în lanț.

Exemplu: Tranzacții confidențiale

Iată un exemplu simplu despre cum zk-SNARK-urile pot ajuta cu confidențialitatea pe Ethereum. Să presupunem că avem un contract token simplu. În mod normal, un contract simbolic ar avea ca bază o cartografiere de la adrese la solduri:

mapare (adresa => uint256) solduri; limbajul codului: JavaScript (javascript)

Vom păstra același nucleu de bază, cu excepția înlocuirii unui sold cu hash-ul unui sold:

mapare (adresa => bytes32) balanceHashes; Limbajul codului: JavaScript (javascript)

Nu vom ascunde expeditorul sau destinatarul tranzacțiilor. Dar vom ascunde soldurile și sumele trimise. Această proprietate este uneori denumită tranzacții confidențiale.

Vom folosi două zk-SNARK pentru a trimite jetoane dintr-un cont în altul. O dovadă este creată de către expeditor și una de către receptor.

În mod normal, într-un contract simbolic pentru o tranzacție cu valoare de mărime valabilă, trebuie să verificăm următoarele:

solduri [de laAdresa] >= valoare

Zk-SNARK-urile noastre trebuie să demonstreze că acest lucru este valabil, precum și că hash-urile actualizate corespund soldurilor actualizate.

Ideea principală este că expeditorul își va folosi soldul inițial și valoarea tranzacției ca intrări private. Ca intrări publice, ei folosesc hash-uri de echilibru inițial, echilibru final și valoare. În mod similar, receptorul va utiliza echilibrul și valoarea de pornire ca intrări secrete. Ca intrări publice, ei folosesc hash-uri de echilibru inițial, echilibru final și valoare.

Mai jos este programul pe care îl vom folosi pentru expeditorul zk-SNARK, unde la fel ca înainte x reprezintă intrarea publică, iar w reprezintă intrarea privată.

function senderFunction (x, w) {return (w.senderBalanceBefore > w. valoare && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} Limbajul codului: JavaScript (javascript)

Programul folosit de receptor este mai jos:

funcție receptor Funcție (x, w) {return (sha256 (w.value) == x.hashValue && sha256 (w.receiverBalanceBefore) == x.hashReceiverBalanceBefore && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} Limbajul codului: JavaScript (javascript)

Programele verifică dacă soldul de trimitere este mai mare decât valoarea trimisă, precum și verifică dacă toate hashurile se potrivesc. Un set de persoane de încredere ar genera cheile de verificare și verificare pentru zk-SNARK-urile noastre. Să le numim confTxSenderPk, confTxSenderVk, confTxReceiverPk și confTxReceiverVk.

Utilizarea zk-SNARK-urilor într-un contract simbolic ar arăta cam așa:

transfer funcție (adresa _to, bytes32 hashValue, bytes32 hashSenderBalanceAfter, bytes32 hashReceiverBalanceAfter, bytes zkProofSender, bytes zkProofReceiver) {bytes32 hashSenderBalanceBefore = balanceHashes [msg.sender]; bytes32 hashReceiverBalanceBefore = balanceHashes [_to]; bool senderProofIsCorrect = zksnarkverify (confTxSenderVk, [hashSenderBalanceBefore, hashSenderBalanceAfter, hashValue], zkProofSender); bool receiverProofIsCorrect = zksnarkverify (confTxReceiverVk, [hashReceiverBalanceBefore, hashReceiverBalanceAfter, hashValue], zkProofReceiver); if (senderProofIsCorrect && receiverProofIsCorrect) {balanceHashes [msg.sender] = hashSenderBalanceAfter; balanceHashes [_to] = hashReceiverBalanceAfter; }} Limba codului: JavaScript (javascript)

Astfel, singurele actualizări ale blockchain-ului sunt hashurile soldurilor și nu soldurile în sine. Cu toate acestea, putem ști că toate soldurile sunt actualizate corect, deoarece putem verifica noi înșine că dovada a fost verificată.

Detalii

Schema de tranzacții confidențiale de mai sus este în principal pentru a oferi un exemplu practic al modului în care se pot utiliza zk-SNARKs pe Ethereum. Pentru a crea un sistem robust de tranzacții confidențiale, ar trebui să abordăm o serie de probleme:

  • Utilizatorii ar trebui să țină evidența soldurilor lor din partea clientului, iar dacă pierdeți soldul, aceste jetoane nu pot fi recuperate. Soldurile ar putea fi stocate criptate în lanț cu o cheie derivată din cheia de semnare.
  • Soldurile trebuie să utilizeze 32 de octeți de date și să codifice entropia pentru a preveni capacitatea de a inversa hashurile pentru a afla soldurile.
  • Trebuie să rezolvați situația de la marginea trimiterii la o adresă neutilizată.
  • Expeditorul trebuie să interacționeze cu receptorul pentru a trimite. S-ar putea să existe un sistem în care expeditorul să-și folosească dovada pentru a iniția tranzacția. Receptorul poate vedea apoi pe blockchain că are o „tranzacție primită în așteptare” și o poate finaliza.

Newsletter Abonați-vă la newsletter-ul nostru pentru cele mai recente știri Ethereum, soluții pentru întreprinderi, resurse pentru dezvoltatori și multe altele. Adresa de e-mail Conținut exclusivCum să construiți un produs Blockchain de succesWebinar

Cum să construiți un produs Blockchain de succes

Cum se configurează și se execută un nod EthereumWebinar

Cum se configurează și se execută un nod Ethereum

Cum să vă construiți propriul API EthereumWebinar

Cum să vă construiți propriul API Ethereum

Cum să creați un simbol socialWebinar

Cum să creați un simbol social

Utilizarea instrumentelor de securitate în dezvoltarea contractelor inteligenteWebinar

Utilizarea instrumentelor de securitate în dezvoltarea contractelor inteligente

Viitorul activelor digitale și al DeFi-ului financiarWebinar

Viitorul finanțelor: active digitale și DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me