Understanding Tornado Cash: DeFi Privacy via Zero-Knowledge Proofs

[00:00:00]in this video i'll explain how tornado cast protects privacy suppose that alice sends 100 ether to another address this transaction is recorded on the blockchain because data on blockchain is public data everyone in the whole world now knows that this address 0xb1b1b1 now has 100 ether now if people know that this 0xb1b1b1 address also belongs to alice then people around the world can conclude that alice still has 100 ether likewise if this receiver address belongs to bob then everyone in the whole world knows that bob now has 100 ether so how does tornado cash protect privacy how is it able to hide the link from the sender to the receiver first let's take a look at how deposit works in tornado cash before she deposits into tornado cash she'll have to pick two random numbers a secret and another fire and then she computes the hash of these two random numbers to deposit into tornado cash she'll send the one eater and the hash of the secret and the nullifier here we'll say it is 0x123 the ether gets stocked in tornado cash contract in this hash call the commitment is also recorded into the smart contract this hash is later going to be used to withdraw this one ether from tornado cash users are always depositing and withdrawing from tornado cash here we'll say that charlie the cat also deposits one ether and his hash is 0x456 the eater gets talked into tornado cash and the 0x456 is also recorded bob the bear also does the same send one e3 and his hash is 0x789 ether gets locked and his hash 0x789 is also recorded into the smart contract you might have noticed that alice bob and charlie all deposited one meter why is it that everyone is depositing one ether why can't alice deposit two ether and bob deposit three ether and charlie deposit 100 liter to answer this question let's imagine that alice has 100 ether bob has one meter and charlie has one ether and they all deposit into a tornado cache later an anonymous user comes along and withdraws 100 ether we know that the only person that deposited 100 ether was alice so we can conclude that alice still has 100 ether so to increase anonymity everyone has to send the same amount of ether into tornado cash this way there is no one user that stands out from the rest of the crowd so that is why everyone has to deposit the same amount of either so now let's see how withdrawal works in tornado cash first i'll explain how it's done incorrectly we'll first withdraw in a way that reveals the identity of the withdrawal and then we'll see how to fix this problem so that the identity of the withdrawal is not revealed so the wrong way to withdraw is that the withdrawal reveals the secret and the nullifier the smart contract checks that the hash of the secret and the modifier is equal to 0x123 and the sas your x123 is recorded into the tornado cash smart contract if it is then tornado cash will send the one ether back to the caller but in this process it reveals the identity of the person who withdrew how is it that the identity of the withdrawal is revealed let's take a look well we know that alice deposited with a hash 0x123 later on an anonymous user came along and revealed a secret and denudifier such that the hash of the secret and the nullifier is equal to 0x123 but because the hash function is a one-way function this means that the only person that knows the secret and the nullifier that hashes to 0x123 is alice this is how the identity of the user is revealed on withdrawal so how can we fix this problem well we know that revealing the secret and the nullifier reveals the identity of the withdrawal if somehow there is a way to prove that i know a secret and a nullifier such that the hash of the secret and the nullifier is recorded onto the tornadocast smart contract without revealing the actual secret and the nullifier so the anonymous user will send the proof that say i know a secret and a nullifier such that the hash of the secret end of nullifier is recorded onto the tornado cash smart contract and this proof does not reveal the actual secret and the nullifier this means that the anonymous user will stay anonymous the smart contract verifies that the proof is valid but it wouldn't know if the proof is for 0x123 0x456 or 789 in other words the proof does not reveal the identity of the anonymous user this is called zero knowledge proof being able to prove that you know some information without revealing anything about the actual information the math behind zero knowledge proof used by tornado cache is called dk snug now notice that when we deposit and when we withdraw we select two random numbers the secret and another fire what is this nullifier and what does it do when an anonymous user withdraws from tornado cash tornado cash doesn't know who is withdrawing the withdrawal can be alice bob the bear or charlie the cat tornado cash doesn't know who is withdrawing this means that tornado cash cannot keep track of who has withdrawn their deposits so a clever hacker would say okay tornado cash doesn't know who if true so what i'm gonna try to do is deposit once and then withdrawal multiple times the hacker sends a proof to withdrawal the proof checks out and the hacker gets one ether the hacker sends the same proof again and then withdrawal one neef again in total the hacker deposited one either but he was able to withdraw two either to prevent this double spend meaning that you deposit it once but you can withdraw multiple times when you send the proof to withdraw you'll also have to submit the hash of the nullifier and inside the proof of the dk snark it would check two things it would check that the hash of the secret and the nullifier is recorded on the tornado cache and it will also check that the hash of the nullifier is equal to the nullifier once the proof checks out tornado cache records that the hash of the nullifier has been spent the anonymous user gets the one ether back and if the same user tried to withdraw again using the same proof then it will fail because the hash of the nullifier has already been spent and it's recorded on the tornado cast smart contract so that is the purpose of the nullifier to prevent double spending now let's see how tornado cache records the hash that is provided by the user when they deposit the way the hash is recorded in tornado cache is by merkle tree actually merkle tree looks like a upside down tree the berry top is called the root and the very bottom elements are called the leaf let's quickly go over how merkle tree is built we start with an array where each element is a hash of some data we take the first two element and compute the hash we take the next two element and also compute the hash we continue this process until all elements has been hashed once the bottom elements has been paired together and then hashed we do the same again so we take the pair of hashes and then hatch them again and then do the same for the next two hashes we continue this process until there is only one hash this is called the merkle root in tornado cache the merkle tree is initialized like this on the very bottom so each leaf is a ketchup 256 hash of the string tornado to show how insertion works in the merkle tree of the tornado cache this is going to get messy so i'm going to re-label these hashes we'll say that the very bottom hash is g0 on the next level they're all named z1 and on the next level the name g2 since the tree has three levels we'll refer to the mercury as g3 this is level zero this is level one this is level two and this is level three okay so let's see how to insert into the tornado merkle tree before anyone deposits this is the merkle tree of the tornado cache we'll say that the first person to deposit selected a secret we will name it s0 and the nullifier n0 hash it together and come up with a commitment named c0 when the first user deposits the commitment so the hash of the secret and the nullifier of that user is inserted as a first element of the array so we'll need to update the hash above and once that's done we'll also need to update the hash above it and then finally we'll need to update the hash of the merkle root and that is what the merkle tree will look like when the first user deposits let's take a look at how the merkle tree will change when the second user deposits so the second user will come up with a secret we'll name it s1 and the nullifier we'll name it n1 and the hash of s1 and n1 we'll name it c1 c1 is inserted into the next available opening which is right next to c0 so we'll need to recompute the hash above and then at level 2 we'll need to recompute the hash and finally we'll need to recompute the merkle root this is how the merkle root will change when the third user deposits so we insert c3 over here and this will update the hash over here and update the hash over here and finally the merkle root over here and likewise for c4 it will update the hash over here the hash over here and the hash over here this is what the merkle tree will look like when the fifth user deposits and the six and so on so that is how merkle tree insertion works in tornado cache so once our hash is recorded into the tornado cache merkle tree how do we prove that our commitment so the hash of our secret and the nullifier is in the merkle tree let's say that a hash is c3 and we want to prove to tornado cache that our hash is recorded into this merkle tree how do we do it the basic idea is that we will need to provide a list of hash and when we hash them together it will match the merkle rule hash so starting from c3 we'll need to provide c2 and having these two hashes we can recompute this hash we'll need to provide this hash and having these two hashes we can recompute this hash and finally if we provide this hash then we can recompute the merkle root so these are the list of hashes that we will need to provide in order to prove that c3 is recorded into the merkle root c3 c2 in this hash over here in this hash over here and if we provide the correct hashes then it should match the merkle root of the tornado cache this proof is fed into the gk snarks and the gk snark will generate the zero knowledge proof meaning that we are proving that c3 is in the merkle tree of tornado cache without actually revealing our hash c3 so once we have the proof we send it over to the tornado cache and if the proof checks out meaning that we are able to construct the correct merkle root of tornado cache then we are able to withdraw the one ether i was surprised to find out that zk snark is already available in solidity let me explain how the smart contracts of tornado cash are built the tornado cash smart contract has three distinctive parts the part that manages if going in and going out the merkle tree that keeps track of the deposit hashes and the dk snark bear fire contract that verifies that the withdrawal has a valid proof for the merkle tree this zk snark bear fire smart contract is built using two tools the first library is called circum and using this library what's called the arithmetic circuit is written this arithmetic circuit contains logic to prove that a hash is included in this circle tree now once this arithmetic circuit is written we pass it on to another tool called snot js and using snark js it will automatically create a dk snark smart contract further study is required on my part to explain to you guys how this part works so hopefully i'll be able to make some videos dedicated to gk snark and how to create zero knowledge proof smart contracts so stay tuned other than that thanks for watching and see you later