Top opcode offenders in the zkEVM

[Music] Carlos Matana work at polygon and today I will be talking about the top code offenders in the zvm in order to explain that basically I will do at the very beginning some introductions about the what are the ZK counters what are the types of the ZK counters available and how many Z counters do we have available on the zbm the second point will be in the analysis of the offenders you will see that there are some straightforward offenders on the zbm so there is no correlation between the gas consumed on ethereum and the Z counters consumed on the zvm but I will go more into the details there are some up codes that are quite straightforward but uh when we analyze uh in this case I will analyze a Unis swap swap uh we will see which is the worst the the worst of codes that uh performs very bad in terms of ratio between gas and GK counters so for that purpose I will analyze a un swap swap trace and in in the third point I will basically explain it what are the next steps um how I would say the the how we can optimize those of codes in order to have a better radio between the gas and the S en counters wasted and also I will explain two different approaches um about how those OP codes could be priced on the zbm okay so let's start what are the zik counters you can imagine the zik counters if you can imagine the gas on ethereum in order to measure some computational cost execution cost you can imagine the zik counters exactly the same as the gas but on the zbm okay basically in the zbm we have in ethereum we have a unit which is a block in the zbm we have a unit of proving which is a batch so there is some relation over there and another difference between the theum and the zbm it's like on ethereum we have one single dimensional um resource which is the gas but on the ZM site we have the Z counters and we have multiple of them okay so basically this this table summarizes what I have just said on eum we have a unit which is a block the ZM is a badge the badge consumes some gas it has some limitation on the gas and the gas basically reflects the EXE the the computational resources that you are wasting when you execute an OP code this b a single dimensional gas on the zbm side we have a batch which is the our unit of proving we have the zik counters we have several of them so it's kind of multi-dimensional and basically they reflect the the proof computational cost okay well this is basically uh piece of code this is in Z assembly uh basically this is the zik ROM we implement the evm in the Z Assembly Language which implements the the evm in Z assembly uh language and basically those are all the ZK counters and all these values quite difficult to read it so in order to understand it better we have as I mentioned in the in the zbm we have a unit which is the the batch and this batch has several zik counters what are those Zig counters basically we have the steps you can imagine the steps sometime I have heard about kind of the you can you can change the word and instead of saying steps you can say kind of Cycles H we have the arithmetic State machine in order to do multiplications and well also we use the state machine in order to prove uh divisions by by doing multiplications we have the binary State machine in order to do additions subtractions and bitwise operations basically we have the memory align State machine basically uh when you read an slot and the CBM two different slots and you want you want to join all the bites together uh we use that steam machine have the kak Ste machine which is obvious in order to do kak hashing we have the padding poon Ste machine and the poson Machine again quite straightforward to do poson hashing and when we want to do a linear posidon which is a concatenation of poons in order to Hash a long r of bite we need to use the padding POS on Ste machine and the very last one is the Sha 256 Ste machine which also doing for so it is very important to say that each state machine has its own capacity so as you may see on on this slide H we have a lot of steps because I would say the computational cost of for step is quite low it's just one I would say one hit one row when we go through the program through the GBM R but for example on the kak you can see that there are way less resources over there why is that because basically it's more complex so it uses more resources so it has less capacity basically one thing that is very important also to mention is that none in a batch we have all those Z resources none of those s Z resources can be overflow if any of those Z resources is is overflowed it means that the proof will not could not be generated basically the pro could not generate that proof so we need to be very aware of that okay so let's do some kind of analysis on the I would say top code offenders on the zbm and as I mentioned there are super straightforward op codes that consumes ZK count ERS very directly and clearly there are offenders on the zbm what I mean when I say offenders it means that those of codes consumes some gas and this gas is basically not reflected on the ZK counters that they consume so there is a misalignment over there the most straightforward one and of course you may heard about in every zvm if you do a loop of kaks then you are wasting a lot of Z resources but you pay quite cheap gas so for example the the first code is the Gard the second code is the code copy and cod data copy uh in this case um I would say that all of codes that has some kind of um dynamic dynamic gas pricing given that uh given the memory expansion uh we need to do some computations on the zbm that of course it C some arithmetization binary and steps and also when we do some kind of copy reation between context one context to another context it will basically waste um a lot of steps as well the third one also I think it's very clear the example it's the external Cod copy op code in this case we are just I mean this op code basically just cop so copy some bytes of a bite code into a memory region okay that's it what you need to do inside the zbm you need to provide the full bite code you need to Hash it with the linear poon you need to check that that hash matches the one that you need to read on the state three so now you know that the full bite code is correct and you need to go to the exactly bite or number of bites that you want to copy into your memory region take that bites and then copy to the memory region so there is a lot of things to do on the zvm but the cost of this code is not that much and of course uh the clear offenders are the pl compil smart contracts uh you know specific functions on ethereum like is recover pings uh modular exponentiation and so on and there is a very huge misalignment between the precompiled smart contract gas pricing and the ZK counter resourcing consuming the zbm okay those of course I would say that are very clear that that are offenders but I wanted to analyze the not the clear codes but the standard of codes standard transactions on the evm in this case uh basically here this table well before going to the table um all these numbers belong I mean there some assumptions the first assumption is that here we are I'm showing data of a one batch that has only one block and this block has and transaction okay and these transactions are always the same type so you can imagine a block in the zbm with just ether transfers with just toket transfers and just with un swap swaps so let's go for the first one the theum transfer we can fill up up to 2,000 more or less trans a bat and we can see that the top GK counter the more limiting GK counter is the arithmetic why because we are basically checking the signator inside the C so we are doing a lot of is recover the recover uses a lot of arithmetic State machines if we go to the next two ones the the Unis swap what we can see is that okay we can fit less transactions because you have you have some execution to do and we can see that the top of kodik counter offender are basically the steps either also I mean either in the and the Unis swap swap regarding the UNIS up it gets even worse I mean you hit the top uh the limit of steps and the other state machines remain at he capacity even less given those numbers uh we're going to get into the details of what are the op codes in a Unis swap swap Trace that consumes more steps okay so yes what are the up codes that consume more steps in a Unis swap swap so in a Unis if if you analyze a trace of the Unis swap swap uh you will find that um push one push two M store pop and push 20 are the most used to coders if you join all the steps consumed by all the appearance of that op coders on the the book Trace you will find that the push one op code uh will weighs around uh 12,000 steps and it appears in the unisoft sh it appears 658 times so same for p two M store pop and P so basically this stop these op codes are the ones that consumes the most steps on the Unis swap shop but let's go again into the details inside these op codes which are the is the user paying the correct gas price I mean is the are paying the correct gas price in order because the up Cod is consuming 2,000 um 12,000 steps so here's the question yes or no so let's go to analyze a little bit and here basically I what I did here is uh comparing the gas of an not code versus the steps that that code consumed on the zbm so basically we can get some kind of a Rao between gas and steps here we can say that by far the worst up code is the Cod copy because it cost just 15 gas and consumes 1,000 steps so the rtio is I would say quite bad the second one is a m store here I highlight it in in in green because it also it's one of the op codes that has more appearance also on a uni swap swap Trace so clearly if we want to increase the efficiency of a v in the zvm clearly we need to optimize we need to get better ratio in the MS St for example op code third one is the call that the copy then push through2 and then call that Lo we want to get rid of those top up Cod offenders what we should do is repricing them or optimize them in order to get a better Rao basically on the other side what are the best of codes what are the ones that uh basically the user is paying um I would say fairly about the ZK counters that it consumes on the zvm so here we have for example the one jump jump conditional stand Cod size or log three of course log three s a store and this kind of op codes the ratio is very very very very low because basically you are paying that you are storage some data on the receip 3 or on the state three okay so now the question is how to di those OP coders accordingly to the ZK counters that they are consuming basically okay and the most straightforward approach which is the one that we are following right now is an static approach you can see from you can imagine uh the batch as a monolithic batch we have all the resources available and think that regardless of the transactions that are executed on that batch that batch has a price that's it in this case 0.01 so the sequencer basically pays for the batches that it post to layer one and the verifier when the verifier verifies those uh batches that are posted in the ler one it receed the the fees that's it super simple so the user I would say that the user um does not care about that only the sequencer and of course this price is splitted among all the transactions in a b but then we can use uh the next iteration I would say we can use kind of a dynamic approach the dynamic approach is very similar to the gas limit on ethereum so imagine that we introduce here A New Concept which is kind of the ZK gas and ZK gas limit so the sequencer does not pay for a full badge but the batch is dynamic so it means that basically the pr can decide the amount of the state machines that needs to prove basically uh we can achieve that via the the bat cops and basically here the sequencer just sets a z gas limit very very similar to the gas limit which is the Z gas that the sequencer is willing to pay for a bat and then when the verifier verifies the proof it's substracting gas for the gas limit and if it runs out it will be kind of a an out of gas but out of gas limit so the batch is kind of uh invalid then the next step is okay let's analyze properly in the in the in the language in the compiler why those OP codes are performing so bad and let's try to optimize them let's try to let's try to iterate let's try to add more instructions in order for those of codes to have a better ratio H let's try to improve the constraints the pill in order for those of c those codes to have a better ratio and not to be offended on the zbm if you want to know more about that uh tomorrow we will do a workshop at 3 P.M on classroom uh C it is called optimize zbm thut Series 2 we did one on Brussels uh which one the series one was a lot of people over there so uh we're going to explain um some optimizations that we did on the Z assembly side and on the compiler in order to optimize those uh top up offenders okay thank you amazing great talk Carlos much gracias all right so remember you can post your questions on the QR code we're going to start to hit the first one the top one um what happens if the sequencer has a bug and it creates a batch that overflows the counters and then it gets committed to ethereum yes inside the good question uh inside the ROM it can happen two things so inside the RM if the sequencer has a bu and commits a badge that overflows the counter uh we have a program as I mentioned which is the ROM which is an evm implementation but inside the the ZM PR we control the counters uh that are wasted if you overflow the counters then the prover can prove the batch but it's an invalid batch when I say invalid batch it means that the Old State Route is equal to the new State Route so there is no State transition function over there the issue is when you have a bug the sequencer and in the ROM then you end up in a situation when you cannot prove the watch amazing thanks um the next one is how much does ef help eliminate or reduce the top offender up codes uh I just read once the this uh I mean I would say that uh we need to analyze uh deeper um what will be the top of offenders given the change of the B code and e o f basically it's very difficult to answer yeah yeah no I I agree it's coming but it's yeah it it just requires a lot of work and uh yeah research do you still need counters if your proving system supports continuations you need counters but I would say that those counters will not overflow since you can continue the provent execution into another batch so this will mean that basically any ethereum transaction will be provable still if you are just doing a loot a loop of kicks imagine that you're looking a very large loop of kyats and it consumes seven batches that ethereum transaction needs to pay the seven batches but we need to be aware on the proving system that it's compute seven batches I mean thanks to the continuation we will be able to prove it you need to pay for it yep makes sense so uh next is around gas cost would multi-dimensional EAP 50 1559 be useful I would say I I I was in some um meetings discussing about this multi-dimensional gas pricing and it could be done but it's not easy to modify the whole I mean adding kind of a new transactions with new fields in order to sign this gas that uh it does not reflect the computation which is the gas but gas layer to or ZK gas whatever you want to call it that uh basically reflects the um ZK counters or proving computation uh you need to change libraries you need to change um uxui metamask this is not easy a chief a lot of work a lot of work all right how do upcodes limit work with Force transactions and would it be valid reason to exclude transactions I mean first transaction at the very beginning is just a regular transactions but you just bypass the sequencer and it works exactly the same that an standard transaction if a force transactions overflows the badge which can be and as I mentioned before in the first question the batch will be invalid and that's it so at the very end you are kind of you want to force your transactions but you are not achieving to execute your transactions because the batch is invalid so and every time of course that uh a user post um a force transaction into layer one the user needs to pay for it because you are bypassing the sequence right right uh the next one is are there any steps that smart contract developers can already take now to reduce the usage of those offending up coost I would it's very difficult you would need to go into a assembly code otherwise solid just put the op codes most beneficial for execution not not to take in account the proving system so I would say it's very difficult yeah I guess it would remind require like yeah reactor architecting the compilers and doing a bunch of like changes and then yes again yeah yeah really deep knowledge of that are there any this is the last one are there any concerns with the resulting Divergence with L1 fees in terms of user experience I mean we are achieving an stage LLY that uh the difference I mean these proving cost are every time that are cheaper cheaper cheaper cheaper and cheaper so H I would not expect um a lot of Divergence between layer one fees but still the zbm has some mechanism in order to Port layer one fees into Layer Two it's the AAP 1559 in the base fees so it can reflect the DAT availability cost on layer one so yeah this is some this is just a technique but there are several ones yeah but I guess like there's a lot of improvements still in the backlog to keep improving layer twos instead of yeah a lot of work uh and I think with that we complete all the questions thank you so much Carlos it's been a pleasure