Polygon-Hermez zkEVM Bridge L1-L2

Transcript

okay so hi everyone i'm jesus licheron i'm from protocol integration team of polygon nervous and i will present our bridge approach in polygon jqm so first of all the introduction basically what we want to build is an bridge that it's be able to transfer assets in a reliable way a smart contract secured and minimize the gas cost and the delay and also approach attempts to be able to interconnect multiple roll-ups using the same bridge right this approach is based on this at the research that was made by vitalik and a discussion from vitalik and jordy bylina if you have like if you want to check it out i recommend it it's very interesting

so let's put it quick and a quick overview uh um okay well it's a little bit it's okay so the idea of the approach is that here we have four networks do you see mainnet that it's layer one and roll up one or two or three and the idea is that every network will have an exit tree which will contain the exit information of this network with this i mean that every time a user wants to transfer assets from one network to another the user will well the bridge will add a exit leaf to the exit tree of that network in the same way we take all the exit trees of all the networks and we

immergalize in what we call the global exit tree route so the global accessory route will be the source of communication of the roll-ups so for example in the last example i put if i want to reach some assets to the main net from the main to the roll-up one i a a new leaf in the exit three of the layer one will be created with more or less that information origin network main net destination network rollup one and then amount and destination address and so on the meta information right and then from the rob one we can check uh things like we have the global exit route with a miracle proof we can prove that exists this leaf and therefore we can claim the tokens and came from the layer one to the roll-up one

and of course the other way around it will be possible also okay so this slide is more like the other slide it was more more general and this is more similar what so with the current implementation that we have here we have mainnet and here we have the our zika vm and we see it's very similar if a bridge smart contract is called a new leaf is added to the exit tree and therefore the exit tree route is is updated and therefore the global excitatory route is updated then the zener knowledge proof or the circuit should be able to uh make available this global exit three row that is on mainnet in the z kvm so uh

this is what basically will do the circuit and and compute all the transactions and so on so in the zika vm we will be able to have the availability of the global exit tree route and therefore claim the assets that came from mainnet and basically the other way around when as a kvm we want to bridge something to the main net we we call the same bridge smart contract that will be on the ckvm and we'll update the exit 3 of the ckvm the circuit will make sure that this tree will be updated on mainnet the exit tree root of skvm and the forum mainnet we should be able to claim this asset now and next we will do a flow of all of this if it's not clear enough and i think maybe maybe we'll answer your

questions so first i will do a how we implement the the logic that i just put that just with the schema so i will put the smart contracts that we use to to implement this basically we have three the reach will be a smart contract that um basically what the what what it does is you can claim assets from another networks or breeds assets to another networks right the rich will update exit 3 as i said before that they will be updating the global exit tree route also we have the global exit rule manager that basically is a contract that just manages the global exit tree route this um we separate the logic that the bridge with the global executor exit road manager

because in this way we can deploy exactly the same logic of the reads exactly the same byte code in all the networks so this make more interoperable right and more easy to use and the global exit route will be different depending on the network i in the next slide i will explain more about it you will see it and lastly we have the consensus contract that in our case will be the proof of efficiency i don't want to get into details of this i just put it because it's the consensus contract that we are and i wish i will just like point that out what what it's important for the bridge and that's it okay so as we see in the uh yes you can read it in the batch information basically we have one call

that it's called sequence batches where the sequencer at the transactions and also the global exit 3 route is taken from the global exit tree road manager and this will be an input in the verifier so as i said before basically we have some kind of input in the verifier and the circuit that will force to make available in the zkvm so in order to the in the zkvm you will be able to claim the assets that came from the layer one right and now we'll explain the smart contracts in the layer 2 that as you see the bridge is exactly the same bridge but the global exit room exit run manager will be different this will be a very special contract because this contract is updated by the by the

circuit or the zero knowledge proof the zero knowledge proof will write in some specific storage slot of this contract in order to make it available in the zkbm so every time there is a new watch to process every time we process a watch in the circuit at the start of all the transactions we write the global exit tree route in some storage slot of this contract and then the rich will be able to call it to claim as we see here and also at the end of the batch we will read the exit tree root of the zika vm and we will write it on mainnet as we said before and now i will do a okay i will it is bridge but it

it's crooked you know but it's reads technical details so uh we'll do a little bit of technical details of how of how is on the reads and then i will do a full flow to to finish the presentation okay so the bridge is done basically as we saw before it has to compute a miracle tree uh the tumor can treat that it's up and only and these logic is already done it's done by the ethereum 2.0 deposit contract so physically we base our implementation on that because it works it has a formal verification and it's pretty efficient so basically it's the same ethereum to the opposite contract but we change a little things like the leaf is different

and the base has a in the deposit contract is sha and we use cacao because it's cheaper in the in the ethereum so and it's compatible with our vm so we use that also for the the bridge will create for sure grab the tokens every time a new token is added to this network and the method of this token as the name the decimals or the symbol will be added to the information of the leaf as well so every everything will be secured by the smart contract okay so this is a the flow i will do two flows from main network avm and the other way around and maybe with this will be all clear so let's start let's have a user i want to bridge something to the z kbm the

user will call the bridge information a new leaf like this will be created original network destination network as you see and for example he's reaching matic so the metadata will be matic automatic token because a new graphic will be created in the execuvm this will be updated the exit 3 of layer 1 that also will update the global exit 3 route so we have the global exit 3 route containing this information the second part will be uh when the batch is processed in the zig avm the circuit will write the main end global exit three route in the z kvm so will be available in zkvm so in layer two and lastly since this information is available with a marker proof we can we

are able to prove that there is a leaf that came from mainnet so we are able to claim these tokens since this is the first time this token is rejected a new graphic will be created with the information that we see in the metadata and for the other way around we have exactly the same interface for the bridge you see but well this time the destination is mainnet it's not zqvm it's very similar but just now we are rotating the zika the zkbm root instead of the mainnet because we are on jkbm uh and then we have to wait the new watch is verified once very when's the new one once the new watch is verified the exit tree that the exit three that the circuit reads

will be updated to the main net basically we see on this schema this is layer two and there is layer one just to make sure that you see it and well basically with once the batch is verified the global exit tree root will be updated with the information of the leaf that we just created and then we can just claim it with the same miracle proof you see the the scheme is very similar but we have to wait that the batch is verified in order to claim it just to finish i think i go pretty fast well it's okay uh there is often issues like bridge nfts we have more or less the approach we have the metadata field in order to

bridge the metadatas but it's not done yet but we know more or less how to do it also one thing that we are considering is richer smart contract calls like uh like one arbitrary smart contract calls this could be done but it's a little bit more trickier and in the end we'll want to optimize the gas and pretty much it so thank you so much for attending and [Applause] so do you have any questions yeah we have time for a few questions one second one second

thanks um so is every like for logic like nft how you say it's starting with just tokens and if you're going like nfts and execution does that mean then basically every those are like hard-coded paths that you have to take within the bridge or is it arbitrary as like a base layer uh well just like the bridge function for instance is that like an arbitrary based approach and then like you're just um like encoding it differently at the at the destination or do you have to like re-update everything every time you want to like add new functionality so uh this is what i want to say what to like you see like the on open issues there's an arbitrary smart contract called this could be inside this like this feature and we are contending you can do uh for

example you want to bridge some different types of nfts you can do like different types of i don't know smart contract calls that calls a contract that creates an ft with whatever metadata or type of nft you want so this will be inside like this group of open issues does this resolve your question i'll ask you okay um and one last one is can you like withdrawal to any other like layer or do you have to go back to l1 then to like it's a good question i didn't explain that the idea of this approach is like the global exit route contains all the information of all the layers so if i'm connected two or three roll-ups i can transfer it from uh the roll-up one to the roller three and i don't have to go

through my net so it's cheaper thank you we have time for one more question thank you for representation uh i have a tech question about the signatures because we have the verify survey code to verify the signatures and then i want to know is the signature save the offline or is it just the saved uh on the on the chain and to verify that you are sorry sorry can you can you can the signature of what the signature for example i want to uh take the token uh on the r1 so that the signature is uh send assign some transaction the signature is saved in the r1 and then use the verified smart contract to verify signature or

just look at the signature directly send the two parameters i see so the verifier is does not verify a signature it verifies as you know it's proof of a circuit okay okay so maybe you misunderstand that yeah okay it may be if if not we can you can ask me later and we can resolve it but the very fire it's it's it's about the zero knowledge proof the circuit like it verifies the whole evm in our case great thank you again thank you very much thank you very much [Applause]