Wat zijn zk-SNARKs en hoe maken ze privacy op blockchains mogelijk?

Wat zijn zk-SNARKs?

zk-SNARKs zijn cryptografische bewijzen waarmee je kunt aantonen dat bepaalde informatie of een berekening klopt, zonder privacygevoelige informatie openbaar te maken. Daardoor kan een blockchain bijvoorbeeld controleren dat een betaling geldig is, terwijl gegevens zoals het bedrag of de ontvanger verborgen blijven. Een van de bekendste blockchains die deze technologie gebruikt, is Zcash. Daar worden zk-SNARKs gebruikt om transacties te kunnen verifiëren terwijl gegevens zoals het bedrag of de ontvanger verborgen kunnen blijven.

De naam zk-SNARK is een afkorting van zero-knowledge succinct non-interactive argument of knowledge. Dat klinkt ingewikkeld, maar je kunt de onderdelen simpel opsplitsen:

• Zero-knowledge: het bewijs toont aan dat een stelling klopt, bijvoorbeeld dat een transactie geldig is, zonder privacygevoelige informatie zoals het verzendadres, ontvangstadres of transactiebedrag prijs te geven.
• Succinct: het bewijs is kort. Een node of smart contract kan het dus relatief efficiënt controleren.
• Non-interactive: na het maken van het bewijs hoeft de maker niet heen en weer te communiceren met degene die het controleert. Het bewijs kan één keer worden gemaakt en vervolgens worden gecontroleerd.
• Argument of knowledge: de maker toont aan dat hij beschikt over de informatie die nodig is om aan de gestelde regels te voldoen, bijvoorbeeld de gegevens waarmee een geldige transactie kan worden gemaakt. De beveiliging berust daarbij op cryptografische aannames: een aanvaller met beperkte rekenkracht kan in de praktijk geen vals bewijs maken dat als geldig wordt geaccepteerd. De informatie waarmee het bewijs wordt gemaakt, wordt vaak de witness genoemd. Stel dat je wilt bewijzen dat je genoeg saldo hebt voor een betaling. De witness bevat dan bijvoorbeeld de gegevens waarmee je kunt aantonen dat je over voldoende geld beschikt en dit mag uitgeven. De blockchain hoeft die gegevens niet zelf te zien, maar kan wel controleren dat het bijbehorende bewijs geldig is.

Naast de private witness kan een zk-SNARK ook publieke invoer bevatten. Dat zijn gegevens die wel zichtbaar mogen zijn en die de verifier samen met het bewijs gebruikt om te controleren of de stelling klopt.

Belangrijk om te weten: een zk-SNARK is niet één vast protocol, maar een verzamelnaam voor verschillende soorten bewijssystemen met deze eigenschappen. De precieze werking kan per systeem verschillen. Sommige systemen hebben bijvoorbeeld een trusted setup nodig, terwijl andere zonder zo'n setup kunnen werken.

Korte samenvatting

• zk-SNARKs bewijzen dat iets klopt zonder privacygevoelige informatie prijs te geven.
• De private gegevens achter een bewijs worden vaak de witness genoemd.
• De bewijzen zijn kort en kunnen relatief efficiënt worden gecontroleerd.
• Een gepubliceerd bewijs kan zonder extra contact met de maker worden geverifieerd.
• zk-SNARKs zijn een categorie van bewijssystemen, geen één vast protocol.

Hoe werken zk-SNARKs?

Bij een zk-SNARK worden de regels waaraan een transactie of berekening moet voldoen eerst omgezet in controles die een computer kan uitvoeren. Die verzameling controles wordt een circuit of constraintsysteem genoemd. Daarin staat precies aan welke voorwaarden moet worden voldaan voordat iets als geldig wordt beschouwd.

Neem een private betaling als voorbeeld. Het circuit kan bijvoorbeeld controleren of iemand over voldoende saldo beschikt, dat saldo nog niet eerder heeft uitgegeven en bevoegd is om het te gebruiken. De privacygevoelige gegevens die voor deze controles nodig zijn, zoals het saldo of de gegevens waarmee het mag worden uitgegeven, blijven verborgen voor degene die het bewijs controleert.

In grote lijnen zijn er drie stappen:

1. Setup Bij veel klassieke zk-SNARKs worden eerst publieke parameters gemaakt. Deze gegevens zijn nodig om bewijzen te maken en te controleren.

2. Proof generation De prover, dus de partij die iets wil bewijzen, gebruikt de witness en de regels van het circuit om een cryptografisch bewijs te maken.

3. Verificatie De verifier, bijvoorbeeld een node of smart contract, controleert het bewijs samen met de publieke invoer. De verifier krijgt de private witness niet te zien en hoeft de volledige berekening niet zelf opnieuw uit te voeren.

Een goed zk-SNARK-systeem probeert drie belangrijke eigenschappen te garanderen. Ten eerste volledigheid: als de stelling klopt en het bewijs correct wordt gemaakt, wordt het bewijs geaccepteerd. Ten tweede soundness: een aanvaller kan in de praktijk geen geldig bewijs maken voor een stelling die niet klopt. En ten derde zero-knowledge: het bewijs maakt geen privacygevoelige informatie bekend, behalve het feit dat de bewezen stelling klopt.

Voorbeeld: Stel dat je moet bewijzen dat je ouder bent dan 18, zonder je geboortedatum te delen. Een zk-SNARK kan in theorie bewijzen dat je aan die voorwaarde voldoet, zonder dat de controleur je geboortedatum of exacte leeftijd te zien krijgt.

Er zit wel een belangrijke grens aan. Een zk-SNARK controleert alleen de regels die in het circuit zijn vastgelegd. Als er een fout in die regels zit, kan een bewijs technisch geldig zijn terwijl het systeem toch iets toestaat wat eigenlijk niet de bedoeling was. De cryptografie kan een verkeerd ontworpen circuit dus niet vanzelf corrigeren.

Waarvoor worden zk-SNARKs gebruikt?

zk-SNARKs worden gebruikt wanneer iemand wil aantonen dat een berekening correct is uitgevoerd, zonder alle invoer of tussenstappen openbaar te maken. Dat maakt de techniek interessant voor privacy, maar ook voor toepassingen waarbij degene die het bewijs controleert niet de volledige berekening opnieuw hoeft uit te voeren.

Een paar bekende toepassingen zijn:

• private betalingen;
• applicaties waarbij invoer of delen van de berekening privé blijven;
• identiteits- en credentialbewijzen, waarbij je een eigenschap bewijst zonder alle persoonsgegevens te delen;
• proof-of-reserves, waarbij een partij kan aantonen dat bepaalde reserves aanwezig zijn zonder alle onderliggende gegevens openbaar te maken;
• validity rollups, die veel transacties buiten Ethereum verwerken en daarna een bewijs van de correcte verwerking op Ethereum plaatsen.

Aleo gebruikt bijvoorbeeld een model waarbij een programma lokaal wordt uitgevoerd. Daarna wordt een zero-knowledgebewijs gemaakt waarmee kan worden aangetoond dat de uitvoering correct was. Validators hoeven dan niet alle private invoer en tussenstappen te ontvangen, maar kunnen het bewijs controleren.

Privacy komt niet automatisch mee zodra ergens “ZK” wordt gebruikt. Welke gegevens privé blijven, hangt af van het protocol en van wat er in het circuit als privé of publiek is vastgelegd. Als bepaalde transactiegegevens bewust openbaar worden gemaakt, kan een zk-SNARK die gegevens niet alsnog verbergen.

Hoe ondersteunen zk-SNARKs privacy?

zk-SNARKs ondersteunen privacy doordat je kunt bewijzen dat een transactie geldig is zonder de privacygevoelige details ervan openbaar te maken. Bij een private betaling kan iemand bijvoorbeeld bewijzen dat hij over geldige middelen beschikt, bevoegd is om deze uit te geven en geen geld dubbel uitgeeft. De afzender, ontvanger en het bedrag hoeven daarbij niet openbaar te zijn.

Zcash laat goed zien hoe zo'n ontwerp werkt. Daar wordt een note gebruikt om een bepaalde hoeveelheid ZEC privé vast te leggen. Op de blockchain staat niet de volledige inhoud van die note, maar een commitment: een cryptografische vastlegging ervan. Je kunt het zien als een gesloten, verzegelde envelop. Iedereen kan zien dat de envelop bestaat, maar niet wat erin staat.

De informatie over de note wordt voor de ontvanger versleuteld. Wanneer een note wordt uitgegeven, verschijnt er een unieke nullifier op de blockchain. Die nullifier laat niet rechtstreeks zien welke note is uitgegeven, maar nodes kunnen wel controleren of dezelfde nullifier al eerder is gebruikt. Zo kan het netwerk double spending voorkomen zonder de onderliggende privégegevens openbaar te maken.

Privacy betekent hier dus niet dat er helemaal geen spoor op de blockchain staat. Commitments en nullifiers blijven zichtbaar. Ook gegevens zoals IP-adressen, timing, netwerkmetadata en informatie die een gebruiker zelf openbaar maakt, worden niet automatisch verborgen door een zk-SNARK.

Hoe worden zk-SNARKs gebruikt voor schaalbaarheid?

Voor schaalbaarheid kunnen zk-SNARKs worden gebruikt om een grote hoeveelheid rekenwerk samen te vatten in één compact bewijs. Dat zie je bijvoorbeeld bij validity rollups: transacties worden buiten Ethereum verwerkt, gebundeld in batches en daarna wordt een bewijs gemaakt dat de verwerking correct is verlopen.

De operator van zo'n rollup verwerkt de transacties en maakt een validity proof waarmee wordt aangetoond dat de nieuwe toestand volgens de regels van de rollup is berekend. Een verifiercontract op Ethereum accepteert die nieuwe toestand alleen als het bewijs geldig is. Ethereum hoeft daardoor niet alle berekeningen van iedere afzonderlijke transactie opnieuw uit te voeren.

Met recursie kan dit nog verder worden samengevat. Daarbij kan een nieuw bewijs aantonen dat meerdere eerdere bewijzen geldig zijn. Zo kunnen uiteindelijk veel afzonderlijke berekeningen of bewijzen worden vertegenwoordigd door één compact bewijs.

Scroll gebruikt zk-bewijzen om de correcte uitvoering van batches met transacties aan te tonen, waarna het bewijs op Ethereum kan worden gecontroleerd.

Mina gebruikt recursieve zk-SNARKs op een andere manier. In plaats van dat een deelnemer de volledige blockchainhistorie vanaf het begin hoeft te controleren, kan de geldigheid van de huidige blockchainstate worden aangetoond met een compact cryptografisch bewijs.

Snelle verificatie betekent niet dat het hele proces goedkoop is. Het maken van een bewijs kan juist veel rekenkracht en geheugen vragen. Daarnaast lost een validity proof niet automatisch andere problemen op, zoals datatoegankelijkheid, censuur door een operator of risico's rond bruggen tussen blockchains.

Welke blockchains en cryptocurrencies maken gebruik van zk-SNARKs?

Verschillende crypto-projecten gebruiken zk-SNARKs, maar vaak voor verschillende doelen. De techniek wordt dus niet alleen gebruikt voor private transacties.

• Zcash gebruikt zk-SNARKs voor shielded transacties. Binnen het Orchard-protocol wordt Halo 2 gebruikt om zulke transacties cryptografisch te bewijzen.
• Aleo gebruikt zk-SNARKs voor private en programmeerbare applicaties. Programma's kunnen lokaal worden uitgevoerd, waarna validators het bewijs van correcte uitvoering controleren zonder de private invoer of tussenstappen te hoeven zien.
• Mina gebruikt recursieve zk-SNARKs om de geldigheid van de blockchainstate compact te bewijzen. Het hoofddoel is hier compacte verificatie en niet automatisch transactieprivacy.
• Scroll gebruikt zk-SNARKs binnen zijn zkEVM om de correcte verwerking van batches met transacties te bewijzen. Deze bewijzen kunnen vervolgens op Ethereum worden gecontroleerd.
• Ethereum ondersteunt de verificatie van bepaalde pairing-gebaseerde zk-SNARKs via precompiles. Daardoor kunnen smart contracts zk-SNARK-bewijzen controleren. Ethereum gebruikt zk-SNARKs zelf niet als algemeen consensusmechanisme.

Let op het verschil tussen een zk-SNARK en een zk-STARK. Beide zijn cryptografische bewijssystemen die zero-knowledge kunnen ondersteunen, maar technisch werken ze anders. zk-STARKs hebben doorgaans geen trusted setup nodig, maar leveren vaak grotere bewijzen op dan zk-SNARKs. Een ZK-rollup hoeft daarom niet per se een zk-SNARK te gebruiken.

Wat is een trusted setup bij zk-SNARKs?

Een trusted setup is een eenmalig proces waarbij voor sommige zk-SNARKs publieke parameters worden gemaakt die nodig zijn om bewijzen te genereren en te controleren. Deze parameters worden vaak een structured reference string (SRS) of common reference string (CRS) genoemd.

Het gevoelige onderdeel is de geheime willekeurige informatie die tijdens zo'n setup wordt gebruikt. Deze wordt ook wel toxic waste genoemd. Als iemand die informatie bewaart of later kan reconstrueren, kan dat bij bepaalde systemen, zoals Groth16, in theorie worden misbruikt om valse bewijzen te maken die toch als geldig worden geaccepteerd.

Daarom gebruiken projecten soms een multi-party computation-ceremonie. Meerdere deelnemers voegen daarbij ieder hun eigen geheime willekeurigheid toe. Zolang minimaal één deelnemer eerlijk handelt en zijn geheime bijdrage daadwerkelijk vernietigt, kan de volledige geheime setupinformatie niet worden gereconstrueerd.

Dat verlaagt het risico aanzienlijk, maar betekent nog steeds dat je erop vertrouwt dat minstens één deelnemer niet is gecompromitteerd en zijn geheime bijdrage echt heeft verwijderd.

Niet elke zk-SNARK heeft een trusted setup nodig. Zcash gebruikte voor oudere Sprout- en Sapling-circuits Groth16, waarvoor wel zo'n trusted setup nodig was. Het latere Orchard-protocol gebruikt Halo 2 en heeft geen trusted setup met toxic waste nodig.

Wat zijn de voordelen van zk-SNARKs?

Het grote voordeel van zk-SNARKs is dat privacy en controleerbaarheid samen kunnen gaan. Je kunt bewijzen dat je aan bepaalde regels voldoet, zonder de privacygevoelige gegevens achter dat bewijs openbaar te maken.

De belangrijkste voordelen op een rij:

• Privacy met controle: gevoelige gegevens kunnen verborgen blijven, terwijl nodes nog steeds kunnen controleren of een transactie of berekening geldig is.
• Korte bewijzen: de bewijzen zijn compact vergeleken met de berekening die ze vertegenwoordigen.
• Snelle verificatie: een node of smart contract hoeft niet de volledige berekening opnieuw uit te voeren.
• Openbare controle: een bewijs kan worden gepubliceerd en daarna onafhankelijk worden gecontroleerd.
• Veel berekeningen samenvatten: met recursieve bewijzen kunnen meerdere transacties, batches of eerdere bewijzen uiteindelijk worden samengevat in een compact nieuw bewijs.

Op Ethereum kunnen bepaalde pairing-gebaseerde zk-SNARKs ook in smart contracts worden gecontroleerd. Daardoor kunnen applicaties bijvoorbeeld bewijzen van offchain berekeningen of privacygerichte controles op Ethereum laten verifiëren.

Wel belangrijk: “kort” en “efficiënt” zeggen vooral iets over de grootte van het bewijs en de verificatie ervan. Voor de prover kan het maken van zo'n bewijs juist veel rekenkracht en geheugen vragen.

Wat zijn de beperkingen en risico’s van zk-SNARKs?

zk-SNARKs zijn krachtig, maar geen oplossing voor ieder privacy- of schaalbaarheidsprobleem. De veiligheid hangt af van de gebruikte cryptografie, het circuit en de manier waarop het systeem in een blockchain of applicatie is ingebouwd.

Een belangrijk risico bij systemen die afhankelijk zijn van een trusted setup, is de geheime setupinformatie. Als de toxic waste van bijvoorbeeld een Groth16-setup in verkeerde handen komt, kunnen aanvallers mogelijk valse bewijzen maken die toch als geldig worden geaccepteerd. Bij een private betalingsopzet kan dat er in het ergste geval toe leiden dat er saldo ontstaat dat volgens de normale regels niet had mogen bestaan.

Daarnaast bewijst een zk-SNARK alleen dat aan de regels van het circuit is voldaan. Fouten in het circuit, de provercode, de verifiercode, de gebruikte parameters of de koppeling met een blockchain kunnen daarom ernstige gevolgen hebben. Een cryptografisch correct bewijs helpt niet als de onderliggende regels verkeerd zijn ontworpen.

Ook privacy heeft grenzen. Bij shielded Zcash-transacties blijven bijvoorbeeld commitments en nullifiers zichtbaar op de blockchain, terwijl de informatie over de notes versleuteld blijft. Daarnaast kunnen publieke gegevens, timing, IP-adressen en andere netwerkmetadata soms alsnog informatie prijsgeven of verbanden zichtbaar maken.

Bij zk-rollups speelt weer een ander probleem. Een validity proof kan aantonen dat een batch correct is verwerkt, maar voorkomt niet automatisch dat een operator transacties vertraagt of gebruikers censureert. Ook risico's rond bridges en datatoegankelijkheid blijven bestaan.

Tot slot betekent zero-knowledge niet automatisch dat een systeem bestand is tegen toekomstige kwantumaanvallen. Dat hangt af van de concrete cryptografische constructie. Klassieke pairing-gebaseerde zk-SNARKs gebruiken andere cryptografische aannames dan bijvoorbeeld transparante STARK-systemen.

Conclusie

zk-SNARKs maken het mogelijk om te bewijzen dat een transactie of berekening klopt, zonder de privacygevoelige gegevens erachter prijs te geven. Daardoor zijn ze interessant voor private betalingen, privacygerichte applicaties en schaalbaarheid via validity rollups. Zcash is een van de bekendste voorbeelden van een blockchain die zk-SNARKs gebruikt om shielded transacties mogelijk te maken.

De kern is relatief simpel: een blockchain of andere verifier hoeft niet alle onderliggende gegevens te zien of de volledige berekening opnieuw uit te voeren, zolang hij een geldig cryptografisch bewijs kan controleren. Hoeveel privacy en veiligheid dat uiteindelijk oplevert, hangt wel af van het ontwerp van het systeem. Een zk-SNARK is uiteindelijk alleen zo betrouwbaar als het circuit, de gebruikte cryptografie en de integratie eromheen.