 What are privacy layers? Why do we need privacy layers? And how are we going to get a privacy layer that people need? So first, let me state the why for privacy layers. Obviously, the reason why we need privacy is because we don't have it right now. If you go to Easter scan, every single transaction is public. You're able to see the entire history of all the wallets. So the second reason why we need privacy is that if we want mainstream adoption of our blockchain technologies, we really need privacy. It's one of the main hurdles alongside scalability and identity in other issues. And finally, I'd like to just quickly address on privacy and regulation issues. And there's effectively a spectrum of solutions. We build privacy technology. We're on one side, you build fully self-sovereign solutions where only the individual control their information and assets. And the other side, you could give a lot of control to the entity actually controlling this ecosystem while preserving privacy between individuals. And so on the right side, you have something like CPTCs. The left side has something like generally cash, right? And perhaps actually in the middle, we'll have something that's more or less maybe accessible for both worlds where we could have a privacy preserving system, yet give some limited form of control to some set of authorities. OK, so enough on the why. Let's talk about what I mean by privacy layers. So just reiterate, everything on your theorems is public. So you're able to see everything on your first scan. And first, what I want to define is the notion called anonymity. So anonymity is the inability to tell who is doing a transaction, right? So if somehow you're going to eat your skin and you look at a transaction and you can't really tell who the address, you know, who's the engine address, then we say that the system has anonymity. And second is a notion of confidentiality. If you go to eat your skin and you cannot see exactly what the trades are, then we say this system is confidential. And it turns out confidentiality is really, really hard on your theorem. It's pretty much impossible unless you want to redesign the entirety of your theorem. So on the other hand, anonymity is actually quite easy. We can use any mixer to mix the funds. And every single time we want to do an operation. However, this is very, very unusable. To the extent that only when you very much need this, would you do such a thing, right? Normal users would not do this for every single person that would do D5 protocols. So the goal is really to make this very usable, right? How do we get usable anonymity for Ethereum? So what do we mean by, again, should we reiterate? This system will have anonymity if you go to eat your skin and you cannot see who's using all these contract calls, right? So the question is, can we get something like this for Ethereum, right? And we don't want privacy anonymity just for payments. We want this type of anonymity for any type of smart contract call. So you can see, on Ethereum, you can do many, many different things. It's an ecosystem of DApps, not just payments, not just peer-to-peer swapping of assets, not just an MTs. It's whatever you can imagine on top of token standards, right? We want to have anonymity by default for all DApps. So that's the question. And that's also what I mean by privacy layer. A privacy layer for Ethereum should have the following set of features. But let us look at what are the current solutions for privacy layers. If you look at the entire ecosystem, we'll have many, many different EVM chains. That's, more or less, you could write a DApp in typical to any of them. And we'll have many, many applications, sometimes on one popular chain, sometimes on many chains. And what are the privacy solutions? Well, we'll have some mixtures. And we'll have some solutions that offer some type of DeFi compatibility. And we have solutions that more or less act as a layer too with privacy. So for instance, Aztec and Zika Alperu are great examples of this. And on the other hand, we also have all privacy all ones. And the examples are like, for example, Alio and Manta, where it's a separate chain. It might be a different ecosystem. And you have to bootstrap all of the quality. And so it turns out there's no single solution that works without all the DApps. So if you look at what these solutions do, so RealGuide and Zika Alperu actually do support some limits in the form of swaps. And project-wise, Aztec connects a while, actually pretty good, DeFi interoperability, but it's not completely compatible with every single DApp. So as they connect, you need to write this custom bridge contract. And in fact, that's basically, if you go to every single Aztec hackathon, that's what people do, that build bridge contract for every single DApp. And that's not scalable if you want this to support every single DeFi projects out there. So this is not preservation. We don't have a privacy solution that is default and really usable. So let's look at what I mean by privacy layer and what we should get in this privacy layer. So first of all, it should be feature-complete. So what I mean by that, you should have two features. You should be able to use this privacy layer exactly the same way you would use Ethereum. So you should be able to use a privacy-preserving solution any DApp that you want, ideally with basically the same interface. You go into a DApp front-end, you click some buttons, and you do a swap. And second, you should be able to disclose what you have done. So if you look at existing privacy solutions, it is actually really hard to tell someone else that you did something. The interface is not intuitive. Whereas right now, for the transparent solution, if you give someone your address, they know they can see your entire history. So we want some type of form of information disclosure. So if you own a set of NFTs and you want to prove to your friends that I own this set of NFTs and I authorize a message, you should be able to do that really, really easily. And the second thing you should do is be backwards compatible. Because we'll have all this amazing ecosystem out there, all these DApps that people use. We don't want to fill it out to waste and build something completely brand new. We want to use the existing ecosystem. So the ecosystem should support YR220, 721, 1155 standards. And we should more or less work with existing applications. And finally, most importantly, you should actually offer some form of privacy, which in this case, anonymity. So recall back to the previous slides, you will be the form, use this thing, and everybody will use this privacy layer. And you're going to easily scan. No one can figure out who did what action. So the question for my talk is, can we build such a thing? And actually the goal of my talk is to convince you that we could build such a privacy layer for Ethereum today. And we're building one. OK, so let's look at how we're going to do this. So let's look at this set of three things that we want for our privacy layer. And if you categorize them, the first two features are basically what the smart contract wallet gives you. So if you're familiar with the abstraction, or any type of smart contract wallet, this is the two things that this should offer you. You should be able to use it on any single application, and it's backward compatible. And the second feature, it's really what a mixer offers you, what a shorted pool gives you. So I realize some of you might not know what a shorted pool or a mixer is. So let me just reintroduce the two concepts. So first of all, what is a shorted pool? A shorted pool allows you to unlink deposits and withdraws. So this is the most basic form of privacy solution that we've had since the Bitcoin days. So it allows you any user to deposit. And later on, you should be able to withdraw. But by the time that you withdraw, nobody else should know who's actually withdrawing. So you withdraw to a fresh UA address. So that's the notion of a shorted pool or mixer. And second, let's recall the notion of a shorted wallet. Let's recall the notion of a contract wallet. What is a contract wallet? Well, for a contract wallet, the users actually do not own an EOA anymore. So for instance, for account abstraction, you will have different address that we use. But basically, for your smart contract wallet, you should be able to do the exact same things that you would do with your metamask. You should be able to submit arbitrary smart contract calls and get executed. And this is done in the form of an intermediary smart contract wallet that verifies some signature and carry out the calls for you. So that's the notion of a contract wallet. And recall what we wanted to do before. We said that the thing we want to build is basically a shorted pool plus a smart contract wallet. So here's what we're actually going to do. We're going to take the two and just put them together. So it's going to be a shorted contract wallet. So what can I do? You should be able to use anything that is on Ethereum. And every single time you use the wallets, nobody should actually know who's actually using the wallet. So there's one single shorted contract wallet that's shared by all the users in the ecosystem. OK, so that's on a very high level. But how does this actually work? So for shorted pools, like we said before, it supports deposits and withdrawals. And for contract wallets, you'll support arbitrary calls. And when put them together, you will support, again, deposits and withdrawals, but also crucially something that you can use to call the app. All right, so here's the picture. Here's how it's going to work. It's going to be a smart contract in Ethereum where it allows any user to enter this ecosystem. And once they enter, they're able to use it as if it's a metamask wallet. And when different users submit transactions, they will be reflected on chain. So if you want to call Uniswap, you want to call OpenSea, you should just work. And furthermore, on EtherScan, you have no idea of who's actually behind the scene doing this operation. And as a bonus, actually, we can make this smart contract wallet compatible with account abstraction, or EIP 4337. OK, so as it turns out, there's two problems if you want to build this. If you want to build this, just combine and show the pool with the smart contract wallets. The first problem is that when user submits a transaction that contains arbitrary calls, you can actually just steal the funds of the entire contract. So here, if the user only owns one Ethereum in the pool, but it constructs a call that consumes 20 Ethereum, this is we shouldn't let this happen, right? Because people would be able to steal the entirety of the funds of the entire protocol. So what's the solution? Well, the solution for this problem is that we actually just separate out the two contracts into a contract that actually holds the other funds, what we call a vault contract, and the wallet contract, which I will actually carry out the calls. So in this way, users will unwrap the tokens that they have, and only the token that they have is inside the wallets when they're asking for a call. This is actually kind of equivalent to the other way of doing it, which is you also have a router and have the wallet holding all the funds and putting the things into the router. So there's two equal solutions to solve the same problem. And the second problem that you feel to do this, which I think is the main reason why we don't have these things before, is that for this type of privacy preserving should it pools, you need to know the exact amount of tokens, that's encoded in the notes, before you insert it into the protocol. So everything has to be known in advance. Whereas in DeFi protocols, you have no idea how much tokens are getting back. There's this uncertainty of the smart contract decides how much you get back. But traditionally, for treated pools, everything has been known in advance. And so this is like one feature that we didn't really know how to do before. And there's a solution for this, which is that we have this notion of refunding to anonymous address. So we have to be able to re-redimize addresses and refund to them. I realized I actually basically sped through my entire deck and the end of the talk. So let's recap what have we learned in this talk. So first of all, privacy is really important. We do not have privacy on Ethereum. We need some type of privacy solution for Ethereum that's really usable before Ethereum can go mainstream. And a shielded contract wallet, combining a shielded pool and a contract wallet, is our bad shot at this backwards-compatible, future-complete privacy layer. And finally, we're building this out. We hope to put something on the public. And the hope is that long-term for this ecosystem, most people will actually be inside of a privacy layer instead of the standard EOA layer. And if you're interested in contributing to this effort, please come talk to me. And I realized I didn't do a self-introduction at the beginning. My name is Wade I, a research partner at ThinkApp or QuipTel. And come ask me if I have more questions about this project. But I'll take any questions from here. Thank you. Hi, congrats for the work. I think privacy is very important. I've worked for a few years on trying to make users have smart contract wallets by default. And the big problem is the gas cost of just having to onboard someone and already having to spend $10, $5, sometimes $100, how do you think that that can be solved? Yeah, very good question. I think two things. What is the actual cost of gas over time as we build the scalability layers should go down as we build more roll-ups? And the second is we could use batching to amortize the gas cost. So usually, actually, in 4.5 to 7, there's a notion of bundlers and aggregators where you compress the authentication information from multiple transactions into a single authorization for all the transactions. And there's different tricks to further optimize the gas cost. So over time, through these two avenues, the hope is that the additional cost incurred to get a contract wallet with privacy is not prohibitive for users, for a vast majority of users. Great talk. I'm interested to hear how you think about OFAC and tornado cash, because if this is like an opt-in. Where's the person coming from? Hi. Over here. Oh, yeah. Hi. No, how do you think about, because if you look at tornado cash and the OFAC sanctions, how do you think about avoiding that kind of thing with, because my understanding is that this would be like an opt-in smart contract wallet. So how can you avoid that and kind of a diverse election and these types of things? So referring back to my slides, where I showed the spectrum solutions, I think as a builder, we should be flexible in kind of, so what is privacy? Privacy is appropriate for all of the information. I don't think privacy is absolute notion where everything should be private to you. There's some societal consensus on what is appropriate for all of the information. And everybody can have their own interpretation of that. Government agencies can have their own interpretation. Individuals in the theorem community can have our interpretation. And they might be incompatible. But I think as builders, we should be open to different versions of what is appropriate for all of the information, because technology is really flexible. And over time, there will be communities that might be incompatible. But we should work towards a solution that's more towards the center, I would say, where we include as many users into our ecosystem as possible, yet give some sort of control, perhaps, maybe, to some set of people, to be able to prevent illicit activities. So when you say we're building this already, how far have you got? We have prototype contracts. It's a very early stage. Yeah, so the idea has been there for a while, but the building is just being abstraction. And we'll have basically two people full time on this. Why not embed these innovations into an existing contract while it's urgent or something? So well, there's many, many different contract wallets out there with different focus. This is a contract wallet with privacy. I think it doesn't make sense to, I mean, we could take the existing 437 standard reference code base and just fit this into there. The main difficulty is actually not being a contract wallet, it's really like how to add privacy, I think, because we need to also change the front end APIs. So every single smart contract wallet have to do this. But I think for privacy, it's more important, because a lot of semantics need to change. So if you think about how clearly you pull balances ready accounts, you first connect your wallets, you pull what is connected wallet address, and you go to the contract icon and pull what is actually my balance. That cannot be made privacy preserving, because you get who it is. So you have to change that into something like connect to wallets, can I get the USDC balance? So a lot of things need to change when something needs to be, you want to imagine a privacy preserving system. So we'll have to collaborate with contract wallet projects. And that's also another reason why we're trying to stay compatible with 437, because we can reuse, have the same bundler infrastructure and this account abstraction manpool. So we'll be part of that ecosystem and contribute to the efforts as well. Great, Doug, thanks. What kind of zero knowledge protocol you decided to use? Yeah, so as it turns out, the easiest way to prototype something like this is circle still. Like there's nothing better out there that you can rather zero on a shortcut and have like a solidifier and like a prover that's running on a browser. Circle is the only ecosystem. So this is like another rank. I would use the most efficient proof system out there. It's probably more like plunk, but that tooling's not there. And also over time, it sounds like you're familiar with the subsystems, but over time, there will be two separate proof systems. So one is on the user side, where you essentially want zero knowledge property only for privacy. So what is this thing? The overall design is very similar to any other sort of pool. You have a merkle tree of nodes. You're referring to a node and spinning it without revealing which node you are referring to. And for that, you need zero knowledge to preserve your privacy. And you actually don't really need a succinctness. And we're going to have this aggregation layer that roll out these user spending proofs. And for that, you really want succinctness. You want to be able to verify on the contracts that really efficiently. And so I think this is something that has been discussed a lot in DevCon in the past couple of days, which is you have the notion of inner proof and outer proof. So for us, this inner proof will basically be the user proof that has zero knowledge. I think over time, we'll probably evaluate things that's really fast in the browser as to your knowledge and maybe some type of compression. It's like maybe a smart center or something. And then on the outer proof, we'll have probably grossing or plonk that really compresses the other proofs. Yeah. So one approach to solving this problem would be to make backwards compatible contracts on Ethereum. Other approaches might be to wait until there's an L2 that has more primitives built in that support this. And I'm just curious to learn more about your thinking of if it ever makes sense that privacy will be in one place and non-private things can exist in another. I think, yeah. So the question is, do we build privacy solutions on top of existing things? Or do we build a new ecosystem to build privacy-preserving solutions? And I think the key question is, what are the privacy-supported? And what is the features of those applications? And so it turns out that the short answer is there's no privacy-preserving ecosystem right now out there that actually support more features than anonymity. So if you look at like Alio or like Mina, it's really just a solution to build roll-ups. With zero knowledge, you cannot get privacy for shared states. So I actually discussed this in another talk on mine. So if you think about the features we can support, I think unless you have vastly more capabilities to support privacy-preserving solutions, which I think it's actually privacy of shared states, it doesn't make sense to have a complete brand new ecosystem. Because the privacy that's achievable is the same. So there's no benefit to building a new ecosystem that do the same thing. So therefore, if that's the case, we should build on top of existing ecosystems because everyone is there with desperately new privacy solutions. And it's possible to build it. So let's not reinvent the wheel. Is it working? So it sounds like you need a sequence of maintaining the miracle tree. Have you got thoughts on how you're going to? Decentralize that, or whether you will? Yeah. So there's actually two different things. So for 4337, you have the notion of bundlers. And we could basically use that. So we could actually, so bundlers, so I think it's yet to be determined exactly what's in the standards. But it seems that for every single contract wallet, bundler needs to run custom code to be able to compress different user operations to one. So we could essentially stay compatible to those standards when it's more finalized to be able to have essentially to plug into that ecosystem. So there could be different 4337 bundlers that's supporting different smart contract wallets, and it will be one of them. And in that way, we can decentralize bundling. And the second is, yeah, so exactly, so there might be this management of miracle trees that's separate to compressing multiple user operation proofs into one. And we can make that permissionless if it thinks of current thinking. So what is the overall story? Because we support, we're backwards and portable, we support the exact same set of operations, users need to pay more gas. You're paying the same amount of gas by default. And the additional things, that's the overhead to maintain everything. And the idea is to make it as small as possible. And the only way to do that is to outsource this aggregated work into some sequencer or bundler. So it's basically necessary if you want to make this usually usable. And so, yeah, so to decentralize, I think, make it permissionless and really design incentives around this, right? That's because these bundlers, sequencers, are providing a service. We should incentivize behavior and make it permissionless and design kind of this ecosystem that's self-sustainable, right? Because I think that users will pay for privacy if it's cheap enough. And you can get its network effect, right? Thank you so much. Wei.