Bevezetés a zk-SNARK-okba

blog 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressHírlevelek

Iratkozzon fel hírlevelünkre.

Email cím

Tiszteletben tartjuk a magánéletét

HomeBlogBlockchain fejlesztés

Bevezetés a zk-SNARK-okba

Áttekintés a nulla tudás igazolásokról és arról, hogyan lehet integrálni a zk-SNARK-okat az Ethereumba. Készítette: ConsenSys 2017. március 27. Feladva: 2017. március 27

otthoni hős

Ebben a bejegyzésben arra törekszünk, hogy gyakorlati szempontból áttekintést adjunk a zk-SNARK-okról. A tényleges matematikát fekete dobozként fogjuk kezelni, és megpróbálunk kifejleszteni néhány intuíciót a felhasználásuk körül. A legutóbbi munkának egyszerű alkalmazását is megadjuk zk-SNARK-ok integrálása az Ethereumba.

Zero-Knowledge Proofs

A nulla tudással történő bizonyítás célja az, hogy a hitelesítő képes legyen meggyőzni magát arról, hogy a közmondás birtokában van egy titkos, tanúnak nevezett paraméter ismerete, kielégítve valamilyen viszonyt, anélkül, hogy a tanút felfedné az igazolónak vagy bárki másnak.

Ezt konkrétabban úgy gondolhatjuk, hogy van egy programunk, amelyet C-vel jelölünk, és két bemenetet vesz fel: C (x, w). Az x bemenet a nyilvános bemenet, a w pedig a titkos tanú bemenet. A program kimenete logikai, azaz igaz vagy hamis. A cél egy adott nyilvános x bemenetet kap, bizonyítsa be, hogy a közmondó ismer egy titkos w bemenetet, hogy C (x, w) == igaz.

Kifejezetten a nem interaktív nulla tudásbizonyításokat fogjuk megvitatni. Ez azt jelenti, hogy a bizonyítás maga az adatok foltja, amelyeket a közmondás közreműködése nélkül ellenőrizni lehet.

Példaprogram

Tegyük fel, hogy Bob kap egy bizonyos H-értékű hash-t, és bizonyítékot akar kapni arról, hogy Alice tudja az H.-nak hash értékeket. Alice általában ezt bizonyítja azzal, hogy s-t ad Bobnak, majd Bob kiszámítja a kivonatot és ellenőrizze, hogy egyenlő H-val.

Tegyük fel azonban, hogy Alice nem akarja elárulni az értéket Bob számára, ehelyett csak be akarja bizonyítani, hogy tudja az értéket. Ehhez használhat egy zk-SNARK-ot.

Alice forgatókönyvét a következő programmal írhatjuk le, amelyet Javascript függvényként írtunk:

függvény C (x, w) {return (sha256 (w) == x);} Kód nyelve: JavaScript (javascript)

Más szavakkal: a program felvesz egy nyilvános hash x-et és egy titkos w értéket, és igaz értéket ad vissza, ha az SHA – 256 w hash értéke megegyezik x.

Alice problémájának a C (x, w) függvény segítségével történő lefordításával azt látjuk, hogy Alice-nek bizonyítékot kell létrehoznia arról, hogy rendelkezik olyan s-ekkel, amelyek C (H, s) == igazak, anélkül, hogy el kellene fednie s-t. Ez az az általános probléma, amelyet a zk-SNARK-ok megoldanak.

A zk-SNARK meghatározása

A zk-SNARK három G, P, V algoritmusból áll, amelyek az alábbiak szerint vannak meghatározva:

A G kulcsgenerátor vesz egy titkos lambda paramétert és egy C programot, és két nyilvánosan elérhető kulcsot generál, egy pk bizonyító kulcsot és egy vk ellenőrző kulcsot. Ezek a kulcsok nyilvános paraméterek, amelyeket csak egyszer kell létrehozni egy adott C programhoz.

A P közmondás bemenetként a pk bizonyító kulcsot, az x nyilvános bemenetet és a w magántanút veszi. Az algoritmus egy prf = P (pk, x, w) bizonyítást generál, amely szerint a közmondás ismeri a tanút w, és hogy a tanú kielégíti a programot.

Az V hitelesítő kiszámítja a V értéket (vk, x, prf), amely igaz értéket ad vissza, ha a bizonyítás helyes, és hamisat egyébként. Így ez a függvény igazra tér vissza, ha a közmondó ismeri a C (x, w) == true értéket kielégítő tanút.

Itt jegyezzük meg a generátorban használt lambda titkos paramétert. Ez a paraméter néha bonyolulttá teszi a zk-SNARK használatát a valós alkalmazásokban. Ennek az az oka, hogy bárki, aki ismeri ezt a paramétert, hamis igazolásokat tud előállítani. Pontosabban, bármely C program és nyilvános x bemenet mellett egy személy, aki ismeri a lambdát, olyan hamis_prf bizonyítékot generálhat, amelyet V (vk, x, fake_prf) igaznak értékel, anélkül, hogy tudná a.

Így a generátor tényleges futtatása nagyon biztonságos folyamatot igényel annak biztosítására, hogy senki ne ismerje meg és sehova ne menti a paramétert. Ez volt az oka a rendkívül kidolgozott szertartás a Zcash csapata a bizonyító kulcs és az ellenőrző kulcs előállítása érdekében végzett, miközben ügyelt arra, hogy a lambda „mérgező hulladék” paraméter megsemmisült.

Egy zk-SNARK a példaprogramunkhoz

Hogyan használná Alice és Bob a zk-SNARK-ot a gyakorlatban annak érdekében, hogy Alice bebizonyítsa, hogy tudja a titkos értéket a fenti példában?

Először is, amint azt fentebb tárgyaltuk, a következő függvény által meghatározott programot fogjuk használni:

C függvény (x, w) {return (sha256 (w) == x); } Kód nyelve: JavaScript (javascript)

Az első lépés, hogy Bob futtassa a G generátort a pk bizonyító kulcs és a vk ellenőrző kulcs létrehozása érdekében. Először véletlenszerűen generálja a lambdát, és ezt használja bemenetként:

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

Óvatosan kezelje a lambda paramétert, mert ha Alice megtanulja a lambda értékét, képes lesz hamis bizonyítékokat készíteni. Bob megosztja Alkkal a pk-t és a vk-t.

Alice most a közmondás szerepét tölti be. Bizonyítania kell, hogy ismeri az ismert H hash-hoz hasított s értéket. A P bizonyító algoritmust a pk, H és s bemenetek segítségével futtatja a prf bizonyítás előállításához:

prf = P (pk, H, s)

Ezután Alice bemutatja a bizonyító prf-t Bobnak, aki az V ellenőrző függvényt futtatja (vk, H, prf), amely igaz lenne ebben az esetben, mivel Alice megfelelően ismerte a titkot. Bob biztos lehet abban, hogy Alice tudta a titkot, de Alice-nek nem kellett felfednie a titkot Bob előtt.

Újrafelhasználható igazoló és ellenőrző kulcsok

A fenti példánkban a zk-SNARK nem használható, ha Bob be akarja bizonyítani Alice-nek, hogy tud egy titkot, mert Alice nem tudja, hogy Bob nem mentette el a lambda paramétert. Bob hihetően képes hamis igazolásokra.

Ha egy program sok ember számára hasznos (például a Zcash példája), akkor egy Alice-től és Bobtól független, megbízható független csoport futtathatja a generátort, és létrehozhatja a pk és a vk ellenőrző kulcsot oly módon, hogy senki ne tudjon meg többet a lambdáról.

Aki bízik abban, hogy a csoport nem csalt, akkor ezeket a kulcsokat használhatja a jövőbeli interakciókhoz.

zk-SNARKok az Ethereumban

A fejlesztők már elkezdték integrálni a zk-SNARK-okat az Ethereumba. Hogy néz ki ez? Konkrétan hozzáadhatja az ellenőrzési algoritmus építőköveit az Ethereumhoz előre lefordított szerződések formájában. Így teheti meg: futtassa a generátort láncolaton kívül a bizonyító kulcs és az ellenőrző kulcs előállításához. Ezután bármelyik közmondó felhasználhatja a bizonyító kulcsot egy bizonyíték létrehozására, szintén láncolaton kívül. Ezután az intelligens szerződésen belül futtathatja az általános ellenőrzési algoritmust, beviteli paraméterként használva a bizonyítékot, az ellenőrző kulcsot és a nyilvános bemenetet. Ezután felhasználhatja az ellenőrző algoritmus eredményét más on-line tevékenységek kiváltására.

Példa: Bizalmas tranzakciók

Íme egy egyszerű példa arra, hogy a zk-SNARK-ok miként segíthetik az Ethereum adatvédelmét. Tegyük fel, hogy egyszerű token szerződésünk van. Normális esetben egy token szerződés középpontjában a címek és az egyenleg leképezése áll:

leképezés (cím => uint256) egyenlegek; Kód nyelve: JavaScript (javascript)

Ugyanazt az alapmagot fogjuk megtartani, kivéve, ha az egyenleget felváltjuk az egyenleg hashjával:

leképezés (cím => bájtok32) balanceHashes; Kód nyelve: JavaScript (javascript)

Nem fogjuk elrejteni a tranzakciók feladóját vagy címzettjét. De elrejtjük az egyenlegeket és az elküldött összegeket. Ezt a tulajdonságot néha nevezik bizalmas tranzakciók.

Két zk-SNARK-ot fogunk használni a tokenek elküldéséhez egyik fiókból a másikba. Egy bizonyítékot a feladó és egyet a vevő hoz létre.

Normál esetben egy token szerződésben, amelynek értéke a tranzakció nagysága, érvényesítenünk kell a következőket:

egyenlegek [fromAddress] >= érték

A zk-SNARK-jainknak be kell bizonyítaniuk, hogy ez érvényes, valamint hogy a frissített hashek megegyeznek a frissített egyenlegekkel.

A fő gondolat az, hogy a feladó kezdő egyenlegét és a tranzakció értékét magánbevitelként használja. Nyilvános bemenetként a kezdő egyensúly, a végső egyensúly és az érték kivonatait használják. Hasonlóképpen, a vevő titkos bemenetként kezdő egyensúlyt és értéket fog használni. Nyilvános bemenetként a kezdő egyensúly, a végső egyensúly és az érték kivonatait használják.

Az alábbiakban látható az a program, amelyet a feladóhoz használunk zk-SNARK, ahol az előzőekhez hasonlóan x a nyilvános és w a privát bemenetet jelenti.

function senderFunction (x, w) {return (w.senderBalanceBefore > w.value && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} Kód nyelve: JavaScript (javascript)

A vevő által használt program a következő:

function receiverFunction (x, w) {return (sha256 (w.value) == x.hashValue && sha256 (w.receiverBalanceBefore) == x.hashReceiverBalanceBefore && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} Kód nyelve: JavaScript (javascript)

A programok ellenőrzik, hogy a küldési egyenleg nagyobb-e, mint az elküldött érték, valamint ellenőrzik, hogy minden hash egyezik-e. Megbízható emberek készítenék az igazoló és ellenőrző kulcsokat zk-SNARK-jainkhoz. Nevezzük őket confTxSenderPk, confTxSenderVk, confTxReceiverPk és confTxReceiverVk.

A zk-SNARKs használata token szerződésben így néz ki:

függvényátadás (_cím, bytes32 hashValue, bytes32 hashSenderBalanceAfter, bytes32 hashReceiverBalanceAfter, bytees zkProofSender, bytees zkProofReceiver) {byt32 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; }} Kód nyelve: JavaScript (javascript)

Így a blokklánc egyetlen frissítése a mérlegek hash-ja, és nem maguk a mérlegek. Tudhatjuk azonban, hogy az összes mérleg helyesen frissül, mert ellenőrizhetjük magunkat, hogy a bizonyítást igazoltuk-e.

Részletek

A fenti bizalmas tranzakciós séma elsősorban gyakorlati példát mutat arra, hogy miként lehet használni a zk-SNARK-okat az Ethereumon. Megalapozott bizalmas tranzakciós rendszer létrehozásához számos kérdéssel kell foglalkoznunk:

  • A felhasználóknak nyomon kell követniük az ügyféloldali egyenlegeiket, és ha elveszíti az egyenleget, ezek a tokenek nem állíthatók helyre. Az egyenlegeket valószínűleg titkosítva tárolhatnák láncon egy aláíró kulcsból levezetett kulccsal.
  • A mérlegeknek 32 bájt adatot kell használniuk, és kódolniuk kell az entrópiát, hogy megakadályozzák a hashek visszafordítását az egyenlegek kitalálásához..
  • Foglalkoznia kell a fel nem használt címre történő küldéssel.
  • A küldőnek kölcsönhatásba kell lépnie a vevővel a küldéshez. Lehetséges, hogy van egy olyan rendszer, ahol a feladó bizonyítékaival felhasználja a tranzakció kezdeményezését. A vevő ekkor láthatja a blokkláncon, hogy van egy „függőben lévő bejövő tranzakció”, és véglegesítheti azt.

Iratkozzon fel hírlevelünkre a legfrissebb Ethereum hírekről, vállalati megoldásokról, fejlesztői erőforrásokról és egyebekről. E-mail cím Exkluzív tartalomHogyan készítsünk sikeres blokklánc terméketWebinárium

Hogyan készítsünk sikeres blokklánc terméket

Hogyan állítsunk be és futtassunk Ethereum csomópontotWebinárium

Hogyan állítsunk be és futtassunk Ethereum csomópontot

Hogyan készítsünk saját Ethereum API-tWebinárium

Hogyan készítsünk saját Ethereum API-t

Hogyan hozzunk létre közösségi tokentWebinárium

Hogyan hozzunk létre közösségi tokent

Biztonsági eszközök használata az intelligens szerződés-fejlesztésbenWebinárium

Biztonsági eszközök használata az intelligens szerződés-fejlesztésben

A pénzügyi eszközök digitális eszközei és a DeFi jövőjeWebinárium

A pénzügyek jövője: digitális eszközök és DeFi

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