ZK Strengths and Limits

Transcript

Uh today we are going to be talking about one of the most fundamental um elements of crypto or primitive of crypto which is privacy and uh we'll specifically be talking about zero knowledge proofs which is zk and uh yeah um a little bit about myself I'm mostly a software engineer I just started doing cryptography and uh I'm with founder of cage or cardiac protocol we basically help um institutions in invest and trade our crypto assets privately and um I also work with project at Zcash. Are you guys familiar with Zcash?

>> Yeah, great. So um I also help with um scaling Zcash. Uh we're working on something called Project Aken and it's meant to improve scalability of uh the Zcash architecture. And uh prior to that I've also worked at previous uh protocols that are focused on uh ZK and implementing uh programmable ZK applications. Uh so yeah so today we're going to be talking about ZK and the future of privacy and uh I'll try as much as possible to um reduce the complexities so we can all like you know get along easily. Uh yeah.

So before I go very deep into um the complex part of explaining ZK um Eric Ugs is is one of the founders of cyber punk and he made a statement about 30 years ago. He said um privacy is necessary for an open city in the electronic age and this was way before blockchains existed. This was when things were mostly text, emails and uh you know web 1.0. Uh yeah so and I think one of the most important thing or important word in a statement is he used the word necessary not optional uh because um privacy is basically our sovereignty. It's um very fundamental to

who we are as human beings and um Ethereum basically builds one of the most you know fundamental applications that we use today. I mean in terms of blockchains and um you know that because it's a public ledger this basically led to what I call the transparency trap and um yeah so we live in a world where every payment every trade every mistake literally every relationship you have it's on the public ledger and um it's literally recorded forever and anyone anywhere can literally access them um via you know ether scan or any scanning tools.

And um you know bringing it back to what the cyber punks were basically fighting for like you know building towards for the future of the internet um they basically they never asked for like you know perfect transparency. It was more about selective disclosures. If I use anything you guys don't understand here just um holler at me. I would explain. Okay. And uh yeah so zero knowledge proves our way of you know um escaping this trap. Uh just to put it in context if your entire life is basically a is basically public it means people would be able to um access where your personal information is publicly people would be able to know that you know you guys are

literally here today publicly. You guys paid for a beer at the bar just because you use USDC and um it's available publicly. So uh this is what ZK basically um helps you with and uh yeah so moving into the topic of today are what the f is [laughter] what the f is zk so zk basically proves truth without [snorts] actually revealing the evidence. It's basically lets you show correctedness uh without showing the data. It helps you prove a fact while um uh while keeping the fact hidden. Okay. So it helps you reveal the result of something but not

the impute that you actually made or yeah it's basically proof without disclosure and um yeah so oh yeah got it. So uh to prove the validity of a statement. So this is me trying to explain um the underlying factors that make ZK what it is. I would still go further along as we progress. Um yeah so to prove the validity of the statements without revealing the statement itself. Um there are mostly two parties involved that you know makes ZK work. One of them is the prover. The next one is uh the verifier. And um in some instances we have um third parties

which are called um the issuer. So how does this work together? The prover is the person trying to prove something. Um the verifier is the person trying to validate that whatever the prover is proving is actually factual or real. And um the verifier could be somebody who actually issues the um um sorry the issuer could be somebody who actually issues the particular information that needs to be verified or proven and then you know it could be the government it could be anybody literally and um yeah so um I'll give you guys a real life explanation of Zik in the real world so you guys could you know really

understand uh what we're talking about in terms of provers in terms of verifiers in terms of issuers. So, uh what exactly does can does ZK do and how does ZK work? So, um ZK could enable you prove that you weigh less than 100 kg without actually, you know, making people know that you're actually 99.9 kg. Basically, you weigh less than 100 kg. So, uh, for example, if you, um, if you get your report from the health facility that, you know, this is your weight, you want to prove it to be able to fly or do something and you don't want to show your actual weight. You just want to show, yeah, I'm, you know, lighter than 100 kg, you could prove it.

Uh, you could prove you're old enough to drink. Uh, you're 18 and 1 month old. Uh you could prove you paid your taxes without actually revealing your income based on the threshold. Uh you could prove you literally attended this talk uh just like we use pope. Um you could prove you're rich. You could prove you're poor. You could prove you're over 18. You could prove your credit score is above a threshold which I explained. And you could prove you're 6 feet and not 510. You know the Tinder conspiracies and uh so much more. So um a live um implementation of ZK is the Google wallet. Um if anyone here is based in the US, you can basically um upload your

driver's license or your passport to the Google wallet. And um if you're trying to like get a pass of something, maybe you go to a bar and they want to, you know, want to confirm if you're 18 years, but you just want to show you're above 18. You don't want to show your date of birth, you don't want to show your uh country of origin, you don't want to show all of those informations. you just want to prove you're 18 years. So if since you've uploaded your um ID to Google Wallet, Google Wallet communicates with the issuer which is the government that gave you the ID to be able to verify those informations.

And once you just, you know, tap to the um to the bar or the club you go to, uh some of them have devices, some of them just needs to see a proof that you're yeah eligible to drink or something like that. you could literally just you know pop up your Google wallet and say yes I'm eligible to drink and that was like you know a real world use case of using zero knowledge pros and um yeah so how is that possible how does this work without just you know how does provers work how does verifier works what are the underlying cryptography underlying mathematics that enables this um happen yeah so um basically proofs comes in two categories we have interactive proofs

and non-interactive proofs. Um interactive uh proofs are basically the ones that uh we use mostly in web tree and um be and I'll explain why. So before I go there I'll probably explain non groups first. So this is um I want to use this as like a case study. So just imagine that you know there's a ring shaped curve and um there's a gate inside a ring shaped curve that basically requires a password for you to go through and um your friend um you know you're the prover your friend is the verifier and um your friend wants to prove that he knows a particular

information because he's the witness. He has to go through the gates. If he goes through A, he's going to uh have to go through the password verification and uh he could tell you I'm, you know, I went through A or I went through B while he's inside the gate. And if he goes through B, he just he could go in and come out the same way. So, um what's the point of of all of this nonsense? Uh the point is basically um interactive is basically the prover and the ver the verifier having to communicate every time um on the validity of a statement or the validity of an action basically. And um yeah so okay good. So um like I said earlier if

you entered through side A you need a password to get through through side B. And if you enter through side B, you could just come out the same way without having to like use the password. So, and this is a good example because it shows like you know um whether or not you're required to use the password uh while doing this challenge. And um yeah, so this literally makes up um some of the core fundamentals of ZK proofs. Uh there's the weakness, there is the um the challenge which is the question, and then there's the response. And we also have um the witness which are witness provers verifier like challenges. So this is basically not very um sustainable in terms of interactive

proofs are not very sustainable in terms of um blockchain applications. Uh why? Because they have a big limitations. They have a big limitation. uh the even after because most times even after the verifier is like you know satisfied that yes okay my friend knows the password and you know I believe is uh uh it went through the tunnel the communication is only between the prover and the verifier third party could not cannot verify that you know this guy's actually um know the information or have access to this information and u yeah so that sums up the slide and uh Yeah. So moving into non-interactive proofs, like I explained before, there are interactive proofs

which I just give you an example of communications between both of them and non-interactive proofs which are used in most ZK blockchain related applications. Um there are two types of non-interactive proofs. Um the first one which is very very early and one of the first to be implemented. uh Zcash was actually the first to do a running application of zero knowledge proofs. Um so it's called zk snacks and then there's zk stacks. We'll talk about zk stacks later. ZK snacks means zero knowledge sustained non-interactive arguments of knowledge and um the zk stands for zero knowledge which means not having an information about something. Uh sustain test because they

are small and they are quickly verifiable by the verifier. So it doesn't you don't need to take so much process to actually verify particular set of information and non-interactive which I think I've explained it means there's only one round of communication between the prover and the verifier you don't need to do the back and forth every time it's just once and arguments means it's theoretically based on math and very very extremely unlikely to be able to fool the system or be able to trick the system into like passing an information that's not correct and I would explain why you know this is and um of knowledge can't be constructed without having access to the information and um I think uh just to explain

further uh ZK snacks they use a cryptographic primitive called elliptic curves um basically it's a method of creating and verifying this proofs and um one thing about zest is that during the initial setup phase case the prover and the verifier must literally agree to use a shared key. Uh this is called CRS which is a common reference string and anyone with this anyone with their access to this key would be able to have details or have information on what was actually verified and what was actually proven and um basically this is what makes Zika Snacks possible. Okay. Yeah.

So to break it a little bit further um zax consists of um three major functions key generation, proof generation and verification. So um ZK snacks really comes down to um these three algorithms the setup which is the proving um and verifying. So everything else is scaffolding. So basically at the setup you create the keys at that point in time. Um I think I explained at first what the setup entails basically the pro and the verifier keys. So um this is where the system basically takes the circuit. I'll explain this also. Um and um the system the the statement that we

actually want to prove you know we could say uh so when you see okay I think I've not okay yeah so for the setup we need cx w is the witness yx is the public impute of the information that you tell. So you create a witness automatically and then we have a proving key which the prover would use to construct proof. So this is W which means witness X is the public compute and um PK is the um public key private key sorry. So if the um if the prover which contains both the public impute

and the witness is incorrect or the PRF which is what is generated basically at the moment you prove wouldn't be valid. So it could be true or false depending on so this is why when I said theoretical it's almost impossible to bypass or to full seek a proof is because uh there's basically math behind it. And um yeah so um a proven key which the prover will use to construct the proofs which is the PRF and um a verification key which is VK and um the PRF which is the proven key and then we have X which is the public input. So a verification um the verification key is what you

could use to verify that the proof was you know uh made and either the proof was valid or invalid. So um basically so at a very very high level um zik snacks are just compile you compile a proof um you prove it and then you verify it. Compiling is where you set up the information the public imputes and the keys and um proving is the computation where you where you generate the PRF and then um verifying is the verifying key which you as a user will be able to verify a particular set of information.

So just to take this back a little bit to our first example. So there's a correlation of um of thoughts or explanations. So when um you want to verify that you are above 18 to be able to drink someone or the developers basically set up the proven um the done the setup of the provers and um so at the moment where you prove the witness is your issuer for example like the governments they know that they know that you proved and um the public imputes is the information that you uploaded and then The private key is the one that you are the only person that is

able to like you know verify this particular set of information and what the verifier just needs is the verifying key and um the PRF which is the proof that was so whenever a proof is completed it creates an ash function um have you guys done a transaction before using Ethereum so you know it has an hash function on the on it stand so basically that hash function is on the verifier and they could you know verify the app function which was generate which is the PRF that was generated when the verification took place and X your public and um yeah so I think one very very important thing to note is both the prover and the verifiers although

explained math they are all algorithms they are not um engineering it's basically algorithms all so um yeah talking about stocks Um I'm more of a snack builder. So I'm not a stack builder. Uh I think stacks could be best explained as the cousin of um ZK snacks. They came very very much later. Vitalix calls them uh the cousin of ZK snacks. So snacks means or snacks rather means zero knowledge scalable transparent arguments of knowledge. And why is this scalable? It's um I explained that snacks were succinct which means they you know require small

proofs. So rather than stacks being succinct they are scalable which means they could generate and verify proofs with like larger weaknesses. Um the previous the previous explanation I gave to you was um you only did like you know probably just one weakness to be able to um assess that this particular set of information is accurate. ser you could use a host of witnesses and um yeah and it does it way more efficiently than zax and uh yeah they're transparent they're not basically private um by nature although you could build more cryptographic primitives that make them private um I think another very important thing is that there's no

trusted setup um what I mean by trusted setup is when I was talking about setup at the previous slide I told you there was like a general generation place and the um setup where you generate the PK and C and X keys um for stacks there's no setup so it's basically publicly verifiable randomness to be able to generate the shared key and um yeah that's about story I won't be going deeper I'll probably publish a blog later on this in case you guys want to read and uh yeah so let's leave Matt for a little bit and then we'll go back to Right. So, what are the use cases of ZK?

Um, Helon, like I said, Zcash use ZK for private transactions. Sorry, I didn't attach as much logos as I should. We have a lot of applications basically using uh ZK in production today. I was just very very lazy to start looking for their logos. So, um we have Zcash for private transactions. Um they also use snacks. Uh we have to cache. I'm sure a lot of us are familiar with cashache. Uh there's ZK money, there's um Pasteek, it's an Ethereum L2, you also use ZK, there's Miden, there's a host, there's inmax, like a host of um ZK production.

And then we have ZK for scalability. So we have ZK for privacy and then we have ZK for scalability. Um and basically stacks are used a lot for scalable uh solutions. you know, upgrading the blockchains, being able to verify informations faster with multiple witnesses and all of that. Uh there's um ZK sync doesn't use stocks, by the way. They use um snacks. Um Polygon EVM, I think they use Snacks. And um there's Cairo. Cyro where Cairo is stacknet. You guys are familiar with stacknet. The Ethereum L2. Okay, great. So yeah, you'll be disappointed, but yeah. Uh so stacknet is a very very famous Ethereum L2. They use um zero knowledge stacks to

scale the blockchain and um yeah for identity solutions we have ZK passport we have um mo ID we have um Google wallet like I mentioned and a lot of cases so um fortunately unfortunately we are only talking about privacy so I'm not going to be talking about like other use cases of privacy of um ZK outside of outside of privacy related solutions But basically outside of this zikk could be used in healthare could be used in um analytics data could be used in um um it's currently used by adil the defense tech company. Um so yeah could be used

in as many fuses as possible for health tech. You could imagine that you want to um probably go to do a blood test but you don't want them to know your origin or whatever. just want to give them a particular set of information and you want them to only see that information you're giving them. So there's way a lot of uh use cases for ZK but primarily for uh privacy private transactions I could send you a dollar and nobody else on it would know that we actually made a transaction. I could do it anywhere to anybody in the world. uh you could scale the blockchain with it and I could prove uh I could protect my identity with zero proofs. So uh yeah so yeah um let's talk about the beauty of

the mathematics. I will try as much as possible to scale down some of the components that u makes zk possible. So I started with sudoku because I think we are familiar with sudoku the game. Yeah. So um basically I'm using sudoku to represent circuit. Circuites are a fundamental in in zero knowledge in zero knowledge proofs they are um constraint puzzles. So basically if you're playing sudoku every box has to and every column they have to be um they must satisfy the rules of the game. You can't put a random number in a random box. So um u security works the same way. You have

a secret solution and the system checks whether all the constraint are satisfied without ever revealing the solution itself. So imagine if you have a um a sudoku puzzle and there there are numbers placed everywhere and you could actually verify that those numbers are actually accurate or inaccurate just you know based on zk. So circuit works in a similar way. Um yes and the next one is um elliptic curves. So elliptic curves are um they're basically like the uh playground. So that's where you use structured algebraic addition and multiplication

um to behave in predictable ways um and predictable and verifiable ways. And um then we have pairings. Uh pairings are like magical to nails basically. sorry basically between two mathematical spaces. So you could use pairings to compare um you could use them to create information across across groups and like you know compare information across them and um you know they're what makes they're basically what makes um ZNA succinct and you know they help with like smaller proofs because you could do easy comparisons as they scale and um they also help with fast verifications and um so uh don't worry if you guys are

not really deep into cryptography. The important idea is that math is beautiful and um this structure is basically you know obviously what enables ZK prove that um prove the truth of something without actually revealing information about itself and uh yeah when most people hear ZK feels like magic. This is basically because of algebraic circuits um pairings elliptic curves these are the fundamental um primitives that basically makes zik possible and um yeah I have this actually okay great so um yeah we have all seen zik is very very powerful uh it's a uh technology that doesn't rely on human errors it relies

on mathematics which a lot of things that we basically use today your devices has a lot um mathematics based implementations and um yeah but it also comes with its cons basically because implementing ZK in production is very very hard and it's very very messy. It's uh and I'll just go over some things that people don't like to talk about. This was supposed to be more of a depth conversation, but I'll try to um break it down in a way that we could actually understand its limitations and not just its limitations, but its limitations with the implications of tools or products that we use that use ZK cryptography.

So, um yeah. Um sorry, I use programs ZK. I don't know what that means. Just sounded nice. Uh so basically so all the problems that happening um that happens with ZK they're not just random are they basically they basically comes from all the primitives um underneath it. uh the prover cost basically when you're proving a particular set of information it's very expensive because it relies on um very very heavy maths amount amount of maths um and they're really not a flaw there just a consequences of mathematics so

zik snacks also rely on like elliptical cves like I explained um MSMS FSTS um very very large circuit like the sudoku I explained and um you know so proofs are basically expensive uh to generate and uh then there's a lot of bugs and constraint fragility I would explain this so uh what I mean by constraint fragility is that a lot of um the circuits that I explained earlier again they are very very fragile so if one piece of if there's a one if there's one piece of information or one piece of constraint that goes missing and um or or one mistake in a polomial

commitment is broken the whole system is basically like dead. So that's a very very important thing and um you don't even see it because it just happens silently. So um there also metadata leaks uh because ZK doesn't cover your um it doesn't [clears throat] cover the network layer. It just encrypts particular sets of information. I would go on to explain this further and um ZK basically only hides values of information. So whenever you make a transaction it obviously hides the value but then there are other things like the timing the routing uh what channel the transaction used to take place and um you know who related the transaction. Um

you guys know of routers like um um what good routers like Jupiter on Solana, Meteora Uniswap. Yeah. So uh these are routers. So if you do a transaction between yourself or you try to do a um a trade so zk could hide your addresses could hide the amount of your addresses which are the values but it might not if you don't you create new encryption to be able to encrypt those information uh those things will still be available and you could get doxed. So and uh yeah um on I think I've explained su fragility um basically you don't um I think from a developer point of view you

don't just debug code as a developer you basically uh debug algebra so if you're not really good at math it's very very bad and um yeah there's also the trusted setup risks uh this is a very very huge uh problem that a lot of people taking Zik to uh main spaced. So at the moment of creating proving and verifying keys if your setup is basically compromised you know somebody can like you know for valid looking proofs um and then you know get access to every information that gets u transmitted over the blockchain and um user experience is

horrible. Uh but then some of these problems actually getting fixed by the way um uh ZK um solutions and public currently being used at large. I personally worked at min protocol. We um basically um reduce the amount of maths developers have to do. So you just use your normal TypeScript. We created SDKs that you could use to build applications that rely on ZK without actually understanding the math behind it. Uh so we just abstract the matter where you just have to do normal engineering. So um what else? So yeah all the problems with ZKS are just side effects of the same mathematics that makes it powerful.

So a lot of us would not really care about this part of ZK. We just want to use ZK related app apps for the benefits that gives to us. So this is why I had to like you know implement this slide. It's um the illusion of privacy. I mean it's all an illusion. So um and basically what I want to talk about here is there are a lot of wallets there are a lot of applications that promise privacy and they are actually truly not private because and um because most ZK based applications they require something called a viewing key and this viewing key is a special key that can

decrypt all your transactions. So ZK alone and because you need to be able to view your balance. So that's what the viewing key basically does for you to be able to, you know, you're on Metam Mask, you want to see the amount of money you have. Um, if it's a private Metam Mask, you're going to need a viewing key to be able to decrypt uh the Ash and be able to see your balance. So that's why viewing keys are like essential in most ZK applications. So um so the problem is most of this wallet they use just zk and they have access to everybody's viewing key or to all the transactions. So if they get sanctioned by the US government or by any government they could literally just you know give access to

all your informations in public because they can decrypt your transactions. So your favorite ZK wallets or your favorite privacy wallets might not be truly private and um some you know some are like exchanges custodians compliance sometimes even the RPC nodes or even the operators that have access to your viewing case depending on the architecture of um the applications and there are a lot but I wouldn't be mentioning them so d and uh yeah so in this applications who can see your transactions Um because of ZK setup, some people still deploy their ZK applications on AWS and when you deploy there, they still get to

be able to, you know, decrypt your transactions. Some Zika applications have compliance partners to prevent the sanctions that happen to Ted Cash. You can see so this uh compliance partners can literally literally encrypt your transactions. Um some of them actually even l the viewing key during you know backup or when they're doing exporting of transactions and um some of them relay your transactions through centralized relayers. So if you see a privacy wallet that uses uh unis swap or lei or um stargate or any of these routers and you didn't see anywhere on

their decks where they have something like you know encrypted mess or encrypted routers set up it means there's a lot of possibilities for them to be able to decrypt your transactions. It means you're not fully um you know like you thought you were. So um some hardware wallets also store your uh viewing keys in plain text because they are not customized for private keys or customized for private wallets. Um custodians of your wallet can also see it. Um yeah, basically everybody can see it. So you just have to make sure you're using um the right wallet.

And uh why does this happen? I think I explained it before. It's the way ZK works. uh you need a viewing key to be able to do balance display. Um some institutions must maintain auditability. So they need viewing keys to be able to do compliance uh to prove that yes uh we made $1 billion this year and uh this is you know our transactions. People on the public can't see it but you know the tax agencies can see it. They have to. Um also some snack schemes are not designed for selective disclosures and um proof to basically only hide what the circuit hides. So this is a very very fundamental part and um uh I think one

way this has been uh getting fixed is uh something called client side proving. So basically you don't prove um uh when you use a privacy hack for example ZK passports well that's why I listed them there if you use them the proving doesn't happen on their servers so there's no way they get to see the private keys actually happens on your device so uh they found there are ways they were able to like reduce the amount of proving size so your phone can actually do proving or your laptop or your devices can actually do proving but this means it's it's a little bit large.

For example, for an identity app, it's like 500 megabytes for just, you know, scanning passport. Doesn't make sense. So, yeah, that's just the uh cost of it. Also, u be careful about compliance rappers. a lot of mixers today or a lot of um pools today or to cache duplicates, they actually have compliance and um this compliance actually have the viewing keys to be able to see your transactions and uh yeah I think that's about that. So one important metric to leave ZK basically hides the values the nodes your balances uh state transitions and your addresses.

Uh it doesn't protect who relate the transactions. It doesn't hide um timing correlation. It doesn't you know decide who gets to see the viewing keys. Uh it doesn't help you in any way with RPC leakage and you know relay user link. So uh this doesn't mean ZK is not um uh useful. It just means there it requires like other primitives to be able to make it actually sustainable. And some applications are actually using this other primitives but some are not or many are not basically and yeah so possible solutions how do we solve this?

Um on the computation part you could combine ZK with MPCs. Um NPCs are multiparty computations. So it's basically um instead of one witness to be able to uh do like comput computations, NPCs could connect multiple independent witnesses or like let's just call them validators to be able to you know it's a decentralized way of proving rather than just the operator being the witness and um yeah so it means no single laptop can you know compromise your privacy. Uh there's also FHE. I personally love FHE a lot.

It means um fully homophobic encryption and um okay so just imagine this um you have I have private data of everybody in this room um automatically submitted to a form but I don't I use the private form so I can't see your personal informations but I want to run a computation or an algorithm or I want to use Google Analytics on this particular form data I could actually use put this data on FHE and be able to actually do computation on this data blindly without actually seeing all your informations.

So I could do an head count of how many people are here. I could ask the data for um informations about you know where are people from here, what countries will they come from and I could do all of this blindly without actually being able to see all of this information. So um [clears throat] Z um FH is still very very experimental. It has mostly been research papers until just a few years ago. So um I don't particularly trust it yet for production cases but excuse me a combination of Zan it's a very very good uh use case that's and that basically you know removes that part where somebody has to hold your

ving key or an operator or the custodian has to hold your keys or it could just be on an FG basically and then there's Z there's T means trusted said um execute execution environment or something similar to that. Um so TE's are not mathematics T's are um machines they're devices they're like servers um Intel SGX etc. So they do private computations of information and they are fast. But the my personal problem with CE is again this is a personal problem is because it require it's it's dependent on hardware and it means if you store your applications data on an hardware if a

fire gets caught up or somebody targets that particular data center it's really so um not as secure as Zika itself but yeah it's fast it's does basically everything is meant to do but it requires hardware or it's dependent on hardware. Right. And um yeah. Okay. Yeah. So I talked about the fact that ZK basically encrypts values and not the um network or execution layer and all of those particular information. So there are other ways you could actually um the other primitive you could implement alongside ZK. So for Kag myself my startup we basically use something called private intent. It means whenever

you do whenever you want to let's say you want to do a trade for example uh you select um Ethereum to USDC uh you want to put a leverage of 20x you want to use a cross margin of this amount you want to do all of this so these informations are passed to the to something called we call solvers encrypted so there is literally no public channel of your messaging or the intent of what you want to do and that's what we call um private intents. So the way it currently works is uh there are cross messaging protocols like across like wormhole uh when you want to do a

transaction they use intent. Intents are basically just um I mean intent like the word in the English word intent it means a request to do something. So the user experience might not feel like you know you are passing a note you might just be clicking buttons but the back end understands it as an intense. So uh we use this intense privately and then we have private meles which means um even if we want to we don't use any third party um routers but even if we want to uh we use only we use them privately. So we could we could um use a router through a shielded pool through our servers to be able to do um private

transactions of any form that you want to do. And then um there's there's also mixn nets um basically it's it's mixnet rely on they protect your IP uh through RPCs they uh protect the timing the routing information and all of this information and um yeah they are great. So the end game basically would be making sure you have encrypted states, encrypted execution, uh zk verified consent uh correctness and smart contracts where no one can see what's happening but everyone can verify the result. So um I think a live application of this I mean

they're test net still but um is Aztec the Ethereum L2 and I'm not um posting any project. I've just personally built with our tech and they actually deliver on they've been building for 8 years. So they actually deliver on all their privacy primitives and that's probably the only thing I'll talk about and uh yeah um good good shall I proceed? Okay, great. So uh yeah personally uh ignore my very very nice fancy name uh I personally think crypto is not crypto without privacy. I think privacy is a very very fundamental uh value that makes crypto what it is today. Uh it doesn't make

sense that you know we exchange freedom and sovereignity for transparency and um yeah um privacy means privacy is normal. Thank you everyone.