ZKwormholes: Account Based Privacy by JimJim || EPS 2025 Workshop

[applause] All right, thank you. I'm going to talk about ZK wormholes. Uh ZK wormholes is a method to obtain plausible deniability on Ethereum. Uh privacy is good, but privacy is even better with plausible deniability. And I'm going to uh also give you a perspective on the accountbased way of doing it.

Uh so what is plausible deniability and why do we need it? So here you can see Jim Jim. This is me made a transaction with tornado cache. Uh tornado cashache is a privacy protocol that ended up on the sanctions list in the US. Uh and a lot of US-based DeFi apps for instance Maker DAO were uh blocking people who use tornado cash including me.

And if you don't know, maker DAO allows you to create a loan, a leverage loan. Uh, and during uh during the during the OA extensions, ETH was crashing and I had a loan open and my uh you I was blocked from using the UI and I had to panic email the maker dow people to unblock me so I can close my loan. So yeah, that that really sucked. Um, but in ZK Wormals you get around this. Every Zika wormal trans uh transfer that goes from public to private looks exactly the same as normal public transfers.

So no one will ever know that I did something uh with privacy. How do you do that? Well, it's a funny little trick. Uh there basically is no private key and I love you. Uh the idea is to create an Ethereum address the wrong way.

So here you can see uh the burn address is just a presiding hash of a secret. Normally a Ethereum address is a hash of a public key. Um but we [ __ ] it up. Uh the nice thing is that if you just hash something, it looks random just like any other Ethereum address. Uh and if you send money to it, it's gone.

But we can prove it's gone. And then we uh asked the protocol uh to allow us to mint new tokens out of thin air because we have just proven it. It's uh burned the anonymity set. So in tornado cache the anonymity set is pretty simple. Everyone who deposits is part of the anonymity set.

But in ZK Wormals, it's really interesting because everyone who plausibly could be using privacy using ZK Wormals could be part of the anonymity set. So onchain, what it looks like is just someone sending money to a fresh account that never made a transaction. And actually, Coinbase creates such accounts. They're not trying to do anything with privacy. They just have accounts that never make transactions called cold storage wallets.

and they're participating in an anonymity set. They're making the privacy of it of uh this protocol better for free. Uh so I'm actually not the original author of this EIP. Uh and uh there's still some UX issues we want I want to solve and which I'm going to demonstrate how to solve them. Um the biggest thing is uh if you make one of those burn address which is just a a hash of a secret uh if you then remint those tokens somewhere else uh privately uh that address becomes nullified which means you cannot reuse it which means if I spend my money privately and someone sends money to that burn address again it is actually burned and it's actually gone.

So that really sucks. Uh and there's some small things like hardware wallet support. Uh a hardware wallet cannot make a zero knowledge proof. Uh there's also problems with the amount of RAM required. The original EIP would prove the entire uh state of Ethereum and that is a lot of catch hashes which is very slow and a lot of RAM.

All right. How do we fix that RAM problem first? So um if there's miracle tree is very slow but it can be better and there are already proposals out there uh you can switch to a binary miracle tree use besidon with way more friendly a hash function uh and this allows you to build it in a way that you don't really have a lot of extra gas cost um however in my proof of concept I made a merkel tree inside a contract because I'm not a core developer so I just uh did it the easy way uh It's a lot faster. You know, the tree is better, but it does cost more gas. Every transaction has to update a Merkel tree, which kind of sucks, but you know, there's right now there's no good way around it.

So, uh, and there's some optimizations you can do. For instance, like burn addresses are people that will only ever be the recipient. You know, if you don't have the private key, you'll never be the sender. So, we can skip updates in the tree like that. Uh here's where I uh did something weird.

Uh I made the uh the addresses reusable. So the original EIP did it in kind of a UTXO kind of way where every time you want to spend the new thing, you made a new burn burn account and then you nullify it. And that's basically kind of like a UTXO. However, to make them reusable, uh I chose to do it in a kind of accountbased way. So instead of um nullifying the entire burn address, I split the problem up.

Uh the burn address becomes the uh basically the way to track how much money you have received. And then in private in a commitment based scheme, we track how much is spent. Uh and yeah, this is how I hash it. The total amount spent uh is like hashing a node hash with an account nons. account nons just iters from zero to uh just like in Ethereum to one two three four every spend and the nullifiers account nons and a viewing key and here I made a little overview uh so uh here you can see that um you have kind of a it's kind of like a UTXO but it only goes one way and only one note will exist at a time uh which is kind of which is basically accountbased Right.

So here you see the first little note the total amount spends is zero. The account nons is zero. Uh and the viewing key is secret. Of course we keep that secret. Uh and there uh it updates and the total amount spent becomes five.

The nons goes to one and the next one you see that as well. Um and what you got to remember here is that the previous node is always nullified. you cannot create uh multiple nodes at the same time and that makes it more account based. Um yeah so and this is uh you know a commitment based scheme. So we need to commit this uh and we commit this into the Merkel tree and like I was telling you before I made my own tree to track the balances.

So the burnt balances are also in here and the note hashes of that commitment based scheme I showed you in the last slide. [clears throat] So why is this accountbased and why is that interesting? Well, I don't have to manage UTXOs. Remember there's only one node that can exist exist for one account at a time. So uh we don't have to mess with UTXOs at all.

The proof time is also 01. We once we are at the circuit we just take the burn balance which is the amount we received and uh the accountbased node which is the amount we have spent. We subtract them from each other and then assert what is left over is more or the same than you're spending right now.

[clears throat]

Um and that uh takes me to the new point that you can make private assertions saying what is the private balance of this person exactly in UTXOs everyone can just kind of hide a UTXO somewhere else and you don't know so you can only say my balance is at least this much but in an accountbased system you can say my balance is exactly this much and this unlocks unlocks more use cases like for instance in gaming where you're uh gating at what what level you should be or any other scheme. The hardware wallet support is very simple. It's exactly like how Zcash did their sapling upgrade. [clears throat] Um so what we cannot do is make a hardware wallet do an entire zero knowledge proof. So instead we make it create a signature and then we verify the signature in the circuit.

And what that gives us is that the user will uh see on their hardware wallet what am I spending how much am I spending and to whom I'll confirm that and uh if the user's machine is compromised the worst thing that can happen is that their privacy is compro compromised. Uh, so that's a lot better. And I've used Ethereum signatures. So you can just use MetaMask Ledger and the current ecosystem supports it. Here I have a little demo.

It's a very uh minimalistic UI, I would say. All right. So

I'll do it like this. So here you see me. Oh, an inter

I I love Ubuntu. It's great. One day I'll do Arch Linux.

It's in here. All right.

All right. Here I just

it is sped up.

So here you can see I have uh connected my account, my public account and my current balance is zero. Now I'm going to [clears throat] bin some tokens for free. And here

so I'm now going to connect my private account. So here I'm signing uh this little message and I'm going to use this signature to extract the public key out of the signature because MetaMask has no [clears throat] method to pull the private key uh the public key out.

And here you can see uh my private account which is a different address. And now I'm going to make a regular transfer to that uh burn address.

And here you can see just my own account. It's now burnt. And this is a regular transfer. The only thing is different than a normal ERC20 transfer that the gas is higher. But um yeah, no one can see no one can tell that this is doing anything private.

Uh now I'm going to mint those tokens out of thin air and send them to a new account. And this will create the zero knowledge proof. Uh so that hash you saw right there um I'm blind signing it which is bad. Uh but yeah in that hash it contains this much money to this person and these relayer fees and that can be better with 712 signing as well. Now it's creating the zero knowledge proof and I will selfre relay it later.

And now Bob. Now we're switching to Bob's account and Bob is gonna claim it. And of course we can plug in a relayer as well. But for the demo I made it self relay. And here you see from 0000 to the new account free money out of thin air.

But you know it was burnt. And now if you switch back to our other account we can see we have a burnt balance of 420. So if you look the look up on ether scan people will see 420 as balance. But uh we have spent 69 tokens and our actual balance is 351 and but only we know that the public thinks we still have 420 tokens.

All right. Are there uh any questions?

Yes.

That's right.

All right.

Thank you. Yes. Amazing demo. Amazing idea. So question uh suppose you had the ability to like you know core devit change the uh L1 change whatever chain this is on do the most slick integration possible.

How far could you push this? Obviously you could do the transfer case but uh how far could you push it using this principle with unlimited power over the chain? What would be the most crazy use cases? How far could you push this concept?

So that's a good question. Like on the base layer this would be even better. Uh, I've built it as an ERC20 because I'm a solidity noir dev. That's what I know. But on the base layer, you will have plausible deniability from the start, right?

You you're not interacting with a sketchy token. And uh if I really have the all the core defaf power to make the decisions, you can have like um a lot a lot you would spend less gas on that miracle tree. Uh you would u have no relayers and stuff like that. So yeah, there's a lot that could be better if we do it on a base layer.

Well, could I do like arbitrary computation? I guess you could do does it have to be transferring an asset in and out or can it be like some broader arbitrary comp private computation thing?

Yeah. Yeah. So zk worm you can use it as a deposit method into a UTXO system like uh for example rail gun and or like ASAC and from there you can do defy interactions and stuff. So yeah, you can extend it way further.

Thank you.

Hey, would this work for existing ERC20s or would it have to be like a brand new deployed ERC20?

Yeah, so my demo is a brand new deployed ERC20. Uh everything works as ERC20 needs.

Um but yeah, you can also make a wrapper, but you have to wrap it. Yeah, but once you wrap, you know, you lose a little bit of plausible deniability,

but if you had it on the chain level, if you're the core dev, then you can do it for everything instantly, right?

Yeah, I love that.

That's what I was going to say, actually. [laughter]

Yeah, thank you. Thank you for the demo. So, I am privacy coordinator at Ethereum Foundation. Um so I like a lot the idea of form halloles uh and uh I I will try to bring it uh to the ACD and like core defs and so on. So the path will be to have it somewhere on rollups and make like IP rollup improvement proposal then have some rollups adopted then we can make an EIP for layer 1 and maybe like in two years or so we can propose it on mainet right but before that um will be great to see like more uh more use cases with ERC20 tokens and with uh with rollups because uh if we propose it directly on like layer one it's unlikely to go.

So, but uh there is I see this clear path and I'm big fan of Jim Jim and wormholes and we'll try to make it happen.

Thank you. I love that.

Yeah. And one thing to add, we need ERC20s to do this as well. So, there there is a a a lot of use case for this as well. I was just curious when it when it came to implementing it on uh existing roll-ups, what that could cause could that cause liability issues for like the existing rollup system like the ecosystem where you know you have just a handful of signers that are like governing a chain. Could that put those signers in a liability situation if the government was coming after them or something?

So I want to add that uh even though plausible deny deniability sounds more complicated um you are able to build uh a proof of innocence system like how real does it on top uh on offchain uh as well.

What is that?

Um no I'm not talking about view someone asked using viewing keys. Yeah, you could also use viewing keys, but that reveals everything. Uh, you really want a zero knowledge proof saying I am not this bad address. Sorry. Um, but you could also make a proven innocence proof.

You have to adapt it to work with this accountbased model, but it should be possible.

Yeah. I mean, the issue that we're kind of talking about like the regulation is kind of I mean, what you were asking is like how do I, you know, not go to jail as like the maintainers of a rollup, right? And uh yeah and it kind of works out well because uh you guys you know Facet doesn't have an uh canonical bridge. Aztec doesn't have a canonical bridge. So anybody implementing um a bridge for your rollup is going to be kind of taking over the liability of being like the value transfer.

You know there's no value like inherently that already exists like no monetary value that already inherently exists on your chain. So, I mean, I'm not like a lawyer, but like that's kind of the same legal approach as Aztec is t uh is taking, which is nice.

Um, I have a question about the supply of those tokens because they would be locked on that uh burn address and the new ones would be minted. In this case, what would be with the supply?

Oh, yeah, the supply tracking. So um yeah, you would just have to calculate it differently. Um uh so how I do it in the ERC20 uh implementation, every time I mint from a remin transaction from the ZKL transaction, I just do not add it to the total supply because I assume well I know it's already burnt. We just verify that. So there's no issue with tracking the supply here.

All right. Thanks, Thank you.