While we await the verdict in the Storm trial, its good to be reminded that shielded pools are just math, and not all that hard to understand. Anyone can implement one. So here's a thread with the basic intuition of how they work:

The goal is to build a system where all information in every transaction remains fully private to the users. We should expect nothing less from our transactional systems. This is the fundamental human right to privacy.

The problem is, if all information is private, how does the blockchain know the tx is valid? How does it know that the user actually has the funds they intend to send? That they're not double spending? The obvious answer is: zk-proofs. But is it really that simple?

Suppose you have an account with a balance of 10. You want to send 5 to Roman's defence. So you make a zk-proof that shows you have 10, and your transaction sends 5. Seems easy enough!

But wait! When you made a proof about having 10, that proof pertained to some state in the past, before the latest block where your tx got included. Perhaps since then, you've spent all the coins! How can you prove you still have 10, at the latest block?

This is actually quite tricky, and is why shielded pools don't really work with account based systems - there's no straightforward, reliable way to prove to a blockchain, in zk, the latest state in real-time. The solution? Use UTXOs. The famous "Unspent Tx Outputs" from Bitcoin.

With UTXOs, you don't have a single updatable account, you have individual "notes" that can only be spent once, in full (like a real coin). UTXO systems are kind of annoying to develop with in general, but this "spend once" property makes them very useful for shielded pools

In a UTXO system like Bitcoin, when you go to spend a UTXO, all the full nodes can check that the UTXO exists (it was created in the past) and it has not yet been spent. This is straight forward. But if all the data in the UTXO is encrypted, how can we check this?

Not only is the data encrypted, but we don't even want to reveal *which* UTXO is being spent. If we did, then whoever sent you the UTXO would know when you spent it. In an ideal shielded pool design, ZERO information is leaked by a transaction.

The core trick of shielded pools is to introduce a "nullifier" value that can be publicly revealed but is uniquely derived by the spender for each UTXO. To spend the UTXO, the blockchain checks the nullifier does not already exist. This enforces each UTXO can only be spent once

Now we can get back to our zk-proof. We simply have to prove that the UTXO we are spending actually exists on-chain, and that the nullifier we revealed for it is correctly derived from the UTXO we are spending. That's it!

In practice, this means that shielded pool systems typically keep two distinct Merkle trees. One contains the hashes of the UTXOs (UTXOs are often referred to as "notes", and their hashes as "note commitments"), and the other contains the nullifiers. Both trees are append only!

When a new note is created, its hash is stored in the note Merkle tree. The note itself is encrypted. When a user later goes to spend that note, they compute the nullifier for the note, and they make a zk-proof showing the note is in the Merkle tree and the nullifier is correct

The nullifier is revealed publicly and the chain checks it doesn't already exist in the nullifier Tree. It then gets stored there, so the note can't be spent again. No one can actually tell which note is being spent, since the original note is left alone in the note Tree!

There you have it, the basic design of all shielded pools today, including @Zcash, @TornadoCash, @penumbrazone, @namada, and more Of course there's lots more involved in shielded pool design. Stay tuned for more threads where we'll dive deeper into those mechanics

@AThryver @0xkaiserkarel Common misconception and arguably misleading use of the term “zk” here. See