IRL Workshop: Build on Ethereum, Hanoi Day 2

Transcript

works and then to talk about how can we make like a zk roll up based upon the evm so so yeah the idea of zk roll up is that is that we want to have a proof of validity for all of the transactions that we're processing and then we publish like the data that we need to reconstruct the state and that's basically the zk roll up idea that we have like a way to do computation that's trusted and we also have that that's like trustless and we also have like data availability guarantees where all the data is published so anyone is able to like unilaterally withdraw at any time because in order to withdraw you need to

know the state of the system uh this also like the benefit of zk roller but also it allows us to build trustless bridges that like when you have a bridge from one l one to another or from one l one to a side chain you have to have a trusting bridge there always has to be some authority that says this state on this side chain or this l1 is correct but because we have a validity proof in zk roll up we don't need to have that we can just have we can have a a bridge that's based upon like the validity proof of the state of the system so that those are the two benefits of zk roll up it means we can have trustless bridges uh

okay so let's talk about like a simple zk roll up first and we'll discuss we will just go through that in order to inform our discussions later today okay we're going to talk about our zkp and all the things we're going to talk about in the next one is going to be happening inside our zkp like i said earlier we need to make a proof of validity in order to be able to in order to show that everything that's happening in our system is is done correctly

so we make a proof of validity with our zkp so here's the things that we need to check inside our zkp uh before we talk about that let's talk about like what does our system look like so we end up so we all the time when we talk about zkp's at least for now we have a zkp we have a merkle tree we have a merkle tree is like an accumulator that has this very short uh representation of a of a huge amount of data and this bigger too okay and this is beneficial because like inside our zk roll up we

have like a lot of data and we don't want to have to store that data on layer one because it's just a lot of data to store so instead of storing it on layer one we store the like very short representation of this data and that's called the merkle root and basically the way basically the way that we calculate the merkle root basically the way that we calculate the merkle root is that we have this we make this kind of tree this is called a merkle tree we have this tree where we have all of our users there's alice bob carl

and denise so each of these users has a leaf in the tree and then we calculate the merkle root by just hashing together these two things so a hash function is this kind of like uh it's this tool that takes like a big amount of data and converts it into a smaller amount of data it kind of compresses that data um yeah that's what a hash function is and the important thing about hash function is it's collision resistant that it's really hard to find like two input data that leads to the same output data so anyway we use a hash function in order to compress this big amount of data into a small amount of data which is just merkle root

how do we do how do we make our first validity proof well the first thing that users need to do is they need to sort of consent to making a transaction so let's say that alice wants to send some money to bob so the first thing that alice needs to do is alice needs to sign the from address the recipient the two and the amount so alice signs this and sends it to our coordinator so let me draw this sends a signature

to our coordinator who makes the zkp so what does the zkp prove so basically the zkp let me clean up a little bit here so we have our signature alex sends it to the coordinator and our coordinator is now going to make our zero knowledge proof our coordinator makes a zero knowledge proof so basically we have a merkle tree with alice's leaf and bob's leaf

and we have our signature so the first thing that the coordinator does or that the prover does is check that the signature is correct you need to verify the signature is correct so so so they they verify the signatures correct inside the zkp the second thing that they do is they look up the from to an amount from the signature they get the from they get the from address and the first thing they need to do is to make sure that alice has enough money

to transfer the money from alice to bob because if alice wants to send like a hundred dollars we need to make sure that alice's balance is more than a hundred dollars so the next thing that they do so they get the from address and then they do a merc they they need to like load this data and with a merkle with a merkle tree the way that we load data is with a merkle proof uh so they make a miracle proof for alice's leaf for the from address yeah and that basically gives us this value here

so the next thing that we need to do is we need to check that the amount is greater than the balance of alice's leaf so we basically do alice dot balance is greater than amount right and like we're doing this check to make sure that to make sure alice has enough money in order to be able to send it to bob uh and this so so like what happens if this proof fails what happens if alice doesn't have enough money to send to bob if alice doesn't have enough money it's impossible for the prover to make this it's just it's just like this this check

has to be satisfied if this check isn't satisfied it's just impossible to to progress so like this is an interesting piece of nuance to to recognize that like inside zk rollups when there's like a failure or an error it's often the case that it's just impossible to proceed with the right so we we need to check the balance is correct and the next and if the balance is correct then we need to reduce alice's balance so alice's new balance has to equal the old balance minus the amount

we've successfully processed about half of the transaction we've taken alice's leaf and we subtracted away the money that she wants to send and the next thing that we need to do is we need to save alice's leaf that like so far we've only processed alice's leaf in memory right we haven't updated the most important thing which is our merkle root we've only kind of loaded this leaf and we did we did what we did so the next thing we need to do is update alice's leaf there's two important things that we have to achieve during this step the first thing is that we need to change alice's leaf

the second thing is that we need to change only alice's leaf we have to make sure that the prover isn't able to change all their leaves in the tree right because there's an attack here that if the if the approver is able to update the tree at more than one position they're able to basically print money like the attack here would basically that like like a malicious prover would update alice's leap but also update bob's leaf at the same time giving bob like infinite money or giving bob like 100 million money and then bob would be able to withdraw and just steal that money from other people in the system so like we want to have this invariant where like money can neither be created or destroyed it just

passes from one person to another right so that's how this work yeah so in order to achieve this we need to look at how we did our merkle proof when we did our merkle proof earlier we got the we got the from but but we also had this like witness so the witness data was basically a summary of the rest of the information in the tree just the way the root is a summary of all the information the witness data ends up being a summary of the rest of the tree for example to prove to make a merkle proof that a is part of root you basically give a and b and you hatch

them together so what we do in order to keep bob's leaf constant is that we use bob's leaf is that we use the same witness data right because like the witness data is a summary of the rest of the tree therefore if we use the same if we use the same witness data then we end up having we end up keeping the rest of the tree constant and we're only changing uh the single leaf that we're the alice's league the single leaf from alice so that's what we do we update alice's leaf with another proof so we say the new root equals alice's new leaf equals the merkle proof

of alice's new leaf alice's new leaf and the same witness from before so now we process half of our first basically we take now we process half of our first transaction basically we take like all of alice's we take an alice's leave and we've subtracted the amount of money she wants to send to bob away right so any questions so far yes so uh so the question is if you're going to

update the rest of the tree shouldn't there be concurrency yes so you so like basically what you're saying is that like you want us to like you're you're saying that well shouldn't we update alice's leaf and bob's leave at the same time is that your is that what you're saying no i'm saying that suppose you have more than one coordinator then you yeah then you should have some conflicts between them right because right so so you're saying that like if you have more than one coordinator there's going to be some conflicts between them yes yeah uh yeah i think so so in this in this case we we have a single coordinator it's possible for us to have multiple coordinators and decentralize that role but like we'll

only ever have one of them making a block at a time just the same way that like with ethereum we have only one person making blocks at a time there's only one miner who's making a block and the mining process is basically the process of deciding who who that is who gets to make that block that like yeah all right thanks sorry mike so i would like to ask about the signatures here from yeah so the signature is the is the you you sign the hash of

two amount uh in this in like we're doing a simple example here where you sign the hash of those things uh but actually in in reality you'll also have nonce you'll have nuns here too but like basically you sign the hash of this when you want to check the balance for example you do a similar thing to what you do when you do the marker that like we have this like succinct representation of everything that was signed and then when we want to look at the balance we provide a proof that this balance is correct okay so um

the signature is from ck group uh just as a signature of normal signatures it's just a normal signature and uh the proof here you you write like up from and witness so it's mean the zika vlog here right i'm sorry fruit of from and witness so this rope is a secret roblox oh so so the from is from the signature okay let me put him in blue the things that come from the signature uh from then the witnesses provided

comes from as like it comes from the coordinator or the approver the prover provides the witness as just a way of proving that the approver provides the witness so that the proof is able to like efficiently check that like this this leaf is actually in the in the in the merkle tree i see uh so the fruit means that from it's in a micro tree it's in the leaf of a marquetry yeah right yeah uh but is it a zika group no it's a miracle proof i say yeah i'm sorry it's a miracle proof so let me update that with

so this is a miracle proof and this is another miracle proof this is another miracle proof ah okay let me clean this a bit yeah i see that good okay thanks cool okay any other questions so what's the next thing that we need to

do so we process half of the transaction we've updated alice's leave we reduced alice's balance so now it seems like the tree is kind of like missing some money we've taken like the amount from alice and we've kind of like but it's it's not an annie leaf in the tree now we've updated the route and it's kind of like the approver has some money in their hand and like their responsibility is to give that to bob because bob is the recipient of this and like it's really important that like the court not only is the coordinator

not able to steal from users but also the coordinator is not able to like remove money from users they're not able to like delete money like because there's a difference here like stealing money implies that you get it you have an incentive to get it but also like deleting money is still like uh uh a bad thing to be able to do because you can threaten people to like delete their money you can extract some kind of like bribe from them or some protection money or something uh so the next thing that we need to do is we need to take the money that the coordinator has taken so far we have to force the coordinator to give that money to bob so let's go through that process i'm gonna delete this part if that's

and do the same process for bob okay so what's the next thing what's the first thing that we need to do yeah we need to do two to bob so how do we do the two-part yes yeah and and then what do we do so we have the two address from the signature and what's the next thing that we need to do

yeah so we need to get the proof uh so this is a merkle proof of what of what you said earlier the two two and the witness what color was i using for witness was that red cool so we got the merkle proof of the two of the witness what do we need to do next so so now we've kind of like loaded this into memory we've taken the the the root and we've got like bob's leaf

we have bob sleep and we need to update bob's leave so what's the next thing that we need to do in order to update bob's leave sorry yeah yeah so let's do that so it's like bob dot amount plus this like that wait that should be in black i'm still following the same plan so it's it's from the signature it's a mount so

it's blue perfect okay so now we've calculated bob's new leaf so let's just call this like underscore okay so now we've calculated bob's new leaf what's the next thing that we need to do we got to update the merkle root and how do we make sure that we update just bob's leaf in the merkle road so what we got to do is we got to use

the same witness yeah so we do that so we say that the new route root equals the merkle proof of bob's new leaf and the witness from before and that's what else do we need to do right yeah so so basically we do that by

just copying the amount in the circuit so like this is just coming directly from the signature well yeah you're you're right so we need to we need to make sure that this amount is the same that's right is there anything else that we need to check nuts so like in this example we didn't talk about nons so the idea of a nonce is to provide replay protection that like in this situation the coordinator could make money proofs taking money from alice and giving money

to bob and just repeat that until all of alice's money is gone and this is bad because alice is only consenting to send 10 but actually a malicious proofer is able to leverage this to send many money amounts so basically the idea of a nonce is it's just a increasing number and like basically when alice does ascend we just make sure that the that alice's nonce is equal to the current the nonce of the signature and after that after that transactions process we increase alice's nuns by one cool so anything else that we need to do so i suppose that like one other thing

we need to do is we need to we need to set the public inputs of this of this zkp right because the zkp doesn't operate by itself it's actually operating between like it doesn't operate by itself it's actually like used by the prover and by the if you the prover like the zkp on its own is not a zk roll up we need to interface with a smart contract and the smart contract needs to be aware of like some of the things that are happening inside the the system so like what kind of things does a smart contract need to be aware of yeah so they so you so you said that

they need to be aware of the input and the output and the change during this step is correct exactly so what's the input right so so this is the this is the data that we need to publish so yes let me put that on chain so let's just have it these are this is a public input so it's from it's two and its amount

what else do what else do we need to pass as a public input the witness no the witness can be provided outside the system yes the old and the new route we have the old route here and we have the new route here at the end new road so both of those are passed to the system so what does the

what does the smart contract need to verify you don't need the nouns you don't need the nonce you can compress the nouns out because the nonce is only ever increasing if i see this to address i can calculate the new nodes because i know the nodes of this account before i just basically say oh alice's nonce is gonna be alice's current nonce plus one and that's always going to be the case the nonce is only ever going to increase like that so like this is kind of like

gives an intuition towards a whole set of optimizations that we can do like we talked about earlier or yesterday about how with layer two the only important thing to optimize for is call data because like our proofs are basically our computation is basically free because we either have a zkp which is like constant cost for our computation or we have a fraud proof which will never be executed or theoretically never be executed because the incentives to pre create a fraud proof are just not there so this is a really interesting like area of reach search in layer 2 about compressing the call data

cool so what what what does our smart contract need to check yeah we need to check that the zkp is correct uh let me make some space to to write this down we need to make uh yeah we need to check our dkp what else yep we need to check the root what about

the root what we store the root root equals root prime and what else is the current one yes we have to check that this route is the current route i'm going to change the colors here a little bit i'm going to have public inputs from smart contract to be red root

group prime i'm going to have public inputs to be red so i can have red here okay so also this is a equality check and this is a this is a variable change what else do we need to check in the smart contract anything else

yeah i don't i don't think that there's anything else either i think i think that that's enough checks i don't think we need to i don't think we need to check anything else in the smart contract no actually the people use the call data to install that so so this is called data but call data doesn't really store okay so sorry let me let me just explain what cold it is so so in ethereum there is uh contract storage and this is very very expensive to store a variable on chain costs a lot because

you need to you're basically asking every ethereum node to store this variable in memory in in the state and that's just and that's really expensive because we need to keep the state small because the state it grows it means that like your hard disk needs to be bigger you need to download more data when you're verifying the chain and like our philosophy is that like we want as many people as possible to be able to verify the state of ethereum so because of that we try and limit the state as much as we tried to limit the size of the state as much as possible yeah because of that we try and so so we make storage very expensive but there's

this other way of making sure that like data is available without making making it making without publishing it and that's that's called like call data or that's kind of like putting it in cold data and basically the idea is that like you just include this these variables in the transaction and you check them you check that these are inputs towards ekp but we don't store them anywhere and like the benefit of this is that like that makes sure that everyone knows these variables everyone knows what they are but no one is able to like but they're not stored so we don't have this like overhead of like having to store these variables having to get them and and and save them again in the state

instead we just have them as part of the the the transactions that you need to download and verify the difference here is that like if you store something you need to have it available all the time if you put something in called data you just need to have it available once and then you can forget it after you've verified that like this data is correct you don't need to store it anymore so like one of them is like read only and the other is read write so call data is read only so it's a lot cheaper and storage is read write so it's a lot more expensive do the critical data help the system to recover

some issue for example like every everybody lost the power supply and then the network needs to reboot or something do that help the the network reboot right so the call data is used to make sure that an important role of this coordinator is to provide these witnesses these witnesses are important to update the state but they're also important for withdrawals and like the issue is that if this coordinator disappears the witnesses won't be available anymore and if the witness isn't available anymore everyone's money is stuck no one is able to withdraw no one is able to

transfer so we need to have a way to guarantee that this is going to be available and the way that we guarantee that this data is available is by providing the call and the idea is that like this this is like really small amount of data to publish but it allows you to reconstruct the whole tree because you can just see that oh this is the state before here's the list of accounts were changed here's how they were changed and you just continue to update until you calculate the latest so um do we need to use the ck property here we don't use the zk property here yeah that's an important uh thing to

recognize that like zk roll up doesn't have any privacy guarantees in fact we're going out of our way to make it transparent we're going out of our way to make it transparent by publishing the list of things that were changed and like this is important because we want to have transparency so that people are able to continue the system that we're building a system that's for scalability rather than for privacy that said we can make something called a zkzk rollup which has privacy as well that's a little bit different uh but it's it's a little bit different but it's it's it's functionally yeah it's a little bit different but we using the exact same techniques we can

we can build the zk roll up except we have to replace the signature with the zkp so instead of having a signature you just have a zkp that like i i've you use as you can pay for privacy from the coordinator right so the question is that like if we try and make a zk roll up will we have some problem with the data availability and the answer is yes but we can adjust our system in

order to overcome that let's think about like how zcash works so zcash works by we have a zkp that some users spend their money and we have something called a nullifier to prevent double spends and we have the new leaf that there that they're updating in the tree and when we have these three things when we have these three things we're able to we're able to make a z cash system and like our data availability problems just depend upon publishing those three things so we we basically publish them uh the problem like it's not going to be as scalable as this because the data you need to publish is bigger like that's

like 256 bits for three things the two from an amount is going to be like from is like 32 bits if we have 232 users this is 32 bits this is 32 bits 32 bits so that's 64 and that's uh 90 something so so like it's basically two transparent transactions for yeah okay so it's like you can have six transfer transactions for one zk okay cool any other questions yeah so you you mentioned that on-chain data variability is very

important yes so what do you think about validium or the recent hybrid approach of stock work which is volition is what validium when they don't have data on chain right but keep only uh at the layer two and volition in which they allows a hybrid approach for the user to to choose whether to have data on jan or just add layer two right right so i think that like having date availability at layer two okay so let me talk about validium first so i think that validium validium works validium is like less secure than zk roll up and the reason for that is that like you're trusting

the coordinator to to maintain the data this these two witnesses these are important for being able to replace the coordinator and for withdrawals if the coordinator doesn't have these if this information isn't shared with other people then the coordinator is able to like prevent people from withdrawing or delete people's money effectively the the zk roll up me prevents people from stealing money but i i feel like i feel like if you or if someone has the power to remove your money they can just insist upon having a very high fee in order for you to transfer your money so

i think that there will always be incentives for people to do that the other way that i think about this is that like we want to build like censorship resistance systems and if we build sensors like this system is not censorship resistant right because it's just a single coordinator if that coordinator decides not to include transactions anymore all the money is basically stuck they're not able to do anything uh their the money is just basically sitting there so like that's my problem with validium uh the hybrid approaches have the same problem where like you have to move like the hybrid approach is that basically like if you're in validium you have the same problem where you're not able to withdraw by yourself and like the

coordinator is able to like charge you a ridiculously high fee in order to transfer or they're able to prevent you from withdrawing if they want to also if they're if they're like doing some censorship attack or forced to do some censorship attack there's no way to recover like i i think that the thing that's important about decentralization is that you have neutrality and you're able to recover from states where where where the system fails and in both in this case with validium you're not able to do either you don't have neutrality because there's like a single coordinate or a group of coordinators who have the data you're not able to recover from you you so you don't have like

neutrality and also you're not able to recover from states where they lose that data there's no way for you to to kind of get the get the latest state after so that's what i think about volidium okay so uh in another way it means that uh if uh like if if you keep only data off-chain then it means that you only have something like semi-custody yeah okay if yeah yeah if you keep data obtained yeah yeah you you don't really have custody of the funds you're like trusting this other group to to kind of maintain your funds for you yeah they cannot really spend your money but they will be able to prevent you from spending it yeah exactly yeah yeah okay thanks sure

any other questions actually like even the coordinator stop working so i think i can uh um like like bring myself to be the like myself can become a coordinator and then reconstruct it that then i can withdraw my money yeah yeah that's that is so there's like there's two things we need to be aware of when we're thinking about this that in the worst case we want users to be able to become the coordinator um and we need to think about like the

leader election for the coordinator like how is the coordinator able to make blocks how do we decide who is making the blocks because we discussed earlier that like we need to have like a single person doing it at a time so like there seems to be two there's there's like two different approaches one approach is that like you have a forced transaction where on layer one you say ah i want you to include this transaction and like when someone includes that transaction they need to to process it and continue um when when you put that transaction on chain the coordinator has to include that transaction if they don't include that transaction they won't be able to make other blocks like that's one approach that helps you the issue with this approach is that it

costs a lot to do the unchained like if you're imagine a world where you have some very popular zk roll up that has like a million users and we're using like the future ip4844 for data availability so the transactions are really cheap if those users want to make a transaction on layer one they just won't be able to there's no way for a million users to make a transaction on layer one so we need to build systems where like the forced transaction is really really cheap the other thing that we need to do the other thing that we need to think about is the leader election like how do we decide who's able to make blocks like one natural idea here is to make

one natural idea is to use proof of stake for leader election on layer twos but i don't think that proof of stake is a good solution for leader election layer too because there's like on layer one it makes a lot of sense because we have this issue of like if there's a censorship attack we're able to have like a user-activated soft fork to to to to basically recover from the from the attack like in that case yeah we're able to have a user activated soft fork in order to recover but like on layer two we're not able to do that there's no way to have like a user activated soft fork on the layer two unless the layer one is also involved and that's like trying to do that trying to orchestrate that for a roll up

that's broken seems to be very expensive and very difficult yeah i think that like we have to be really careful when we think about leader election on there too like what you're saying does make sense that like theoretically you could become the coordinator to make your own blocks but we need to make we need to be careful when we think about building on layer two how how is the leader election decided how are people how do we decide who's able to make blocks yeah so i'd like to have a question so as we are approaching the merge what do you think are the potential impacts of the merge uh to uh the zika roll up ecosystem right now

ah so i don't think there will be much impact at all i i think that the merge is like there will be some nice benefits of having like more consistent transactions and maybe we'll be able to have like get bigger yeah so like let me talk about that in a second but like i think like the first order effects is basically nothing i think there will be some second order effects that will help like one problem right now is that it's hard to make big it's hard to make a transaction that's really big that has really big big call data and when we're putting a lot of call data on chain we want to have a transaction with a lot of call data the reason that it's hard right now is that like the the network is not really uh the the network is not really optimized

for for for broadcasting transactions uh or bigger transactions there's always this worry about the uncle rate because of the proof of work system is dependent upon transactions being broadcast across the network very quickly because of that but that will change when we move to proof of work or proof of stake there's some other interesting things like we could reduce the call data cost for the same reason that like if we're not using miners anymore we don't have to worry about so much about trans blocks propagating through the network as quickly as possible but like i think that our current approach is that after the merge we're going to focus on 4844 ap484 is basically

massive call the call data availability so it should reduce the gas cost of call data a lot it'll it'll be slightly different than the current approach of just publishing on chain uh as part of a transaction there will be a separate transaction type but yeah i think i think that that's the the real that's the time when like zk rollups and optimistic roll-ups are just gonna i just gonna explode i think that we can have like millions of users and thousands of transactions per second when we get there and like that's that's one of the things where like ethereum is like really that's like you know that like people talk about ethereum's functionality escape velocity like what is the minimal set of features

that we can have so that you can basically build anything and like the one thing that's missing is like massive data availability and once we have that i think we'll be really close to being have roll-ups that have millions of users and i think that we could get there now but it would just be a little bit expensive so i'm really excited for ep-484 the merge is less interesting for zika roll-ups or an optimistic roll-ups but there will be some like second-order benefits there right but you know like with the recent event that eydx is leaving software because of the scalability problem that they claim oh i didn't hear about this yeah so so what is the issue uh there

is the coal data cost is too expensive uh well i think that they they claim that uh 1000 tps is not good enough for them right but as you say uh we're going to reach like median yeah so yeah so dydx is like okay they're gonna move to to site uh their own change oh right okay okay yeah i did hear about this yeah yeah i don't know how much of that is just like i want to do another token and and how much of that is like really about about the issues like it does the ydx consistently have more than a thousand transactions per second requirements

like they're on stark net right now is like what is that is that the zk roll up stark net or is that the validium circumnet it seems uh should be uh zk roloff okay okay see your role okay interesting okay uh yeah i don't know i don't really know about about this what do you think um sorry give me a second what what are you thinking about optimistic thrown up and the girl ng corona yeah i think they're both great i think they're both complementary and i think that like the systems that will eventually be like the

most secure are systems that that are combine the security of both that you have a zk roll up and an optimistic roll up that yeah you have a zk roll up an optimistic roll up that's that work that that like you have something that has the security of dk roller but also optimistic roll up so we have a fraud proof and a validity proof and like the this this would be really nice because it will let us if there's a mistake in one of the one of the proof systems it's very unlikely that the same mistake will appear in the other so it's like it's like kind of how we have like multiple implementations of of of the evm and the consensus there clients we have this sort of redundancy

like gk optimistic runner yeah we could have a combination of both and i think that that's that would be the thing that i would trust the most um yeah yeah so i i think both are great i i think that like we have a lot to gain from working together i actually i disagree in current states i use optimism and rb charms a lot but i think it enjoyed creating the fragmenting fragmentation in liquidity so i i don't think in this current state optimistic grown-up is the future so i

i really want uh zika run up because for nfd or other currency other token token you if you want to transfer from the army shaman from abicham to the ethereum it takes eight days [Music] yeah that's true so it's very annoying that's true that's true yeah i yeah i hear you yeah um yeah that i definitely underweight the importance of liquidity uh i think that like it'll be interesting to see ck roll ups in production and see or is evm compatible dk rolls in production and see like how

they compete and like the different trade-offs and guarantees there but like yeah like what you're saying is compelling like that that does seem like a limitation but like i suppose that i was answering was like i just wanted to maximize security but like maybe that's that's maybe not what you're trying to maximize here that like we're trying to optimize for different things and that's why we have like a slightly different answer so barry i heard that after the merch uh you say that uh will focus on um lower the rafi for codata yes but and i heard also some proposals for some function that dedicated for zkb like

rescue or president and also some some some new curve so some big curve for for big secret of zkb so what what other state for zika for the proposal we will actually have soon or maybe a lower it might be involved in far future yeah so like i think that like the first thing we're going to do so right so let me ask answer about the the call gas cost reduction so there's two approaches here there's the like relatively conservative

just reduce the cold data gas cost and there's the more radical but also like much better uh ep 4844 where we end up with like sharing and huge amount of data availability yeah so i think that like i hope that we can get to ip484 in the in the higher fork after the march i think that like we should prioritize that to the point where we just don't worry about anything else i think that that's just such a such a huge priority that that should just be our main focus um i hear you about so about the the hash function standardization

theorem i don't think that's gonna happen anytime soon although i don't have any insider information i'm not part of the core devs or or any of those institutions i'm that's just my personal experience without having like discussed it a lot i just know that i've been waiting for those types of things for a long time and they haven't really worked out um i think that like on our side we're trying to focus on making efficient proofs for evm friendly things like ketchup and sha-256 i think that that's like i think that that's like the solution that's like at least inside our control that we're able to optimize those things so like i think i i think what you're getting at here is like the deposit cost

for a zk roll up that uses poseidon uh or rescue or something else is quite expensive and you want to know when that cost is going to go down so i think it's not going to go down i think that we should architect our zika roll ups to use snark or snark to use evm friendly opcodes in order to avoid this okay thank you um some another question about the cadence so as the secret knob is cheap because we can invest many many transactions however in the early phase of a neutron up by example there's a god of they harshly can get

enough of transaction to make a batch and how how does the the the the premier uh run up like the casing or software do with the zig problem yeah so that's a big problem that like these systems work well when we have a lot of transactions per second but like when you make a new one it's often quite low transactions per second so i think that like one of the approaches that people are taking is to try and make a zka evm compatible roll-up because if you have that then you're able to if you have that then you're able to have like many transactions per second or you're able to have like a bigger set

of people because it can be anyone with a smart contract that building like an application specific ck roll can be hard to bootstrap and like i've seen that with some of the some of the application specific zk roll ups the optimist and marathon didn't have that problem so much uh there's other things that we can do to mitigate as well like one thing we can do is have like this weaker economic finality so that like when a user sends a transaction we can basically say okay let's wait and include this transaction later yeah let's wait and include this transaction later here's a here's a here's a here's a guarantee that the transaction will be included or else i'll lose 100 or whatever like that seems to be like decent enough ux

that like it should still work and then you just make a proof once per day or once every few hours but like that is still kind of costly and like bootstrapping rollups is something that's that's hard to do you know thank you so much let's do like five minutes about evm and then take a break okay so we talked about like we talked about this and like how we can make a ck roll up the next thing that we want to think

about is like this is really simple right this is just transactions we're just we're just processing transactions and that's that's all we're really processing so how can we make how can we make a system that that that does more because like we're worried about having enough critical mass to make our zk roll up popular and we're also worried about like how can we how can we support more users or more applications so it seems like a natural way to do it to to approach this is to copy what the optimistic roles are doing the optimistic roles that are evm compatible and they've had like huge adoption they

don't have any issues with trying to get more more people to build on top of them so let's explore let's explore this idea and see how can we make a zkp for the evm before we do that we need to think about well how does evm work let's let's have a look and see is it yeah okay so like the evm is basically like a

stack machine where we have a whole bunch of op so we have a stack so this is like a sort of a temporary memory i think the stack has like 1024 elements and basically you have like four op codes that can interact with the stack there's push pop uh dope and swap so basically push if you do like push one it basically just puts one on the top top top of the stack

if you do pop it just basically takes the thing off the top of the stack and passes and returns it so i'll just give one back uh there's dope and swap dop is like duplicate two elements let's swap his take two elements and swap them uh let's not worry about dopant swap for now let's just keep it simple with push and pop uh so that's the stack and the other thing we have is like the the the byte code so the byte code is basically just like a list of the of the op codes so we can have uh let me do i code basically we have like push push zero

pop add yeah let's just do let's just have a program that does this uh oh no so let me okay let me do a program that actually makes sense so let's do push one push one push two pop so what what how does this how does this actually work so basically we take the we take the byte code and we start at the top we do them one at a time

so push one that basically just puts one on the top of the sack and then we go so we finish that we go to the next one we say push two okay so we push two we put two on the top of the stack then we get to add basically what i do does is it takes two things it adds them together and it puts the results on the top of the sack so we need to take two things off the stack one and two add them together three push the result back on the top of the second three finally pop takes the top the thing off the top of the stack three so that's it that's our program it just like takes things adds and puts things on so this is the first layer of complexity it seems like okay

that's hard to do like we talked about before about how like a user was like passing passing money around it would take money away from bob will give money to alice like when we were doing that we were doing marco proofs and it seems like we could do merkle proofs here too like we would just have the stack and we would push one onto the stack we would have a merkle proof we would update the road and we would push two onto the stack we would have a miracle proof we would update the route and we would do this for like all of our different operations like the problem with doing this is that like it's it's expensive to do that much hashing uh especially when we're doing a per op code so like let's look at the cost of

these opcodes like these off codes are all costing less than five gas less than five gas and like an ethereum block has right now has 30 million 30 million gas so 30 divided by five is like six six million six million push adam pops and that would mean that like if we were having a miracle proof for each of those we would we would have like and this is two thousand ones and twenty four we would have these really big merkle proofs it would just become like really prohibitively expensive it seems like the approaches that we've taken before can't really be applied to like the system that we have here uh so any questions so far

okay okay let me introduce like the next layer of complexity we have our program here but we also have like a whole bunch more off codes that we need to deal with for example jump jump is quite tricky so okay let me let me write another bicode that does the same thing but it's a little bit more complicated let me start here so let's do do push one push one okay so we put one on the stack let's do push three so we're gonna put three on the stack let's do jump

jump is basically going to take oh wait i mixed up the ordering this should be like when you put something on the stack everything else moves down so like i put one here and then i put three but that's wrong yeah so it should be on the top so i i when i push through one here and when i want to put three i gotta delete this one put one here and put three here and that means that our merkle tree approach that we talked about earlier won't work right because if we have a merkle tree of like oh here's one and we want to update it and put another thing on we gotta shift this one down this one has to go here and like three has to come here

and that's just that's just really hard because we end up just shifting everything and shifting everything inside the merkle tree is going to be like at least a bit of work uh yeah you're gonna yeah like we might be able to come up with some like clever way to do it where you just shift everything down and then you have like the left hand side or whatever but it might be it might be hard anyway so that just makes the merkle tree a little a little bit more difficult uh okay so we do push one push three then we do jump uh so so like let's have like some other upgrades here i want to jump to five so let's have some other outcomes here

uh and let's add jump test and then let's do let's do push let's do push 2 let's do add and let's do pop what happens here we do push one this should be push five push one push five so this is our current stack then we do jump basically what jump does is it says okay take the top thing on the stack and go to that index

in the bytecode so we have like index zero one two three oh okay let me just start the index from one so one two three four five six eight this is index so we say okay let's just jump to that element so we do that we go so we say jump to five okay so we come here this is our this is our this is our program location one one of the rules of jump is that like you have to jump to a jump destination so we're like okay fine let's move here jump destination is correct so we we've removed five from the stack

when we did the jump because the jump will take an element off the stack and go to that location and we went here and the next thing we need to do is make sure that like we did a jump let's make sure it's a jump dust okay that works let's move to here push two okay we gotta push two which means we gotta take one and move it down one goes here two goes here so we're filling up our stack let's go to the next op code let's go to add so we take two elements off the stack and we put the results we add them together we put the result on the on on the stack so that's three and then we do a pop we take three out the stack and then we're done so we do a pop

we take a three off the stack and then we're done this is a little bit more difficult so we talked about like okay we could we could potentially manage our stack by doing this kind of like uh jumps or by by doing a kind of merkle tree but it seems like it would be prohibitively expensive so let's think about like how can we handle the byte code like how can we handle this like jumping and stepping between like we could do the same thing with a merkle tree we could have like a merkle tree with all of the different bytecode and then when you update the index you just go to that to that when you update the index you just go to that location in the merkle tree but that also seems to be pretty prohibitively expensive because each op code is like can be like one gas and if

you're doing a merkle proof for each cast that's going to be really expensive in in terms of prover time so this is this is some of the reasons why the evm is hired let me introduce the other two like tricky things uh the other two tricky things is that like we have like this is like this is like temporary memory and it's really it's really short it's like the it's like the cache the l1 cache on your cpu it's just like really small and it's really cheap to access it's really quick but it's it's small and you can't really do a lot of bigger calculations so we have this m memory memory is much bigger and we're able to insert more things into the memory so memory is much bigger and like

another cool thing about memory is we can have like an index in the memory we can just say oh store it at this location store to this location so that's really nice we have like a key value tell you key value the other thing that like this is also like non-persistent storage the other thing that we need to have is storage this is persistent storage which is which is like a merkle tree uh and it's a it's a merkle tree with

ketchup hash function and it's a really weird three formats merkel patricia tree it's it's it's very it's not very common it has a lot of like edge cases and things like that yeah so this is cat jack this is super expensive this is super expensive and like very complicated to implement the the memory the memory is also expensive but it's not it's it's it's it's it's similar to the stack the stack and memory are pretty similar uh so to interact with these you have op codes like we have m store and store m load and s load just to interact with

stack and storage yeah this is basically all the stuff that's in the evm that we like this is not all the stuff but like for the purpose of this conversation we can just limit the scope to this the rest of the things can be solved using the same the same the same approaches so like whenever someone writes a solidity smart contract they compile it they produce the bicone and that's the buy code here like every erc20 token is just this stack it's just like going through the stack going through by code by byte code it's yeah it's it's going through here it's managing the stack it's managing memory it's managing storage this is this is like how ethereum smart contracts get executed so like let's pause here and like after

the break let's explore how we can make like zkp's to to to to like really implement this system any questions okay let's have a break [Applause] sir

what time should we finish that latest we already talked about like can i use the back of this one no i can't okay no it's okay sorry uh okay so we talked about like the evm and how we so we started off talking about like zk roll up and how it's how to implement a zk roll up and then we talked about the evm and why it's difficult to make a ck roll up for it or zkp for it so now let's talk about how we actually do it the first thing that we kind of did was

to say okay let's just separate these things out that it seems like we have a circuit it seems like we want to do like four independent things stack memory storage and by code so let's just break them into like separate components so let me clean up a little bit here okay so we have four things we want to we want to do one excuse me

four by code so we want to do these four things uh let's let me clean up a bit and we'll talk about one at a time ah also i want to merge these two together because they're very similar memory and stack are very similar so we can talk about those two together so let's about talk about those

first so let me let me write up a little example so we have our bytecode here so we have our bytecode where we start at like zero this is our index zero one two three and we're doing storage so are we doing stack so let's do push pop one okay so let's look at the like what this

looks like on the on the memory side so on this on the stack side so on the stack we basically have index equals one and then we have index one so that's when we push that's when we push the value we push the first one on to the the stack and index one becomes one and then we say okay we're going to push two on so then index one becomes two and index index two becomes one right

because basically what we're doing is that like we have our stack here we have our stack here where we have so stack when we do push one we just put one here then when we do push two we have to take this one out put this one down in the second position and put this one here in the first position basically we can convert oh but wait let me do let me do the rest of the of the steps so then we do a pop so pop means that index index 1 will become uh one

and index two will become zero right because when we do the pop so we had our we had our stack that was like uh two one so we do a we do a pop which basically means we take two out and then we have to move one up to the position to the index one and that's that's the next step of the stack call and then we do another pop which basically means we remove one from here so how does that look in our transcript well then we just basically say that index one equals one so like this is this is hard to do because like we're basically

when we're adding something to the stack we end up having to change a whole bunch of different locations in memory uh yeah we end up having to look like edit every single other other location on the stack uh so hold on let me think for one moment hmm yeah i'm not i think we might have a more efficient way to do the stack but like let's just continue with with this approach and like we'll discuss it and there might we might have a more efficient version that's slightly different but this is still the way that we do memory okay so like the next step here is to say that like like there's two things

that are hard here the first thing that is hard is that like when you put something onto the stack it kind of affects everything else the second thing that is hard is that like the order in which these things happen is undefined at setup time because this is like a smart contract anyone can deploy a smart contract that does this thing in a different order basically what we say is we add another column here and we basically say we have index but let's add another column that's like timestamp so this is the this is value and this is timestamp right so like the timestamp is basically the time at which it happened so we say

okay at time time zero this happened at timestamp uh zero this happened no at times time one this happened so that's timestamp 0 is this timestamp one is push two so these two happen at time step one and at time stamp two at time time two these two happen so this is two two and this is three the final thing that we do to make this easy is that we reorder everything at the moment things are ordered by timestamp but what we want to do is order them by instead index and then by time stamp

so we want to have all the index one stuff together and we want to have all the index two stuff together so let's do that reordering and see so so let me do that in blue for the reorder so we're going to do our reorder reorder of value okay so let's start with index one uh so index one value one is zero

zero index one timestamp one is two and what goes next next goes index one value one times time and what comes next the next one value one times time three can someone tell me how to do the next part for index two so basically what we're doing is we're just ordering things by like the index instead of by the timestamp

2 1 1 2 0 2 yes exactly let me see yeah yeah you might be right oh here yeah this one should be zero yeah that's this one should be zero and that means that this one should also be zero okay let's notice notice one thing here

that equals that oh wait wait wait sorry sorry no that's not that's not the right thing to notice push push pop okay wait value two so basically when you reorder like this

the value is supposed to be oh yeah whenever you do a push the value just gets set to whatever you want whenever you do a push you can just set the value to whatever you want so let's mark the pushes push 1 is here push two is here this is a pop no wait push one push two yeah this is a yeah right so this is only pushes

right yeah okay okay i see so let me let me describe this a little bit better when you do like okay so we have this new ordering we have this new ordering where where like things are a little bit easier to compute the things that are easier to compute is like push and pop become really easy because when you do a push you just take the timestamp and you just change the value at that timestamp and when you do a pop you just take the of the previous timestamp and you and you and you use that so this means that like the push and the pop become like just looking backwards yeah it's just looking backwards or updating the current value

so because of this we're able to make a circuit that like does our stack storage and memory for just like one roll per per edit per element uh and that's and we do this by like reordering things the one thing to to to to think about here is that like well we're reordering things though but how do we how do we make our circuits talk to each other that like it seems that like we have all of these different circuits and like we just talked about like we just talked about like stack and effectively memory but like the bytecode circuit needs to be able to take the output from these things and include that in the latest

computation so wait let me let me slow down a little bit so for the for the stack and the memory circuits does this make sense do people have some questions right so for the memory sorry let me repeat your question for the memory the index can be allocated dynamically and like how do we deal with that here so basically that's true and the way that we deal with that here is that like we just create

another index for whatever address is allocated randomly like or that is allocated dynamically so if this is like this is one here but this could easily be like 52 or whatever this could be just any any location so the question is like what if the memory gets reallocated for another for another thing so that's fine i mean the memory is getting reallocated here as well right because like when we're doing the extra push we're kind of moving things down on the on the stack

like when we do this first push we put one that into index zero and then when we do the second push we're kind of reallocating index zero to have two instead of one i i see that there are one one last problem with this well is it the the the location where people uh put the free pointer to the the net data like maybe uh zeros uh it's uh your uh osm 40 that address that holding the free partner right okay so what's the definition of the free pointer is that like the next place to put memory yeah yeah okay so that's handled in the bytecode circuit so let's talk

about that we have our so this is how we're doing the the stack of memory so what does it look like here when we say do push one so let's take this as an example let's make a bytecode circuit that's very simple oops oops okay so let's do by code circuit so basically we have our index our by code index which is zero one two three our op code

and our code okay so this is push push one this is push two this is pop and this is pop let's do that so the other thing that we have is we have our stack table so our stack table has the timestamp the index and the value

so our timestamp is just like this number that's increasing for every op code our index is the like location in and our value is is the value so so let's go through this and see so the first thing that we need to remember is that the stack table is created by the stack circuit and the stack table is kind of passed to the bytecode circuit to be verified afterwards so the stack table basically is is this right it's just like for different indexes you have for different timestamps you have different values if i want to do push one i basically make i just basically look

up index one add so if i want to do push one at time stamp zero i basically look up this table and make sure that the value is one right so when i'm doing this push operation i get my timestamp which is zero i get my index which is also zero and then i get my value and the value is so i put the value one and then what i do is i just make sure that this is in this table and if this these values are in this table it means that when we did this circuit that was the value that was inserted here so it's kind of like an api call to another location questions

i'm going to get to the question about the dynamic memory or to the free pointer location in a second okay so so basically another way to think about this is that this is like an api that we have one circuit and that circuit's responsibility is to handle the stack and we have another circuit and that circuits responsibilities to handle the byte code independently they don't prove anything but once you verify once they you have both proofs they verify that the stack and the buy code have been working together and that have been calculated correctly the reason that they that they need to be calculated together or verified together

is that like they just cover different parts and they need to they need to have communication in order to be able to verify everything so like we tell our approver prover you just make a proof about the stack and that proof can be whatever you want right now we're not gonna we're not gonna check anything but later if you want to combine that proof with the proof about the byte code it needs to be it needs to be consistent with what we're going to do there we're not going to check that right now but we're going to check that soon so we tell our approver to to make the first proof and then later we kind of consume that proof in another proof we look at like different results of that proof and say that oh this is correct because like this is the value that that

we wanted to have here we wanted to push one to index zero you're asking about the free pointer so if we wanted to have like a free pointer like if we wanted to remember the last place in memory that's not adjusted there it seems like there's two places we could do that one thing we could do like is the free pointer just like always increasing whenever you just add a value you just increment and when you pop a value just decrement incremented okay so so if that's the case what we could do is we could do it we could use we could just do it as part of the push in the pop-up code that like the first

thing the push or pop-up code would these values in the stack table and the second thing it would do was increment would be increment in the case of push and decrement in the case of pop the free memory index or the free memory pointer so so actually for the free pointer um the the compiler going take care of it when every time i write the course and it's going to store a new value after trying to free that like it's using the the m star to the

free pointer to start the new free address index right so that's handled by the compiler but do we need to worry about approver trying to store things to like not the free pointer location like it seems like that's one of the things that like so let me just give the context that you're working on like a wasm a proof of validity for wasm and like in wasm i think that like if a malicious prover is able to write to like not the free pointer or if they're able to write to an incorrect memory index that could be an issue

yeah yeah so so in that case we need to force them to always and only to write to that to the free memory index maybe i'm not sure 100 about the case of wasm but there is definitely a bunch of edge cases that we deal with where we try and make sure that they don't write the we try and limit where they write things that like for example if we didn't make sure like for example we have a stack pointer right we need to remember what the that

current bottom of the stack or like how many elements are included because for a couple of reasons one reason is that we can't have more than 1024 elements and another reason is that like for a couple reasons one is we can't have more than 124 elements and another reason is that like is that like we need to be we need to know where to go next like if like if someone tries to push like more than 1024 elements there's this weird error case that we need to think about so anyway for that we stack we we track the current stack pointer and we say this is the current stack pointer to make sure that like the prover doesn't kind of overflow that like when we think about

proofs of validity we're really careful about the error cases because like if the error cases don't match like ethereum's error cases or if the error handling doesn't handle doesn't match ethereum's ever handling it can be a little bit tricky to yeah it can be a little bit tricky it it can lead to cases where we're not 100 ethereum compatible which might lead to attacks yeah it might lead to someone being able to make like a smart contract fail in a way that wasn't that it wouldn't fail with the edm like one benefit of using the evm as the virtual machine is that you inherit you you kind of copy across all of the security guarantees of the evm or the

security patterns that are used there that changing the evm could result in patterns that are different or like for example if i have a smart contract that works on ethereum and i try and deploy it on some zk evm roll up then it can result in like a bunch of different issues related to yeah then it can result in a bunch of different issues related to like if the security if that contract then gets hacked that's bad right we want to have the security guarantees the same as much as possible so that's why we try and support the error cases cool okay um let me check the time any other questions about this part

basically the intuition here is that like by reordering uh things and separating separating it into two separate circuits we end up being able to we end up being able to have like memory be super cheap memory and storage let me clear this one and then i'll talk about like how the different components kind of come together so we have our bytecode

so we already talked about how our bytecode circuit and our stack circuit talk to each other and they talk to each other via this kind of like lookout table what else needs to talk to to what else we have our storage our storage needs to talk to our buy code circuit as well

because our storage is where all of our storage values come from but it's also where we load the actual buy code from so we have this we have another connection between the buy code circular storage circuit uh and our memory circuit has to go to storage by co2 so our memory circuit goes to storage another thing that like we've implemented and and and need to connect to two different circuits is that catch x are good so catch act circuit is basically just

like doing a lot of hashing and we need to connect catch up to the storage as well as to the to the code circuit because like the storage circuit ends up doing like some merkle patricia tree proofs and that means that we just connect the catch x circuit there too uh also the the the bytecode circuit will will like process it needs to perform catch operations so because of that we we kind of connect the catrice circuit there then we have some other other circuits like we kind of then wrap this in a big aggregation so because

this is many circuits i kind of just wrap this together in aggregation we wrap this all together because we need to have like a succinct verifier uh at the moment the verifier is a little bit more expensive because like if we were to verify all of these proofs independently it would cost a lot of gas because like number one they have a lot of columns and number two it's just a lot of proofs so the verifier is quite expensive so we have an aggregation circuit to kind of merge them all together once we merge them all together we're

able to like verify them pretty efficiently you you have mentioned that uh we can treat the the memory in the way that we treat the stock so that's why we not combine the stack and memory circuits together yeah yeah like that's one reason the other reason is that in the evm you're able to do two different types of memory operations you're able to do m store but you're also able to do m store eight where you store eight bits in memory and that's that's really that adds another couple of constraints because we like basically in this in the memory

circuit we need to break everything into 8-bit operations we store everything as a 8-bit word but in the stack we don't need to do that but i actually i think that at the moment we have merged the memory circuit together with the stack circuit and like half of the storage actually for that reason uh the stack you also have the the like the boost and the one i mean the opposite boost one because there are many kind of push up code oh yeah there's push one push yeah yeah yeah exactly oh right right right yeah that's true yeah yeah yeah so we end up having to do right but like the i the the issue like

the difference is okay so sorry let me just explain so like when we were talking earlier we talked about push and and like simple stack up codes but it's not actually as simple as that because there's push one push two there's like push 32 where you're pushing like different like numbers of bytes onto the the memory op code has a similar pattern where you can do m store but you can also do m store eight where a where like in one case you're pushing 256 bits onto the side in the in the other case you're pushing like eight bits onto the you're storing 256 bits in memory but in the other case you're storing eight bits of memory so like the difference is that with m store eight

you're able to like insert into the middle of a bigger word like if this is like zero zero one and this is one two three nine you can do m store eight in the middle of an index you can do online inserts but with uh push one through eight it's not online you just have like an element on the stack that like oh this is 256 bits and this word is like a bits but they both go on the stack as like independent words so you never you're never like merging words together but like with ms or a you're merging things together and

because of that we basically had to have to break it down into like eight bits that's what we did at the start we broke it down into bits but like in the longer term we'll probably yeah we broke it down into 8-bit words but in the in the longer term we'll probably change that so that we can do online memory in the circuit and the reason for that is that m store 8 is just really it's really cheap and it causes our m store to be really expensive in terms of like the numbers of rolls so we're working on like a spec for the unaligned memory in the state in this in the in the memory circuit and that should reduce our gas costs a lot cool any other questions

let's talk about so so in in the original section we talked about the public inputs at the start so what are so let's say we have a zk roll up that's based upon the zkvm proof so what are the public inputs that we need like the public inputs for this service like we did the previous uh like we need the previous days of the of the smart contract also we need the input from the and then maybe we also need the context of the

the caller like the current construct of okay so what's a good representation of the current evm state uh maybe maybe i'm not sure about it like could we use something like the state route stay root and we also need to have the the the new state route and then we have the list of transactions we've included what else do we need to include

in the proof yeah so like okay the context here is that like we're making a zk roll up with the zkvm what are the other public inputs we need to pass from like the layer one contract to the layer two circuit the byte code right but the byte code comes from the storage which comes from the state route all right maybe some interconnection uh maybe from layer one only two to layer one so withdrawal and the music something like that okay that's an interesting idea so the way that we handle the positive

withdrawal is we have a very simple message bridge so the message bridge basically sends the layer 1 state state root and this is enough to look up anything that's happening on layer one so in order to build like a deposit and a withdrawal what we do let me clean this a little bit and i can draw it

so we have here layer one this is our layer one and we have a deposit contract and this is our layer two and we have a deposit contract here as and then basically what we do is we use our message bridge to allow this contract

to talk to this one so basically when a user wants to deposit money they send a transaction to the to the deposit contract which updates the values in the deposit contract to store the deposit at a certain location in the and then they come to the layer 2 and they provide a merkle proof that for the deposit contract at this location in storage there's a new deposit and that allows the deposit contract to basically take the

that allows the deposit contract to take the users uh that allows the deposit contract to unlock the deposited money so when we create the deposit contract we basically initialize it with like infinite ethereum an infinite erc20 tokens and basically anytime you make a deposit on layer one you you use the message bridge to talk to layer two the advantage of this approach is it makes the creation of deposit contracts completely trustless you can make like whatever deposit contract you want and the discussion and like the communication between the different layers is is relatively easy to do yeah so we need our message bridge but

the message bridge is only the layer one okay any other any other questions about okay let's uh let's finish there thank you everybody for coming also i'd like to say thank you to quinn

for for organizing everything and making all this happen thank you quinn okay so hi hi everyone so let's wrap up the fourth workshop continuously from saigon to hanoi four days continuously two days in sangon and two days in hanoi so i see like some of you also enjoy bookshop in hanoi and in saigon right and then what did we learn in the first workshop in in saigon the first day like we do the meet up with like depp vietnam community and also like sharing about ethereum projects and also like about gkp right and the second day we study about

uh plan tutorial implanting plan on python right and two days in hanoi what did we learn yesterday we learned about merci about quadric fundraising and also today we learned about zikro up and zk evm so we thank you barry very much you know like spending the time with like that vietnam community with eat vietnam and like sharing a lot of like knowledge with us um and especially we can learn from the expert and also like thank you for kaiba team also let's have been supporting us and also like you know like co-hosts for the

last minute like workshop in hanoi thank you for all of you to joining at the workshop online and offline so we're also looking for your feedback i think that like with your feedback we also can do you know the better you know next coming workshop so can you scan the qr code does this take only one minute to do it also like for whoever joining the workshop online live stream please like scan the qr code now or if you want to give some feedback for now like we also would love to hear from you also like whatever you want to share with us or with barry or with its room foundation yeah do you have any

two or two anyone of you want to share anything about feedback our workshop in hanoi and ho chi minh city so we also can can know like what we can improve and and do better and then also like if you can do online so like let's scan this so this is the only five question uh we would like to understand like before you join the workshop and after you join the workshop so can you just like have to do it one minute and also like uh after this workshop we

also do many others like weekly and monthly workshop online and offline so if you want to looking for more information about the workshop under eat vietnam weekly please scan the qr code over there so also can check the information on the 8th vietnam website and we do the main event in november 25th to 27th so also after the workshop also can enjoy the hackathon and also enjoy the event so let's keep in touch enjoy the community of eat vietnam and then we also can share other information from the mentor and ask questions thank you very much okay thank you let's have lunch