Developing a Fully Compatible zkEVM

Transcript

hello everybody i'm george melina i am the technical lead at polygon hermes and right now what we are developing developing right now is the zika vm fully compatible ethereum ebm a rollup where you can execute any smart contract where you can deploy any smart contract and so on we started this project some months ago first in the first place in the first part of the presentation i'm going to give you an overview of how the project is moving forward and then i'm gonna focus in uh in the bridging between layer one layer two and between layer two layer two that we are going to use in the zika vm okay

so if we see a big picture of uh what do we have in in what we have to build in order to build the zika vm this is the main the main things we see we have some set of smart contracts uh coordinator selector we have the l102 bridge this is the one that i'm going to talk about we have a node and we have a brewer the most important thing of this slide is what we don't have to build what's not here here for example we don't see a compiler we don't see so we don't we want to use solidity the same solidity and the same op codes that you have in the compiler we don't have uh tooling because we want to use so metamask should be compatible and all the tooling at the end the node should

publish something very similar what would be their pc idea so these are the main blocks okay if you go to the proper the most difficult part or the one that's the engine of of the ckvm is the prover and here here are a little bit the blocks that we are building uh for more information you can go to the presentation that i gave in paris to go more in detail how we doing more technically but the idea is we have a appeal pill means a polynomial identity language just to build uh some polynomial identities on top of that we built all the state machines that will run the the kvm state machines here we have the mainstream

machine but we have a signature for hashing for arimatic programming and so on on this state machine in the main process like a main processor we have an assembly so we can build we can run programs on this state machine and the main program that's going to be run is what we call zika vm and mainly what it is is an interpreter so mainly it's a program that it reads the transactions and executes those transactions so mainly we are building a full ethereum uh on on top of the kbm so we take all the transactions we analyze the transactions with the code we check the signature uh if there is a smart smart contract deployment we we put it we just execute all the states okay and we do it in this

in this uh thing so with this um with this approach the idea is that we can design the state machine very tailor-made so that it's a single program that's going to run on top of that so we can tailor-made very much in order to be very um efficient on that okay so once we have this state machine we have to execute when we have a set of transactions we need to execute those transactions if you want to build all these specific polynomials with these polynomials we build a stark okay the star is going to be a proof itself and on top of this stark instead of of verifying these stars directly on mainnet what we do is we will generate a circuit

um that will be in gross 16 or in planck that will verify this a stark and this is the final piece so it's the final verifier will be very very cheap it's we are talking about 200 200k gas just to verify the full zika via improver okay so this is the status right now we have built uh all the pieces we're finishing the the circuit part right now uh the project is quite well defined and we are just putting all the pieces together and so we are going at this point we're going quite fast of course there is still a lot of work to do but we are going quite quite fast at this stage okay so now i'm going to focus i want to

focus in the in bridging so how do we uh so how we transfer funds from the layer 1 to layer 2 or even from one roll up to another roll up okay so this is a a main thing we have been thinking a lot improving a lot and we here we are recovering uh an old idea that at the beginning of ethereum when sharding just before ethereum 2.0 people start talking there is some there are some vitality conferences talking about that and this is recovering a little bit they there but so it's so simple that's interesting so i want to show how this uh works okay so here we start for example with a main

net imagine that in this main net uh there are three roll ups running we call it roll up one roll up two and roll up three and we want to move fonts from layer one to roll up two then to roll up three and then back to the to the main network okay so the idea here is that what we are doing in each roll up so each piece will have what we call it an exit tree an exit tree if you one is uh it's a well it's a merkle tree it's a it's an at only merkel tree so it's a tree that you cannot remove things so you are just only adding things and the idea is that every time that you do um that you want to move phones to some

other roll up you you just uh build this you just add another leaf in this merkle tree in this case for example you can say that okay i want to move uh here another c20 of this quantity of value and i want to move it to roll up three i can do the same with nfts or even i can do a you know generic messages just to communicate between contracts because some some there are some new contracts that can have value not with nfts or with uh erc20 can have other of the ideas so the idea is that we at one of these things in the tree okay so each roll-up or the main net have one of those trees

and then when what we are doing the idea is that in the main net we are building uh what we call it a global exit tree it's a tree that includes all the trees of the all the roll-ups and even the three of the of the main of the of the main three so with a single global exit with a single global exit tree route we can have all the exits that has been in all the networks the layer one and layer two okay so this is the structure that we are building so how would it work okay imagine that we have a token uh we have matic tokens and we want to transfer to uh to a roll up to a layer one so well we would send this to a

bridge contract okay this bridge contract would write this leaf in this exit tree of the of the layer one okay and this will be probably shut this also will be added to the global uh tree exit tree okay then um when a rollup creates um creates a batch actually there is an exchange of information between the roll-up so between the layer one and the layer two this is of course the the the the the layer one so the roll-up the batch of the roll-up is uh forged in layer one so what we do here is we just pass a hash you know we take the global exit tree

and we store this in the roll up in there in the roll up state and we take the exit 3 of this roll-up state and we add it in the global exit 3 on the layer one and this happens in uh in a batch transit so every time that the transaction is batch and this is the most important thing only one hash so only one 32 bytes are moved from the roll-up every time that the roll-up is watched and only 32 bytes are moving from the roll-up to the global to the global state okay so once we deposit the the matics this then this this transfer new batch happening so this transfer happens so now this state is in the roll-up so

inside the roll-up if it's a zkvm in this case what we can do is we can withdraw these roll-ups so we do with america proof mainly we are proving that this exit 3 happens so is in this in this global exit tree and of course we we nullify we we just mark this and in order not to withdraw it two times so we mark it as uh two times okay so now what we have is a kind of a wrapper this is a double circle we have a wrapper that represents the erc20 inside the inside the roll-up okay so imagine that no we wants to move this token so this token to from roll up three to roll up two okay we do exactly

the same we send these rapid tokens to the bridge smart contract in the layer of tour roll up three a new um a new um leaf in the local exit tree of this roll up is is added of course this this this this this rapid token is in this case is burn it's not locked it's born because it this belongs to another the regime of this token is the layer one in this case okay then there is a transfer so once this there is a transfer between layer two and layer one so this exchange of information is put so all this exit is stored in the in the global exit tree of the of the root okay this is it for roll up three

then this happens exactly the same for roll up two roll up two we transfer this global state to the global state to the roll up to and now we are in roll up two and we do exactly the same we do exactly the same procedure we can just prove that there is this uh this leaf in the global exit tree with a miracle proof or a zero knowledge in this case we can do it and then we just create this erc 20 wrapper in this roll up too okay for imagine that we want to go back to the layer one we do exactly the same we send this to the bridge the bridge is is born just burned these rapid tokens it adds it that's uh

uh a leaf in the local miracle in the local mercury saying that in this case the destination is layer one with a specific owner okay transfer of information happens between this roll up layer 2 and the and the main net so in the global tree and then already in layer 1 we just withdraw so we can withdraw from the bridge just doing a single again just with a single proof and of course with the nullifier so this is very simple it's a very simple uh approach but this allows to bridge between roll ups and

between uh layer one and layer two in a universal manner okay there are some open questions i just put it here the thing is for example how we white list roll-ups this is one of the interesting things here there are some ideas and the other is i think and this is just open but i think it would be good idea to have a kind of erc standard for bridging in here so i just put the things open just for people to think about it and yeah that's very mine that's very much what i wanted to talk we're just this is the goal of pulling on just building having one billion users using it

and thank you very much so thank you very much georgie for this nice presentation do we have a question in the audience we have time for questions i'm sure there is some questions in your mind but please okay jolly do you have any yes hey a really cool presentation uh thank you i'm curious if you have a benchmark of how much you expect like this message sandy in terms of costs and overhead how much does it include and how does it grow depending up here i cannot i cannot

get it how expensive is it to do this bridging how expensive is the the how expensive is the transfer yeah this is for the yeah the idea is that the cool thing here is that of course the layer one transactions the layer one transactions um are uh expensive it's like a transfer this would be a little bit like when uh the same cause that would be for example when you are staking uh two-layer route two because you are adding to this merkle tree some way so the cost would be around there you could do it you could even do it with a miracle proof or aggregating things so you think you can do things in order to load the case but for layer one uh this is things but the cool thing here is that uh once you are

in layer twos and from transition one layer two and two other layer two the cost is uh is free because all these transfers all these transfers all these transfers of information are happening always and it's every time that uh a block is happening so it's not one single transfer per transfer this happens once per batch so the every time that you transfer here maybe you are aggregating all the transfers that happen there so it it it works um so it it just uh move forward back and forth so once you are in layer twos uh it's free of course when you are going back but my question is more like the merkle proof parts because the miracle

proof as the tree grows the call data for you to actually submit this group gets more expensive for the roll-up yeah so here's if there is maybe a different construct or approach that you can actually minimize this part of the cost that the user feels a lot right so miracle proof is also verifying numerical proof is uh is is not that expensive it's because i mentioned 32 levels miracle proof i think that sha the k-cock is 50 so 50 times 32 this is not much uh in in in the identification what's expensive is the the storage that you need to save the storage but the storage the the cool thing here is

that just check for example the the ethereum to deposit they are doing they are working with exactly this way and the idea is that you don't you modify just uh lock two uh lock two elements in the tree so you don't have to brighten and you are recycling so you are you are not creating new ones you are recycling which is a little it's cheaper in the it's cheaper in the in the in the gas cost um in any case and i would i would i believe that uh once layer twos are mainstream somewhere i don't i think that most of the people will stay in layer

two so we will not go back to layer ones in most of the cases right now for example in nerms you can already for example withdraw tokens in layer two you can do payments you can work in layer two you can deposit maybe to an exchange through so most of the i i expect that in near future uh everybody will work in layer two and layer 1 will be just anecdotic and just for for validity proofs mainly but this is i don't have the crystal ball that's what thank you another one uh hi jordy um i have a question which

is in this setup do we assume that all the individual layer twos need to sign up to have their exit routes going out by the same exit tree yeah this is this is i don't i'm not sure if you understand this is if all the layer tools have to sign up for these themes this is the the when i talk about the open questions is how do i list a roll up this is a thing one thing to do and here maybe i'm going a little deep here is that uh in the in the record maybe you can here you can add an entry that says what are the trash side roll up so when you are depositing when you are depositing the the tokens you can say okay i'm depositing

these tokens here but only these roll up this roll up and this roll up is valid okay this is one way the problem here of the of doing this is that then you will have in the layer twos in the in the once you are in the layer twos you will have different ercs 20s you will have different tokens because some of them will have one security so they will be like good for some some some draw-ups and others will be for some other roll-ups maybe that's not an issue because at the end they all represent the same token but it's something that we need to think about and it's not um it's an open topic okay right now we are building one roll up so in some in

some way we have this sole for us but it would be good to be this to be solved for any roll-up uh on for any layer 2 solution here and have a standard way to do this okay thank you for the answer i think we have time for our last question um there already someone in the in the back hi are you planning to use zk snarks like long [Music] in your zika even implementation i cannot hear anything i i see that we are running some snarks

yes my question is about are you planning to use snarks in part of your implementation of zika evm we are right now what we are doing is uh what we are doing mainly is a stark so we are the the main proof is going to be a stark and what we are doing on is instead of very verifying this stark directly on mainnet what we are doing is we are verifying this stark in a plonk or ground 16 circuit and in the mainnet we are only verifying the proof of the proof this one level of recursion if you want so we

have a stark uh very fire and i i don't know if i couldn't hear very good the question but this is what we are doing this is the answer thank you thank you yeah we can talk now later if you want because well guys thank you very much and any questions thank you zodie for everything