zkVerify Online Hackathon Workshop #5: Integrate zkVerify with EVM Smart Contract dApp

welcome to the next edition of the zek verify hackathon live stream series got a good one for you today got uh Luca Giani here he's gonna go through one of

the coolest things that we can do with the uh web 3 uh EVMS and ZK verify I'll introduce Luca in a second I just wanted to actually I'm GNA introduce you right

now so you can say hi Luca so Luca's software engineer been uh at Horizon labs for three years uh he does uh development on the cryptographic side so you know we got all these white papers

and ideas of zero knowledge proofs that are heavy duty cryptography papers somebody has to convert that into working code uh Luca is our main guy that does that uh really good in Rust

solidity JavaScript and we'll talk a little bit about what he's going present in a second but uh LCA thanks for joining us yeah thank you Ral for the

introduction and uh yeah uh today we are going to see in in detail how it's

possible to develop a onchain ZK app which uses ZK verify for performing uh verification of ZK proofs

in an efficient in efficient way wonderful let me give everybody a quick overview of what our hackathon is uh and then we'll get started and uh and

and do that so it's our hackathon is the ZK verify ZK app and infra Builders hackathon it's available on dev folio two weeks from now the projects are due

so that's December 10th uh we've got a lot of great information here uh about uh what it is that you can do with ZK verify what we're looking for from the hackathon uh all sorts of stuff like

that I'm happy that we've got uh some solid sponsors and $26,000 available in prizes we've got really high quality uh

judges and speakers uh from all aspects of the ZK space Horizon Labs is a sponsor hyper Bridge ZK pass cnry and then we got a bunch of really useful

ideas in the frequently asked questions so uh put a lot of uh time and effort into that uh and one of the things that I do want to highlight uh is that if you got an idea and you want to talk about

this uh with me with developers um you know I've got experience in in building businesses uh doing all sorts of different things uh product Market fit that kind of stuff happy to talk with

you about uh the different types of uh things that that you might want to to build uh if you got specific questions on how to integrate with ZK verify um

then we actually had a couple previous live streams um that uh on on developer tools that Steve rushby did uh on how to

uh do a decentralized proof verifier for uh web 3 uh and and browser based games that was earlier this week uh had uh some of our Builders and sponsors talk

about how you can win their specific prizes uh and today um is the one that I've really been looking forward to which is to have Luca talk about how to

integrate ZK verify with an evm smart contract app and you might say well why do we even need that because you know there's the BN 254 elliptic curve on

every evm and you can just verify um your uh ZK proof there well you need it because since that um BN 254 precompile was put on

ethereum the there's been like seven years because we've done that in 2017 there's been seven years of zero knowledge proof advancements there's so much advancement

in this space there's the ability to use ZK virtual machines ZK co-processors there's new elliptic curves there's Starks there's FIS and every week I turn

around somebody's making a new kind of ZK proof you got to verify the proofs and so ZK verify is the leading

blockchain that's a public decentralized ZK proof verification uh platform so I see in the future all these different ZK proofs can come together and be verified

publicly highp speed low cost on ZK verify and then we can share them through the hyper bridge bridge to every other blockchain that's out there and so

today Luca has a specific demonstration and we're going to quickly get into some serious technical code review and I'm going to be quiet while Luka does that

but the idea is to have a web3 application a smart contract that wants to be more secure so he's going to take

um grath 16 not using the BN 254 precompile but using the much more secure BLS 12381 elliptic curve verify

that on ZK verify and send that verification receipt back to the ZK verify smart contract on the evm and make it available to the application and

this same exact design pattern can be used for the other types of proof verifications that somebody might want to do so right now there's developer teams that are developing proof

verifiers for ZK verify for Halo 2 for starky for plony 2 and the succinct sp1 um uh Stark um proof uh and we're

just going to keep adding more and more as we go along so Luca uh please go ahead and share your screen and and and start talking about how we can do this

stuff yeah so I'm sharing my screen okay should be able to see it now yeah let me pull that onto the stage

here and uh we will get going okay so uh uh rol already told everything basically

of what we are doing uh but yeah to reiterate we are uh goingon to see how

it's possible to build an onchain ZK app so uh what do we mean by that so uh it's a onchain app so part of the logic lives

in a smart contract on chain more specifically in a solidity smart contract which on evm uh

and uh the logic of this app requires checking ZK proofs and more importantly uh these

checking of the proof must uh happen on chain so of course this is already possible on uh on

EVMS if you stick basically to to a handful of proof system which use elliptic curve cryptography on a

specific curve which is the BM 254 uh and there are a lot of application which do already do this uh

either for privacy uh so for the ZK properties of ZK proofs or for let's say uh

computational Integrity so uh to be able to verify a lot of computation without Rec Computing it so in an efficient

way uh however all this system must uh let's say make jump

through uh hoop Hoops in order to uh bring their proof on chain uh because uh basically you are restricted to only a

few proving systems uh on specific curves uh so uh here enters ZK verify

which instead uh being a a blockchain which is specialized on verifying ZK proofs offers a much wider uh range of

possibility so I just want to interrupt you for a second um is it possible you can make these words look a little bit bigger on the screen it's just with the

resolution I'm having a hard time seeing them um that's already better maybe one more oh no that's that's good I think that's good right there sorry to interrupt you about that I just wanted to make sure that everybody could see

the actual words that that you're going through yeah thank you

uh and uh yeah so uh okay to be more concrete now we are developing a very

simple uh app I mean the logic will be almost silly uh because okay the objective of

this uh live stream is to see let's say the architecture of uh of the app so all the components how they interact with each

other uh and uh we don't focus on the actual log logic of the app in order not to overshadow the the let's say the

architectural discussion and so uh our app will

require a user to generate a ZK proof that he can actually compute the he knows the factor of the number

42 so it's let's see an extremely uh trivial uh application and uh uh then the user will have to generate this

proof and submit this proof on chain to uh the app Smart contract and if the uh verification is successful then the

basically the smart contract will emit an event so this is the simplest let's say ZK app uh but it contains all the let's say

the elements which uh the basic components which every ZK app actually has to to implement uh so I'm just going to jump in here and

say 42 has a special uh reason with Horizon so when we first started Horizon we wanted people to be able to uh to have secure nodes to have copies of all

the Horizon code all over the world and we decided that they needed to own 42 Zen to be able to participate in the secure node that was way back in 2017

that we Des decided that uh and so secure nodes and then super noes have become an important part of horizon uh ever since so of course 42 from The Hitchhiker Guide to the Galaxy it's

always it's always the answer so sorry to interrupt thanks yeah that's a nice

trivia and uh okay all the code you can access it inside ZK verify giab it's on

this freshly created Repository verify evm the app example uh at the moment it lives in its own Branch Branch initial

inut but right after this uh this live stream uh I will merge into main so for the moment if you want to see the code

you have to switch to the initial imp branch and uh yeah uh so okay maybe we can start from let's

say uh uh analyzing the workflow of ZK app which wants to use ZK verify can you

zoom in on picture too a little it's just yeah yeah perfect okay so uh this example uses a

specific application which is polygon cdk which uh as you may know is

actually L2 on ethereum so polygon offers this CV cane which you can spin up your own L2 which settles on ethereum

uh by posting ZK proof so it's a very complex piece of code very complicated ZK app but we will see that the

components are always the same so here our app of chain component is this polygon cdk which receives transactions

from the users bundles them together in blocks and generates ZK proofs for uh proving the correctness of of the

transaction and in the original polygon cdk this proofs are directly sent to a Smart

contract uh on ethereum called here don't know if you can read but it reads validium do Soul so it's the polygon CD

K Smart contract and then this proof get sent to another contract which is a f long verifier contract which guess what

uses the BN 254 curve uh and so uh originally the polygon cdk

uh directly sends proofs to ethereum for uh for settling them uh however this okay restricts the cryptography it can

uses it can use and uh also sending this proof is quite expensive and so if smaller L2 rollups have a hard time

justifying this expense if they don't have a high high enough throughput so uh as one one of our first

exercises let's say we converted this polygon cdk to instead use uh ZK verify for settling the proofs so how the

workflow changes so the polygon cdk stays basically unchanged except that instead of sending the ZK proof to

ethereum it sends this proof to the ZK ZK verify main chain specifically DK

verify offers several uh proving system among these is the F flong verifier which is the one used by polygon cdk so

uh there is this okay this method inside ZK verify which checks the the proof If the

proof is Su the proof verification is successful then it gets included into a

block and anent is emitted which allows the client to know that his proof has been successfully included in ZK verifi

chain and after a while basically when enough time has passed or enough proof has been sent to ZK

verify uh ZK verify produces a so-called attestation which is uh we attests the

uh correctness of a set of proof technically this happens via merel membership proof so the attestation for

those of you who are familiar with merel trees is just the attestation is just the merel root of the merel tree of

basically of the statements of these proofs okay then when this attestation is produced there is a

basically a relayer which which takes this attestation and posts it to uh a smart contract to ZK verifies

Mar contract on ethereum so an ethereum on each not only on ethereum but on each evm which we support which is ethereum

at the moment on in test net uh but uh there are Al we support also other other EVMS such as goby which is

Horizon evm and then also on achain or arbitrum test net

and uh more will be added in the future and uh okay then this attestation now has been

posted to uh the ZK verify smart contract then basically the PO on cdk has to trigger another

transaction uh for uh I mean in must post to the DK verify smart contract basically the

meral proof of inclusion so to uh ensure on chain that

the proof which uh has sent to ZK verify has been verified and has been posted to zfi Smart contract so at a high level this is the

the workflow and uh I mean now we will dig into the code which actually performs

all of these action so uh it should become everything more clear okay so this is a this is a general model that

people can use to have um the the smart contract have their verification done on ZK verify instead of natively on

ethereum or an evm and so that that that gives you the ability to not only do a lower price but also use a different type of ZK proof um so this was this was

I know this was the first one that that y'all did and then uh also did one for uh ZK sync era for for the bjam and so

we still are talking to um projects that want to do their own ZK rollup using this way because you're right it's to me price is always part of the design

factor and so um by being able to have a lower price by sending the receipt of the verification to the layer one that's

a much less expensive transaction than doing the transaction of actually verifying the proof using the BN 254 curve pre- compiles on ethereum so this

is still you know this is a very valid uh system um polygon's not doing this they got their their their you know polygon AG layer but individual projects

that may want to do ZK rollups using the polygon cdk or the ZK sync era still might want to do this and they should talk to us about

it yeah definitely okay thanks uh so uh okay let's jump into the

code so so uh basically we see the three main building blocks of our application so there is the what I call the app

which is the let's say offchain logic uh which actually generates the proof and

uh sends the proof to the uh ZK verify chain listen to the relevant events emitted by ZK verify and uh which is

necessary to retrieve all the information that must then be posted to instead to the evm in order to uh make

the evm smart contract uh aware that this proof has been verified on ZK

verifi then there is the circuit which actually uh contains the ZK logic basically and then there is the the

contracts which contains the evm smart contract so I think we can start from the circuit which uh for most ZK apps

maybe it's the most complex uh part but but for us it's very simple because as I already said uh the logic is very simple

so as I said I've used the grth 16 uh so I developed the the circuit in the circle

language and yeah code is really simple and okay it's just this factorization which can be configured

for different n here we configure it with 42 and this circuit basically only makes sure that okay takes in input to

signals which are private so we don't reveal actually the factor a b and ensures that the product of A and B is

equal to n and uh okay here we take another uh public

input uh address which is I mean doesn't appear in any other constraint but it's revealed revealed as a public input so

this is let's say a trick uh which can be used to ensure that your proof isn't exploited by other other people which

didn't generate the proof but would like to reuse it so uh because uh

uh in a we will see later in the app logic in the smart contract logic that we require that these public input is

set equal to the address of the sender of the transaction action so this ensure that if you generate some proof and send

it on chain then this proof of course is becomes public and if we didn't introduce this trick uh then anyone

could exploit it uh for their own uh and so yeah this is the only let's say tweak in our circuit uh but for the yeah I got a

question about this so we do have some people that join the hackathon that don't have as much experience with um generating ZK proofs so looks like

you're using the circom domain specific language here and factorization is a native method of of C of uh in circum I'm sure there's a number of other native methods as well but this this

seems like a pretty straightforward uh way to generate a zero knowledge proof in a basic way I bet there's a bunch of other examples

out there too so um was was talking um with uh Gaylord at ZK hack uh and we're also co-sponsoring something with ZK hack right now and he's had a lot of

experience bringing people into the ZK space and his recommendation is to start with a really basic circuit first to kind of get your feet wet with um with

ZK proofs and you can always make it more efficient or more performant later on start with something basic uh and then you can always make it more

complicated so to me uh as a as a basic software developer this looks pretty straightforward this looks like something I could do that wouldn't be too scary I'm sure that you can make things a lot more complicated in circom

but I I really appreciate you sharing this example here yeah yeah yeah it's always a wise choice to start simple

and it's always possible to add additional complexity it's yeah so instead of factorization if maybe a is bigger than b or if a is equal to B you could

probably do that too right yeah yeah yeah okay actually yeah okay just a SI a side note for

those of you who are not very familiar with circuit actually even uh okay it's this is ZK

Tech is quite strange and for example even uring that a is bigger than b is not that easy I mean ccum provides some

let's say abstraction which makes it look easy and you can do that in a line of code but under the hood this requires

for example uh doing uh what are called these uh uh bound checks basically and this requires

introducing the in the circuit a lot of constraints so yeah definitely uh uh getting into the ZK space can be quite

intimidating but uh uh okay now things are starting to change uh in the sense that besides circuits which can be quite

difficult to write properly uh uh are starting to appear also zkm which are much more user friendly

one example is risk zero for which allows you to write a a your code your

ZK logic in Rust so plain simple rust and uh then magically uh build a ZK proof out out of that with without

having to worry about all the cirquit writing stuff which can get complicated quite fast I'm glad you mentioned that um I was thinking maybe we should have a

live stream next week but maybe maybe we do something where we show people how to build something really basic in uh risk zero because we have a native risk zero verifier that verifies the the risk zero

Stark proof and and we're one of the the very few places where you can publicly online um verify a risk zero Stark proof

um so glad you mentioned that okay that that's something that maybe we want to show in the future sorry to take you off track please please continue no

problem uh okay so this is the circuit here

uh okay gr gr 16 requires to uh also uh requires to run a trusted setup

before being able to generate and verify proofs and uh here I I've included a a little make file which uh allows to run

all the necessary uh all the necessary steps of the setup just by running make make call uh this requires uh to install

snark JS as a dependency uh but then it's pretty State forward but if you want to try out the

application uh you don't need act to rerun the setup because uh I've already committed the final result of the is set

up uh here in this uh in this directory so no need to rerun if but of course if you are curious you you can uh do

it uh okay so that's it for the circuit and uh we pass to the more let's

say beefy components so uh here we we take a look at the

contract okay okay so here is our contract just let me close this okay so this is our ZK

factorization contract so uh okay now I I'd like to spend

uh uh no no let's do that later so uh here okay hold off for this line for uh some minutes we will uh get back here in

a few minutes minutes so here we just see okay this contract has these two immutable variable which are initialized

during contract deployment which are the address of the ZK uh verify contract on on the Chain you are interested to

deploy on and the hash of the verification key of the

circuit uh okay so uh uh as those of you who are familiar with gr 16 know uh approving system has the the concept of

verification key uh which basically encodes the statement which you are approving and uh here if we go back to

the Circuit directory it's this uh for gra 16 it's this structure

for graph 16 is quite small the verification key and

uh the smart contract needs to know which uh which verification key you are using because needs to ensure that

you're are proving a specific statement not any general uh ZK proof and uh so uh

and uh yeah you in technical lingo you must commit to this to this verification

key uh through uh its hash and so we must compute beforehand the ash of of

our verification key so here I have include a small utility which uh actually actually

register to ZK verify uh the the verification key and gives back its hash so we can just run this

script okay sorry so uh uh okay this is Javascript so we use

node to run it uh oh yeah sorry wrong of course being a live demo uh

things are bound to go wrong so okay it didn't specify the account ah yeah uh

sorry ah because yeah I did some last minute refactoring which broke things so I can

okay this should fix it okay okay so

uh now we have submitted here we can see the code while we wait so here basically

uh we are using ZK verify JS library to interact with uh with ZK verify chain for those of you who have already

followed the previous live stream uh Steve already introduced this Library uh so here we are we are just

reading the VK from from the file that we saw before so inside the CIT setup

folder and we are establishing a session with ZK verify uh since okay here we have we are using

the uh URL of the RPC for ZK verify and uh we are passing the SE phrase uh of a

wallet which has some funds on DK verify and then we send the DK verif the verification key with the register

verification key for the gro 16 proving system and yeah we pass the VK and uh then we await the transaction

result and this among the other things this gets back the statement hash which is basically the hash of the

verification key okay so this is this particular value and uh okay so we know now that

the the hash of the verification key which we want to use and so uh this was a little detour to say that we should

include this value uh here inside the uh environment file uh no sorry inside the other enir

environment file so the contracts environment file okay here we have copy pasted the

verification key hash Okay so back to our contract okay

so now uh okay we know uh the the Contra the DK verify cont address the VK

hash uh here we are defining okay the event which we emit if a successful proof submission happens

in the Constructor we pass the values uh the actual values of the address of the ZK contract and of the VK hash so that

our contract knows how to interact with ZK verify and which particular statement we are proving and then there is let's say the

main method of the smart contract which is a this method which okay the name says it all and

[Music] uh yeah uh okay so here I think I can close this

tab uh basically here we are performing so as a first step we are

actually calling these internal method which actually verifies that that a proof has been posted to

zkv we will see later the internal of this method and if this check is successful then we just emit okay we set

let's say the the uh the result in a mapping uh and we emit the relevant event saying

that the the sender of the transaction successfully submitted a proof but of course here for an actual the app it's

where the interesting stuff happens for example ZK app could uh could uh uh mint

n fft nft for example or do some other cool stuff okay but here basically we

are we we we see the internal of this verified pro has been posted to [Music]

zkv so this method takes as input the an ID of uh the

attestation the uh okay the the So-Cal public input of the proof and as we saw earlier this public

input is just the for our case the address of the sender of the transaction then uh okay as I was saying

the attestation is actually a meracle rout of a miracle Tre so to be sure that uh that a proof has been

included uh in the attestation we must provide the mer the so-call meracle path and then there are some additional

details which uh must be known in order to uh check the miracle proof which is the total number of leaves of the

tree uh of the attestation tree and the particular and the exact index of our own uh proof inside that

three so okay important things is that these three actually

these uh four uh parameters namely attestation ID mer paff Leaf count and index are something which can be

retrieved from the DK verify chain after we have submitted our proof to it

instead this public input must be is actually recomputed by the uh the smart contract and and this is a typical

pattern in in the in the in ZK apps uh so in ZK apps often times the

public input is independently recomputed by uh by the by the smart contract in this simple in this example Rec

computation is straightforward because the p input is just the center of the transaction the address of the sender of the

transaction uh and uh okay so here we see actually

how this verified proof has been posted to zkv is implemented so okay this is something okay this is the most uh tricky part of

the contract because uh in uh okay in ZK verify treats public input in big

endian format instead in ethereum the format is little endian so we must switch the endianness of uh of

the public input and this is performed by this change andan method which is here uh I

mean it's it's a bit Technical and it's the most tricky part but it's just a technical detail so basically encoded input is just the properly proper

encoding of the address of the sender in this in our case then we must compute actually the so-call

leaf of uh which is a hash of the statement we are uh

verifying and this is composed this you can find the details inside thec verify documentation and

uh basically it's just the catch Ash of the proving system ID

which specify which particular proving system you are using so in our case proving system it's gra 16 and so it's

just the kak 256 as of the gra 16 string okay we concatenate this with the VK hash which we computed before and

which it's saved inside this immutable variable in the smart contract and the hash and we uh basically append

also the hash of the encoded input uh all of these is concatenated together and hashed and this this is

basically a unique identifier of the statement of a particular proof you see we are basically saying that okay what

we are proving is proving with this particular proving system this particular statement encoded by this particular VK which has this

particular hash and that the input is this particular public input so we are fixing

all the variabilities and later we call actually the zkv contract and in particular we call the

verify proof attestation uh also this you can find documentation in ZK verify uh repo

and uh okay now basically uh we just pass the attestation ID merel PA leave count an index which was passed and here

the leaf has computed here and if this method returns true it

means that the proof was successfully verified on ZK verified and sent to the smart cont contract to the verify smart contract on

ethereum so here we just decode the result result and return okay so it was quite

involved but hopefully this is more or less clear uh sorry Rolf I cannot hear you H I had myself

muted said this was great I think see you did the whole circle of starting in the smart contract sending the proof verifying it on on ZK verify coming back

to the smart contract are there other important things that people should know when they're uh developing yeah basically uh I mean we we we sold as Mar

contract and we already explained a bit the logic behind all the this back and forth for between the the client and the chain and the two chains basically and

here is just the piece of code which actually uh performs all these orchestration so

uh here is the the so-called app code which in this case the app is just a simple script in

JavaScript so okay uh going to the important stuff okay here we we see uh okay dependencies we we use again ZK

verify gjs library for interacting with the ZK verify chain then we use The Ether library but you can use the

library of your choice for interacting with the evm chain instead uh and uh yeah and for

generating the proof we use the snark JS Library which allows generating gr 16 proofs

so uh okay we can uh take let's see make quick tour of uh the code so okay here we are just loading

some useful info from from the environment [Music] file in particular the UR of the RPC for

interacting with ZK verify the S phrase of an account of ZK verify the RPC for Interac with ethereum the secret key of

an account on ethereum and the address of the ZK verified contract and of our own

app uh contract uh okay here we see that with snar JS generating a proof is quite

simple of course this uh this program takes as input uh the two factors A and B

uh and generates a proof that a uh time B is equal to 42 okay so here now we have the proof and the public

signals here we retrieve the VK from uh the from uh from the file and we start

uh a session with ZK verify using uh ZK verify JS Library and here we send the proof that we

generated so proof public signals mvk we send them to ZK verify to the gr 16 verifier of ZK verify uh for

verification here is a modifier which makes the method wait for the actual publication of the atation by Z

verify so when this method will return uh the uh relevant attestation will have been published on ZK

verify so to keep track of uh where of the stage the transaction uh is at we just listen on

some events emitted by ZK verify in particular we listen when the transaction is included in Block when

it's finalized and a possible error which arise during the transaction life

cycle and uh yeah as I was saying before after this method Returns the attestation has been published so we can

retrieve uh the IDE of the attestation the Le digest that we saw how it's computed these lifs digest

inside the smart contract and uh via another RPC call the po which means proof of existent RPC call we also

retrieve the details about the meracle proof of inclusion of our proof our statement inside the attestation so we

can rate the Merle proof number of leaf and leaf index which are all uh details which are needed by ZK verify smart

contract for performing the uh his checks so now that we have all the uh okay at at this stage

to recap the proof has been sent to ZK verify verified by ZK verified and uh

some events have been emitted to uh with which contains basically the details of the attestation which contains our

statement and the miracle proof which allows to show that uh to the smart contact that our statement was included

in this particular attestation so now we have all the details which are necessary to actually interact with the evm side

so we use the eers uh library to uh set up uh a session with uh the

EDM uh okay so here we Define the AI of the contracts we are interested in interacting with namely the DK verify

contract and in particular we are uh we are interested in being uh in being informed on when the attestation of

which we called later which we spoke late uh before uh was actually posted to ethereum

and uh instead for the our own app contract we are interested in invoking the Pro you can Factor prot2 method and

being informed of successful Pro submission so here we just set up everything and here it's the interesting

piece of code okay so here we just wait for the ZK verify verify contract to

emit the event attestation posted with the attestation ID which we are interested in which was

uh actually computed here so here we uh keep listening to

event and as soon as this event attestation posted is emitted by uh by

the ZK verify smart contract then we can send our own transaction to the app Smart contract so we invoke the prove

you can Factor 42 passing in all the details that we retrieved before uh by in a ZK verify chain so the attestation

ID meral proof number of leaf F and leave index uh we recall that every every one of them was

retrieved by either this call to ZK verify or this other one

so and then uh after okay this we submit this attestation with this transaction we

just wait for our contract the app contract to emit the successful Pro

submission of with our own account okay so uh Time Is Running by so

we make a quick demo of these actually running so okay maybe I

maximize okay of course I must pass the uh our SE well-kept Secrets A and B so we pass a the first Factor equal to

seven okay so okay transaction has been submitted to ZK verify and here we get the transaction hash so now we wait for

finalization of the transaction okay transaction has been finalized in this particular block okay now we are waiting for the

attestation of which contains our own proof to be actually generated by ZK verify and this could take up to one

[Music] minute okay so the the process that we're waiting for because obviously 6 time 7 is 42 so we should be able to get

a positive answer here um hopefully yes hopefully yes um and maybe after this we can do a test of seeing what happens if

we send it a bad set of factors um but I I I know from what you've explained to me before this sends it to um ZK verify

right away uh and one of the validators which runs all the verifiers on it um verifies it then when two out of three

of the validators agree that it's true it gets posted to the blockchain and the blockchain has a sixc time so there's a new block every six

seconds and then we have an attestation bot that gathers together the uh the the so it's on the blockchain after basically about six seconds if it's

correct and I know that right now y youall have the attestation but you can bring a bunch of things oh there it is so you probably have it set up to go every minute or something like that it

can be set to every block it can be set to when we get 127 or 204 7 uh uh proofs verified there we're still in test net we've been in test net

since March and I've been wanting you to do this spefic demo since March so I'm really excited so tell us what we're seeing

here yeah okay so basically all the workflow uh executed correctly so yeah as I was saying before transaction okay

uh proof was generated of course uh even though no log were printed uh then this proof was sent to ZK verify uh since the proof was

corrected correct the transaction was accepted then the blockchain finalized the transaction and uh after the transaction is finalized then

periodically an attestation is produced uh which contains basically uh our proof so here we get all the details of the

attestation so it's ID uh the digest of our statement and details about the Merle proof so with

all these details we are able to actually invoke uh our smart contract so

basically we waited for also the attestation to be not only published by ZK verify but also posted on ethereum but the by this attestation Boot and as

as soon as that happened then we sent our transaction to uh to the basically to the our app

contract and uh and yes this our app contract basically queried ZK verify contract saying hey did you see an

attestation containing these Leaf digest uh and here is the merel proof the details of the metal proof that you

must know in order to be sure of the inclusion of this Leaf digest inside the attestation so the ZK verify contract

answered yes and so the app generated this event that the of a successful Pro submiss and and closing the loop

basically of course everything can be checked on the Block Explorer of both uh uh the evm so on ether scan and of ZK

verify don't know if we have time for that so L we got all the time in the world everybody wants to see this demo

and build web 3 apps to to do ZK Veri so um okay sure so let me just okay so

here we should be able to retrieve for example the transaction sent to our

contract okay so this is the details of the transaction so you see that we called the prove you can Factor 42

method and these emitted the successful proof submission and uh I think in internal

transactions we can see that actually this transaction interacted with another contract which is actually the ZK verify smart

contract so for performing proof verification uh it basically quered the ZK verify attestation smart

contract uh on the other side we can also see on uh on [Music] uh on ZK verify block

Explorer ah okay this is the old block Explorer got use the new fancy block

Explorer I don't remember URL I don't remember the URL uh gosh um I will look it up though I I'll look it

up just give me a sec yeah by the way uh here is the link to all interesting

uh documentation for ZK veryify particular in this CK verify Hub you can for example see all the contracts of the attestation contracts

on this chains which which we support the URL of the RPC for interacting with ZK

verify and uh okay here the proof I know it's the proof Explorer but okay here is

the block Explorer also oh good new fancy block Explorer okay okay here we can see that uh

actually our transaction for ZK verified was for a gr 16

uh where do we Okay for the gr 16 verifier with the BL BLS

curve and with this particular Decay and this is the actual proof and this is the public input which

actually was the address uh the evm address that we used for sending the transaction for the to

the evm H yeah that uh that's that completes basically the the loop

so I don't know if there are questions so obviously on these live streams one of the reasons we do them is so people can ask questions on x.com while we're doing live stream of course

people are welcome to ask questions later on in the Discord or the telegram and uh one of the things that we want to be sure is that everybody who's entering the hackathon um is getting the support

that they need so please if if you're you're developing and you got questions um if you want to have ask your question public publicly in the hackathon Channel please do you can go to our ZK verifi

Discord you can do a ticket uh for a private discussion um we we have some telegram groups set up with some developers already where they're asking

specific questions um one of the things that uh like I said I do very basic development is to try to figure out like what's wrong with my code because a lot

of times my code doesn't work uh do you have any uh recommendations for people how to how to trouble shoot different

aspects of this um uh or uh that's probably a broad concept or or thing because I mean you have a great uh

JavaScript example here it brings in the solidity contract and it uses the ZK verify JS that that Steve rushby went over a couple days ago so I think this is beautiful you said all this is going

to be published this working version on the ZK verify GitHub yeah it's already published it's already there if you want to take a look

and yeah I mean here I think that yeah of course definitely if you find some blocker or something unclear definitely

reach out on Discord you will find some developer able to help you out and uh in

particular I think that still one of the rough uh edges that are still there we are working on it though is uh in this

particular part of the code let me so in the smart contract actually uh in

Computing actually the en properly encoding the public input can be

tricky uh and uh so in in this case it required the changing the endianess of the input which okay entails this

strange looking piece of code so it it's the the trickiest part we are actively working on making it much easier but in

the meantime if you find some difficulties here just reach out on Discord and we will be able to help you I think the biggest most important thing

is a working example uh that's so this is wonderful uh I think we're about ready to wrap up LCA this was great I really appreciate you going through this and I'm sure a lot of the developers in

are hackathon uh are too any final words uh before we finish up yeah I mean uh of course this was all

the let's say architecture that you need and all the pieces uh now you just need to fill in the interesting stuff yeah oh AB

absolutely no this is a great framew work uh thank you very much well I think we're going to go ahead and end up here uh we may end up doing a uh another live

stream on how to use a ZK virtual machine um with there there's a number of different ZK VMS out there we want to have verifiers for all of them most of

the zkv virtual machines they'll create either like a plony 2 or a pony3 uh proof or a stark and then they'll wrap it in Groth 16 and send that wrapped

Groth 16 to an evm of course ZK verifies on an evm and we got verifiers for everybody that's our plan so instead of taking the extra computation the extra

time to send that zbm uh to wrap that zkm proof into grth 16 you just send it to us as a as a stark or a plunky 3 or or whatever so

alrighty well thanks again Luca we're going to wrap up and uh look forward to the the next one this this was great thank you so much bye everybody thank you for

joining awesome we're done that was awesome