Medan vi väntar på domen i Storm-rättegången är det bra att bli påmind om att avskärmade pooler bara är matematik och inte så svåra att förstå. Vem som helst kan implementera en. Så här är en tråd med den grundläggande intuitionen om hur de fungerar:

Målet är att bygga ett system där all information i varje transaktion förblir helt privat för användarna. Vi bör inte förvänta oss något mindre av våra transaktionssystem. Detta är den grundläggande mänskliga rättigheten till integritet.

Problemet är, om all information är privat, hur vet blockkedjan att tx är giltigt? Hur vet den att användaren faktiskt har de medel de tänker skicka? Att de inte spenderar dubbelt? Det uppenbara svaret är: zk-bevis. Men är det verkligen så enkelt?

Anta att du har ett konto med ett saldo på 10. Du vill skicka 5 till Romans försvar. Så du gör ett zk-bevis som visar att du har 10, och din transaktion skickar 5. Verkar lätt nog!

Men vänta! När du gjorde ett bevis om att du har 10, hänförde det beviset till något tillstånd i det förflutna, före det senaste blocket där din tx inkluderades. Kanske har du spenderat alla mynt sedan dess! Hur kan du bevisa att du fortfarande har 10, vid det senaste blocket?

Detta är faktiskt ganska knepigt, och det är därför skärmade pooler inte riktigt fungerar med kontobaserade system - det finns inget enkelt, pålitligt sätt att bevisa för en blockkedja, i zk, det senaste tillståndet i realtid. Lösningen? Använd UTXOs. De berömda "Unspent Tx Outputs" från Bitcoin.

Med UTXO:er har du inte ett enda uppdaterbart konto, du har enskilda "anteckningar" som bara kan spenderas en gång, i sin helhet (som ett riktigt mynt). UTXO-system är lite irriterande att utveckla med i allmänhet, men denna "spendera en gång"-egenskap gör dem mycket användbara för skärmade pooler

I ett UTXO-system som Bitcoin, när du går för att spendera en UTXO, kan alla fullständiga noder kontrollera att UTXO finns (den skapades tidigare) och att den ännu inte har spenderats. Detta är enkelt. Men om all data i UTXO är krypterad, hur kan vi kontrollera detta?

Data är inte bara krypterad, utan vi vill inte ens avslöja *vilken* UTXO som spenderas. Om vi gjorde det skulle den som skickade UTXO till dig veta när du spenderade den. I en idealisk skärmad pooldesign läcker ZERO-information ut av en transaktion.

Kärntricket med avskärmade pooler är att introducera ett "nullifier"-värde som kan avslöjas offentligt men som unikt härleds av spenderaren för varje UTXO. För att spendera UTXO kontrollerar blockkedjan att nullifieraren inte redan finns. Detta tvingar varje UTXO att bara spenderas en gång

Nu kan vi återgå till vårt zk-proof. Vi måste helt enkelt bevisa att den UTXO vi spenderar faktiskt existerar på kedjan, och att den nullifier vi avslöjade för den är korrekt härledd från den UTXO vi spenderar. Det är allt!

I praktiken innebär detta att skärmade poolsystem vanligtvis har två distinkta Merkle-träd. Den ena innehåller hasharna för UTXO:erna (UTXO:er kallas ofta för "anteckningar" och deras hashvärden för "anteckningsåtaganden"), och den andra innehåller nullifierarna. Båda träden är endast append!

När en ny anteckning skapas lagras dess hash i Merkle-trädet för anteckningar. Själva anteckningen är krypterad. När en användare senare går för att spendera den anteckningen, beräknar de nullifieraren för anteckningen, och de gör ett zk-proof som visar att anteckningen finns i Merkle-trädet och att nullifiern är korrekt

Nullifieraren avslöjas offentligt och kedjan kontrollerar att den inte redan finns i nullifier-trädet. Den lagras sedan där, så att anteckningen inte kan spenderas igen. Ingen kan faktiskt säga vilken anteckning som spenderas, eftersom den ursprungliga anteckningen lämnas ensam i anteckningsträdet!

Där har du det, den grundläggande designen för alla skärmade pooler idag, inklusive @Zcash, @TornadoCash, @penumbrazone, @namada och mer Naturligtvis finns det mycket mer involverat i design av avskärmade pooler. Håll ögonen öppna för fler trådar där vi kommer att dyka djupare in i dessa mekaniker

@AThryver @0xkaiserkarel Vanlig missuppfattning och utan tvekan missvisande användning av termen "zk" här. Se