What a Modern Privacy Protocol Needs

Transcript

Great to be here. It's great to see so many of you here. I'm very happy to be in India. Um, let me start off with a question to the audience actually. Uh, who here is building a privacy protocol or is interested in building a privacy protocol? Great. I actually see quite a lot of hands hands. I'm happy to see that. Well, this talk is for you. Um, I do product at privacy pools. I uh I'm not very technical. So, I'm gonna essentially keep it high level. I like talking to users. I like learning what users want from us and uh how we can fit their needs. So, um I'm going to start off with uh a bit of a reality check check though, which is

building in crypto now kind of sucks. Um we kind of know that. We see it every day. Uh there are exploits and hacks happening everywhere. Obviously real funds are at risk from day one. And besides that it is also because of that especially now super expensive to build in crypto. Uh you have so many audits and like an audit from two years ago is no longer an audit that you do today. So um there's a lot of costs that come with that. And then the second reality check is that building in privacy sucks even more than in regular crypto. Uh, and there's a few reasons for that. Um, besides the the regular tech that we use for smart contracts and all of that, we

obviously have CK circuits and all the complexities that come with that that make it even more vulnerable, even more difficult, and even more expensive. Besides that, the space within privacy is also moving incredibly fast. there are a lot of us now which is great to see but that also means that it's hard to keep up and you need to be shipping fast in order to stay competitive and then user demands are also very high for privacy. um it is not really quite as straightforward as let's say a perex or a swap because um yeah users expect it to really be a public good almost which is fair enough because privacy is normal

and privacy should be the default but that leads you to make um very specific design choices that that meet users where they are and then there are also other considerations um compliance is a big one uh the privacy spectrum which I'm going to talk about right after this and then there is also the quantum risk. Um so first the privacy spectrum uh this is a uh pallet provided by L2B where they grade privacy protocols and if you're building a privacy protocol this is your absolute cheat sheet. Um there are several like when you're building a privacy protocol obviously the most important thing is keeping your users private making sure they don't leak

making sure that you are honoring the trust that they place in you and so this pallet here is a great cheat sheet into doing that. Uh there is five categories. First is the public observer. So that is what anyone you looking on epherscan can learn from anyone using the protocol. And then you have the chain analyst which is maybe a company like TRM Labs or Elliptic that puts a lot of time and effort into monitoring everything that happens on chain really what can they learn about your users. Uh you have the network observer so that is like your ISP your RPC um can they deanonymize you just by interacting with the protocol.

uh the privileged insider so that is the operator of the protocol. How private are you from the person running the privacy protocol and the future adversary which is the postquantum set and yeah within privacy if you're operating in this space. One slip up can undermine your entire product. So use this this is your bible. Um make sure you know exactly what every category is and how you uh score get a green score on it. Um so then I want to take a look back at privacy pools v1 first. Um privacy pools v1 was launched a year and a half ago or so on the mainet. Um and the goal was really very simple. Um we offer basic privacy. It is a protocol in which you

can withdraw uh sorry in which you can deposit and then withdraw as you can see on the diagram here. So you can withdraw with an address and then withdraw arbit withdraw arbitrary amounts to different addresses. Um the innovative aspect of this was the compliance and compliance is really an enormously important part of building a privacy protocol because if you don't pay attention to it um suddenly uh your single Ethereum is not equal to um a an an Ethereum that did not come out of a privacy protocol because like exchanges won't accept it, platforms won't accept it, you might have a hard time offboarding your funds.

And so that is what we try to innovate on within privacy pools v2 v1. Um and last week we have launched privacy pools v2. And for privacy pools v2 our design goal was really quite explicit. We had three features that we really wanted to optimize for. So first of all is the UX. We wanted we wanted it to be a a state-of-the-art privacy protocol that where we essentially wanted to enable users to be able to do anything that they would do with a public address but then privately. Um so we really want to reduce the friction between a public and a private account and I think we've done a pretty good job in that. uh you

can do transfers, you can do private swaps, you can do private bridging, we have private yield, and we even have uh Venmo style uh payment requests where you can essentially just uh enter any amount that you would like to request from someone, send them a link and they can pay that either with their public wallet, with their private wallet, hopefully soon with fiat as well. Third design, second design goal is the DevX. So we believe that it doesn't really make sense for privacy protocols to be a standalone product. Users shouldn't have to worry about privacy at all really. Um and so we think that privacy should meet users where they're

at. Um they shouldn't specifically come seeking you out. And so for that we have uh three different SDKs actually. the Kohaku SDK obviously being the most prominent one which Fatalik just demoed. Um we are incredibly excited for seeing that being developed. Uh then we also have a TypeScript SDK which powers privacy pools uh which powers the privacy pools app and we have a rust SDK which is optimized for mobile applications. And then the third part is the compliance. Um again our main goal for privacy pools is making sure that wherever users want to go after privacy pools their funds are being accepted.

They can offramp, they can exchange, they can trade whatever. Um they must be able to pre their we must do any everything we can to prevent their funds being frozen or being subject to extra scrutiny or anything like that. And so um our privacy model, our architecture is different. Um and so we made a lot of innovations on the ASP where we can um in an anonymous and private way still trace funds through the pool um without yeah as I said any the anonymization.

And then we have viewing keys as well. Obviously, no global viewing keys, but viewing keys that the users hold themselves and that if an exchange or any third party ever wants to know uh what happened, you can share that either on a transactional level or on an account level. Um and then if you look at the architecture of these uh two protocols, you can see that it has really become a lot more tricky and a lot more difficult. um privacy pools v1 was two contracts and privacy pools v2 has 20 27 verifiers as opposed to two. Uh the complexity has gone up and um that

obviously creates a lot of challenges. So privacy pools v2 comes with the same privacy guarantees. Well, this relates back to the L2B overview that I showed. Um, not exactly, at least not yet. Uh, Privacy Pools V1 scores green on every single aspect uh, except for the privileged insider and that is a design choice that we've purposefully made where the ASP screens deposits before they go in and that is why um, yeah, the ASP as an operator uh, does look at the source of funds of wallets depositing into the protocol which makes it at risk. Privacy Pools V2 um has some other issues as well as you

can see. Uh we are working incredibly hard on getting all of that to green and um yeah, our road map for that is being finalized. The fixes are being deployed. Uh we hope to be green on all these aspects very soon. Um then a little bit about where privacy is headed and if you're building a privacy protocol, what should you be be paying attention to? I think one of the big things is of course base layer implementations. Ccash style proofs uh pools on every chain. Uh the tech frontier of what is hot in privacy right now and the embeddedness.

Um so for base layer implementation there are uh several different options. Uh we see native shielded pools like Ccash has uh CK wormholes are also an option. Um but the thing is is that we there are a lot of security risks come with this. Uh so Zcash obviously had a bug that um is hopefully unexploited but um if there is a soundness bug within your proof proving system that could eventually like or immediately if it is discovered undermine the integrity of your entire chain. So L1s are being quite hesitant and are taking very serious um assessment making very

serious assessments about whether to do this or not. We saw just last week I ironfish which is um an L1 with um privacy built in got exploited and their uh entire supply got basically uh minted and taken off chain and swapped and then Monero also has the postquantum threat. So yeah, it is not very straightforward doing this at the base layer. And then secondly, there is also a lot of incompleteness in the tech still and that is what I want to talk about next.

Um, what do you want to be focusing on if you're currently building a privacy protocol? I think multi-igs are going to be a huge thing. private multiigs is um I think a huge unlock that is actually coming in the near future but there are a lot of tradeoffs and different design decisions and different methods of building these and um I don't think Bermuda Bay is another privacy protocol they have their frost implementation live but I think they're currently the only ones um and so that is a very interesting angle to look at then obviously there is security where a lot of people are working on the postquantum threat to uh ZK proofs and also hardware wallets. So being able to

store part of your proof on a hardware wallet is going to be a huge unlock because currently um if you keep your proofs on your device, if your device gets compromised, so do your proofs. Programmability, which is what Aztec is obviously working on, um, is going to be huge. Being interoperable with other applications is going to be a huge unlock. And then there is also in pool programmability with things like spending limits, uh, policies for wallets within the pool. that being customizable is also I think a very interesting um aspect to the whole privacy scene and um something that we can still get a lot of um innovation in

and then also scalability. Um so privacy pools v2 for instance uh works on a 5x5 uh schema which means that you can maximally enter five nodes and get five notes back. Um, a note is a deposit into a privacy protocol. And so if you are a power user and you make loads of deposits, um, you are actually quite limited in the functionality within the pool because you're capped by the five nodes that you can use. Um, scaling this, uh, which we have already done for withdrawals is, uh, going to be a huge unlock that makes your user user experience a lot more flexible.

Uh then thirdly, the embeddedness. Uh we want privacy where users are at. We don't want standalone applications. Um I have to give a quick shout out to the wallets leading this and these are largely uh communitydriven wallets. These are grassroot implementations, but they set incredible examples and they have done an amazing job in envisioning what a user experience uh or what privacy in a wallet should be and how it can be uh yeah really productized. So these wallets here, Ampire, Cloaked, Casper, Walletch Chan, uh they are really leading the way here and um I highly highly encourage all of you to test these wallets and and see how this looks like and how it functions. And

then in the app layer, I think there is going to be uh a lot of applications that are going to be implement or routing their traffic through privacy protocols as well. Um I think some of the tech for this to be productized at scale is is still missing. Um multisigs are I think the biggest unlock in actually realizing this. But um yeah that is going to grow the privacy pie so much that uh it's it's really an exciting time to be building in this space because the market I think is going to grow so so fast and so much.

Um so then a small section on what not to do if you're building a privacy protocol and I think this is almost as important as uh what you should do. Um so global viewing keys is something that uh Zach talked about as well. Um I think this is a major major risk. Uh who bears the responsibility for this? you can get hacked and I think that um personal viewing keys, user fueling keys, especially if you want to have like a more let's say enterprise focused privacy protocol, you can very easily enforce usage of these viewing keys around the edges. So if you as uh an application are dealing with let's say

many enterprises that require very strict standards and want to have more transparency into what happens within a privacy protocol you can very easily enforce the sharing of these viewing keys within your application and I think that really solves the need for having that a global viewing keys in the first place and then I see a lot of talk within privacy protocols about funds freezing as well. Now I think the audience here is uh I I don't have to explain too much about why that is a bad idea. Um but a lot of these a lot of these um protocols that are building these kind of tech uh frame their privacy tech as being focused on enterprises.

uh but I think even that argument doesn't really hold because if you as an enterprise are building a truly global application that you want your customers and the customers of your customers to use then having global viewing keys having funds freezing that is going to undermine the trust for a global applications. These companies all work in different jurisdictions and they will not trust one single operator holding a viewing key. And then trusted execution environments. Um they bring a lot of benefits but they introduce a third party that every single user within the protocol has to trust. Uh it it comes back to that again. You do not want a third party to be the middleman within your protocol.

Um I think a great example of uh this this uh the way of thinking here is Aztec. Um Aztec connect went live four years ago already and um after the tornado cashache sanctioning um in March 2023 they turned off their protocol and they obviously had a lot of time to ask the question right like how do we manage our compliance? What should we do? Should we have global viewing keys? should we have the ability to freeze funds? Um, and then they went live again a few years later and as you can see now, um, compliance ended up in the app layer instead of in the base layer. And I think this uh just highlights that um

applications should manage their compliance uh as they see fit, but there shouldn't be any centralized freezing, fewing keys, custody, anything like that. Um, so if you're building a privacy protocol, summing up what I've just said, uh, what you want to do is you want to be green on every aspect of the L2B pallet. You want to have a differentiating UX. You want to bring something that other privacy pro protocols don't have yet. Um, you want to have commercialization, which is also incredibly important, but I haven't really talked about it all yet. Um, and I think, yeah, one message I really want to drive home, do not implement any back

doors. Um, so if you've done all of this, uh, you have your product ready, uh, now you have the absolute barebone minimum of what you need to do as a privacy protocol because a privacy protocol is really fully dependent upon, uh, the anonymity set that it is built on. So you have your product, now you have to look at the commercialization. And this is such an extensive topic and uh also a very complex one that I could give a whole new presentation on that. Uh and I definitely can't fit it into the one minute I have left. Um it's something very important to take into account though. How are you planning to grow your anonymity set? Um what is your

commercial strategy? Uh that really is phase two of what you're building here. So yeah, that was my presentation. Uh I hope we have some time for Q&A. I hope you enjoyed it. Uh we if you see me around a venue, do reach out to me because of we just launched Privacy Pools V2. We are doing a little activation and we have a little alpha for you if you uh reach out to us. So come talk to us. Um yeah, thank you for being here. >> Thank you. Okay, we have quite a few questions. If I could get the Mircat screen up, please.

Okay. What are the differences between Privacy Pool's proof of innocence and rail gun proof of innocence? >> Yeah. So the privacy pool's proof of innoc the real gun proof of innocence is essentially an automated system based on different uh input variables like for instance third parties like chain analysis other screening providers and then within an hour um your uh result you either get accepted or not um we take probably a bit more of an opinionated approach. Our system is automated to some extent but not always.

Um, if we for instance see a deposit coming in from Coinbase for a large amount, let's say a 100,000 USDT, it gets withdrawn from Coinbase and straight away deposited into privacy pools. Every single provider will tell you, "Oh, Coinbase is a legit venue. These funds are legit. These funds should be accepted into the pool." However, we know about social engineering, fishing. These things happen to a lot of people. So what we would do is we would probably let the deposit sit there for a day and give Coinbase the uh possibility to reach out to us and if these funds are indeed hacked or so we would not let them into the pool. So there is a manual aspect that comes with our uh PPOI as well um yeah we really have as a goal to not get

any whatsoever tainted funds into the pool. As I said, the most important goal for privacy pools is to have our users being able to use it without any considerations of are my funds going to get frozen by exchanges or anything like that. And so, yeah, we we put a lot of time and effort into making sure uh that is indeed the case. >> Okay. What additional info does an ASP have compared to someone just looking at the chain? um like well we we use a lot of different tools. So when a deposit comes in we obviously have third parties like for instance chain an analysis that gives us a score about the address. Um we have

our own internal tooling as well. We use various databases to see hey is this address flagged anywhere? Um but from a tech perspective there is no let's say um special knowledge that the ASP has that a public observer couldn't theoretically obtain themselves. >> Can I withdraw directly into an exchange and not get flagged? Which exchanges are supported regarding compliance? >> Yes, absolutely. That is my main job to ensure your funds don't get frozen. uh you can use any major exchange and if you do run into any problems uh please do reach out to us because as I said this is my main job this is my main

responsibility I will be solving that for you ASAP. >> Can I migrate from V1 to V2 easily and privately? >> Um yes you can. Um V1 and V2 are different kind of products. They have they serve almost different kind of use cases. For instance, V1 uh is still very very good for uh let's say stealth address operators to aggregate all their balances into a a single private account. Uh however, um V2 is more focused on having you know your entire onchain balance private. You can do anything within your V2. You can

you can just keep your funds there. there is no opportunity cost of okay I'm leaving my funds in privacy pools v2 they are not earning anything for me because you can earn natively within the pool and so uh you can very simply withdraw from privacy pools v1 to a fresh address and deposit that in privacy pools v2 um there is no specific migration contract or so currently >> okay does the level of privacy depend on time in the pool like other pool-based privacy apps >> yes and No. Um, if you if if you look on chain and someone deposits a very specific amount, let's say uh $53 and then gets accepted and within 2 minutes you see a

withdrawal for $53, you might reasonably assume that those people are the same person. However, I also know of people that that have funds in privacy pools V2 or and V1 as well, and they look specifically for these kind of oddnumbered transactions and then withdraw that amount. So, they're trying to impersonate the person with depositing. Um, there are a lot of different ways that that uh you can gain privacy within the pool. Uh, it is better, generally speaking, to leave your funds in there longer. You now also earn yield on them, so you're not losing out on anything. Uh however it doesn't necessarily um mean that that you lose all your privacy if you just route go in

and out basically. >> All right. Unfortunately, that is all the questions we have time for. As he already mentioned, if you see him along the hallways, just stop him and have a quick chat.