20240322 ETHTaipei Workshop_ZKBankai @G Part 2

or this is these are trees that can only grow uh um some home okay and um I mean if you see how the the rollups work uh I mean the rollup uh so the sequencer at some point uh it includes this uh well actually um there is what we call it Global exit gr this is in layer one and here is a tree of all the local exit grot local exit grout of layer one local exit grot of a local exit gr so we have one Global exit route that actually collects all the local exit roots of all the chains okay this Global exit is the only this is the only piece that actually is transferred to the to the r i mean this is broadcast to all the RS okay when this Global ex is updated This Global exec is updated every time U um every time a proof is generated so every time a rollup uh generates appr proof has a new local exit rout and then this local exit rout of the Roll Up is included in the global exit Okay and U it's so the idea here is that the sequencer the sequencer can start using a global exit route can start using a global exit route uh before uh before before it's a valuable in L1 but then he needs to prove when you are pro when when you prove you need to prove that this Global xit rout actually was uh was was was correct uh uh okay but the the important part is this this this state yes we have a kind of a state and and then you can deposit and and withdraw or sending messages or whatever okaye with tokens nfts is the same nft can be understand understood as a token with just a supply of money okay so um okay this is how it works right now okay but this is the I mean the problem of this is that yeah you need to wait for the proof uh uh somehow I mean it's like you don't have the the proof and you don't come to layer one you don't know that this Global exit rout is updated and and and so on okay so when you have a ination layer the idea ofation is imagine that you have a kind of a that's would necessar be a blockchain but to simplify the things imagine that you have a kind of a blockchain with relatively with fast finality okay and uh the idea is um so the idea is that uh here the chains uh commit to States and also solves all the all the all the dependencies okay so imagine that here on this blockchain the users are the the users are the chains okay the sequencers of the chains if you want okay so when a chain a uh maybe chain a commit to maybe commit to State A1 okay but then chain B okay and come it to B1 but B1 here have some it can have some dependencies okay so I commit B1 but I have a dependency of A1 okay so it's like okay I'm commit to this state but this state is going to be valid only if the uh state in the in the chain a is is A1 okay then I can have maybe just com of the chain C com to C1 but it's based on B1 here you you can see that this dependes is is like okay this C depends on B1 but B1 depends on A1 so you have like a a graph of of of dependencies here okay okay so this is this is the the the the just the the comments okay and later on later on maybe the same chain okay a different transaction okay you can you may have off you generate the proof of P A1 okay then you generate maybe somebody else here generates the proof of uh B1 and uh and so on okay um if you see this chain is a consensus of course if somebody is a proof of A1 A1 has no dependency so A1 is already valid so I can include the A1 I just include the in the global exit grout that I'm generating I including A1 here when I generate B1 but A1 is already valid uh A1 is already valid so B1 here the will have U A1 and B1 but if I do it the other way around I that here I I I check B2 and then I check uh so I'm checking B1 and then I'm just generating A1 so the global X here will be still the empty but here when I'm validating A1 actually I validated A1 but A1 so this B1 is already generated so this means that the the here the GL will have both uh this point here you need to solve these dependences but if this a consensus you know what you have here okay and what's interesting part uh uh uh well so what's interesting part here interesting part is that so when is that A1 does not need to trust the one or so there is not there is not necessary to be any Trust of uh a of uh the different shes and let me explain why and what are the conditions that needs to happen for this to not trust okay so imagine that I'm a sequencer you are another sequencer and and you can be a malicious chain and I can be a malicious chain okay so here so what's the thing that can go wrong so I'm chain a I come to A1 and and and you're taking chain B and you are using a A1 but then I for example I do a reor of A1 and I this com is not valid and then you as B you become screwed because I mean you are you are assuming you're state is based in that the state of A1 is valid but if I do a reor or I change my State uh then I'm back so if you are B1 what are the word so what are the conditions for if you are chain B what are the conditions for for including chain a well actually is if you are able to build the proof of A1 then I'm safe why because if the chain one does not include the proof I uh the chain B can include that proof anyway so there is a commitment so a commitment is you come to the state actually this state can be anything can be something that be a fake okay but um the chains the the other so the other chains will trust I mean we use this EST state only only if they are able to build the proof okay so and what can be they able to build the proof well maybe it's because they already have the proof maybe the proof is already generated by the other chain you don't want to synchronize the chain you just receive the proof maybe because you are following you have a full note of the chain and uh and and and you have the proof and this means for example that if if a is a validum you also need the data avilability of because you need to build the proof you need to be able to build the proof yeah build the pro are saying generating proof or verifying Pro for for when you saying when they they need to be able to build a proof are they are able to so they need all the information so they need all the information required to build a proof so that means that uh so here the idea is that um okay um is this coming to A1 so I want to create a state that's based on this A1 but A1 I need to guarantee that this A1 is going to be valid so I need that uh the proof is is able to be generated okay and the idea here is if the chain a does not generate the proof I the chain B that are relay in chain a I will be able also to to to build the proof in the worst cases are you saying like have the capability to build that proof or in the background are you actually generating have the capability of build the proof is an enough condition for uh improving a dependent state of an and what distinguishes having the capability to BU through for just a follow uh well yeah yeah I mean if you if you have a full note you if you have a full note of the other chain and uh I mean and the state matches you will be able to build the proof by definition okay but I mean here if you are chain me you have like two options either run a full note of chain a or just wait for chain a to the proof in order to okay yeah so see that this can so in Practical um the order cannot be like that so like uh in order for CH to uh commit a uh transaction depend on a I have to wait for the proof coming from a well actually I mean the the chain a so the chain B uh so practical is so for order to include the chain a A1 needs to be committed because the first thing is A1 cannot change so it needs to be committed in the sense that okay chain one uh this is what it is and it it's it so it cannot go to maybe A1 Prime okay it can be another state that's valid but no they cannot so they already commit to this state and this is going to be the next state so A1 cannot reorder okay so that's the the thing and it's it's a valid State okay so with you have the guarantee that this chain is going to go to this to that state okay so uh a CH a can keep going I mean here I can come to a one but here there is a com of A2 so come to A3 come to A4 I mean they can come to different to different states different mean can to create blocks okay this com is a block I mean you can it can be a single block or can be every 10 blocks okay so you can SP but you just you are you are so you are chain a moves goes on uh chain B goes on maybe chain a generates one block every 3 seconds and chain B maybe generates a block every 10 minutes that's fine okay and they don't need to Wi one each other but at some point I want to include the state of chain a in chain B so I can for example with this this state can be the full state if you want the state can be the loal ex mention before Global exit of a yeah so I want to include not as a global but individually want to include this chain this chain this chain in my state okay yeah what happens you have the capability by a actually doesn't a what a a actually doesn't change the state it has the capability no a exactly here the idea the whole point here is that a cannot so once committed to the state to a state they cannot re they cannot change the state they can move forward but they cannot go backwards okay that's the that's why we need that's why you need I mean and and you can I mean this is me that is a blockchain just it's a consensus actually is for this you don't really require a blockchain you have less things but uh the easy way to understand that is a blockchain okay you can SC much better but that's another that's another problem okay uh so uh uh well with this you are um I mean you are moving forward this this can be I mean this this this transfers uh I mean this these states can go really really fast I mean if this blockchain I mean at the end is the finality of this uh whatever this blockchain uh uh half will this commitment that's final okay and uh um the idea here is that at some point just to continue at some point you will do kind of a snapshot snapshot is you will set up a kind of a snapshot at a point and then you will get all the proofs that are with the snapshots and aggregate all these proofs in the single proof that are the ones that you going to send to to the uh to the Le one okay without with the global exit that you are already uh uh build uh on there okay and of course this proof is going to be validate that in layer one uh to move okay but with this uh thinking in uh cross chain um message passing okay um uh cross chain message passing uh of a few seconds is depending of course on the consensus aling here but the two 3 4 seconds uh message passing between chains is is uh perfectly perect perfectly perfectly possible okay um that's as the last topic U um here the I mean the this commitments of A and B okay so here are two transactions okay but the idea here is that I can have a transaction that can be a commitment here I can do a commitment of C1 that depends on A1 and on D one that depends on being one okay so I can have like a multi comment transactions and was maybe the two signol right this is the idea of a shine sequencer so the idea is that if you want to do uh so you can sign uh you can sign so you can sign different commitments and the idea is that you here you can do atomic transactions with ch with this in one side in the other side okay so this is would be a kind of a shot sequ so sh this so this this method allows sh sh sequencer for S uh for Atomic let's say for Atomic for Atomic transtions I mean it's a low priority thing but it's the model allows you to to to do also this this this kind of U uh Atomic uh transactions question uh so you just say like this kind of message P passing to be achieve with like few second so you just say like this this kind of thing can be used message passing in between the chck and as you say it's going to be take only a couple of seconds right and so my question is uh if I understand correctly the proof I mean the proof is going to be complicated the proof will in a few minute like then well the first the the I mean with this model with this model the the generation of so the time so the fact that you are splitting the commitment with the proof uh generation so you don't depend on the proving time I mean if you are following chain a uh then you can go as fast as following chain a if you are not following chain a then you have to wait for the proof and then the proof the proving timeing becomes relevant for the for the time between uh change but this this allows you to scale I mean if you have 1,000 networks maybe you are going to follow the five CP so you will have a f interaction five C networks and the other you just wi for a so the whole idea is I don't need to wait for the proof coming out in few minutes but I uhum as far as I am able to build the I have as far as I have all the so I have I far so I have I'm following the chain so yeah yeah I follow so and and and I'm sure that I have the capability to build a proof I don't do it I don't somebody else will do it I mean I will do it only if nobody else is doing and and I need to uh commit uh to to that that part yeah so here I mean the idea of this um uh Atomic transactions also this can be a chain of course this also this a blockchain this also allows you for uh uh for example for for paying the provs I mean this is allows to coordinate the generation of the provs and here you can have the centralized proving that are whoever generates this proof I don't even care that this can be incentivate here for generating this proof so here we can create this market for these pro market of provs and just they connect to a chain and they generate a proof of different different chain of course he the economics incentives that can run a to of these of these well that's very much what I wanted to explain this is the the aggregation layer B3 that we are working so in your example the the the mansion that is running is more like L ch right and so the Manion that you are running L2 CH and the CH a are L3 chain that on top of L2 and and they actually running the same protocol say so they will have the ability to uh be able to uh have the capability to prove the transaction from the other ch um well this is I mean the the proof I mean here we are we are working very much with retion I mean the Proof full proof is a it's a proof that proves A and B so you can have a here you can with these two proof you can can generate a proof that actually have P A and P So Pro of the snapshot so you canate the that you can you can aggregate proofs So Pro an aggregating proof is a proof that proes another proof that's the the full topic here and and you can recursively create as many as as as you yeah actually for example we are extensively using currently this anation with the uh zkm there is a single proof that's proving many badges so every half an hour it takes all the badges that happens in half an hour it agregate all of them and um and it generates a proof all the but but the prerequisite of CH a and is that they will need to follow this recursion stuff right for example they cannot be like polygon and optimis they don't they don't they don't understand each other yeah I mean here the the the you need to prove this in the proof you need to include all these dependencies and this is where me little bit the complexity coms I mean it's not that hard because they doing a dependency means that well you need to reild full tree of the the the differences so okay here the main primitive is that you want a a tree there is one I mean here is one I can if you want I can go deep to a one structure that we are using a lot for this kind of proving dependencies that's uh I mean we are seeing that this very very very useful okay so in a normal blockchain but this is this a little bit off of top a blockchain so the full point of a blockchain and that's why it's called blockchain what in the hash of the block you the has of the BL so have a block one block two and here the hash of block hash of B is so of B2 is is include the hash of E1 in the hash the watch okay but imagine that so here the the structure that we are doing doing is imagine that here you have instead of including the hash of the previous chain you are including a tree of all the history of the blockchain so uh you have that you have the history of the blockchain so it's a tree where mean it's a binary tree where aen Orly tree where you are adding the the hashes okay and here you have a tree of the of the full history of the previous chains and here you have the the G the G block okay so when you are creating a new Block Main what you do is at the beginning of the block you are and and all this is in the all this can be in the same state okay so in order to compute the next state the first thing you do is add this hash to this stream computer block generates a has the block and then here you just this is okay so this allows you to uh check um so you can you can uh you can check that easily that uh uh a old block is included in so that the new block includes the old block without having to linear reild the full blockchain I mean you do this instead of doing in end you do it in Lo hand because you have this this this structure and we are we're extensively using that uh in the this structure we are extensively using it I mean it's a little bit more complex to maintain but it give us a lot of flexibility for uh for um uh for proving uh um for proving the for this for this aggregated proof here the full point is um you have a block when you have a batch um you are there is you are assuming that there is there is one uh one state that's valid okay so here is you have a state here is AUM that's State one is Val okay you have another block but here you are assuming that the state two is valid so what you do is at the beginning of the block you you just check that the one that you assume in the previous block is uh included in the one in the one that you are assuming in the next one so at the end you just need to so in the smart contract you just need to check that that the last state of the aggregation of the proof is is is Val okay and the to check is inclusion I mean maybe from the state one to state two maybe there are many states that is State one of the other chain maybe there are many many states over there so you can check yeah you can check easily that this was included in the other one have structure like this but there a repor thing I mean is uh in instead of so instead of for each block checking that something is included in the last one so what I'm and I mean the last one maybe something in the future I don't even know when the proof is going to be generated uh something that will happen in the future so in a in my in the blog is what's the current state right now S one okay I'm assuming that S1 is valid and then and then I just check the log assuming that s one is Val in the next blog s S1 maybe S2 or S3 so they already the block Advance okay but in the previous one I already generated the proof for for S1 so in the next proof what I'm doing okay I'm assuming so here I'm assuming S2 I'm checking that what I assume it the previous block was valid so at the beginning of the proof I'm checking that S1 is included in S2 and and I could move and I move forward okay this allow me to allows me to generate proofs as we go before committing and when I have a chain of proof that at the end is okay I have all these proof that are valid as far as SN is valid as as far as it's Global ex is well and this is actually what I just check maybe there smart contract I don't even do it in the proof but with a single check in the smart contract I I can validate all the proof because I did it reely inside the inside the okay and this and this is easily done when you have a structure like that you keep the history and then you path uh that you are checking okay so you have you can possibly have many layers ofion aggregating F right and it seems like this um I guess my my like simple question is this is the number of layers fixed or is it going to be dynamic yeah based off of the this I can I don't know how much we are if you are interested I can explain to you I'm very I'm very interest but yeah I don't know how much yeah let me just plug my laptop let me see how we do inin comp complexity at at at time yeah and I guess I'm really interested in finding like what's the optimal lay like number of layers recursion how many times are you recursing you got as many as you want but but in terms of like optimizing for you know like like user transaction finalization or like frequency withdrawals like based off of what people are demanding of B based off what the users are demanding from these applications how do you find the most optimal way to orchestrate a number of lers you would see that it's much easier than that okay cool cool yeah maybe yeah me see if I can I connect this