Building Privacy Protocols in Web3: Lessons from the Frontlines - Petar Atanasovski | Curvy

Hi everyone, I'm Peter from Kurvy and today I'm here to share with you the unfiltered version of the story which is uh sometimes painful but it is anyway always interesting and exciting about building a privacy protocol and how it actually looks like uh behind the scenes what is happening what is the thought process it's been u two and a half years almost two and a half years since Vitalik published this blog post about uh stealth addresses and uh stealth addresses are very powerful concept uh simple and powerful at the same time uh basically you can register your ENS so let's say have your username and once when I know your username I can generate without any intervention from your side I can generate a new deposit address uh for for for for you and send assets to those uh addresses and basically no one externally can connect which addresses belong to you. Only your wallet will aggregate those funds and only your wallet will be aware what are the balances that that that belong to you. So uh in 3327 which is our uh research part of the company uh we played around with different cryptographic primitives uh even before that with some similar concepts and we gave oursel a task can we build the protocol the stealth address protocol which is uh aligned uh with Ethereum compatible with Ethereum without requiring any change uh on the on the protocol side of Ethereum and can it be more efficient than what we already have uh on the market. So we started digging deeper deeper deeper and we wrote few research papers. The first one uh had this goal that I mentioned like it needs to be compatible with Ethereum and it needs to be fast.

The second one was okay if we achieved that let's see how we can uh support stealth addresses to be postquantum resistant. Then we said okay it would be cool if we have like multi-IG option and if people can actually uh organize themsel and uh have different rules in order to manage their assets within their organizations. And then at some point we said okay we learned something through this postquantum resistant protocol. Can we implement some of these uh some some some of these uh logic into the existing stealth dress protocol and make it even more efficient? And that was a long process and very very exciting.

But at one point we said to ourselves, okay, it is time to go through this uh from from this research phase to actually building the product phase. And then we started exploring how the product the privacy protocol built around stealth addresses could look like. And once when you start thinking from the other perspective from the end user it becomes more and more challenging because you have many other challenges that you need to solve. And these are like just some of them that uh that had to be solved and that we started to think about because as I mentioned earlier stealth addresses are great concept but they're great concept for receiving funds. Once when you have funds and uh you protected your privacy during that process you start asking yourself okay how can I move those funds now the first thing is like if you have your assets spread around hundreds of addresses uh logically at some of those addresses you won't have native tokens and you want to ask yourself okay I don't have now funds to pay for gas fee I I I can either sponsor those addresses uh with the native token uh in order to pay the gas fee to the gas fee and to move funds but that will expose my privacy so it kills the purpose of the stealth addresses.

So we had to figure out the way how we can actually solve this problem of the gasless transactions or guest uh sponsorship from our side in order to to protect user privacy. Then you have funds spreaded across uh many many addresses and you need to send some bigger amount. Then you come to the problem how can you actually batch those transactions uh again by protecting your privacy. Then we want to be uh present ac across uh multiple chains and to enable our users to use uh to use our product uh wherever they want and it needs to be aligned with their every everyday workflow. So how do you solve that?

And then we came to the another important part of our product which is called Zikary layer which is important part for the spending uh and for keeping your your end to- end privacy. So on the left side you can see how funds are going into the system. On the right side, you can see how you are actually managing those funds and how you are actually spending those assets because it is important to have both parts uh to protect you and your privacy in order to have like the fully private um uh the fully private protocol and then you can imagine that we come to the new challenges uh across that. First, if you want to build uh something which is friendly for on boarding new users and for bringing the new mass adoption to crypto because I strongly believe that if we solve privacy in the right way, it will actually unlock many new use cases and bring the totally new groups of users that we don't have today present here. Uh and in order to do that, you need to be uh friendly to on board the new people who are not familiar with our our industry at all.

And then there is here you know lazer my CTO and uh we come frequently to the point that when we have some challenge and I say we need to address it in this way he says it is literally not possible to do that and then we fight and then we go back to the whiteboard and then we start discussing and then we have find some middle ground. I often say that I'm lucky enough to work with the smartest group of people that I had a chance to met. They're definitely much smarter than me, which is not that hard, but they're literally uh some of the smartest guy that guys that I had a chance to to to to to meet and uh basically some of these solutions uh are already presented in other products. But combining all of them and making like the whole uh the whole uh product which will actually address these many challenges is not something which exists on the market. So you need to go back and forth, back and forth, back and forth and find the middle ground.

And through all these you know struggles and discussions how we can actually solve and is some problem actually solvable with the tech that we have today. We needed to find the northstar. We need to find some common ground that we will say okay this is actually our end goal. This is what what the product will look like and this is actually the problem that we are trying to solve for for users and we need to as a team internally and you are actually the first ones who will uh who are out of the team who will hear about this. We need to find okay what is that actually problem that we are solving and what are some things that are pillars of that product and the pillars of that uh these pain points that our users are feeling that we cannot have compromise with.

So what we are actually doing we are building a compliant private and fast crypto payments protocol and what it means it means that it has to have several pillars that we always have to have in our mind and that we have to balance with. So curvy needs to be uh usable in the first place to put usability then to have to be private compliant open of course secure to be uh fast enough to be cost efficient and you might say okay if you have these many things uh in your in your uh product manifest it means that you don't have focus which might be true at at at this phase but this is not a sprint this is not connecting all these pieces that exist already but you need to find like to solve one piece of one problem at a time and then once when you solve one problem you will come to the another problem. Then when you solve that another problem you will create another problem etc. And this chain of problems that you actually manage to solve through throughout time will became your innovation stack and that's what like uh will be the end value for for for our users. So let's break that down piece by piece.

What do I mean by saying usability? First, curvy should be intent based. It means you you remember that I said about on boarding new people. Intentbased means that you just define what your end goal is and Kirby needs to handle everything else in between. It's you don't need as a as the end user to know what is happening under the hood and how it works.

You just need to say okay my goal is to say to send to this uh user 1,000 USDC whatever you have at your wallet K curvy will handle everything else uh in between also if you want to receive funds in need it needs to be seamless it needs to be easy and it needs to work like with your everyday workflow uh either through like ENS integration or like receiving funds from uh centralized exchanges or like wherever you have funds already. It needs to work out of the box without like with zero complexity and without requiring those uh other players from the market to support you and it should be like simple. It it should just work aligned with your with your workflow. Privacy as the second uh important pillar. Privacy is never zero or one.

There are like many many many shades in between, many grades in between. But what it is important is that with curvy it cannot it can never go to zero. But you need to put like the the the power in arms of your user to decide how they want to balance uh the the complexity of like speed, cost and privacy at the same time. So you don't need to force them to be always fully private because it might not be the use case that they need at that particular moment. But you need to give them the options.

Giving them the options mean that at some point we might be like the uh privacy aggregator which will actually uh support you with offering the right uh roots for your transaction and your intents to be achieved with keeping your privacy but with different uh privacy uh score so to say. So it will never go to zero on our side but it doesn't need to be 100% private all the time if you don't need you need just to have the options to choose what are your preferences. compliance part needs to be built in the protocol side itself. At the very essence level at the beginning basically you have two uh in on our cryptography you have two uh private keys spending a viewing key and if you share your private viewing key with someone else like someone who is doing audit you can actually prove what are your addresses and what are your actions without giving them the control to move funds. On the other side, uh anyone externally without knowing your private viewing key cannot connect what are what are your actions and uh which assets belong to you.

So it's fairly easy at the very beginning to prove your actions to someone who who who wants uh to regulators. But all we also have some other checks and one important part of the zary layer is actually to do the ML and KYT checks and to reject the transactions that uh don't don't uh pass those checks. So we make sure that the the relayer parts stay compliant as as well. Openness openness basically means that we are not building a wallet. We're actually building a protocol and the protocol needs to be open.

The protocol needs to be multi-chain and the protocol needs to be something that anyone can build on top of it. So anyone can come and build on top of Kurvy. Uh different applications, different business models, anyone can actually align their business goals uh and their business model with uh what what uh Kurvy is offering. So you need to keep that uh uh in in mind. Security is fairly easy because there is like zero compromise with that and uh it is straightforward so to say um bear in mind that these pillars are not prioritized basically as I mentioned you need to to keep them uh in the balance but with security there is no balance with the security you're just not making any exceptions speed as I mentioned with the privacy part there is also like uh cost and and speed to to to keep imbalance.

So you need to give uh uh to the end user the control how much they want to sacrifice which part of that and basically what makes curvy special as well is that Kurvy can be as fast as the underlying protocol underlying blockchain is. So basically as fast as the blockchain that you are transacting at is uh you will you will get the same the same results with Kirby. And if you're building like a real payment protocol for the wide audience and the wide adoption basically it needs to be fast uh as the thread is and to enable you like to pay with your card uh at to any merchant and to receive like the response in less than I don't know half seconds uh in order to make that transaction happen. So for like real world use cases we need to balance that as well and the cost of course if you look at the architecture of the stealth addresses the architecture of the stealth addresses is like that that you will have your assets spread around hundreds of addresses. So it means that once when you want to move those funds by the nature of it you will have a multiplier because you will have n addresses that you want to send those funds from.

So you will need to pay multiple uh transactions and multiple gas fees etc. And when we started digging deeper into like the cost structure and how the operations of the relayer will look like etc. we came to at one point to the conclusion that it would be like 60 times uh 60 times uh more expensive than sending a regular transaction. So the question mark is like where is the right threshold? I don't have the answer what is the right threshold because it is a very um it is a very individual answer to that how much is someone willing to pay for for the for for for having like the fully end to end private and compliant solution but on the other side uh we all agree and we all have a feeling that 60x is not uh good good range so we need to balance we need to optimize and we need to find what is the right uh way how we can you know reduce the cost uh increase the speed and and uh the throughput but keep uh end to end privacy for for for the user and have all of that uh in balance.

So that's again another another thing that we need to have uh in our mind in a nutshell. If you look like um since we're talking with you know many people and then uh someone will say okay there is this product which is solving this or using this it is a true but what kurvy is definitely not we are not a mixer we are not uh privacy pool we are not yet another stealth address protocol although this whole story and uh our u initial product started with a stealth addresses and although stealth addresses are very important uh piece of this puzzle It's not the only uh the the the only part and we are not uh tied or married to any specific tax solution. What we are actually building we are building a model or payment layer that should have like uh privacy and compliance embedded on the protocol level and that is designed for real world use cases. That means that it needs to be be scalable and that it needs to be aligned uh with your uh everyday business models that we are already used to. Uh we just launched to mainet a week ago uh less than a week ago actually and we on boarded the first 100 users.

Uh maybe some of you are among them. Actually if you participated at the hackathon here at Belgrade or if you flew with the airplane uh from from Prague to Belgrade uh you most probably then staked uh your funds through Kurvy. Uh so I'm beyond thankful also to the ETH beltway team because like when I spoke with Peter, Petra said okay we need a solution for this uh staking uh for this uh staking use case and we didn't even think about that particular use case of uh staking for hack hackathons. So uh basically anything that requires payments can be shifted you know and translated to curvy that requires payments and privacy and compliance at the same time. Uh and that's why I'm like really excited about because like we can shape together how how these uh these products uh will look like.

My goal for today was actually to share with you uh how this uh two years process looked like from from from our angle compressed in these like 15 minutes talk. Uh I hope like that a year from now once when we meet again here in Belgrade uh I'll be able you know to share what actually worked and what didn't work uh in the meantime and I hope you know that uh all these ideas that that uh we presented during this talk will actually be be be live at that point and we will be able you know to share also like the the both success and failures. Um that was it from my side for today. Now we can switch to questions. Thank you.

[Applause] Yeah, first a silly question. Do you support Haroya wallets? Right.

Uh not yet, but yeah, it should be uh supported in the near future.

Okay. And uh do you use in any way the 7702 since you guys seem to be pretty active with EOAs, right? That's how stealth protocol works and we have plenty of them. Is there any use case for you from this particular EP 7702? Yes, the delegation.

Uh well well yeah we are exploring that for the relayer part uh the architecture of the relayer part basically for the stealth addresses as such or for entering you know the the the the system it is not uh feasible. um it can be but it requires you know different flows of funds and then you will break some of these pillars that we discussed about like openness uh you wouldn't be able for example to send from centralized exchanges etc. So it can be done but it it will have you know some different um different things uh to to consider regarding like the cost the opponent's part and that's exactly like some of these questions were also like our internal discussions then when we needed you know to define these pillars and to see okay what are the things that we cannot break uh during our like uh architecture process uh in order like to to find like the perfect solution that that will fit the use cases that that we need. So yeah, we are considering that for the relayer part. For the stealth addresses part, it is still not feasible because we didn't figure out a way uh to build it with that without breaking the the the the openness and cost part.

There is a discussion going on uh I forgot the name of the EAP that u Ethereum uh might support so-called wormholes or something like you know private ETH transfers where you can burn and minted and nullifier is in place. uh on the protocol level. So what's your take on this and you know in general about supporting more of a privacy uh tools on like L1 not on the infrastructure level but by the protocol itself?

Yeah, it's a it's it's a good question because I think that um basically for similar pain points you have different uh different approaches how you can solve that. uh what was like from the very beginning at the for curvy if you remember I said like it needs to work with Ethereum and it needs to be compatible that that the protocol itself doesn't require any any changes on the uh underlying protocol level. So maybe even the protocol is not the the the the right um the right term in this case because when I say curvy protocol someone might think that it is like L2 or that it is you know something which is uh like going in parallel with Ethereum. It is not true. It needs to be like aligned with the with your flows.

So once when we have um like obviously privacy is very important for the Ethereum road map itself and we can expect you know some changes on on the Ethereum side uh to to happen which will support u other use cases and make most probably our life easier uh with with building you know these kind of products. But until it happens like there are also other part and other missing uh pieces of the puzzle that we need to solve on our side in order like to have this wrapped up product that can actually be bridge between like web two business models and what we want like as the web 3 adoption. more questions. I assume that's what will be it. Thank you very much.