Terwijl we wachten op het vonnis in de Storm-rechtszaak, is het goed om herinnerd te worden dat afgeschermde pools gewoon wiskunde zijn, en niet zo moeilijk te begrijpen. Iedereen kan er een implementeren. Dus hier is een draad met de basisintuïtie van hoe ze werken:

Het doel is om een systeem te bouwen waarin alle informatie in elke transactie volledig privé blijft voor de gebruikers. We mogen niet minder verwachten van onze transactiesystemen. Dit is het fundamentele mensenrecht op privacy.

Het probleem is, als alle informatie privé is, hoe weet de blockchain dan dat de transactie geldig is? Hoe weet het dat de gebruiker daadwerkelijk de fondsen heeft die ze van plan zijn te verzenden? Dat ze niet dubbel uitgeven? Het voor de hand liggende antwoord is: zk-proofs. Maar is het echt zo eenvoudig?

Stel dat je een account hebt met een saldo van 10. Je wilt 5 naar de verdediging van Roman sturen. Dus maak je een zk-proof die laat zien dat je 10 hebt, en je transactie stuurt 5. Lijkt eenvoudig genoeg!

Maar wacht! Toen je een bewijs leverde dat je 10 had, betrof dat bewijs een bepaalde staat in het verleden, vóór het laatste blok waarin je transactie werd opgenomen. Misschien heb je sindsdien al je munten uitgegeven! Hoe kun je bewijzen dat je nog steeds 10 hebt, in het laatste blok?

Dit is eigenlijk best lastig, en daarom werken afgeschermde pools niet echt met op accounts gebaseerde systemen - er is geen eenvoudige, betrouwbare manier om in zk aan een blockchain te bewijzen wat de laatste staat in real-time is. De oplossing? Gebruik UTXO's. De beroemde "Unspent Tx Outputs" van Bitcoin.

Met UTXO's heb je geen enkele updatable account, je hebt individuele "briefjes" die maar één keer volledig kunnen worden besteed (zoals een echte munt). UTXO-systemen zijn over het algemeen een beetje vervelend om mee te ontwikkelen, maar deze "eenmalig besteden" eigenschap maakt ze zeer nuttig voor afgeschermde pools.

In een UTXO-systeem zoals Bitcoin, wanneer je een UTXO wilt uitgeven, kunnen alle full nodes controleren of de UTXO bestaat (het is in het verleden aangemaakt) en of het nog niet is uitgegeven. Dit is eenvoudig. Maar als alle gegevens in de UTXO versleuteld zijn, hoe kunnen we dit dan controleren?

Niet alleen zijn de gegevens versleuteld, maar we willen zelfs niet onthullen *welke* UTXO wordt uitgegeven. Als we dat deden, zou degene die je de UTXO heeft gestuurd weten wanneer je het uitgeeft. In een ideaal ontwerp van een afgeschermde pool wordt er door een transactie GEEN informatie gelekt.

De kerntruc van afgeschermde pools is het introduceren van een "nullifier"-waarde die openbaar kan worden onthuld, maar uniek wordt afgeleid door de spender voor elke UTXO. Om de UTXO uit te geven, controleert de blockchain of de nullifier nog niet bestaat. Dit zorgt ervoor dat elke UTXO slechts één keer kan worden uitgegeven.

Nu kunnen we teruggaan naar onze zk-proof. We moeten eenvoudigweg bewijzen dat de UTXO die we uitgeven daadwerkelijk on-chain bestaat, en dat de nullifier die we daarvoor hebben onthuld correct is afgeleid van de UTXO die we uitgeven. Dat is het!

In de praktijk betekent dit dat afgeschermde poolsystemen doorgaans twee verschillende Merkle-bomen bijhouden. De ene bevat de hashes van de UTXO's (UTXO's worden vaak "notes" genoemd, en hun hashes "note commitments"), en de andere bevat de nullifiers. Beide bomen zijn alleen append-only!

Wanneer een nieuwe nota wordt aangemaakt, wordt de hash ervan opgeslagen in de Merkle-boom van de nota. De nota zelf is versleuteld. Wanneer een gebruiker later die nota wil uitgeven, berekent hij de nullifier voor de nota en maakt hij een zk-proof die aantoont dat de nota in de Merkle-boom staat en dat de nullifier correct is.

De nullifier wordt openbaar onthuld en de keten controleert of deze al bestaat in de nullifier Tree. Het wordt daar opgeslagen, zodat de nota niet opnieuw kan worden besteed. Niemand kan eigenlijk zien welke nota wordt besteed, aangezien de originele nota onaangeroerd blijft in de nota Tree!

Daar heb je het, het basisontwerp van alle afgeschermde pools vandaag de dag, inclusief @Zcash, @TornadoCash, @penumbrazone, @namada, en meer. Natuurlijk is er veel meer betrokken bij het ontwerp van afgeschermde pools. Blijf op de hoogte voor meer threads waarin we die mechanismen dieper zullen verkennen.

@AThryver @0xkaiserkarel Veelvoorkomende misvatting en mogelijk misleidend gebruik van de term “zk” hier. Zie