zero-knowledge airdrop in which you enable anonymous governance where people's votes aren't impacted by other people's votes Where people can vote independently and they're only revealed once you want to tally the votes or once the voting period is over In order to do this to do a zero-knowledge airdrop you need a way to avoid double-claiming That is people can anonymously claim their tokens to an unlinked account But still there is some identifier that represents them that prevents them from claiming the same airdrop twice Or maybe we want to do an anonymous message board in which we know That each of the people cannot be identified But we know for instance that maybe the first poster is the same as the third poster or imagine We want to do anonymous voting within a large anonymity set such that the very first person to vote has the full power of every single person in this anonymity set or Really any civil resistant anonymous application so we thought about what we could use to Be this kind of tool that stops us from double-spending and it's kind of unique identifier of someone on chain and After talking a bunch on discord we decided to create a new z-canalifier scheme on ecdsa This is joint work with person labs geometry research and originally done at Xerox Park and MIT So to kind of clarify what exactly this nullifier is let's try to maybe go through some properties So if you want to avoid people from double-spending and we want each person to claim only once Then we need this property this this identifier I'll put it by this account to be unique that is everyone should have a different one We also want this value to be deterministic that is if I have some ethereum public private key pair I should only be able to generate one of these signals Finally the signal I generate should be verifiable without access to my secret key This is because in a ledger wallet or in a secure enclave It's not possible to even read the secret key or take it out of secure enclave We also don't want users copy pasting their private keys all over the place And finally we want this number or this scheme to be completely non interactive If you've heard of nullifiers before you might have heard of something like tornado cash or semaphore And the way that works is that as people sign up the anonymity set grows bigger and bigger and bigger However, the first person to use tornado cash or the first person to sign up for a semaphore group has zero anonymity Until more people join but if we want the full power of the entire anonymity set for the very first person We need the scheme to be non interactive that is there shouldn't be two phases like a sign-up phase and a utility phase So to understand these properties a little bit more one useful exercise is to go through some examples of schemes that may work Or may not work so imagine when we wanted someone to post this Deterministic value that identified themselves that stopped them from double claiming or stopped them from double voting that they use the hash of a deterministic ECDSA signature Now you might guess that this has all the properties we want. It's unique if you're signing a message a Deterministic signature there should only be one It's it's a non interactive anyone could generate a signature and blend into the anonymity set You don't need people to interact and sign up for the scheme first However, the issue with deterministic ECDSA signatures is that you cannot verify that a deterministic ECDSA signature was Generated with the correct deterministic randomness unless you have access to the private key That is deterministic ECDSA signatures are identical to non deterministic ECDSA signatures But the randomness is like the hash of the private key And so if you're trying to verify this on chain or in a ZK snark You would need the private key But it doesn't quite achieve what we wanted to achieve a second idea is this idea called a verifiable Unpredictable function or a unique signature now the vast majority of the schemes for these are on pairing friendly curves and Ethereum which is on ECDSA on secpe 256k one is not a pairing friendly curve So the vast majority of this literature is fairly inaccessible to us We could try something like hash of message come a public key You'd imagine this is unique every account every public key has a different value of this hash It's deterministic if you have a public key and there's some message say the app ID Then this hash is deterministic It's verifiable without your private key, and it's non interactive. You can give this hash without signing up in advance Now the issue with this is that it's a little bit subtle But it's actually possible to de-anonymize people who are using this for anonymity The way you do that is you can take the list of all 200 400 million private keys on Ethereum Calculate the hash values for every single one and match it up with this nullifier value on chain and boom De-anonymize a person who tried to use this as a unique identifier Maybe kind of getting inspired by this we can try something like hash of message comma secret key You'd imagine this is similar to the the public key case except You can't take everyone's secret key on chain because you don't know everyone's secret key So it's not possible to de-anonymize people in the same way But the issue is to verify something that's behind a hash You have to calculate the entire hash function inside the zero knowledge proof or inside whatever I don't need primitive you're using and we don't want to use this copy around their secret key And so this scheme isn't quite it. So finally we resolved on this scheme We use a hash of message comma public key to the power of secret key It's kind of similar to the other schemes But it turns out that it has this nice property that it's a DDH VRF or a decisional Diffy Hellman verifiable random function and Specifically what this means is that we can verify that this is actually calculated correctly without access to the secret key So to maybe summarize like what exactly the properties we are that we want so far Is that we want this deterministic function of a user's secret key that can be verified with only their public key and keeps them anonymous And the way we do this is we define a new deterministic signature scheme on ethereum So I'm going to try to go through what exactly the signature scheme is and so this is going to get a little bit mathy And I've tried to slightly color code the numbers that are the same so you can kind of correlate them across And although the math is a little bit difficult to understand on first glance I'll try to give you an intuition for why it achieves the properties that we want it to achieve So remember our nullifier was the hash of message comma public key to the power of secret key And so this value will be public it will be calculated inside the user's wallet Whether it's our metamask or their ledger or anything else and this value will stay public the entire time It will be posted on chain eventually for everyone to see These private outputs will be created by the wallet and given to the user These outputs if they were seen by the external world could de-anonymize a user For instance if you saw their public key you would obviously know who they are And so the idea is that these signals are kept to the user and the user can use them to generate a zk-snark So what the user does is once they have these signals you can think of this as Splitting the signature scheme into a deterministic part the nullifier and the non-deterministic part the private part The verifier simply checks these values are calculated correctly Now it's a little bit hard to dive through all this math So I'm going to try to give like a high-level overview of why we have this kind of C value floating around Now the reason we have this like C value floating around is that when you're taking a hash It's impossible to brute-force the output of the hash So you must know all the inputs that went into the hash This means that the person you can kind of think of this C commitment as a hash Commitment to these values of G to the R to our nullifier to our public key Then we calculate this value which is s which is based on the C value, which we know must have been calculated after C and Notice that this S value does not reveal the user's secret key although it has secret key in it It's blinded by a completely random number the check in the snark You'll also notice has no secret keys in it We only pass in these signals none of which you can use to derive the user's original secret key And the check that we do is effectively did the user calculate C in the correct order did they commit to their secret key Their public key and calculate their signature in a way that would have actually proved that they owned that secret key And finally the zk snark apart from checking that the nullifier was calculated correctly in a termistic fashion On the correct curve. We also check whatever public key check we want to do This allows us to verify that the public key is in fact acting correctly and has some unique identifier But now I have to verify that the public key is in fact allowed to interact with this protocol Maybe they're in a miracle proof Maybe they submit a miracle tribe Patricia proof that they are they satisfy some condition on chain And the idea that we would also lump this in with the verifier check in the zk snark So to summarize the wallet generate see signals the user plugs them into a zk snark and post the zk snark with the public nullifier Output on chain proving that they are allowed to interact with this protocol and a unique user who is still going to be kept anonymous Now interestingly when we were doing this work. We discovered this quantum secrecy interactivity trade-off now It turns out that semaphore is extremely quantum secure because it uses hashes But it's not in it is interactive meaning that you have two phases and the first people interact the interact with the protocol have no anonymity Our scheme on the other hand is fully non-interactive the very first person to use another fire We'll have the full anonymity of the entire anonymity set. However, it is not quantum secure and The way that you can kind of think about quantum adversaries in the situation is that a quantum adversary can effectively take discrete log and prime factorizations, but it can't undo hashes You can imagine that when we have a quantum computer with 2,000 signal qubits that can break all of Ethereum's public keys and derive their private keys in The actual situation of the chain continuing. This is completely fine users can sign There are new key with their old key before Contents of pharmacy occurs and the entire chain can move seamlessly to a new quantum resistant system However, if you can derive all the user's secret keys Then if you remember the trick we did in the very beginning where we calculate the hashes message come a public key for all the users and De-anonymize people we can do the exact same thing with this quantum adversary calculated secret key What I'm adversary simply calculates every secret key for every private for every public key on Ethereum Calculates the nullifiers for every single one of these keys and matches them up with the anonymous signal and so interestingly any future quantum adversary can break past anonymity and The issue is that actually any deterministic nullifier scheme that has the properties that I defined in the beginning has its vulnerability Because if you source randomness from only the secret key that means the quantum adversary can derive it as well And so you have to source randomness beyond the secret key which requires users to remember that value Which means you need to have a password so to kind of get a better intuition for like whether this actually matters or not There is the the predictions of quantum researchers very extremely widely some researchers have mentioned They think it's going to come as soon as 30 years signal cubits that can break ecdSA some researchers think Somewhere around a hundred years and some think that because of the noise problem. It's theoretically impossible and it will never happen It's a little unclear as of right now we have about 20 signal cubits and we need over 2,000 to break ecdSA So I've written a short mental model that you can read once you look at the link on the slides Which describes kind of how I think about this quantum mental model of how these systems are going to evolve And whether or not we should be worried about it, but I think for now the decision that we made is that it makes more sense to not be worried about quantum oracles because as long as the Protocols are transparent that you will be denomized in something between 30 and 100 years The idea is that most people probably won't care because by that time for instance even governments Declassified their secret documents in this kind of time frame So to understand more how this nullifier scheme is going and if you can use it yourself We have a paper in which we proved all the security properties of this nullifier scheme We have a blog post that's going to be coming up on the persona labs blog soon And we also have a proof of concept in rust and in a metamask snap finished The next step is to put it into a ton of other wallets into Ledger into burner wallets into metamask core creating ERC standard for people to use this scheme so that we can have unique anonymity across the board and to potentially Write in appendix when it f rfc to make it a complete standard across all of cryptography If you're interested in seeing more about the code This link will link you to our github repo where we have all the open-source code We'll be linking to all the slides here as well along with a quantum mental model And our Twitter if you want to learn more You guys are interested in this want to use a scheme or are curious about Studanimity I'd be happy to talk and it would be really fun to see where the scheme can go And if anyone has any questions about understanding the scheme or Thoughts on where a can or can't be used. I'd be happy to take any questions for the next five or ten minutes Test, okay. How is the scheme cold? So right now the scheme is called just a zk nullifier because we think this is the Kind of most straightforward way to describe what is going on, but I'm open to any other name suggestions I think it was a question in the front Can you like explain probably maybe using an example how like this non interactive Is like it's like seen in practice like in terms of like using the scheme Like maybe like an airdrop like can you explain like how that system would work? How like user were interact and like kind of that maintain that property? Yeah, that's a great question I can maybe go through the kind of the whole airdrop scheme and try to describe Why it wouldn't be practical with something like semaphore, but why it could be practical with something like the nullifier So if you imagine the semaphore scheme for the airdrop the way it would look is that people would first have to sign up to receive the airdrop And this is the people have to submit their semaphore commitment to some either like an on-chain directory or an off-chain list and The issue with this is that people can then civil attack this airdrop very easily because they know that an airdrop is going to Be coming and this is a way to gain eligibility for it And so because they have this two-step process people can spam whatever Mechanism it is that they're using to determine who is eligible and who is not Resulting this being a somewhat impractical solution You can also imagine that if you didn't have a two-phase process We're I said people could sign up for the semaphore keys whenever and claim whenever and the very first person to claim the airdrop We'll sign up for the semaphore key You would see only one semaphore key in the list of all semaphore keys And then that person would claim their airdrop and see would know that the person who posted that proof Must have been the person who claimed the airdrop and so there's all this small anonymity set is Is not ideal if you're trying to maintain perfect anonymity for everyone in the set The way the nullifier scheme would work is that when you claim the airdrop you prove that you have another fire for a message like I am claiming the ZK airdrop and the verifier would prove that you in fact signed that message that you created your deterministic nullifier correctly and Would allow you to claim the airdrop and then add that nullifier to a block list from ever claiming again And so what would happen is a very first person to claim no one would know who they are out of the entire set of all the keys that are eligible for the airdrop Where does the like NFT eventually end like it's an Ethereum address Versus like is it like the things are happening on chain or it's like an off-chain process or like Just trying to understand that. Yeah, that's a great question Those who didn't hear the beginning the question was basically how does the ZK airdrop actually implemented and the idea is that what you Would do is you would prove that you own an account that is in the Merkle tree of eligible addresses for this ZK airdrop you would Generate a summer for nullifier for that scheme in the original case And then you would claim it to a completely unlinked unused account that has never had any transaction on Ethereum And then all the fire scheme you do a similar thing You would prove you have an account in this Merkle tree you would prove ownership without account You would prove the nullifier via the deterministic nullifier scheme and similarly the tokens would go to a completely new fresh Ethereum account There's no history on it and it's effectively anonymous Yeah, that's a great question though Yeah So just to expand on the previous question like a concrete example So you wanted to like airdrop an NFT an NFT to Anyone who has a crypto punk and but you want people to be able to claim it without revealing which punk they are With it semaphore or anything that's like a two-step your anonymity side is only going to be the amount of people who like sign up for the semaphore and With this the anonymity even if it's just two people that end up claiming the NFT They have the full anonymity set of like all punk on all punk holders if that makes sense And it's going to like a new address not to the one that has the punk Hello, all right, so I'm wondering can you expand a bit upon if you if you use this scheme for a sort of a Multi-step protocol where it's not just maybe a tornado cash deposit and withdrawal or a claim scheme, but you continue where you maybe have some sort of Transfer of private assets within the anonymity set. Do you keep that anonymity and and how does that work? Yeah, so the the way darkpool transfers would kind of work with this anonymity with this nullifier is that The way most people enter a dark pool is I send their assets to like a specific smart contract And so you already know that the enemy says limited to everyone who has ever interacted with a smart contract and one thing you could do is you could use something like semaphore and if you interact with a smart contract the Guarantee that you have to sign up for a semaphore key So because the end you said is already limited by something like an on-chain interaction The nullifier wouldn't add additional anonymity because already limited by the chain interactions However, what it could do is prevent you from having to memorize secret notes So for instance with tornado cash you have to download a string and remember it forever and if you lose that string then you lose your money, but What you could do with this scheme is that instead of having to memorize a tornado cash note You just remember the amount of money you've got and then you could say okay I got one ETH so I'm going to sign a message saying tornado cash one ETH And I know that the nullifier that it creates will be a valid note for my deposit and the contract can simply validate that and so it can help saving memory or losing Strings for anonymous money, but it wouldn't add significantly additional anonymity if the original scheme was implemented With the darkboard correctly sending to the contract. Yeah, that's a great question though Hey, hi I'm pretty sure like many of us would have read about nullifiers for the first time in Vitalik's article the one with like privacy applications for GKS now and Like I did not understand it completely, but I thought it was Vitalik who wrote it so it must be true so So can you like just give a brief difference between that nullifier technique and your nullifier technique For us to compare right so the nullifier technique that is classically referred to in mostly ZK snark posts Is another part technique that exists which is kind of why Halo 2 defined a number of years ago And it's kind of evolved into being this semaphore type scheme in which a nullifier just represents that you can't double-claim or double interact with a specific protocol because that nullifier nullifies your ability to do so That usually get added to a smart contract or something and then when you interact with that in the future It would notice that you've already interacted with it before and then stop that transaction from going through So the scheme that likely is being referred to that in that post is likely a semaphore type scheme or a Sign-up type scheme in which this nullifier is like a hash of some string Which again would have to be interactively generated I mean so when I when I say this kind of semaphore side or this like interactive side that's larger than the classical nullifier than I'm referring to Thank you for the talk. I had a general question I'm kind of about coming back to the example of the token gated a drop So if you either use like this you can nullifier or semaphore to generate a proof that an address is eligible for an air job based on I'm owning an NFT in a set for example How does that respond to updates for example when you transfer the NFT afterwards since the nullifier is only tied to the address Could you then transfer that NFT to different address and create another nullifier and again qualify for their job? Yes, it's a great question. So The way that you would solve this kind of multiple qualifying for the air drop problem Is that when you define when you release this air drop? You define like a strict set of keys that are eligible for this air drop It can be say like people who owned a certain NFT at a certain block in which case there's a finite number of addresses I can claim that or it can be so anything you could prove in the Ethereum storage Miracle Patricia try or it could be like a specific just a list of addresses in a Miracle tree like a standard air drop is done So the idea is that even the the reason the nullifier is used is it would only suffice for this claiming step Because once you've claimed the nullifier to an account and you've claimed this NFT or air drop or whatever to this account that account can do Whatever it wants with that information now It's it's come from a completely anonymous source and so it can it can go wherever and it'll continue to maintain the anonymity So the you continue to trans transact the NFT or you see 20 But you just wouldn't be interacting with the original airdrop contract ever again So you wouldn't need a nullifier in the future Yeah, okay good. So this is probably a silly question When people redeem it right they have to Provide some gas so the gas must be coming from some account even even though we have all this anonymity is probably hide the Adgers that's going to receive it, but when people provide the gas This transaction actually links the account that's receiving the NFT versus the account having the gas So it's still revealing like something for me. Yeah, that's a great question The question was basically how do you pay for the gas? Without de-anonymizing yourself and there's kind of two main ways to do this one is The airdrop contract itself will pay for the gas So the way this would work is when you claim the airdrop contract would record the amount of gas being used in the transaction There would be a certain bank inside the contract to pay for that gas Plus a little bit extra and so the idea is that you could send your claim transaction on chain Or To a private mempool an MEV searcher would actually be incentivized to claim this transaction act as your relayer and decentralized manner because they're getting compensated for it because the Contract is calculating and reimbursing them more than they would have paid for the gas There's one way to do it It's like a way to do it with something like account abstraction where you can again have a third party pay for the gas Usually out of the contract this can happen with say the contract doing an atomic swap with say the token that is giving you and ETH to pay for the gas Similarly reimbursing the the front-running relayer effectively or you could send it to like Something like a keeper network, which would incentivize which is basically a place where MEV searchers can post Or people can post any of the ideas and MEV searchers can take them you could use a mempool or you could use a kind of a private Centralized or decentralized method to do that. Yeah, that's a great transaction. That's a great question though Thank you so much a juice big room for plus


I don't typically create swap partitions or swap files on my main production machines. And the reason I don't do that on my main production machines is because they have so much RAM in them. My current main production machine has 64 gigs of RAM. So even if I created a swap, I'm never going to use it because I'm never going to use up all 64 gigs of RAM on this machine. It's never going to happen. But I try to remember to create swap partitions on video when I do my Linux installation guides. And the other day I did an Arch Linux installation guide. And I created a swap partition on that video just to show you guys how it was done. But people pointed out, hey, you've never shown us how to create a swap file. What if we prefer to create a swap file rather than a swap partition? Can you show us how to do that? And that's a great idea. Because I currently don't have a swap partition or a swap file on my main production machine, I'm going to show you guys how to create one. It's actually very easy. So let me switch over to the desktop here. I'm going to launch a terminal and let me zoom way in so you guys can see exactly what's going on here. Now, the first thing we need to do is create our swap file. And the program you need to use to create the swap file is the dd command. So with root privileges, of course, we need to sudo ddspace. And then set these values if equals if is the input file. So where are we taking input from and where are we writing it to, which of course will be the output file. So if input file equals slash dev slash zero space, OF equals for the output file is going to equals slash swap file, all one word, because the swap file needs to be in the root directory. The root directory, of course, is the slash symbol. So it's going to be at slash swap file space.  And for me, I'm going to set BS equals one capital M for one megabyte space and then count equals and I'm going to do 1024 because I want to create a one gigabyte swap file. How does that equal one gigabyte? Well, the dd command, we told it to use one megabyte chunks here. That's what BS equals one megabyte is. How many one megabyte chunks should DD use? They should use 1024 of them, 1024 one megabyte chunks equals one gigabyte. Hope that makes sense. Then, of course, it's going to ask for your root password and it was created successfully there. Now, swap files are very particular about their permissions. They have to be set to file permission 600. How do you do that? Well, you do sudo space chmod space 600 space slash swap file. And that sets the swap file to 600 for the permissions. If you don't do that, the swap file will complain and it will actually tell you this in the terminal. It will be like, hey, set the swap file to permission 600. So it's best to go ahead and take care of it right now. Now, just because we use the DD command to make that slash swap file, it's not really a swap until we make it a swap. How do you do that? sudo space MK swap for make swap space slash swap file. And you see, we get some output there. It gives us a UUID number, which we typically use UUID numbers to add something to the file system table. The F stab. You don't actually have to use UUID numbers with swap files. So we actually don't need this number. The next thing we need to do is turn the swap on. So do a su space swap on space slash swap file. And we don't get any output. But that's a good because no output means it worked correctly. We could verify it with swap on space dash dash show. And you see, we have a slash swap file and it is one gigabyte in size. Finally, we need to add our swap file to our F stab, our file system table. So I'm going to use VIM for this. But if you want to use nano or whatever editor you're comfortable with, it doesn't matter, but you need to be root or have root privileges. So I'm going to do sudo space VIM space slash Etsy slash FS tab and I hit enter.  And then the first value you see is usually a UUID. But that's only for partitions. Remember the swap file is really just a file UUID numbers are not used for files. So this the file system column actually just needs to be the path to the swap file. So do slash swap file space and then I'm going to space over to this value here, which is the mount point for the mount point. I'm just going to write the word none and then I'm going to space over and then this is the type. It needs to be swapped. I'm going to space over and then this next options category. I'm just going to put defaults and I'm going to space over and where you see the two numbers here, it can just be zero space zero. And that should be all I need to do. I'm going to do an escape here in VM and then colon WQ for write and quit. And if everything worked out, all right, I should have swap when I reboot. So it was very easy to add a swap file. It's very easy to add a swap file when you're installing your Linux distribution. But even after the fact, you know, I've had this instance of Rco running for several weeks on my machine. I didn't create a swap partition or swap file when I did the installations. But you can see going back and adding a swap files very easy. In contrast, going back after the fact and trying to add a swap partition is a real nightmare. It's a headache because you don't want to go back after the fact and try to partition a drive because you can lose all your data. It's not worth it. I wouldn't try that. But when you're dealing with files, it's very easy to go back after the fact and just create a file or delete a file. Same thing with deleting a swap file. It's very easy to go back after the fact and delete one. As a matter of fact, I can show you how to delete that swap file I just created. The first thing you need to do is turn swap off because you can't delete a swap file if the swap is turned on. Well, let me show you. If I tried to do this, sudo rm for remove space slash swap file, it's going to give me an error. It says operation not permitted. The reason it's not permitted, you can't remove the swap file while swap is turned on. So let's turn swap off. I'm going to do a sudo swap off all one word space dash v. Give it the v flag space and then slash swap file. So we turn to swap off and now if I up arrow a couple of times to get back to that remove command sudo rm slash swap file. That actually works. If I do a ls on root, you will see in my root directory, I actually don't have a swap file. So we deleted that. And that's really all you need to do. Well, there's one other thing you should do.  So I need to do a sudo vm space slash etsy slash fstab.  And just like that, that swap file that we had created and activated, we just deactivated it and removed it from our system. So swap files. I love them. They're much easier to work with than swap partitions. Now before I go, I need to think a few special people. I need to think Michael, Gabe, Corbinian, Mitchell, Devin Fran, Arch 5530, Akami Channel Chuck, Claudio, Dylan, George, Kelly Devils, Louis Paul, Scott and Willie, these guys. They are my highest tiered patrons over on Patreon. They are the producers of this episode without these guys, I wouldn't have been able to create and delete a swap file on camera. Well, I could have done it without them, but these guys are a big help. I also want to thank each and every one of these ladies and gentlemen, all these names you're seeing on the screen. These are all my supporters over on Patreon because this channel is supported by you guys, the community. You would like to support my work. I hope you considered doing so. Look for DistroTube over on Patreon. All right, guys. Peace.