Ievads zk-SNARKs

emuārs 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressBiļeteni

Abonējiet mūsu biļetenu.

Epasta adrese

Mēs cienām jūsu privātumu

HomeBlogBlockchain izstrāde

Ievads zk-SNARKs

Pārskats par nulles zināšanu pierādījumiem un to, kā zk-SNARK integrēt Ethereum. Iesniedzis ConsenSys 2017. gada 27. martā Ievietots 2017. gada 27. martā

mājas varonis

Šajā amatā mūsu mērķis ir sniegt pārskatu par zk-SNARK no praktiskā viedokļa. Mēs uzskatīsim faktisko matemātiku par melnu lodziņu un mēģināsim izstrādāt dažas intuīcijas par to, kā mēs tās varam izmantot. Mēs arī sniegsim vienkāršu nesen veiktā darba lietojumu zk-SNARK integrēšana Ethereum.

Nulles zināšanu pierādījumi

Nulles zināšanu pierādījumu mērķis ir, lai verificētāja spētu pārliecināt sevi, ka sakāmvārdam ir zināšanas par slepenu parametru, ko sauc par liecinieku, apmierinot kādas saistības, neatklājot liecinieku verificētājam vai kādam citam.

Mēs varam konkrētāk domāt par to, ka mums ir programma, kas apzīmēta ar C, ņemot divas ieejas: C (x, w). Ieeja x ir publiskā ievade, un w ir slepenā liecinieka ievade. Programmas rezultāts ir būla, t.i., vai nu patiess, vai nepatiess. Pēc tam mērķim tiek dota konkrēta publiska ievade x, pierādiet, ka sakāmvārds zina slepenu ievadi w tā, ka C (x, w) == true.

Mēs īpaši apspriedīsim neinteraktīvus nulles zināšanu pierādījumus. Tas nozīmē, ka pats pierādījums ir datu lāse, kurus var pārbaudīt bez sakāmvārda mijiedarbības.

Programmas piemērs

Pieņemsim, ka Bobam tiek piešķirts hash H ar kādu vērtību, un viņš vēlas iegūt pierādījumu, ka Alise zina vērtību s, kas hash pret H. Parasti Alise to pierādītu, dodot s Bobam, pēc kura Bobs aprēķinātu hash un pārbaudītu, vai tas ir vienāds ar H.

Tomēr pieņemsim, ka Alise nevēlas atklāt vērtību Bob, bet tā vietā vēlas tikai pierādīt, ka zina vērtību. Šim nolūkam viņa var izmantot zk-SNARK.

Mēs varam aprakstīt Alises scenāriju, izmantojot šādu programmu, kas šeit uzrakstīta kā Javascript funkcija:


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

Citiem vārdiem sakot: programma uzņem publisko jaukumu x un slepeno vērtību w un atgriež vērtību true, ja SH SH-256 jaukums w ir vienāds ar x.

Tulkojot Alises problēmu, izmantojot funkciju C (x, w), mēs redzam, ka Alisei ir jāizveido pierādījums, ka viņai piemīt s, ka C (H, s) == taisnība, neatklājot s. Šī ir vispārējā problēma, kuru atrisina zk-SNARKs.

Zk-SNARK definīcija

Zk-SNARK sastāv no trim algoritmiem G, P, V, kas definēti šādi:

Atslēgu ģenerators G ņem slepenu parametru lambda un programmu C un ģenerē divas publiski pieejamas atslēgas, pārbaudīšanas atslēgu pk un verifikācijas atslēgu vk. Šīs atslēgas ir publiski parametri, kas attiecīgajai programmai C ir jāveido tikai vienu reizi.

Sakāmvārds P kā ievadi ņem pierādīšanas atslēgu pk, publisku ievadi x un privātu liecinieku w. Algoritms ģenerē pierādījumu prf = P (pk, x, w), ka sakāmvārds zina liecinieku w un ka liecinieks apmierina programmu.

Verificētājs V aprēķina V (vk, x, prf), kas atgriež vērtību true, ja pierādījums ir pareizs, un citādi – false. Tādējādi šī funkcija atgriežas kā patiess, ja sakāmvārds zina liecinieku, kurš apmierina C (x, w) == taisnība.

Šeit atzīmējiet ģeneratorā izmantoto slepeno parametru lambda. Šis parametrs dažkārt apgrūtina zk-SNARK lietošanu reālās pasaules lietojumprogrammās. Iemesls tam ir tas, ka ikviens, kurš zina šo parametru, var ģenerēt viltus pierādījumus. Konkrēti, ņemot vērā jebkuru programmu C un publisku ievadi x, persona, kas zina lambda, var ģenerēt pierādījumu fake_prf, kuru V (vk, x, fake_prf) novērtē kā patiesu, nezinot par noslēpumu w.

Tādējādi, lai faktiski darbinātu ģeneratoru, ir nepieciešams ļoti drošs process, lai pārliecinātos, ka neviens nezina un nesaglabā parametru jebkur. Tas bija iemesls ārkārtīgi izsmalcināta ceremonija Zcash komanda rīkojās, lai ģenerētu pierādīšanas atslēgu un verifikācijas atslēgu, vienlaikus pārliecinoties, ka procesā tiek iznīcināts “toksisko atkritumu” parametrs lambda..

Zk-SNARK mūsu paraugprogrammai

Kā Alise un Bobs praksē izmantotu zk-SNARK, lai Alise pierādītu, ka viņa zina slepeno vērtību iepriekš minētajā piemērā?

Pirmkārt, kā jau minēts iepriekš, mēs izmantosim programmu, kuru nosaka šāda funkcija:

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

Pirmais solis ir, lai Bobs palaistu ģeneratoru G, lai izveidotu pierādīšanas atslēgu pk un verifikācijas atslēgu vk. Pirmkārt, nejauši ģenerējiet lambda un izmantojiet to kā ievadi:

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

Ar lambda parametru rīkojieties uzmanīgi, jo, ja Alise uzzinās lambda vērtību, viņa varēs izveidot viltus pierādījumus. Bobs dalīsies pk un vk ar Alisi.

Alise tagad pildīs sakāmvārda lomu. Viņai jāpierāda, ka viņa zina vērtību s, kas sajaukta ar zināmo hash H. Viņa palaiž pierādīšanas algoritmu P, izmantojot ieejas pk, H un s, lai ģenerētu pierādījumu prf:

prf = P (pk, H, s)

Tālāk Alise uzrāda pierādījumu prf Bobam, kurš vada verifikācijas funkciju V (vk, H, prf), kas šajā gadījumā atgrieztos kā patiess, jo Alise pareizi zināja slepeno s. Bobs var būt pārliecināts, ka Alise zināja noslēpumu, taču Alisei nevajadzēja šo noslēpumu atklāt Bobam.

Atkārtoti izmantojamas pārbaudes un pārbaudes atslēgas

Mūsu piemērā iepriekš zk-SNARK nevar izmantot, ja Bobs vēlas pierādīt Alisei, ka viņš zina noslēpumu, jo Alise nevar zināt, ka Bobs nav saglabājis lambda parametru. Bobs varēja ticami spēt viltot pierādījumus.

Ja programma ir noderīga daudziem cilvēkiem (piemēram, Zcash piemērs), uzticama neatkarīga grupa, kas nav Alisa un Boba, varētu palaist ģeneratoru un izveidot pierādīšanas atslēgu pk un verifikācijas atslēgu vk tā, lai neviens neuzzinātu par lambda.

Ikviens, kurš tic, ka grupa nav krāpusies, var izmantot šīs atslēgas turpmākajai mijiedarbībai.

zk-SNARKs Ethereum

Izstrādātāji jau ir sākuši integrēt zk-SNARKs Ethereum. Kā tas izskatās? Konkrēti, Ethereum varat pievienot verifikācijas algoritma pamatelementus iepriekš sastādītu līgumu veidā. Tā rīkojieties šādi: palaidiet ģeneratoru ārpus ķēdes, lai izveidotu pierādīšanas atslēgu un verifikācijas atslēgu. Tad jebkurš sakāmvārds var izmantot pierādīšanas atslēgu, lai izveidotu pierādījumu, arī ārpus ķēdes. Pēc tam viedajā līgumā varat palaist vispārējo verifikācijas algoritmu, kā ievades parametrus izmantojot pierādījumu, verifikācijas atslēgu un publisko ievadi. Pēc tam varat izmantot verifikācijas algoritma rezultātu, lai aktivizētu citas darbības ķēdē.

Piemērs: konfidenciāli darījumi

Šeit ir vienkāršs piemērs tam, kā zk-SNARKs var palīdzēt nodrošināt privātumu Ethereum. Pieņemsim, ka mums ir vienkāršs simbolisks līgums. Parasti simboliska līguma pamatā ir kartēšana no adresēm līdz atlikumiem:

kartēšana (adrese => uint256) bilances; Koda valoda: JavaScript (javascript)

Mēs saglabāsim to pašu pamatkodolu, izņemot to, ka atlikumu aizstāsim ar bilances jaucēju:

kartēšana (adrese => baiti32) balanceHashes; Koda valoda: JavaScript (javascript)

Mēs netaisāmies slēpt darījumu sūtītāju vai saņēmēju. Bet mēs slēpsim atlikumus un nosūtītās summas. Šo īpašību dažreiz sauc par konfidenciāli darījumi.

Lai nosūtītu žetonus no viena konta uz citu, mēs izmantosim divus zk-SNARK. Vienu pierādījumu izveido sūtītājs un otru uztvērējs.

Parasti marķiera līgumā par lieluma vērtības darījuma derīgumu mums jāpārbauda:

atlikumi [fromAddress] >= vērtība

Mūsu zk-SNARK ir jāpierāda, ka tas atbilst, kā arī ka atjauninātās jaucējierīces atbilst atjauninātajiem atlikumiem.

Galvenā ideja ir tāda, ka sūtītājs izmantos savu sākuma atlikumu un darījuma vērtību kā privātu ievadi. Kā publiskus datus viņi izmanto sākuma līdzsvara, beigu līdzsvara un vērtības jaukšanu. Līdzīgi uztvērējs kā sākuma slepeno ievadi izmantos sākuma bilanci un vērtību. Kā publiskus datus viņi izmanto sākuma līdzsvara, beigu līdzsvara un vērtības jaukšanu.

Zemāk ir programma, kuru izmantosim sūtītājam zk-SNARK, kur tāpat kā iepriekš x apzīmē publisko ievadi un w apzīmē privāto ievadi.

function senderFunction (x, w) {return (w.senderBalanceBefore > w.vērtība && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} Koda valoda: JavaScript (javascript)

Uztvērēja izmantotā programma ir zemāk:

function receiverFunction (x, w) {return (sha256 (w.value) == x.hashValue && sha256 (w.receiverBalanceBefore) == x.hashReceiverBalanceBefore && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} Koda valoda: JavaScript (javascript)

Programmas pārbauda, ​​vai sūtīšanas atlikums ir lielāks par sūtāmo vērtību, kā arī pārbauda, ​​vai visi jaukšanas gadījumi atbilst. Uzticams cilvēku kopums ģenerēs mūsu zk-SNARKs pierakstīšanas un verifikācijas atslēgas. Sauksim tos par confTxSenderPk, confTxSenderVk, confTxReceiverPk un confTxReceiverVk.

Izmantojot zk-SNARKs token līgumā, varētu izskatīties apmēram šādi:

funkciju pārsūtīšana (adrese _to, bytes32 hashValue, bytes32 hashSenderBalanceAfter, bytes32 hashReceiverBalanceAfter, baiti zkProofSender, baiti zkProofReceiver) {baiti32 hashSenderBalanceBefore = balanceHashes [msg.sender]; baiti32 hashReceiverBalanceBefore = balanceHashes [_to]; bool senderProofIsCorrect = zksnarkverify (confTxSenderVk, [hashSenderBalanceBefore, hashSenderBalanceAfter, hashValue], zkProofSender); bool receiverProofIsCorrect = zksnarkverify (confTxReceiverVk, [hashReceiverBalanceBefore, hashReceiverBalanceAfter, hashValue], zkProofReceiver); ja (senderProofIsCorrect && receiverProofIsCorrect) {balanceHashes [msg.sender] = hashSenderBalanceAfter; balanceHashes [_to] = hashReceiverBalanceAfter; }} Koda valoda: JavaScript (javascript)

Tādējādi vienīgie blokķēdes atjauninājumi ir atlikumu jaukšana, nevis paši atlikumi. Tomēr mēs varam zināt, ka visi atlikumi ir pareizi atjaunināti, jo mēs varam pārbaudīt, vai pierādījums ir pārbaudīts.

Sīkāka informācija

Iepriekš minētā konfidenciālā darījumu shēma galvenokārt ir paredzēta, lai sniegtu praktisku piemēru tam, kā Ethereum var izmantot zk-SNARK. Lai izveidotu stabilu konfidenciālu darījumu shēmu, mums būs jārisina vairāki jautājumi:

  • Lietotājiem būs jāseko savam atlikumam klienta pusē, un, ja jūs zaudējat atlikumu, šos žetonus nevar atgūt. Atlikumus, iespējams, varētu glabāt šifrētā ķēdē ar atslēgu, kas iegūta no parakstīšanas atslēgas.
  • Svariem ir jāizmanto 32 baiti datu un jākodē entropija, lai novērstu spēju mainīt jaukumus, lai noskaidrotu atlikumus.
  • Jānodarbojas ar sūtīšanas uz nelietotu adresi gala lietu.
  • Lai nosūtītu, sūtītājam ir jāsadarbojas ar saņēmēju. Varētu būt sistēma, kurā sūtītājs izmanto savus pierādījumus, lai sāktu darījumu. Tad uztvērējs blokķēdē var redzēt, ka viņiem ir “gaidošs ienākošais darījums”, un var to pabeigt.

Abonējiet mūsu biļetenu, lai iegūtu jaunākos Ethereum jaunumus, uzņēmuma risinājumus, izstrādātāju resursus un daudz ko citu. E-pasta adrese Ekskluzīvs satursKā izveidot veiksmīgu Blockchain produktuTīmekļa seminārs

Kā izveidot veiksmīgu Blockchain produktu

Kā izveidot un palaist Ethereum mezgluTīmekļa seminārs

Kā izveidot un palaist Ethereum mezglu

Kā izveidot savu Ethereum APITīmekļa seminārs

Kā izveidot savu Ethereum API

Kā izveidot sociālo marķieriTīmekļa seminārs

Kā izveidot sociālo marķieri

Drošības rīku izmantošana viedo līgumu izstrādēTīmekļa seminārs

Drošības rīku izmantošana viedo līgumu izstrādē

Finanšu digitālo aktīvu un DeFi nākotneTīmekļa seminārs

Finanšu nākotne: digitālie aktīvi un 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