Paths to a Faster EVM

Transcript

[Applause] uh hello everybody my name is ran akit I broke Paradigm uh on Rust etherium I basically I am auor of auor of rust TVM uh very fast TVM implementation and today I'm talking about paths to the faster evm uh sorry this works uh we'll start with we'll start with interpretor Loop basically it's the main Loop that every instruction basically needs to be executed is the hot Loop that a lot optimization can be done basically most of them are

obvious uh some of them are needed years to figure out not just figure out but to get idea that it can be done uh but it's always nice to just list good list few of them just to to see from where we came and where we are now uh for example padding the bite code uh so evm bite code can uh end at any place that means uh previously if you want toate bite codes you need it like to check the length of the bite code this is very easily mitigated just with padding zeros so if you are padding the bite code and you can assume that your bite code bite code is always going to

end with stop so your Loop is very simple one of things is like using for the gas calculation using native uh un sign 64 previously from optherium I worked on opium a little bit uh they had like generic over un sign 64 to big number and it's like I think everybody now uses native it's lot easier a lot smaller calculations uh removing jump table pass uh this was one of things that we stumbled about when the F started using RAM and started profounding it uh and

most of the fuzzing uh was spent on basically calculating jump table jump table is needed so that when you do any jump inside DVM so that you know where the jump destination are the problem with that is with the push you have arbitrary bites inside hopefully this going to be like fixed in a ter object format it's going to be fixed in ter object format probably um and idea they was why not like save jump table calculate only once and just reuse it even in red we are uh basically saving jump table as the least of bits inside the database so

we are skipping that part yeah because if you don't skip it's like iterating bite code two times one for analysis second time is for execution not that great gas block and stock stack limit requirement something that evm implemented basically if you have list of op codes that you know that are going to be executed you can pre-calculate gas and you can pre-calculate how much stack items it needs so you can basically do uh gas calculation uh smaller number of times the things that are not that

impactful basically that uh are not giv that much of performance basically we had some assumption but yeah uh basically any preparation for the calls any preparation for the crate are not that impactful uh the idea measurement that I did is uh that most of the performance is spent on interpretor Loop database fetching uh previously when we fetched the database through the Mer tree that was problematic because you needed like 15 like fetches of database to Traverse the merrye now we flat key key value database this is not a big problem you

still need like to read that and at the end comit that and to calculate State Roo after that but it's not that big a problem inside evm uh two things that you wanted to do recently is shared memory shared stack uh that idea was like assumption that we made was hey we don't allocate memory when we don't needed we have some kind of memory Arena where we can reuse memory or for both memory and stack but performance impact of that was very small and basically in interpret Loop using match switch or upod table gained similar performance so there there was a

lot of improvements on one side and there is a lot like lot of assumption that we made that didn't P out as true in the end what we have now or not just Ram but evm in general evm one was one representative of evm that's very nicely polished and very performant we have very polished interpreter that works very nice we already know the pain points we already know what needed to be done and a lot of new ideas were implemented and with a object format few of those things are going to be like baked in the protocol and it's very nice so next step for that interpreter

is it is what it is so we can transform The Interpreter what exactly is that now it gets interesting super codes are uh good example good introduction to that so there is few basically pairs triplets uh of op codes that is that are very fre frequently used simple idea is hey let's make uh one structure one up codes that's going to Encompass that basically transform the bite code even not on protocol level but customize uh create new bite code uh with parallel with the original B code with some custom up codes that are going to

have basically a custom upod that are going to Encompass same functionality but they're going to be a little bit faster this the original C so that we are compliant but either way idea is there make another bite code expanding that we can even pre compile contracts why not we already do that for cryptographic functions why don't we do that for some contracts or bu codes that are very frequently used idea is the same as the ordinary pre compiles but but we need to build that those contracts and making them in

the native language it's probably is going to be a lot faster but it's like new code that you need to audit you need to verify that's correctly run and that's downside of that maybe for a few of them that are very frequently to use we could do that but for all of them it's like a lot of work um basically one step forward to that let's go native just in time compiler head of time compiler compilation basically you're not uh manually creating bite codes but you are creating automat automat automized way for your bite codes to be

created this this allows basically to use bite code original bite code transform it some way uh compile it in uh LV or something like that and get the different kind of B code that's native it that should be faster uh first I first heard about it from Yim that his work on gtbm there are few experiments after that uh but there is no production ready code in the end it is uh it seems like good research and seems logically seems that it should work especially with the the uh op codes that are like in one

block of the basic op codes that are one by one they're not like jumps anything jump destination between them you know the results of that block of up codes is going to be same so optim optimizing that could be possible evm um a object format is introducing like static jumps so the compilation of that should be even faster and and um basically it should allow native compilers like lvm or something like that to have more data that can compile statically so uh punch line here is we can go behind beyond the EVN interpreter

idea is hey let's make our native code that we're going to use and we can load that any time it can be dynamic Library that we can use so last step forward let's talk about par execution example of that is access list where having uh yeah actually a good example of that not the best way to paralyze things because there is some problems but idea is what exactly are aess lists do the do they contain read the writes do they contain only touches uh do they

contain storage or just accounts now do we want to paralyze of account of the contract or storage for example rc20 uh you would like storages and there's like introduction of the balance increment decrement that we can paralyze maybe we don't want to apply every like balance change but we can like postpone it and make it more parallel major major problems with that with access list is uh dependency dependent section can change your basic logic so if you're constructing access list beforehand uh you need to overco compensate for it to be even if you can

basically if this something that's stored on the storage and something that you don't know your transaction going to fail and we will increase action size so the next thing is brute forcing it uh basically executing every transaction a standalone Gathering every read bright axess list or List uh start applying transactions one by one and uh trying to find collisions because we had read the right access list you can basically check if there is collision and if there is Collision res intersection uh first paper on that is

block STM uh written by DM implemented in optos some brof Force versions are imp implemented uh for polygon and B binas and they got like 50 to two% two times uh faster execution as name applies it's Bru Brute Force F that means if there is Collision you can expect few to be executed multiple times so it's a little bit wasteful parallel even even claim so this idea is just imagine if you already know what transaction can be running parallel you have a cyclic graph where

you know hey this transaction depend on this this transaction this information can be obtained serly but idea is it can be obtain externally you can download it for somewhere else main idea is if you have that dog basically you can execute transactions in parallel and while you executing you can check if your if you can check if your basically claim to the parallelism is correct that means if there is like data races or something like that you can ab abandon the evm abandon the basically that execution just execute

serly uh idea how that could be implemented inside the protocol that's very farfetch it is years of research after this but blog Builders already know some information that a lot of uh lot of uh validat don't don't that basically have transaction that they want to include so they can execute theaction in serial and just create the dog the best they can can can have uh Min balance is one of the contested uh addresses that is um add imbalance after every transsection that can possibly move at the end of block or maybe behind the last transsection

because uh M and block Builders want to use that reward from to bribe things so why parallel uh the the cratch that I got hey is in the state the problem yeah it is and that's the problem that we need to focus on but focusing on Parallel is something that will come eventually it's something that even if we don't include in the protocol it's something that we can even reuse a few examples are fast initial sync basically cutting some speed on that uh faster traces because you know dependency on some uh transection you

can re execute just subset of transaction that you need and maybe getting Shadow vents even like re executing water section one of uh I took that from Twitter uh adding parallelism for evm is not about speed uh but it's about high enabling light clients basically same thing with executing traces you don't need to execute every every transsection so my point here is going parallel is just matter of time it's not priority at all now we started some research on that in on

in uh red but going parall is just matter of time it's nice optimization and nice uh performance that we can get get and matter of time I mean years and years I think that's it thank you very much [Applause]