Inleiding tot zk-SNARKs

blog 1NieuwsOntwikkelaarsEnterpriseBlockchain ExplainedEvenementen en conferentiesPersNieuwsbrieven

Abonneer op onze nieuwsbrief.

E-mailadres

Wij respecteren uw privacy

HomeBlogBlockchain-ontwikkeling

Inleiding tot zk-SNARKs

Een overzicht van zero-knowledge proofs en hoe zk-SNARKs te integreren in Ethereum. door ConsenSys 27 maart 2017 Geplaatst op 27 maart 2017

thuis held

In dit bericht willen we een overzicht geven van zk-SNARKs vanuit een praktisch oogpunt. We behandelen de feitelijke wiskunde als een zwarte doos en proberen een aantal intuïties te ontwikkelen over hoe we ze kunnen gebruiken. We geven ook een eenvoudige toepassing van het recente werk aan het integreren van zk-SNARKs in Ethereum.

Zero-Knowledge-bewijzen

Het doel van nulkennisbewijzen is dat een verificateur zichzelf ervan kan overtuigen dat een bewijzer kennis bezit van een geheime parameter, een getuige genaamd, die voldoet aan een relatie, zonder de getuige aan de verificateur of iemand anders te onthullen..

We kunnen dit concreter zien als een programma, aangeduid met C, met twee ingangen: C (x, w). De invoer x is de openbare invoer en w is de invoer van de geheime getuige. De uitvoer van het programma is booleaans, d.w.z. waar of onwaar. Het doel krijgt dan een specifieke publieke input x, bewijs dat de prover een geheime input w kent zodat C (x, w) == true.

We gaan specifiek niet-interactieve nulkennisbewijzen bespreken. Dit betekent dat het bewijs zelf een klodder gegevens is die kan worden geverifieerd zonder enige interactie van de prover.

Voorbeeldprogramma

Stel dat Bob een hash H van een bepaalde waarde krijgt, en hij wil een bewijs hebben dat Alice de waarde s kent die hashes aan H geeft. Normaal gesproken zou Alice dit bewijzen door s aan Bob te geven, waarna Bob de hash zou berekenen en controleren of het is gelijk aan H.

Stel dat Alice de waarde s niet aan Bob wil onthullen, maar in plaats daarvan alleen wil bewijzen dat ze de waarde kent. Hiervoor kan ze een zk-SNARK gebruiken.

We kunnen het scenario van Alice beschrijven met behulp van het volgende programma, hier geschreven als een Javascript-functie:


functie C (x, w) {return (sha256 (w) == x);} Code taal: JavaScript (javascript)

Met andere woorden: het programma neemt een openbare hash x en een geheime waarde w en retourneert true als de SHA – 256 hash van w gelijk is aan x.

Als we het probleem van Alice vertalen met de functie C (x, w), zien we dat Alice een bewijs moet creëren dat ze s bezit zodat C (H, s) == true, zonder s te hoeven onthullen. Dit is het algemene probleem dat zk-SNARKs oplossen.

Definitie van een zk-SNARK

Een zk-SNARK bestaat uit drie algoritmen G, P, V die als volgt zijn gedefinieerd:

De sleutelgenerator G neemt een geheime parameter lambda en een programma C, en genereert twee publiekelijk beschikbare sleutels, een beproevingssleutel pk en een verificatiesleutel vk. Deze sleutels zijn openbare parameters die maar één keer hoeven te worden gegenereerd voor een bepaald programma C.

De bewijzer P neemt als invoer de beproevingssleutel pk, een openbare invoer x en een privégetuige w. Het algoritme genereert een bewijs prf = P (pk, x, w) dat de bewijzer een getuige w kent en dat de getuige voldoet aan het programma.

De verificateur V berekent V (vk, x, prf) die true retourneert als het bewijs juist is, en anders false. Deze functie geeft dus true terug als de bewijzer een getuige kent w die voldoet aan C (x, w) == true.

Let hier op de geheime parameter lambda die in de generator wordt gebruikt. Deze parameter maakt het soms lastig om zk-SNARKs in real-world applicaties te gebruiken. De reden hiervoor is dat iedereen die deze parameter kent, valse bewijzen kan genereren. Specifiek, gegeven een programma C en openbare invoer x kan een persoon die lambda kent een bewijs genereren fake_prf zodat V (vk, x, nep_prf) evalueert naar waar zonder kennis van het geheim w.

Het feitelijk uitvoeren van de generator vereist dus een zeer veilig proces om ervoor te zorgen dat niemand de parameter leert kennen en deze ergens opslaat. Dit was de reden voor de uiterst uitgebreide ceremonie het Zcash-team voerde de opdracht om de beproevingssleutel en verificatiesleutel te genereren, terwijl het ervoor zorgde dat de parameter “giftig afval” lambda werd vernietigd tijdens het proces.

A zk-SNARK voor ons voorbeeldprogramma

Hoe zouden Alice en Bob in de praktijk een zk-SNARK gebruiken om Alice te laten bewijzen dat ze de geheime waarde in het bovenstaande voorbeeld kent?

Allereerst, zoals hierboven besproken, zullen we een programma gebruiken dat wordt gedefinieerd door de volgende functie:

functie C (x, w) {return (sha256 (w) == x); } Codetaal: JavaScript (javascript)

De eerste stap is dat Bob de generator G laat draaien om de beproevingssleutel pk en verificatiesleutel vk te maken. Genereer eerst willekeurig lambda en gebruik dat als invoer:

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

Ga voorzichtig om met de parameter lambda, want als Alice de waarde van lambda leert, kan ze nepbewijzen maken. Bob zal pk en vk delen met Alice.

Alice zal nu de rol van de spreekster spelen. Ze moet bewijzen dat ze de waarde s kent die hashes met de bekende hash H.Ze voert het testalgoritme P uit met behulp van de ingangen pk, H en s om de proof prf te genereren:

prf = P (pk, H, s)

Vervolgens presenteert Alice het bewijs prf aan Bob die de verificatiefunctie V (vk, H, prf) uitvoert, die in dit geval true zou retourneren omdat Alice de geheime s goed kende. Bob kan erop vertrouwen dat Alice het geheim kende, maar Alice hoefde het niet aan Bob te onthullen.

Herbruikbare bewijs- en verificatiesleutels

In ons bovenstaande voorbeeld kan de zk-SNARK niet worden gebruikt als Bob Alice wil bewijzen dat hij een geheim kent, omdat Alice niet kan weten dat Bob de lambda-parameter niet heeft opgeslagen. Het is aannemelijk dat Bob bewijzen kan vervalsen.

Als een programma voor veel mensen nuttig is (zoals het voorbeeld van Zcash), zou een vertrouwde onafhankelijke groep los van Alice en Bob de generator kunnen draaien en de beproevingssleutel pk en verificatiesleutel vk op zo’n manier kunnen maken dat niemand leert over lambda.

Iedereen die erop vertrouwt dat de groep niet vals speelde, kan deze sleutels gebruiken voor toekomstige interacties.

zk-SNARKs in Ethereum

Ontwikkelaars zijn al begonnen met het integreren van zk-SNARKs in Ethereum. Hoe ziet dit eruit? Concreet kun je de bouwstenen van het verificatie-algoritme aan Ethereum toevoegen in de vorm van voorgecompileerde contracten. Hier is hoe: laat de generator off-chain draaien om de bewijssleutel en verificatiesleutel te produceren. Elke bewijzer kan dan de beproevingssleutel gebruiken om een ​​bewijs te maken, ook buiten de keten. U kunt vervolgens het algemene verificatie-algoritme binnen een smart contract uitvoeren, met behulp van het bewijs, de verificatiesleutel en de openbare invoer als invoerparameters. U kunt vervolgens de uitkomst van het verificatiealgoritme gebruiken om andere on-chain activiteit te activeren.

Voorbeeld: vertrouwelijke transacties

Hier is een eenvoudig voorbeeld van hoe zk-SNARKs kunnen helpen met privacy op Ethereum. Stel dat we een eenvoudig symbolisch contract hebben. Normaal gesproken zou een token-contract in de kern een mapping hebben van adressen naar saldi:

mapping (adres => uint256) saldi; Codetaal: JavaScript (javascript)

We zullen dezelfde basiskern behouden, behalve een balans vervangen door de hasj van een balans:

mapping (adres => bytes32) balanceHashes; Codetaal: JavaScript (javascript)

We gaan de afzender of ontvanger van transacties niet verbergen. Maar we verbergen de saldi en verzonden bedragen. Deze eigenschap wordt ook wel vertrouwelijke transacties.

We gebruiken twee zk-SNARKs om tokens van het ene account naar het andere te verzenden. Eén bewijs wordt gemaakt door de afzender en één door de ontvanger.

Normaal gesproken moeten we in een tokencontract om een ​​transactie met een omvangswaarde geldig te laten zijn, het volgende verifiëren:

saldi [fromAddress] >= waarde

Onze zk-SNARKs moeten bewijzen dat dit het geval is, evenals dat de bijgewerkte hashes overeenkomen met de bijgewerkte saldi.

Het belangrijkste idee is dat de afzender het beginsaldo en de transactiewaarde als privé-input gebruikt. Als publieke input gebruiken ze hashes van beginsaldo, eindsaldo en waarde. Evenzo gebruikt de ontvanger startsaldo en waarde als geheime invoer. Als publieke input gebruiken ze hashes van beginsaldo, eindsaldo en waarde.

Hieronder staat het programma dat we zullen gebruiken voor de afzender zk-SNARK, waarbij zoals eerder x de openbare invoer vertegenwoordigt en w de privé-invoer vertegenwoordigt.

functie senderFunction (x, w) {return (w.senderBalanceBefore > w.waarde && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} Code taal: JavaScript (javascript)

Het programma dat door de ontvanger wordt gebruikt, is hieronder:

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

De programma’s controleren of het verzendsaldo groter is dan de waarde die wordt verzonden, en controleren ook of alle hashes overeenkomen. Een vertrouwde groep mensen zou de bewijs- en verificatiesleutels voor onze zk-SNARKs genereren. Laten we ze confTxSenderPk, confTxSenderVk, confTxReceiverPk en confTxReceiverVk noemen.

Het gebruik van de zk-SNARKs in een tokencontract zou er ongeveer zo uitzien:

functieoverdracht (adres _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; }} Codetaal: JavaScript (javascript)

De enige updates op de blockchain zijn dus de hashes van de saldi en niet de saldi zelf. We kunnen echter weten dat alle saldi correct zijn bijgewerkt, omdat we zelf kunnen controleren of het bewijs is geverifieerd.

Details

Het bovenstaande vertrouwelijke transactieschema is voornamelijk bedoeld om een ​​praktisch voorbeeld te geven van hoe men zk-SNARKs op Ethereum kan gebruiken. Om een ​​robuust vertrouwelijk transactieregime te creëren, zouden we een aantal problemen moeten aanpakken:

  • Gebruikers zouden hun saldi aan de clientzijde moeten bijhouden, en als u het saldo verliest, kunnen die tokens niet worden hersteld. De saldi kunnen misschien versleuteld in een ketting worden opgeslagen met een sleutel die is afgeleid van de ondertekeningssleutel.
  • Saldi moeten 32 bytes aan gegevens gebruiken en entropie coderen om te voorkomen dat hashes kunnen worden omgekeerd om saldi te berekenen.
  • Moet het randgeval van verzending naar een ongebruikt adres aanpakken.
  • De afzender moet communiceren met de ontvanger om te kunnen verzenden. Men zou mogelijk een systeem kunnen hebben waarbij de afzender zijn bewijs gebruikt om de transactie te starten. De ontvanger kan dan op de blockchain zien dat er een “in afwachting van inkomende transactie” is en kan deze afronden.

Abonneer u op onze nieuwsbrief voor het laatste Ethereum-nieuws, bedrijfsoplossingen, bronnen voor ontwikkelaars en meer.Hoe u een succesvol blockchain-product bouwtWebinar

Hoe u een succesvol blockchain-product bouwt

Hoe u een Ethereum-knooppunt instelt en uitvoertWebinar

Hoe u een Ethereum-knooppunt instelt en uitvoert

Hoe u uw eigen Ethereum-API kunt bouwenWebinar

Hoe u uw eigen Ethereum-API kunt bouwen

Hoe u een sociaal token maaktWebinar

Hoe u een sociaal token maakt

Beveiligingshulpmiddelen gebruiken bij slimme contractontwikkelingWebinar

Beveiligingshulpmiddelen gebruiken bij slimme contractontwikkeling

De toekomst van digitale activa en defiWebinar

De toekomst van financiën: digitale activa en 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