 Thank you so much for coming. My name is William Tien. I'm from Singapore doing some privacy stuff at the EF. And today it's my honour to share a view of my work on the past four months to build a mix-up using zero-malage proofs. Can you talk louder? Okay. There's no mic, right? Alright, I'll try to. Can you get me in the back? It helps to be somewhere. Yeah? Can you get me in the back? Yeah, here you go. No, you can't. Okay. Is that better? Yeah. Yeah. Okay. So around the middle of last year, the middle of this year, there was a lot of my activity on Twitter. A lot of people talking about mixers because Vitalik posted a hack and D and Amin pushed out for people to build mixers on the EF. And there was a bit of a mixer renaissance where we saw a lot of interest in the space. So today I'm going to show you one of the mixers that is out there that I built along with Darren Pitehand and Kobe Kirkhan. And we built this on the zero-malage signalling gadget called Semaphore. And I explained that later. But before we do this, I just want to give a high-level discussion about why do we need privacy at Ethereum? And the usual argument for privacy is that it's just a human right on that. It's something that everybody wants. Even if they don't think they need it at the moment. But I think that's one, something that people don't really talk about is why people need privacy of Ethereum specifically. And I think this is interesting because Ethereum users need privacy more than any other blockchain because Ethereum has DeFi. That's because Ethereum has labs. The more people use Ethereum for different applications, the more they need privacy. And because of network effects in Ethereum and DeFi, users tend to need more data than on any other chain. Because in any other chain like Unero or Zcash, you are just sending crypto back and forth. You aren't necessarily linking the data to on-chain smart contracts. But in Ethereum, your smart contracts have meaning. And the meaning is something that is your personal data. It's set to lose. And I set the lose privacy because your identity might be linked to that on-chain activity in DeFi and on the smart contracts. You go to the event on kickback and you use your address to sign up for that event. Now someone knows that you went for that or didn't. Or you just buy coffee, now the berry stock can stop you because they know your balance. And then they can link that to other DeFi apps. So it's not good. So you want to fix that with any way possible and it makes us one step towards adding more privacy to Ethereum. There is a fantastic report on the state of mixers that I'm currently working with. This is like a broader overview of all the mixers out there right now. But today I'm going to focus on right things. So how does it work? Yeah. So there are two transactions. The user only does one transaction to deposit F into the contract. When they do that, they also pass in an identity commitment which is the hash of an EDDSA public key and some random data. When they want to withdraw, they generate a ZKSNAP proof that of your membership in a set of all identity commitments. Already in the smart contract, they send it to a relayer. The relayer contract passes on the proof to the micro mix smart contract which verifies the proof and sends back the ETH to the recipient. But it also sends back a reward to the relayer. So the user doesn't have to pay gas to withdraw. And this is good because if they had to pay gas, they would have to get the gas or the ETH to pay the gas and they would defeat the purpose of a mixer in the first place. So at the risk of a demo failing and a proof of people, I can show you the demo. So this is like a micro mix of F. It's in the department of COVID, it's a 0.1 F deposit or 20 die deposits. So let's just mix 0.1 F. So this is where we deposit the funds and it's just going to take a long time because it's a live demo. What is 0? Perfect. So what we do here is that the goal is to educate users to leave the deposits as long as possible. We don't want to tell users that the more deposits there are, the more privacy you have because it's possible to fill in the pool of deposits with their own funds and give a forced impression that another anonymity pool is very large but when in fact they might know most of the transactions and be able to meet and advise you because they stamp the pool with it. So what we're trying to do here is just to encourage users to have better best practices and better anti-heuristic based attack behaviour in order to maximise the privacy. So what we do here is that we just encourage them to withdraw only after midnight UTC or the day that they deposit so that they don't, they aren't told that the bigger the pool, the more privacy you have. But that can be better ways that they can use us and this is just one way. For the sake of a demo, we can basically generate the, do the withdrawal right now, which is something we don't encourage. This is where we generate the ZK Snap Proof, we download all the identity components from the smart contract, we generate the Merger Proof, we download the ZK Snap Circuit and the Proving Key and then we, which is, this takes like 30 seconds to, because it's, because ZK Snap takes a long time to prove but a short time to verify it. And while this runs, I'm going to go to the next slide. Okay, so, yeah, so this is more like a deeper, more details of the architecture of Retomix. We have the UI, we have EDDSA keys stored inside the user's browser in local storage. The reason that we use EDDSA keys for the identity component is because this is more stuck friendly than EDDSA keys. And this poses a challenge for wallet providers because we need to have better ways to store this key for the purposes of this demo, it's not encrypted or anything like that, but there's a whole topic that we can cover in a different discussion. We have, it's all linked to the contract and we have a really server that has API that accepts proofs and also manages the nouns for sending the withdrawal transaction to the smart contract. Right now, this contract supports either 0.1 kF or 20 die deposits. The reason that we have fixed amounts is that we want that, if we have, we can't support arbitrary amounts because that would de-analyze users. We layer a case of gas. Right now, we are using a centralized layer, but in the future, we're going to have a relay network where we have different relays to compete for users to send their transactions to relay and get rewards in return. We have a function that lets you generate the proof and send it as a transaction and pay the gas for that in case you need to withdraw early. And we allow you to, we have the in browser proof generation and the classic work in the browser and it's in quite a program right now. Before I go into the more technical details about the server form, which is the underlying, it's not gadget that powers the whole thing. Let's see what's done. All right, it's downloading it. So right now, you can see that it's still generating a proof. It needs two pieces of data. The circuit and the fruiting. The circuit is 15 pages. So 15 pages and it's like 20 pages. And it just takes like 30 seconds to print it. It's very exciting. It's in the browser just to be sure that it can spread it. And it's just generating a proof. And it's going to send it to the relayer which will send it to the customer. So fingers crossed. So guess what it is because the user just sends a transaction data off-chain to an API. And we will see how the spell contract sends back a small portion as a reward to the relayer at the top of the front to the recipient address. We will see that this is a reward for the relayer and this is the front that I'm going to mix. So it will work. And I have ten more minutes to go into the technical details but anybody have any questions right now? It's the gas cost. Quite high. Gas cost for withdrawals is $7,000. The gas cost is high because we support to the power of 20 deposits. If we support a lower number of deposits then the gas cost will decrease. Both depositors and the receiver have to trust the relayer. If the relayer is rolled, what will happen? The relayer can censor transactions but the relayer cannot change the reverse too. So they don't have to trust the relayer but they just need to trust the relayer to send the transaction. They don't have to trust it possibly. After the deposit it took our way. I don't need it to any more relay for you. The relayer only sends passes along the call data on the proof to withdraw funds. If they don't do it they can ask a different relayer to do the same thing. Last question. So it's dope and thank you for your service. So we have two measures of the activity of this contract because I guess the number of deposits of practice like the number of withdrawals and for a given deposit you can look at the number of withdrawals for practicing them to get a very, very weak notion of what the anonymity says. If you're thinking about this more seriously, what heroes can you use to determine the safety of the mix and work like this one? Wow, that's a minute about the text. Cool. You would say that tags are the biggest weakness of this whole thing. So right now apart from saying that we need to educate users on the best practices. I don't know what the best practices are. I think leaving it in the contract for as long as possible and educate users that the size of the pool is not necessarily the best country of privacy. It's a tough question. Yeah, it's a very tough question. Can you add noise by telling a bunch of extra contracts? Extra contracts. Extra transactions. Yeah, it's just not a measure. It's just not a measure. The last one. Can you run the layer? Let's say I deposit my funds and next year I want to withdraw it. But then there's no layer online. Can I run the layer? Oh, you can. Anybody can run the video. So the relay system is something that's being built by Lakshman Saka who is coming later today. It's kind of out of scope of this presentation right now. Okay, so in the next five minutes I'll try to explain a bit more of the sneaky stuff. Sorry if you're speaking a bit louder. Yeah, okay. Yeah, I'm sorry about that. So basically the mixer is one application of semaphore which is a city-stuck circuit and smart contract. What semaphore does is allows you to register your identity and allows you to broadcast any other tree string. And it prevents double signaling. So to apply semaphore to a mixer the identity registration is a deposit and withdrawing funds is broadcasting a signal. And in the same way that double signaling doesn't work, it prevents double-spending. This is the summary of the ZK-stuck truth. It proves three things that the identity component exists inside the other tree that the signal was only broadcasted once. For this one, for the second one it also relies on the storage of the smart contract to check whether a nullifier exists inside the storage, but a circuit check whether the hash is valid. And finally there's also an EDDSA signature verification that ensures that the public key that the user used was associated with the private key that used to sign the hash of the signal and the X of the nullifier. So in three minutes, I can't explain the whole thing, but I'm having to sit down and everybody just to dive into the code later. Yeah, I'm not good at this type of thing. Yeah, so just to summarize, to deposit we do these steps and to withdraw we send the truth to the reader. Yeah, this is the contract. And yeah, as we mentioned there's a whole, there's a really great paper about how heuristics can de-analyze users and this was so they looked at Zcash and so there's one downside of this system. The other downside is ZKStark and smart contract security flaws and third of all is the trusted setup. So to mitigate the last two first of all we're having this thing where so any ZKStark trusted setup is divided into two parts. The first phase is something that's common to all ZKStark circuits and they're doing an often party computation separately where anybody can join and share of that setup and this is going to last forever as long as people want to do this and any ZKStark circuit can take a point in this chain of contributions and branch off to the second phase which is the circuit specific trusted setup. So we're doing this something called a perpetual powers of power ceremony so far there have been like seven participants and we are going to keep doing this and we're going to pick a point at which we do the trusted setup for the e-mixer and we're funded by QA Network and the EF for an ongoing audit and we are just going through this process right now. So we are very grateful to EF and QA Network for this to make this possible and when you validate that you can't understand that you can only withdraw if you know the product key and you can't like mint money. This is the name of the network. So again, definitely check it out and finally all the source code is open source you can find me at the conference I'm happy to answer any questions in person and thank you so much for coming.