Session 9 - Intro to zkVerify

Transcript

question on Wednesday is going to be also you or mea because she told me 27 is going to be you but I don't know for Wednesday. >> Uh we hope she'll be back on Wednesday but I will have to check with her. >> All right. I'll put you on the calendar invitation anyway. So >> sure. >> All right. I think we can start because people sometimes can be come after 10 minutes and I don't want you to wait that much long and >> got it.

>> Yeah, >> sure. >> You feel free like floor is yours and >> got it. Sure. >> I share my screen. Hey I hope you guys can see my screen now. >> Yeah, we can see. >> Cool.

Uh yeah. So I guess you have uh a lot of lectures before to this where you guys explored a lot about zero knowledge cryptography starting from >> question. >> Um just uh yeah uh we can see your your camera uh like >> oh >> I think it's going to be better for everyone. >> No like if if you're free. If you don't it's that's okay. >> Oh yeah. No it is okay. I hope you can see me now. Yeah, right now. >> Yeah.

>> Cool. Uh yeah. Uh so I hope like you guys have been reading a lot about CK uh starting from hashing functions what I heard from Elitza. You guys explored a lot about hashing functions and KG and actually writing some circuits at CIRCOM. Then you also got some lectures from Ato about Noir and all those things. So maybe this is your last uh week or the second last week and in this uh week we'll be trying to focus more on how to apply all those things which you have learned to actually build ZK products or ZK applications out here and ZK verify itself is a very big part of it. Uh so I guess you guys knows about the two parts of ZK. One is the proving

and one is the verification. So we try to do the verification part out here. uh and we have partners with uh we have partnered with multiple of proven networks who help us to do a lot of the proving things as well. Yeah. So to start with uh brief intro about myself uh I'm Arman. I'm the solutions architect at Horizon Labs. Horizon labs is the main research uh company behind ZK verify and the horizon gene and uh we have been doing a lot of ZK specific research.

If you have heard of Poseidon 2 hash that's also one of the things that our researchers contributed to. So we have been in this field for a long time now. Cool. So today's agenda is we'll talk about what is ZK verify. Obviously that's the whole thing. We'll understand how it works, the whole architecture, but I would like you to focus more on why do we need it and then I'll show you some use cases and then how to actually use ZK verify in your real applications because just doing theoretical level stuff is not what I believe in. Uh I try to make things much more implementation friendly. Uh so I'll try to give you some real life use cases and we'll try

to actually write a circuit and then try to verify it on ZK verify. Cool. So let's start with the actual definition of ZK verifier. There's nothing specific but uh as I told uh in the whole ZK pipeline we have two things uh one is the proving layer and one is the verifying layer and proving is uh kind of the most computational expensive layer where you actually do all those field elements hashing elective curves things so it's basically uh it's the kind of the slow process and verification is kind of uh the easy process to do but So when you do it in a

blockchain, think of any EVM blockchain, take Ethereum, any L2 or even Solana or any Cosmos ecosystem chains as well. Uh all those system all those chains are built for some specific amount of computation. If we try to do anything over from that, we start getting a lot of lags. They are not too much ZK competition friendly. We don't have lot of field elements implemented there. So obviously uh verifying ZK proofs on all these chains are very very hard and are not very very efficient. So what we have done at ZK verifier is we have built a particular blockchain and the only thing this chain does is just verifies proof.

It doesn't hold any smart contracts. It is not a general programmable blockchain. It's kind of an app chain. It's a layer one. You can see it in a layer 1 app chain. The only thing this chain can do is just verify proofs and we have uh support for multiple types of zk proof. So sircom the graphics 161 noir ultra honk if like obviously you have heard of then all the zkms we support almost everything whatever you have whatever is in the market whatever you're trying to develop with those things we already support it. So we're trying to basically build the universal verification layer for Z zero knowledge proofs and why this is needed because when you try to verify proofs on EVM

chains or for any web3 applications there's a lot of inefficiencies which you'll explore more in the further slides and we're trying to solve that particular purpose and this is just so not so cool definition of ZK verifier is that we just verify ZK proofs we don't do anything else and uh if you guys have heard of substrate framework so it's a term from the polarot ecosystem of how you build chains so technically speaking ck verify is a substrate based blockchain elvin blockchain we are a solo chain we are not related uh or like we don't have any connections with the polarot ecosystem we host our own set of validators similar to ethereum or any

other one and we try to do everything on our Um, >> and >> I'm sorry, can I ask you what's substrate framework? I didn't understand that. >> Okay. So, uh, have you heard of opt stack in chunks? >> Uh, what stacks? Which stack? I I'm sorry, I couldn't hear it. >> Uh, OP stack. >> Oh, yeah. >> Yeah. So, OP stack is a way of building L2s, which is build optimism, right? So think of substrate is a similar framework built by the polar dot uh ecosystem >> and it basically makes easy for you to develop blockchains. So when you think

of a blockchain there are multiple things involved right uh networking state management everything. >> Mhm. And what substrate enables you is that you can build all those things uh you can just build focus on the app logic of what your chain actually do and while all the state management and networking is handled by the framework. >> Oh I see. >> So that you don't have to indulge in that >> like in cosmos I believe it must like it chain protocol or something like that some okay like that. >> Thank you very much. >> Yes. Uh so there is one more term I would like to focus I forgot to add it to the slides but there is something called as pallets in substrate framework and these pallets are basically smaller parts of the whole blockchain. So in

polar dot what happens is uh balances like the 20 as we talk about in Ethereum context the 20 tokens in polar dot uh this is called as balances and balances is written in a specific pallet. So everything is break broken down into small small pieces of code which is known as pallets. So in ZK verify what we have done is as I told you we support multiple proof types. We have uh built pallets or specific logic for every particular proof type. So the verification for a groth 16 proof is different than the verification of a ultra honk proof like the logic is totally different. So

that's why substrate is one more much more powerful thing for us because it enables us to build all this pallet specifically for each proof type. So this was more about what is zk verifier but why do we actually need zk verifier? We have all the chains we have smart contract verification systems for all the proof types. uh if you have explored uh the ZQL uh framework so when you write a circuit over there instantly you get a smart contract as well which you can deploy on any ABM chain and verify your ZK pro then what's the need of CK verifier

and this is not the main reason but one of the uh very efficient reason of using ZK verify is the cost of the proof verification so on Ethereum Not right now. But when the gas spike happened maybe 2 3 years back, the verification cost of a single ZK proof was ranging from $ 20 to $30 and even it went to $50 at the hike of the uh gas. So this is one of the big reason why we need Zika verifier because as we go to the next stage of the cyber punk or the privacy world we say we'll see a huge influx of proofs for everything let it

be identity let it be defy let it be AI and all the EVM chains are not able to handle all these computations so ZK verify is trying to solve this issue in the whole ecosystem uh and we're trying to lower down the proof verification cost uh for Zika developers and products. So uh we'll dive a bit more into uh the exact issues that we face. So you all have heard about ZKVMs. Uh if not uh the easiest way to explain ZKVMs are like you have built circuits with graphics team, you have built circuits with no R, right? And uh one thing in

both the things uh in both the ecosystem is that you have to write their specific language. So if you're dealing with sircom for graph 16 uh you have to learn the sitcom language the and it only support the field element type and what are the operators everything is different even if you want to do a greater than operation you have to write a whole and you have to import a whole new circuit then rewrite it again and there's lot of the devx is not very very good to say uh noir is much more efficient in terms of devx when it come when compared to sircom or the graph 16 one uh where is very similar to rest but uh still no has some kind of its own way

of doing things for example hashing uh for example signature verifications all those things and uh this this is one of the biggest hindrance of zk not being mainstreamed because developers are not able to build on this stats right because all these languages are domain specific So there's a very steep curve of learning these languages and then implementing it. So ZKVMs are a new way to handle the ZK issues. And how they do is you write your logic in Rust at least right now.

And in normal Rust you don't need to learn any specific Rust for ZK. You can write your specific things in Rust normal Rust. And you can then try to say which thing will be private and which will be public. Which particular variable will be private and which particular variable will be public and then you can do a lot more of computations. So if you have heard of the latest trends in the CKVM space so SP1 has been verifying Ethereum blocks almost real time within 12 seconds. uh there is one more stew based verification and they are verifying bitcoin blocks as well. So all those comput computations are very very big

and they cannot be done in normal snark proof which you have learned till now and they have to be implemented in a stark proof basis and ZKVMs are the best way to do that kind of but the issue with ZKVMs is that they produce star proof type and verifying them on EVM chains is not at all efficient and here's here are some reasoning which I want to graph for this. The first is the stark proof size is like 7.4 mgabytes and that's the average uh for some event process 20 megabytes as well and the current Ethereum block size is like 150 KB. So you think of it like how

will you put this particular proof inside a block to be verified. So it's not at all efficient. You can do it in some manner like split the 7.4 4 MB into multiple blocks and just divide it. You can get a a lot number of blocks to send specific uh chunks of the proof and then verify it. But that's not efficient. It will take a lot of gas and all those things as well. The other thing and the more specific thing for starts is there is something called as FRI. I don't want to go into detail what FRI is but it's very very computationally expensive. There's a lot of hashing. There's a lot of mercury

tree inclusion and a lot of things happening over there and right now if you want to do it on EVM it's not I I would say it's not even possible in some EVM constraints as well because the maximum block uh gas like the maximum gas that you can use in a block is 30 million right now and uh the stack proof cannot be verified in a single block because of this. So again you can split the whole computation of verification into multiple chunks of blocks but again it's like it's not the best way to do it.

And the third thing is no pre-ompiles. So with snugs uh or the gross 16 or ultra plunk ultra hong uh with the no language we have some kind of efficiency because we have pre-ompiles in the EVM ecosystem. What I mean by pre-ompiles is uh for example doing a hashing function on AVM is not efficient. So what happens on the background is there's a there's a particular Ethereum node which takes your particular input hashes it and give you back in the smart contract and for this you pay some gas to the node.

This is not the best example but an easy way to make you understand. So there is some kind of offchain competitions also done in SNS but stocks at least till now we don't have the pre-ompiles for that and that's one of the biggest draw downs for stack verification on AVM chains but in ZK verify the best thing is we do support stack verification natively so you don't have to do it anything of your own so you don't have to care about the proof size you don't have to care about the amount of computation to do onchain everything is handled by us because we have a substrate chain which is customized just for this purpose. It's very very efficient

and uh this is just uh a depiction of how it works for stocks. So there are multiple proofs for example this is a proof chart. So think of a single proof is splitted into multiple proof shards previously and then we compile all of this into a single proof and without ZK verify what used to happen is we convert this compressed proof into a G 16 because we know that G 16 is verifiable onchain on AVM and then we verify this GR 16 proof onchain. So there's an extra step you can see out here and when you do with zk verify you don't have to do it you can just directly verify the compressed proof you don't have to wrap it to a graph sch again so you're

removing your one whole layer of computation around this and based on the current uh mainet fees of s1 proven network this straight up uh gives you an edge of more than 30%. So currently if you do it without ZK verify you would be spending around.3 proof per uh for proving something on the main net and when you do with ZK verify you just do it within2 proof so that's 30% of 33% of exact uh proving cost efficiency and this is one of the main reason why

the soil product came uh as I told the GR 16 proof verification was around $10 to $15 at a time but when you do it on ZK verify it comes down to 08 it's like very very cheap it's like thousandx cheaper than E and then analytics cheaper than L2 so even if you do in L2s for example base optimism arbitum it will still cost you around $.1 but if you do it on ZK verify it's like 08 so for an individual dev who is doing maybe 10 proofs a day maybe this is not something very significant of saving but uh when we're talking with D5 protocols uh so if you have heard of

singularity they have been a good partner with ZK verify and they have been building a lot of cool stuff and they have been uh verifying uh at some time like 100k 200k proofs per day and when you compare this particular saving it like ends up saving 50k is 60k per day of proving cost verification cost sorry so this is the main reason why we have CQ verify and then we'll explore further uh the whole architecture and all those things but before moving forward if there are any questions on uh why do we need Zaryify and all those things I need to clarify that Any

questions guys? >> I think no. >> Um, in the chat someone asked that are there any L tools using ZK verify? Uh so we have connected L2s uh so on the test net we have around six to seven L2s connected so we have arbitrum optimism edu chain uh base even horizon in L3 right now we've connected all those things on mainet we have base connected and there are plans to integrate much more uh L2s in up few weeks and days

>> thank Okay. >> Um, Austellar like whether they're going to implement or not. >> Sorry, I'm not sure about the question or like is it about the integration of ZK verify with Stellar? >> Yeah, I believe so. >> Yeah. So, we have been talking with a lot of nonABM chains as well and the first one at least for now the predator is Solana. we want to go there first but we do have talks with uh move based chains like so Solana Stellar Cosmos based ecosystems as well and because we are chain agnostic and we are not having a particular environment like EVM it's

basically it is very easy for us to connect with chains so if you're building anything on stellar or something this ping me or milit will connect you with the engineering guys and maybe they would just help you make a bridge within few weeks I think that's all that's all.

>> Yeah. So okay, we'll move forward to the architecture of how we build ZK verify and how it works. So uh as I told it's a specific L1 chain of its own. So it's not an ADM chain. It's not an any ecosystem right now. It's a very separate chain only meant for verification. And in normal chains you interact them with RPCs. The same thing with ZQ verify as well. we have an RPC URL uh and you can just send us proofs through it. So in normal uh chains you send us the smart content interactions, you want to make a swap, you want to buy some

tokens, all those things. But for ZK verify you can only do three specific thing. The first one is obviously the senders proof to verify. So as I told we have interface for multiple proof types here it's uh risk 0.16 noir but uh we have added like four five more out there. So every part of the proof type has its own interface you can interact with it and send proofs for verification. The other thing is obviously transferring the balance. So verify verify has VFI token as its native token. So you can own the VFI token and you can use it to pass it around. Uh and for verifying these proofs you need the

VFI token as well. And the third thing is the governance of this chain. Uh this is an L1 chain so it's has its own governance and all of those things. So that's also a part of it. Uh so now coming back part to the technical layers of how it works. So uh we have an interface uh common interface used by all the proof types. You send us the proof and then as I told we use something called as pallets and these are nothing but smaller code snippets for each proof type on how to verify those proof type. So this interface take your proof passes it to the respective pallet which has the logic to verify this particular ZK proof and then once

it is verified it's it is included in the block. So uh as it's any blockchain we also have blocks uh so it is part of a block now and then as it happens in any chain the block is included the block is finalized and then some more events happen as well. So here once your proof is verified it is now part of the block and then after 6 seconds it is finalized as well. So the block time for ZK verify is 6 seconds. So once you send a proof uh within 6 seconds it it's get included in the block if it's a valid proof and then this particular proof is then passed to something called as receipts aggregator and why we need this

component is because we want to connect ZK verify to multiple chains as I told we have been working with multiple L2s Ethereum obviously and uh Ethereum L2s and then Solana and other nonM chains we want ZK product from any ecosystem uh to use ZK verify for verification. So without this particular component it's not possible for any other chain to know if a proof is verified on ZK verify or not. So this particular component lets other chain knows that yes this proof is verified on ZK verify. So how it works is for every proof you verify on CK verify and you want to emit it to a

chain in the while submitting it to the interface you tell us the chain ID where you want to submit the aggregation to and what we do is uh we verify your proof on the main chain and there are a few conditions once once they are met it is now related to Ethereum any other to Solana any other chain you want So this is uh I I'll say the biggest USB of ZK verify chain as it is because we can connect ourselves to any ecosystem.

We are ecosystem agnostic to say. So if you're building anything on any chain you can just use ZK verify out of the box to verify it and you don't have to move your smart contracts to any specific chain which we support or even our home chain. You can just uh have your logic which is already implemented and you can just plug your proof through ZQ verifier. >> So this is the main architecture. Sorry >> I'm so sorry. Can I ask two question? It is about this. So that I wanted to ask. Um sure >> the first one I'm just trying to understand the process like uh in ZK verified are there nodes that try to verify different type of uh proofs like does not know each node try to verify

different type of proofs or all of them try to verify the same one like >> yes so all the nodes have the logic to verify all proof types >> and whenever you send a proof to the zk verify chain each of the valid validator which is uh so basically it's a proof ofstake chain. >> So at a particular time stamp only few validators are active. >> So out of 30 validators maybe five or six are active at that particular time. So it's basically an election based process where every six hours a new set of validators come in. So when you send us a proof uh so all the active validators will verify that proof each validator will verify that proof.

>> Okay. And uh I want to ask one more thing about receipt aggregator. Um I think I understood wrong because I thought that if I verify something um I can just take the you know block ID and where is the verification and I just show that why do I need something like this like I don't know if I understood completely wrong but >> okay uh yeah so if you want to do it in an offchain level obviously you can just verify with the block number and your transaction number as well you can just say that this transition has my proof which is verified on ZK verify but without this received aggregator how will you connect it to a different chain

or >> um so what this aggregator produce I didn't understand for example I have an smart contract on Ethereum and I verify something with ZK verify uh what does this aggregator gave me for my contract >> yes so uh I I'll show you more further of this but later but How it works uh right now is for each proof which is verified on ZK verify and needs to be emitted to a chain you'll get an unique hash of it and this hash is basically uh it includes everything like which proof type it was uh the the whole proof of uh which is verified the public inputs and

everything and then you can verify that on any smart contract on Ethereum. So how it works is every aggregation has its own unique ID and then you can check if this unique ID has the matching proof details which I want to verify or not on on your EVM chain. >> Okay, thank you very much. >> Sorry to interrupt. If anyone has more questions on this uh because this will be crucial to understand the next slide.

Uh okay. So as a developer this is the workflow that you would be working on. So you have a proof generating system. uh it can be your ZK app, it can be your ZK rollup, anything. And then you generate your proof and then in the step one you verify it on ZK verifier. So this is the ZK verify main chain. We verify your proof and then as I told at the end of the pipeline it's get aggregated to the Ethereum chain. So as you can see uh in step number two the proof is aggregated and the aggregation is passed to Ethereum. Now uh when the aggression is passed to Ethereum uh we do emit some

events at the ZK verify chain on which particular degregation ID was your proof part of. So in a proof generating system uh then this this can be a front end or back end anything. Then on the Ethereum chain, what you can do is you can check for this aggregation ID if this proof and inputs are matching or not. So basically you'll get a hash and the aggregation ID out of the CK verify chain to an AVM chain or or any other chain you want to verify on and then uh you can verify if the aggregation ID actually contains your proof and inputs or not. So it's a Merkel proof. uh I'll show you further in the examples but uh

this is what the exact system is like so and we have tried to make it much much simpler for you so we have something called as a relayer service and we don't want developers to get into issues of connecting with RPC handling tokens the VFI tokens so we have built an API service uh which I'll show to you right now and this API service can you can just submit proof through it. Uh and then at the end of it, you'll get the aggregation ID and the leaf uh for your proof and then using both of this you can verify on Ethereum or any other chain that uh is your proof actually verified on ZK verify or not. So that's

the usual workflow that you would like to build with ZK verify. So the next slide or the next thing is about having a demo. I'll show you a demo before moving to it. Any questions on the workflow? Uh yes, I have a question. Um I just wondered u is the output of the verifier the same regarding the um the different uh types of uh uh schemas like G 16 Plunk like um is it a way to see which

type has been used has been used uh by looking to the output I don't know. >> Yeah. Yes. Uh so the output which is sent to all these chains it is basically hash and the hash is basically uh a hash of everything that you have. So it's a hash of which proof type you used 16 ultra honk blanc risk zero. Even for risk zero we also have different parameters like which version of risk zero you used then uh the public inputs of it uh and the proof of it and everything. So everything is uh actually a part of the whole leaf which is sent to the smart contract. So you can check every detail of the proof verified uh on

the smart contract out here. >> Okay. So you unify the outputs by hashing it. >> Yeah. >> Okay. Thank you. Any more questions okay I'll share a demo uh of how to actually do CK verified stuff. Uh it's not something very fancy but it is something very very simple and would be easy for

you guys to understand. Let me just um so have you I guess you guys have explored ZK Rapper right where you write the scom circuits and generate the proof and all those things. Cool. Share my screen. I hope you can see my screen now.

>> Yeah. >> Okay, cool. Yeah. So, coming back to the first lecture maybe. So we have the example circuit zk ripple. So whenever you load zk ripple this is the example circuit that you'll get and when you compile the circuit you'll find few things out here the main was and few other artifacts and when you generate a proof you would need this but as you're just trying to verify it uh let's do it uh something around you can click on gro 16 to select which proof type you want to prove in and here you'll get uh all the important files for verification

So and even generation of the proof as well. So you have this main.gloss.html. So you can use this thing to me show you can use this particular thing to generate proof uh locally on your browser. So if I give an input of five and 77 if and if I want to generate a proof to say uh as you can see I generated a proof uh and then I can verify it locally uh only on my system that is it's a valid proof but we want to do this on zk verify so there are a few things that we need to download from here so for every particular zk circuit you write uh there

will be a file called as v This is the verification key which is unique to a circuit. So based on how you have constructed the circuit, the V key will be compiled by the silicon compiler. So we'll need this. Let's download that. So okay. And then as I told we have something called as service. I'll try to spin up the docs show you something. Okay.

So the old way or the kind of the advanced way of doing verification with ZK verify is by doing it through ZK verify JS. So it's the OG verification stack that we have built and how it works is uh you need to give your seat phrase for your wallet which has VFI tokens and then based on the proof type out here you can try to read the proof data which you have downloaded like the V key the proof and everything and then as you do it in any other blockchain you need to create sessions and send transactions to it out here as well. You create a session and

then you call the verify transaction. You give it which proof drive you want to verify and then at the end of it the proof data as well. So these are few things but to start with I would recommend you to use the relayer service and this is the rest API and this is built by Horizon labs the research company behind ZK verify and delay was meant to be making the developer experience much much simpler and we do it through web two APIs so you don't have to handle tokens you don't have to handle uh anything how it works is You just make an API call to the test net API we have out here and then you

can just verify proofs start uh like you don't have to do anything else. So uh I'll show you a few examples of how to do this. We have even have these swagger documentation. If you want to explore more about this you can go onto this links and try to do that. But yeah uh I'll try to show you how to do in sitcom. So we even have a tutorials repo as well. So if you go to zk verify you have you'll find a protocol tutorials and there you have zk js as well and vlayer as well. So we have few examples here.

I'll try to go through this and I'll try to go through the sircom one because that's the easiest one to say. Okay. So we have some artifacts already here uh which I generated previously and I used it. So uh this is the similar thing which you will download from zkir ripple u out here the v key and all those things. So it's the same vi uh for some different application.

Now out here when you generate a proof you can see you have pi a pi b pi c uh and all those things. So I have a similar proof I have pi a pi b pi c protocol and curl all those things and the public json. So we just need three things out here to verify something on zk verify. The first thing is the verification key for the circuit. the proof file uh which actually contains the zkip proof and the public.json which contains your public inputs.

Uh so both the circuits are not same obviously uh the circuits has two this circuit as one. So this is a different circuit uh which I was building and trying to verify for and uh now I'll show you how to do it with relay. So as I told it's a API stuff. Maybe I'll zoom it up a bit. So how it works is uh you have an API and uh to use this API you would need uh API key. If you want an API key just uh DM me or Milit anyone we can give you an API key to start verifying proofs on ZK verify. And we're just uh parsing out the proof the public inputs and the

verification key from uh from the public files that we have stored out here. So we go to assets sircom you get the roof public and v key. So you're just uh importing it here trying to read it from those and then uh you can remove this part. This is something more advanced but we're just trying to construct the parameters of the proof which you have read the public signals of the circuit which is in the JSON file. This uh V like you can directly pass the V key as well but this is a more efficient way to do it. We hash the V key uh through a particular process and then we pass it as well. So

you can do that as well and you can give the proof type. So that's the first thing you need to pass which is which type of proof are you trying to verify with zk verify. These are some more advanced things uh which you can explore later and then the proof options. So like for graph 16 proof zky support multiple variations of it. So whatever you generate through zkil is snagjs library based and bn128 based. But uh there are some other libraries as well called as arc works. I can show you that.

So this is uh arc works is basically a rust library or a model library to write CK circuits. They do support gro 16 and multiple proof types out here. So you can see it here and like the gross 16 implementation of artwork is a bit different than smartJS. So for we also support that. So you can the library can be that as well and this is the parameters what what you want to verify and then what you do is you use exos I guess you guys are familiar with exios but if you're not it's just an way to make API calls to a backend service so and you can post it uh with the API URL and the API key and passing this

parameters that I want to verify this proof this is the proof type this is the chain ID So as I told we can give the chain ID where we want to send the a destination or the reef to it. So that's uh one thing. So maybe I'll just change it to sepoleia for now. And then you can see the proof data and all those things. So and out of it you instantly get a message that either the proof is success or not which means the proof is valid or not. And if it's valid so then you can wait for different kind of messages coming through the zq verify chain that if the proof is was included in the block if the proof was finalized and if the proof was sent to the destination chain or not for here it's

the is it polia chain and then uh this is the same thing and let's try to run this and let's see if it works. So as you can see we get a job ID and we got an optimistic verify success which means that yes the proof is a valid one but uh we are waiting for it to be included in the block. So as you can see the object is submitted which means that the proof was submitted to the chain. It was included in the block and it was aggregated uh sorry it was finalized as well. So the blockchain things the core components things are done. Now we need to wait for the aggregation. Now the

aggregation is a bit tricky to say because uh it depends on the traffic of the on the chain. So think of there's a lot of people who wants to send proofs to Sapoleia chain. So aggression will happens very very fast and if there are not a lot of people we wait for a specific time. So think of uh right now not a lot of people are interested in sending proofs to Ethereum Sapoleia. So we have a cutff time of 2 minutes. So either we have a lot of traffic or we have 2 minutes. And if any of those cases fails in we'll send a proof or send an aggregation to uh Ethereum support. So we are just

waiting for it. So let's wait and in between if you have any questions you can ask. Yeah. So as you can see uh it was aggregated and we got the graph 16 proof type, we got the chain ID, we got the transition hash. We can try to verify

this as well. As you can see, it was verified 2 minutes ago. Uh, and it was successful. And it will have the whole proof like the ABC part, the V key, the public inputs and everything. And it also holds the domain ID or the aggregation stuff which you want to do out here.

And the next interesting thing that I want you to focus on is the aggregation ID and the statement. This is the two things which I told uh that the chain will give us to verify it on other chains. So the statement is basically a hash of all the details that is part of this particular proof. So I can show you how this particular thing is built. Yeah. So when you submit a proof to ZK verify how it works is we hash the verifier context which is like which type of proof it is the V key or the verification key the version of the proof as I told for risk zero we have

different kind of versions and then at the end of it the public input bytes and this is unique for everything. So in this I can try to verify uh or like I can try to say that using all the components I'll get an hash the leaf digest which is out here uh deep fes in the statement and and using this I can regenerate the same thing on any other EVM chain and try to verify if this is the exact same thing or not and I can try to check if the same proof was verified on zk verify or not.

So we'll try to uh check that uh on the next stage of this tutorial. But uh if you have any questions, this is like the core part of using ZK verify. This is how you use it end to end of how you make the API calls. Uh as you can see it's very very easy nothing like uh you can even pass it to chat JP and it can write the whole code within the first prompt itself that just write parameters what you want to verify just make an API call that's all. No need to make RPC connections, no need to sign transactions, make transactions, all those things. So, it's very very easy.

Uh, any questions before moving ahead? Cool. Okay. So we'll move away to the aggregation uh side of things of how do you verify it with CK verify on any EVM chain. I'll try to demonstrate that now before moving there just a minute I'll reload the remix portal. Uh, I'll reshare my screen.

I hope you can see my screen now. >> Yes. >> Yep. Uh, so we have came to remix uh uh because you want to prototype fast the whole thing. I'll try to zoom it a bit. So uh over in the docs you'll find the contract addresses in specific chains. So we can go to supported networks on mainet we only support base for now as I told in the coming days you will see a lot more on test net we do support a lot of jeans as you can see and out of this we are doing foria so let's so as you can see uh let's get the proxy contract

address we don't need that this is a proxy contract address and then out here we have deployed uh our contract obviously on Sapoleia which keeps track of every aggregation and then you can make a function call to our contract to check if your proof was part of that aggregation or not and we pass the domain ID ID leaf and everything out here. So I'll try to demonstrate it and then I'll make you explain what each things does.

Okay, we'll do an AIA for deploy. Okay, so I've deployed this contract. Now what's happening inside this contract is we are passing the aggregation contract address. The address where ZK verify is storing all the aggregations. And then we want to verify if this domain ID has my proof or not or has my leaf or not. So we can pass it here. I'll just pass the mission contract domain ID is zero for Sapoleia. If you want to check how it's calculated. So go to learn section over here on the proof aggregation engine. We have domain management and for test net as you can see for Ethereum

Sapoleia it's zero. So we use the bot one. Now the aggregation ID which we got out here is this one. I'm just copy paste the leaf this number of Okay. And then the last part is the Merkel proof. uh you'll get everything within the events from zk verify just need to rewrite it here.

Oh, so we have sent it all and Too Cool. As you can see this transaction

passed uh without any errors. Uh so there is no error and it passed perfectly. If I change the aggregation ID for example, if it's an invalid proof, you'll say it will revert the whole transaction seeing that this proof was not part of this aggregation. So this is how you basically interact with ZK verify and we do also a test on any other blockchains as well. So that's the whole workflow of how you use ZK verify and then try to uh make it chainless with contacting any other chains uh through ZK verify.

Do we have any questions? Do you have any like uh tutorial like code examples on GitHub so that we can check? >> Yeah. Uh yeah. Uh wait, let me reshare my screen. Uh yeah. So the best resources that I can share you is if you go to ZK verify docs out here and if you go to the proof of out here. So over here you

have all the snippets for each proof type which you want to try on and you don't have to actually write any code out here. You just like whatever I showed out uh uh in the VS code uh thing. It's exactly the same thing. Copy pasteed from. Yep. >> Oh, I see. Mhm. >> So, you can just go to this page and try to copy paste each and every part of it and at the end of it you'll get the same code. >> Okay. Thank you. >> Cool. >> Okay.

Okay, so Mimi will move to the last slide or the last section of what are we building with ZK verify specifically. So as I told uh ZK verify is meant specifically for handling volume of roofs in a much more cost efficient and time efficient manner. Uh so these are the two use cases that uh we have been researching on and I've built both of those things in the past 2 three months. Uh the one is is proof of geolocation.

Uh so how it works is think of you want to share that I am in a specific state, specific city, specific country without actually yeah uh yes. So basically mobile proving can be done. So you generate your proofs on any mobile phones using mo and then you verify it on ZK verify. ZKway is a chain. So you can connect it uh through desktop uh mobile phones, Raspberry Pi, light lens, anything. Uh so yeah, it's not dependent on your device just >> um in the example that you gave like a photo is actually captured an iPhone.

Have you used the Apple's enclave? >> Sorry, I was not able to hear you. uh in the second tweet um you said that in the tweet it says that it use uh Apple secure enclave isn't it for like a bioinformatic data or something like that you know >> yes I'll explain how both of these things work there's a bit of context around it so both of the things are mobile based where we generate the proofs on the mobile phones and then we verified on ZK verify and the whole ideology behind this both projects are that mobile phones uh is right now the biggest consumer electronics out there and if you want to onboard the next masses to web 3 or CK

mobile phones are the way to go and we wanted to do some kind of research or PC on that side. So the first one is built with something called as Moro. So, Moro is an effort by the PAC team from Ethereum Foundation and those guys built have built a very specific uh library for generating zero knowledge proofs much much faster inside a mobile phones and in this application which we have built uh you can prove that you are in a particular state you're in a particular country without exactly sharing where you are.

So think of uh you're going to dev connect and you want to share that yes I am at def connect but I don't want to share uh with side event or like am I at the main stage or where am I so I can use this particular uh geolocation thing out there the other thing is proof of secure media and this is uh the whole ideology behind building this project was AI is coming a lot of deep fakes are destroying the markets uh we have seen the whole bunch of fake videos, fake photos coming in and there was no way to verify if actually a photo was taken by real device. So the second example the proof of secure media how it

works is uh right now it's only on iPhone uh because Apple has something called a secure encra inside it and how it works is whenever you in uh install the application that you have built to your iPhone it will generate a unique key pair and the private key is all is always stored on the secure enclave so that no hacker no one can actually get the private key out of The only way to get your private key is to break your phone and after that you cannot take any photos. So that's the safest way to store your private key. Uh and this enclave is even uh used for your face and log and all those things

on your iPhones. Uh now what happens whenever you take a photo with this application which we have built it automatically gets signed by that private key and then anybody in the world can verify uh there are two verification stages for this that if the photo that I'm watching or I'm the the video I'm watching or the photo that this guy is showing that he has captured was actually signed by a private key first of all like uh we'll have the public key verification and then the second stage is is this public key or private key is actually generated inside the secure enclave or not. So there are two kind of verification and if both the things passes it means that yes this particular

photo was actually generated by a valid iPhone and uh it's not a defake so that's a way to stop it and alpha to all of you guys if you're going to dev connect if you will be around there. So we are launching a kind of social campaign using both of it with some in incentivization as well. So stay around look for tweets from ZKV and uh maybe you you can be a part of that as well. >> Are you in our telegram group? Maybe you can share the details there too. I know that a lot of people going to go that connect you. Maybe they can.

>> Sure. >> Yeah. Sure. Melissa will be there so she'll be taking a lead into all those efforts. Uh yeah, sure. >> I'll do that. Sure. >> Cool. Uh yep. So that's a whole review of what is EK verify, why we are there, why people need us, uh how our things work. Uh we have tried to make the devx kind of easy. So we are always open to feedbacks. If you want to build something on CK verify, ping me, Melissa, anyone in the team. Uh we happy to help you. Uh if you have any feedbacks, if the DevX is not good, you want to improve something, please ping us. We'll be happy to uh listen to what

you say. And uh yeah, that's it. Uh that's a whole lecture on what ZK verifier is. Yeah. >> Um thank you very much. It was an amazing lecture and if you have questions people this is the right time I believe. Uh yes can I go with a question? Um yeah thank you for the presentation on the last example that we gave proof of secure media. Um I wondered what's the guarantee

uh that you give when someone take a picture with the iPhone that the picture actually comes from the iPhone like there is no secure channel between where the picture is taken and the secure enclave. Right. >> Yeah. So how it works is uh whenever you take a photo and as I told we have a private key involved in this whole process it signs the content of this photo and then it is embedded inside the photo itself.

So some pixels of the photos are changed are kind of played with and we do keep the signature of that photo inside that photo. And if I want to verify if this photo was actually taken by an iPhone, what I can do is I can extract that signature pixels from this photo and then from that I can verify the ZK proof out of it. And the zk proof verifies that this photo was actually signed by a private key uh for which I have the public key. And then uh Apple has a service called as app attest if you want to dig more into that. What app attest enables you to check is if this particular private key or public

key was generated for this app or not. So if you are using the app that we have developed whenever you generate a new key pair a private or public key along with the key pair you'll generate an attestation out of it through which I can always check if this particular key was generated through my phone or or through my app or not inside an iPhone and then when I take the photo I check the signature that if this photo was actually signed by that keeper and And then I verify that this key pair is actually part of my app, not any random app or any other source is it is actually from an iPhone or not.

>> Okay. Yeah. So you can't externalize um you yeah you but you could do the verification outside the iPhone. >> Yeah. Uh yeah. So only the proving part happens inside the iPhone. The verification can be done anywhere. Okay. And is it the same with all types of thing that we can prove? I haven't had the time to check the geoloization, but it's the same concept that you need to have the prover inside.

Um I don't I don't don't remember the example, but you always have to have the the prover uh along on the same system that the data you want to pro. Yes, that's a basic way to do it uh in a private level proving stuff. But uh if you explore more about CKVMs, I'm not sure if those are explored in this course or not, but CKVMs are very very computationally like it's very expensive to create a ZKVM proof and normally uh it's not meant for client side proving.

So people do it in like huge CPU servers. So uh companies like SP1 risk zero they have like bunch of GPU servers running and people ask them to generate a proof for them. So there it depends on your application what you want to do to try to do uh alongside that. >> So for the example of a picture how long does it take is it costful? >> No. Uh so we are not using ZKVMs over here. >> Yeah. >> Uh so we are using the blocks only. Just like take two seconds to generate a proof.

>> Okay. Okay. Thank you. >> Do we have any other questions? >> Uh we have one questions uh in the chat. >> Yeah. So on the scalability side of things at ZK walifi we are so we do have a cap right now of around 8 million proofs a day. Uh so and we want to extend it a lot more. So we are building few parach chains of zk verifier. Think of as like as uh child chains of zk verify for each proof type. So instead

of having all the it is right now now this parent chain will have small small child chains which can handle specific proof types and that basically gives us the power to do a lot more proof types or like a lot more proof than we have right now. So >> I have a question. >> Um like mentioned in the architecture of ZK verified that when the relay aggregated proof receipts like eventually uh are uh added to the Ethereum blockchain but

you also mentioned in the starting of the lecture that uh ZK verify is a layer 1 app chain. So like if the proofs are eventually adding to Ethereum, shouldn't it be like an L2? >> So we are not adding proofs to Ethereum. We're just adding the harshest of it. >> Oh, okay. >> So we are not submitting the whole proof to uh Ethereum or any other chain and like uh so the point of L2 was like it is converted only to one chain to say but we wanted to be chain agnostic. We don't want everything to just happen on Ethereum for example. So building an L1 help us to connect with any chains we want to and know obviously we don't submit all the proofs and all the proof

details out of it. We just submit a hash of the proof that's it. >> Okay, got it. Thank you. >> Okay, there's a question in the chat about will the parach chain can be over for the infra. So it will not it will actually uh make it more scalable. Uh that's because uh instead of one chain doing everything, we'll have multiple small small chains handling specific proof types and because of that uh the block times can be low for some proof type which are uh which are not very computationally expensive for example block 16. So right now it's 6 seconds but we can lower it down to like 1

second or 2 seconds while uh it it it is more efficient because uh the same block space for example 50 MB is specifically meant only for 16. Right now it is for everything SV1 ultra plunk and everything but when we do this parachin wall stuff then it boils down to every specific chain doing a specific proof type. So more block space, less completion time, it's more scalable. Do we have any other questions?

I think that's all for the question. Um, thank you very much for today's session. uh for the both theoretical part and the practice part demo part um and uh I believe like uh we have shared Arman's uh social in the telegram group if not we can so that if you have any questions you can ask directly to him and yeah thank you very much it was an awesome session >> thanks a lot thanks for hosting me on >> we're really happy to have you here >> thank you Um, so probably see you on Wednesday as well, right?

>> See you. >> Yeah, see you. Take care, please. >> Byebye. >> Just bye bye.