Privacy's HTTPS Moment

Transcript

Hello everyone. First of all, thanks a lot for staying here till the last talk. Appreciate your patience. Uh and one more mention is that uh instead of me at this stage should be our CTO I mean Solommani maybe someone knows him and unfortunately because of the visa issues he wasn't able to make it till here uh but I'll do my best to kind of showcase like this this topic and make sure that uh you'll be interacted like you were with I mean maybe less jokes but I'll do my best so bear with me. Uh the talk is that uh about HTTPS and how

isn't the privacy still isn't the privacy still the same thing. So nobody in this room basically uh thinks about this uh small lock there in Chrome browser you won't even even see it by default you have to open the settings and stuff in Firefox or Brave you will see like the gray out icon which is uh hidden by default and it's because of the consistent work which was done by many engineers to uh make an uh adoption of the uh HTTPS uh a normal uh thing uh in your browser.

Um it's hard to say that no one pays attention here since half of the room it's probably builders and cipher punks. However, for the regular user, we can assume that uh it's not a big thing. So it wasn't because um people learned on how to use the uh TLS or like it was a deliberate choice. It was uh made for like a continuous process and there's a couple of things of that.

So it was embedded. So even though Netscape uh developed this in 1994 uh you now had this by default and they did not claim the executive rights for that. Uh they just uh made it possible for everyone to use that. It is also free. You don't pay for the certificate that you use. You just uh can register this uh with the Let's Encrypt. And currently they're registering 10 mil or maybe even more a day of certificates. So everyone can do that. Um this is trusted. Uh any website which has like proven your certificate uh uh will authorize you and secure the connection.

So right now with the privacy onchain uh the things are not looking that well. So we are going back in history till like the HTTPS in 1999 uh the HTTP sorry in 1999. So privacy works as back then with the HTTP if you're an expert and if you know what you're doing. So maybe most of the people here uh you will be trying to find a good protocol a good relayer uh a good uh connection using to maybe or uh whenever to secure your connection. You also need to kind of um remove your normal habits on the timings or how do you process uh the notes. Maybe someone

heard about Vitalix mentioning the agents to kind of randomize uh on how do you like you know show your onchain activity. It's kind of hard uh for the people for for the normal people to follow all that and do all that and more than that even you're doing everything right there might be a cost and the cost is that uh your funds if you're using some privacy protocol and don't want your activity to be visible on chain they can be uh on hold uh by the text because of their regulations.

Um they can be frozen or you can uh kind of lost your funds or um someone who you're interacting with can like showcase that your um your fonts are tainted and uh now they don't want to interact with this and this is uh I would say a huge problem for the community. Um this is what I'm talking about like uh the if uh which was which is coming from the regular privacy protocol doesn't equal to uh the normal if and you definitely need to do some you know

workarounds in order to make it work. Um, and we also have the situation when if you're doing uh like a regular privacy protocol, it's like you're doing a self-signed certificate. Yes, it's the same certificate. Yes, it's same size, same length. It does also work. However, no one u vouches and can validate that this certificate is actually legit. uh like uh you know that this is correct but you need people to trust you that this is correct. So we need some trusted authority. Uh same things happening uh with us. So we're trying to deal and solve with this the same problem. So

the funds from uh our protocol are credited like a normal EH and you don't have to deal with the uh you know restrictions and they accepted on any text and this is uh something that let's encrypt made possible with the HTTPS. So yeah, as I was saying, uh this is uh our goal here, but this was uh mainly uh already spoken by uh Mike here. So I would mostly try to focus on how do we process things here and how do we make sure that your fonts are safe and can be used afterwards on any other platform that you want. So after the initial screening

and um after we see your transaction on the blockchain uh we put up an ASP which does uh um complex like processing of your uh deposit. Uh this contains of uh the internal screening of the KYT. Uh we do not uh require any KYC or your identity to be present. So we doing the onchain investigation on how did you end up with the with these funds. We're just making sure that uh your wallet is safe uh to be let inside the pool. We also um partnering with uh KYT providers

which uh allow us to kind of see the funds history. However, um every you know Ky provider has its own like you know cons since uh and this is why we're trying to make our uh system to do u most of the stuff internally. Uh after that you have an outcome and you either can be uh approved inside the pool and uh to continue use your funds uh privately or in the worst case scenario you will be not approved but you can instantly uh withdraw your funds back to the original wallet. So we uh are non-custodial and we do not track

your funds basically. Uh after your fonts are inside the pool uh what you can do is uh like basically bunch of stuff. Uh this was mentioned. What I will say is that the system will continue to monitor and uh do the um ongoing investigation and funds will be rejected over time. uh we will uh dive a little bit more deep about how this works uh during the next slide here. So why do we need that? U every deposit uh it cares it's all our origin and this is the label which is assigned to every

deposit. It's a privately computed uh unique uh identificator of your deposit. And this would be uh assigned and stored privately. And only like this is the difference that we that we did uh between the V1 and V2. And the difference is that uh current like on V2 label is uh stored onchain in the encrypted form and only ASP uh does know the label uh that you hold for for this deposit. After that you can do whatever activity you'd like. For example, if Alice wants sends fonts to Bob uh and Bob later does some other activity and

already multiple hops were uh provided uh and somehow it happens that uh Alice is a listed actor and we did that with a continuous screening. So we did not know that at the time Ellis made a deposit and we screened it and let her inside the pool. So at this point we can flag this retroactively and remove this label from the association tree. And in this case uh the funds will be uh uh removed from the pool even like after they made some hops. So the current owner of the funds uh they will be able like uh it's only the uh page quit function after that. So it can only go

back to the original wallet uh but not be able to stay insetable. What I'm I'm trying to say here is that privacy it should be available for everybody and we highly encourage builders and everyone who like wants to support onchain privacy to try it out. This is why uh we are putting a lot of effort for the TypeScript SDK for the Rust SDK which will come out soon for the mobile uh wallets and uh builders which want to create integrate with

mobile. Uh maybe some of you saw the presentation of Kohaku. So the kahaku SDK also will be supported on the privacy pool and the good thing is that like an HTTPS uh it doesn't cost nothing to you. Uh so screening is basically on us of course uh and we do not charge uh the gas token for for withdrawal. uh the layer will facilitate this for you and just take uh its um cut and while you're inside the pool you'll be also able to generate the yield uh in order to kind of your fonts not to lay still but uh accumulate some

uh value while you're continue to use the pool. So one thing which I want to specifically mention like take as a case of the adoption of the protocol and and the privacy would be the cold start. Um because there are multiple ways to kind of uh get inside a pool. First one is the basic one like you're registering directly. You have some wallet you have your wallet and you have some funds on it. You're connecting it and uh then you'll be inside the pool. The second one would be uh the gasless registration uh when like the relayer will um take this and submit it for you like and the

cold start which we're trying to take out here. um is the situation when you want for example to uh like on a real use case you want to pay your friend or you want to invite some user to use that as well or you want to uh do the business transaction and nobody wants to do that nobody needs to see what this transaction is about and on this example the Alice wants to privately pay Bob for whatever So Bob somehow needs to have the wallet in order to receive the payment and let's say that Bob registers as clear wallet

uh which doesn't have any funds on it. So ideally uh like he would be like facing the problem that Bob um needs some gas in order to receive the funds. Uh but in this case what we will do uh we will uh do the offchain transaction of the uh no um we will send an offchain link uh and Alice uh will deposit to the fresh address which was sent to her by Bob uh and even though the wallet does not have any funds Bob can visit the link He will

sign the message uh will be registered in the key certificate and u relayer then takes the uh Bob's funds it register it on his behalf and uh just takes the gas uh for this transaction and Bob can use the funds even though uh no funds were like uh on this wallet before. So any fresh wallet can be now a user of privacy pools. Uh this allows you to kind of stay uh hidden and um don't uh expose your privacy.

So what we're trying to do here, what we're trying to address is that the privacy on the on chain should be as default as your the privacy now in your browser. Ideally, you don't even need to know that you're doing some operations in order to preserve like your privacy on chain. We don't need users to know that they so something happens under the hood something uh computes and something validates users just need to have that by default you don't even need to see right right now you don't even need to

understand how and what is the TLS and how does it work you just enter this the website and you have your connection secured uh we want to achieve uh the similar thing uh for the onchain and this I would say would be our goal if you if you want to help us and we highly encourage you first to give it a try. Uh second uh we have an open source SDK. So it will be cool if you want to build something on top. Uh this would be highly appreciated also. Um and yeah, if you have u any ideas on how can you improve privacy or how can you

build on top of the protocol, we'll be h help happy to help you. Uh yeah, I think that would be it. Thanks a lot. >> Okay, so we do have a few questions. Could I get the Mircat screen up, please? All right. How many years until most onchain transactions are truly private by default?

Well, basically it depends uh and it depends on us and as soon as we will mass adopt the privacy and as soon as everyone understands that this should be uh a thing by default and uh we should not you know encourage everyone and uh say or begging uh please uh do it the private way. As soon as we have the understanding ourself and start to implement the tools which are working flawlessly like the HTTPS does that user does not need to do anything. Uh I think this would be the breaking point when uh the most of the transactions will become

uh private. >> HTTPS won because browsers and Google force the switch. Who plays that role for onchain privacy? Is it wallets, L2s or Ethereum? Well, yeah, this is the really good question because um right now you cannot be enforced uh to kind of use it the private way. Uh we now have a lot of thoughts and a lot of talks of uh Ethereum moving uh to the ZK model of uh of the validation. So I I would say at first uh it will be the user who decides that who u like m makes the switch to

the uh private mode. Uh later uh we are we'll see because it's ongoing discussion and uh Ethereum itself EF has some thoughts about how can they make it possible on the protocol level. uh there are uh kahako implementations uh which will work like from any browser and from any wallet. So we'll see for now we don't know. >> Doesn't compliance break the 1/8 is one e rule.

>> Uh probably not. So this is the um like a debateful topic because uh we had a funny situation when uh you have someone from privacy pools uh talking about them then you have the guy who does the critique on that and then you have again the guy from the privacy pool. So this is a good thing because uh you can make your own opinion on that. Uh what I will say is that if it would be really easy and possible to make a permissionless system which will work flawlessly uh I would be the first guy to adopt it. I will uh be happy to do that. However, what we've seen in the in the past is that you can have the situation when

even like a minor portion of bad actors can spoil like or can poison uh the um the pool of trustworthy people who just wanted to stay uh private and do it for the good things. Uh privacy the compliance makes it possible to kind of separate the good people which want to use that u in a legit way and let them do that and not being like restrained for from the rest of the chain. So in this case I would say that one if would be equal to one if um however I would

say you heard like multiple opinions on that and it would be great if you will make your own decision. >> The previous presentation said privacy pools v2 can freeze the user's default. Is it true? Uh no the both V1 and V2 uh are um non-custodial. So at any point any uh depositor doesn't matter if he was approved or rejected by the system they can do the withdrawal function uh oh sorry the rage quit function which automatically publicly withdrawals the the funds back to the original address.

So we do not hold uh the funds at any point of time in in any scenario. >> Okay, 30 seconds left. How does certificate verification work in HTTPS? So you have a centralized uh provider which is the in this case it's uh let's encrypt and when we entering uh the like when the connection established we have the verification from the let'sit grip that uh your https certificate is uh legit this is similar to like you can do that ourselves. Uh that's what we

called the self-signed certificate. However, the less encrypt lets everyone know that this uh certificate that was issued is fully legit. >> Okay. Well, since he's the last speaker, I think we can continue with these final questions. How does protocol usage uh or how would protocol usage work with existing dexes? Would they need to adapt or can this work as is right now transparently? Oh, so for the uh V2 SDK, it's fully possible to integrate it with the DEX.

Um because um SDK gives um wide uh opportunity set for everyone who wants to um integrate it. It also can work for like um high frequency operations I would say with the like one distinction is that uh this should be pre-approved uh deposits. For example, if you're doing the auction, what you need to do uh is to just have the maximum threshold or the white listed subset of uh this auction. Then we will be able to even do that uh on the like subsecond interval for the high frequency operation. So yeah.

>> Okay. Okay. And the last one, let's encrypt was a nonprofit and supported by Mozilla, Cisco and so on. Should onchain privacy go with a similar approach? >> I would say yes. And uh in the end we should end up with a situation when uh you have that uh by default and uh this is uh globally adopted and um you have a full right to use it everywhere and at any use case scenario. Uh would it be possible soon? It again it depends on the builders and on the community if they will be supporting this uh or not.

Uh our goal would be to provide the uh initial initial tool to showcase that this can work and this is the good way to kind of start using uh onchain tools differently and uh make a change which will eventually uh become uh a breaking point and which will change on how people use the chain.