Uvod u zk-SNARK-ove

blog 1NewsDevelopersEnterpriseBlockchain ObjašnjeniDogađaji i konferencijePressBilteni

Pretplatite se na naše obavijesti.

Email adresa

Poštujemo vašu privatnost

Razvoj HomeBlogBlockchaina

Uvod u zk-SNARK-ove

Pregled dokaza bez znanja i kako integrirati zk-SNARK-ove u Ethereum. od ConsenSys 27. ožujka 2017. Objavljeno 27. ožujka 2017

domaći junak

U ovom postu želimo dati pregled zk-SNARK-ova s ​​praktičnog gledišta. Tretirat ćemo stvarnu matematiku kao crni okvir i pokušati razviti neke intuicije oko toga kako ih možemo koristiti. Također ćemo dati jednostavnu primjenu nedavnog rada na integriranje zk-SNARK-ova u Ethereum.

Dokazi nultih znanja

Cilj dokaza nultog znanja je da verifikator može samu sebe uvjeriti da dokazivač posjeduje znanje o tajnom parametru, pozvanom svjedoku, zadovoljavajući neku vezu, a da svjedoka ne otkrije vjerovniku ili bilo kome drugom.

To možemo konkretnije zamisliti kao da imamo program, označen sa C, koji uzima dva ulaza: C (x, w). Ulaz x je javni unos, a w unos tajnog svjedoka. Izlaz programa je booleov, tj. Istinit ili netačan. Cilj se tada dobiva određenim javnim unosom x, dokazati da dokazivač zna tajni unos w takav da je C (x, w) == true.

Konkretno ćemo razgovarati o neinteraktivnim dokazima nultog znanja. To znači da je sam dokaz blob podataka koji se može provjeriti bez ikakve interakcije provera.

Primjer programa

Pretpostavimo da Bob dobije hash H neke vrijednosti i želi imati dokaz da Alice zna vrijednost s koja se hashira u H. Obično bi Alice to dokazala davanjem s Bob-u, nakon čega bi Bob izračunao hash i provjerio da jednako je H.

Međutim, pretpostavimo da Alice ne želi otkriti vrijednost s Bobu, već samo želi dokazati da zna vrijednost. Za to može upotrijebiti zk-SNARK.

Alicein scenarij možemo opisati pomoću sljedećeg programa, ovdje napisanog kao Javascript funkcija:


funkcija C (x, w) {return (sha256 (w) == x);} Jezik koda: JavaScript (javascript)

Drugim riječima: program uzima javno hash x i tajnu vrijednost w i vraća true ako je SHA – 256 hash w jednako x.

Prevodeći Alicein problem pomoću funkcije C (x, w), vidimo da Alice treba stvoriti dokaz da posjeduje s takav da je C (H, s) == true, a da ne mora otkriti s. Ovo je opći problem koji zk-SNARKs rješavaju.

Definicija zk-SNARK

Zk-SNARK sastoji se od tri algoritma G, P, V definirana kako slijedi:

Generator ključa G uzima tajni parametar lambda i program C i generira dva javno dostupna ključa, dokazni ključ pk i potvrdni ključ vk. Ti su ključevi javni parametri koje treba generirati samo jednom za zadani program C.

Ispitivač P uzima kao ulaz dokazni ključ pk, javni ulaz x i privatnog svjedoka w. Algoritam generira dokaz prf = P (pk, x, w) da dokazivač poznaje svjedoka w i da svjedok zadovoljava program.

Verifikator V izračunava V (vk, x, prf) koji vraća true ako je dokaz točan, a false u suprotnom. Dakle, ova funkcija vraća true ako proveritelj poznaje svjedoka w koji zadovoljava C (x, w) == true.

Ovdje imajte na umu tajni parametar lambda koji se koristi u generatoru. Ovaj parametar ponekad otežava upotrebu zk-SNARK-ova u stvarnim aplikacijama. Razlog tome je što onaj tko poznaje ovaj parametar može generirati lažne dokaze. Konkretno, s obzirom na bilo koji program C i javni unos x, osoba koja zna lambda može generirati dokaz fake_prf takav da V (vk, x, fake_prf) procijeni na true bez znanja tajne.

Stoga zapravo pokretanje generatora zahtijeva vrlo siguran postupak kako bi se osiguralo da nitko ne sazna i spremi parametar bilo gdje. To je bio razlog za izuzetno razrađena ceremonija tim Zcash-a proveo je kako bi generirao dokazni ključ i verifikacijski ključ, istovremeno osiguravajući da je parametar “otrovni otpad” lambda uništen u procesu.

Zk-SNARK za naš primjer programa

Kako bi Alice i Bob u praksi koristili zk-SNARK kako bi Alice dokazala da zna tajnu vrijednost u gornjem primjeru?

Prije svega, kao što je gore spomenuto, koristit ćemo program definiran sljedećom funkcijom:

funkcija C (x, w) {return (sha256 (w) == x); } Jezik koda: JavaScript (javascript)

Prvi korak je da Bob pokrene generator G kako bi stvorio ključ za provjeru pk i ključ za provjeru vk. Prvo, nasumično generirajte lambdu i koristite je kao ulaz:

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

Pažljivo rukujte parametrom lambda, jer ako Alice nauči vrijednost lambde, moći će stvoriti lažne dokaze. Bob će podijeliti pk i vk s Alice.

Alice će sada igrati ulogu dokazivača. Ona mora dokazati da zna vrijednost s koja se raspršuje prema poznatom hashu H. Ona pokreće algoritam za dokazivanje P koristeći ulaze pk, H i s za generiranje dokaza prf:

prf = P (pk, H, s)

Dalje Alice prezentira dokaz prf Bobu koji pokreće funkciju provjere V (vk, H, prf) koja bi se u ovom slučaju vratila točno, budući da je Alice pravilno znala tajnu s. Bob može biti siguran da je Alice znala tajnu, ali Alice nije trebala otkriti tajnu Bobu.

Ključevi za višekratnu provjeru i provjeru

U našem gornjem primjeru, zk-SNARK se ne može koristiti ako Bob želi dokazati Alice da zna tajnu, jer Alice ne može znati da Bob nije spremio lambda parametar. Bob bi vjerovatno mogao lažirati dokaze.

Ako je program koristan mnogim ljudima (poput primjera Zcash-a), pouzdana neovisna grupa odvojena od Alice i Boba mogla bi pokrenuti generator i stvoriti ključ za provjeru pk i ključ za provjeru vk na takav način da nitko ne uči o lambda.

Svatko tko vjeruje da grupa nije varala, tada može koristiti ove ključeve za buduće interakcije.

zk-SNARK-ovi u Ethereumu

Programeri su već počeli integrirati zk-SNARK-ove u Ethereum. Kako ovo izgleda? Konkretno, Ethereumu možete dodati gradivne blokove algoritma za provjeru u obliku unaprijed sastavljenih ugovora. Evo kako: pokrenite generator izvan lanca da biste proizveli ključ za provjeru i ključ za provjeru. Tada svaki dokazivač može koristiti ključ za dokazivanje za stvaranje dokaza, također izvan lanca. Tada možete pokrenuti opći algoritam provjere unutar pametnog ugovora, koristeći dokaz, ključ za provjeru i javni ulaz kao ulazne parametre. Tada možete koristiti ishod algoritma za provjeru da biste pokrenuli druge aktivnosti na lancu.

Primjer: povjerljive transakcije

Evo jednostavnog primjera kako zk-SNARKs mogu pomoći u privatnosti na Ethereumu. Pretpostavimo da imamo jednostavan ugovor s tokenima. Uobičajeno bi ugovor s tokenom u svojoj osnovi imao mapiranje od adresa do stanja:

mapiranje (adresa => uint256) salda; Jezik koda: JavaScript (javascript)

Zadržat ćemo istu osnovnu jezgru, osim što ćemo vagu zamijeniti hashom vage:

mapiranje (adresa => bytes32) balanceHashes; Jezik koda: JavaScript (javascript)

Nećemo sakriti pošiljatelja ili primatelja transakcija. Ali sakrit ćemo stanja i poslane iznose. Ovo se svojstvo ponekad naziva i povjerljive transakcije.

Upotrijebit ćemo dva zk-SNARK-a za slanje tokena s jednog računa na drugi. Jedan dokaz stvara pošiljatelj, a jedan primatelj.

Uobičajeno u ugovoru s tokenima da bi transakcija vrijednosti veličine bila valjana moramo provjeriti sljedeće:

salda [fromAddress] >= vrijednost

Naši zk-SNARK-ovi moraju dokazati da to vrijedi, kao i da ažurirani hashovi odgovaraju ažuriranim saldima.

Glavna ideja je da će pošiljatelj koristiti svoj početni saldo i vrijednost transakcije kao privatne ulaze. Kao javni ulazi koriste hešove početne bilance, završne ravnoteže i vrijednosti. Slično tome, prijemnik će koristiti početnu ravnotežu i vrijednost kao tajne ulaze. Kao javni ulazi koriste hešove početne bilance, završne ravnoteže i vrijednosti.

Ispod je program koji ćemo koristiti za pošiljatelja zk-SNARK, gdje kao i prije x predstavlja javni unos, a w predstavlja privatni unos.

funkcija senderFunction (x, w) {return (w.senderBalanceBefore > w.vrijednost && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} Jezik koda: JavaScript (javascript)

Program koji koristi prijemnik nalazi se u nastavku:

funkcija receiverFunction (x, w) {return (sha256 (w.value) == x.hashValue && sha256 (w.receiverBalanceBefore) == x.hashReceiverBalanceBefore && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} Jezik koda: JavaScript (javascript)

Programi provjeravaju je li saldo slanja veći od vrijednosti koja se šalje, kao i provjeru podudaranja svih hashova. Skup pouzdanih ljudi generirao bi ključeve za dokazivanje i provjeru za naše zk-SNARK-ove. Nazovimo ih confTxSenderPk, confTxSenderVk, confTxReceiverPk i confTxReceiverVk.

Korištenje zk-SNARK-ova u ugovoru tokena izgledalo bi otprilike ovako:

prijenos funkcije (adresa _to, bytes32 hashValue, bytes32 hashSenderBalanceAfter, bytes32 hashReceiverBalanceAfter, bajtovi zkProofSender, bajtovi 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; }} Jezik koda: JavaScript (javascript)

Stoga su jedina ažuriranja na blockchainu hešovi stanja, a ne sami saldi. Međutim, možemo znati da su sve bilance ispravno ažurirane, jer se možemo provjeriti je li dokaz provjeren.

Pojedinosti

Gornja shema povjerljivih transakcija uglavnom daje praktični primjer kako se mogu koristiti zk-SNARKs na Ethereumu. Da bismo stvorili robusnu shemu povjerljivih transakcija, trebali bismo riješiti niz problema:

  • Korisnici bi trebali pratiti svoja stanja na strani klijenta, a ako izgubite stanje, ti se tokeni ne mogu obnoviti. Vage bi se možda mogle pohraniti šifrirano na lancu s ključem izvedenim iz ključa za potpisivanje.
  • Vage trebaju koristiti 32 bajta podataka i kodirati entropiju kako bi se spriječila mogućnost obrnutog raspršivanja za utvrđivanje stanja.
  • Trebate riješiti rubni slučaj slanja na neiskorištenu adresu.
  • Pošiljatelj mora komunicirati s primateljem da bi mogao poslati. Potencijalno se može imati sustav u kojem pošiljatelj koristi njihov dokaz za pokretanje transakcije. Primatelj tada na blockchainu može vidjeti da ima “dolaznu transakciju na čekanju” i može je finalizirati.

Newsletter Pretplatite se na naš bilten za najnovije vijesti o Ethereumu, rješenja za poduzeća, resurse za programere i još mnogo toga. Adresa e-pošte Ekskluzivni sadržajKako izraditi uspješan blockchain proizvodWebinar

Kako izraditi uspješan blockchain proizvod

Kako postaviti i pokrenuti Ethereum čvorWebinar

Kako postaviti i pokrenuti Ethereum čvor

Kako izraditi vlastiti Ethereum APIWebinar

Kako izraditi vlastiti Ethereum API

Kako stvoriti društveni žetonWebinar

Kako stvoriti društveni žeton

Korištenje sigurnosnih alata u razvoju pametnih ugovoraWebinar

Korištenje sigurnosnih alata u razvoju pametnih ugovora

Budućnost financija Digitalna imovina i DeFiWebinar

Budućnost financija: digitalna imovina i DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map