# EVM-first EIPs Workshop | Devcon Bogotá

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-07
- Duration: 39:33
- Watch: https://streameth.org/watch/yt-6ZMd4xmX8D4
- YouTube: https://www.youtube.com/watch?v=6ZMd4xmX8D4

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/evm-first-eips-workshop/

This is a workshop discussion about the EVM. Anyone can come up and pitch their favourite EVM-first EIPs.

We want to be a bit more unconventional and would like to transform the room into a "live voting space" where attendees can fight for their favourite new EVM feature.

Different proposals will be listed and discussed for 3-5 minutes each, where invited panelists give a short opinion followed by loud interaction from the audience.

Speaker(s): Alex Beregszaszi, Paweł Bylica
Track: Developer Infrastructure
Keywords: evm

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] it's apparently very early for some people but we kind of imagined it to be a con continuation of the Ethereal magician session we had I think on the first day but the focus for for today would be eaps related to evm so uh yeah this this possibility to take a mic and and describe or pitch for AIP you are interested in and we can discuss and maybe ask questions from the audience um so if anyone wants to start if not I can take like five minutes 10 minutes to to to talk about eof the like three five EIP proposals we have drafted so far so this is a this is a slide for my lightning talk about eof but mostly uh what I wanted to to have on the screen is the five five VIPs we have two first are the first uh potentially scheduled for for Shanghai which means the next execution layer upgrade at a defined uh the kind of the basic of the UF structure so eof stands for evm object format and this and is a a kind of on our idea to structure the the evm programs in the way that the kind of behave more predictable way so that we know where the data is in the program we know the code is and we conversion programs so that also gives us some additional backwards uh compatibility features and on top of that we can build additional features and these three additional features are the the next three IPS on the list so firstly um eof allows us to to Define instructions and in a bit different way so we can have some immediate values means the op code can be followed by additional numbers that means something to the instruction that will interpret it that will interpret the the values following that wasn't possible before because of the backwards compatibility of existing evm so you can in the current VM you can craft a program that um that will break if you interpret into values following up codes in a different way so this static jumps are more efficient that's current ones and also um there's also easy easier to analyze from from external tools and also from the code validation in the AVM itself and additionally um uh the the next one is eof functions which means we can additionally partition the the evm code into separate separate sections we meaning uh individual native functions in the evm and there are additional instructions that allows you to go between these two between these partitions and all combined with the starting jumps and the functions we can get rid of of existing Dynamic jumps in the evm which it should improve efficiency and most importantly we can get rid of jump this analysis um so this the jump this analysis uh is a process that has to be performed before we can start even executing evm programs currently and uh it's Pro like the the cost of doing that is proportional to the to the to the size of the code and none of the cost of evm execution actually reflects this uh this analysis and and lastly uh we can also put additional uh verification uh in the eof format that will allows you to to check statically before deploying the code if if a function performs stack Overflow or possibly stack underflow and we can reject such programs such programs would be by definition a bit more restrictive than the current ones [Music] so this there are some tricks you can do in current VM that would not be possible anymore but I think most of the compilers that Target CVM doesn't really exploit this this exploit this properties so that also brings some additional efficiencies because you can kind of check for correctness in at least in the terms of Stack Behavior during deploy time and you don't have to repeat these checks [Music] right later during execution okay so that's that's all I can say in five minutes about that um so yeah I'm open to answer some questions and also if someone wants to join on stage and talk about some interesting evm stuff uh yeah okay I have been spending the week trying to better understand eof um and one question I have is um so I understand you know you have different versions of UF that you can implement but you can also add there are there are additions to the to an eof version that can be done without a version bump um can you like walk through what are like the proposals of you know of those fives and maybe others that you have like which One require version bump which one don't and how how would you think about like deploying the whole thing over time uh okay so um so the the first two kind of the basics of eof uh will be introduced with version one and and reminding like three additionals uh will require the the version bump um and um this is kind of the question how many features we want to pack and into a single version um so like has originally we we kind of wanted to split that and that's what also reason we have like five eaps not like single one because people freak out if the EP is big enough so it kind of splitted that um into like multiple pieces which also brings some inefficiency in there like in the design all of that because we need to update multiple documents um so just to be clear so like each so like uh 35 40 36 70 they require obviously you're introducing uof requires V1 but then there's none in the list of like 4200 4750 and uh the last one I can't see but anyways uh yeah nothing like the last three yeah uh can be added so you could add all three together and make eofv2 yes exactly and then you can like combine how many features you want right it's like up to kind of our yeah what what do you yeah what do you do what you define as a version I mean like multiple versions bring some like like new kind of complexity to the system we don't have so far right so currently when we change something to evm it's mostly time based like to like to some point evm works this way and from some point it it works differently so um I think all the codes still like have all of the versions historic versions and because people care about executing every instruction from the beginning but you can imagine you can design a client that only kind of has like the recent two or something like that so you can kind of scrap the code that is and like do the the full sync which means doesn't execute the the transactions just collects the state and goes on from that uh I think nobody did so far this way but uh it's possible and like this qof itself will like introduce kind of the new evm that will run next to the the Legacy one and they will be able to communicate within the single transaction right so you can have like Legacy contract that calls the new one and the new one called the old one and like nothing breaks on this level but it will have kind of two parallel events and yeah just to follow up so like of the say like the the last three are there any say we were to split that in like two in one or like three hard Forks uh like are there any that don't require a version bump or do they each as long as they're not shipped together all the time required version bumped um I think that the static relative jump doesn't require version bump at all so um like kind of the forward forward what is that forward backward no the forward compatibility of eof is that you can always drop new instruction into it without version bomb so whatever you add to the instruction can be like whatever of any complexity you can always do that because we make sure the op codes that are undefined currently are not used in the programs so like we can yeah we can drop the static relative jumps uh like without the version bump um but I'm kind of I don't know I like my feeling is like it's probably like better to pack as many features I as we have capacity for so we don't have multiple eof versions later right uh what about the backwards compatibility of packing in um new optional eof format sections like if eof functions were separate from the code section and provided data on top of it same with the stack validation information it was it had a separate section number um that would go on top of it I mean could those be done in a forward compatible way with it doesn't break things um let me think uh so so far we didn't actually like think about this way but uh maybe that would be the way to design it in the way we can actually drop this feature later without a version bomb uh eof functions requires a separate code block right yeah yeah but you can kind of uh so the thing is you can like when you have something commandatory you can make it optional later right so uh because kind of the the previous deployed contacts will all will have this thing there but if it's optional it's still fine so maybe there's a way to have like single code section with the information that maybe later will enable like more call sections so like single code section contracts from before will still work we'll just have single function there so maybe this way to design it in the like forward compatibility way so we don't have to version bump uh it does I think nice idea I haven't really thought about before would adding a minor version in the eof header be useful to indicate that I'm I require these uh forward compatible changes but I'm compatible with a Backward Compatible interpreter and like HDMI 1.1 2.1 uh I'm not sure I mean it's like still like system like all the all the contracts have to like do exactly uh like the same things and like this not really like optional think you can perform uh in the sense that all the clients have to behave the same way so I'm not sure like they're actually that having like minor version will make any change make any difference so either it behaves differently or not so if it's like two versions numbers I don't think that makes any difference okay I mean I guess I just thought this little could always just hacks yeah maybe like the functions there's a way to do it I think we will need to like take a look into this and the last one probably not because it just adds additional requirements of the code structure so the previous programs probably will not follow these um doya do I understand correctly that the last tip doesn't require the version bomb because it's just the change on the EDM side so it's uh not in the bytecode and and you can do it uh whenever you want no that's actually the one the last one actually requires the version bump because it puts additional restriction rules on the code that means we want to make sure that when you load the the evm program from database and you see the version number you know exactly what you can expect from the code so if you like if if some rules are not there at the deploy time it means that the program you load from that era will like have different uh will have different structure and you can't rely on it anymore yeah I got it thanks so I'm unfortunately then just come across the eof um but um so I'm guessing um that the intention of these changes is to make it easier to do static analysis on the evm code particularly Computing predecessors to basic blocks which is always a challenge with evm at the moment um and doing static translation will become a lot easier um you like you mean like external tools like all of the well uh so I've got sort of three main use cases um so one is stat Statics and a symbolic execution for example um another is translation translated to x86 um um and another is um uh you know doing static analysis of contracts to see if they're valid um so imagine that all these things are going to help out with that so like I think our main goal about control flow changes is to just get rid of jump this analysis and make it more efficient but we kind of expect to be also like dlf programs to be much easier to be analyzed but external tools but I think we just need like actually inputs from you like like you probably should like take a look and see like if it helps or not like how much it helps because that's not really like area of our expertise uh but yeah we kind of expect it to be much easier to do it analysis externally yes certainly it's the static static jumps will help enormously um personally but because of the practice has a problem essentially and we need to talk about you know the distribution of of this beautiful so arm has the zero register there's a lot of registered machines out there push zero will also be quite convenient um fuel also has taken the zero register from arm in their virtual machine the evm currently has the gas counter and the program counter and I think they're registers when registers oh this way uh I thought you will start talking about pool zero EIP because this one on the list uh so maybe you want to talk about it no okay I have uh so okay like let me start like from there from the back uh there's like one AP that introduces like poor zero instructions I think this is what this kind of analogous to arm and all of that so the it's just to like make sure like people don't use like kind of exotic way of like M size of that to put zero on the stack so we just will delegate one instruction to do exactly this with the same gas cost of the kind of the hacks we currently have uh and that's also scheduled for Shanghai if you remember right can I want to confirm that okay what I think it is and um so that's one thing uh registers in the VM probably never uh so this like eof stuff looks already complex enough that uh I don't know like what is the time scale we can deploy it or maybe it's it's it will never be deployed on the minute um but the thing is like it has kind of different structures so we kind of design the evm loop interpret a little differently but the instructions they operate on a kind of share between Legacy and the new one and I think that's the current current direction we're going with nobody proposed like radical changes I think like radical change would be just to take some other VM like I don't know we try to develop assembly maybe the fuel VM and I'd put it somewhere on L2 or whatever whatever uh I don't expect to see so drastic changes to evm it's kind of the same it's kind of the same of as the question like why do we have 256 bit size words right and we I probably there's also not like a notary option to shorten it to something smaller all right one more question hey um so Greg colvin's got his simple subroutines EIP as well could you explain how that is different than these yeah I I will sit down because um I so those some I'm sure I can I can give a full picture so maybe someone will jump and help me but I can start with that it kind of wanted to introduce this subroutines which are kind of analogous to what our functions are and to existing evm um so they'll do some technical issues like one is about having this immediate values uh in the instructions which are not like fully backwards compatible and secondly um it kind of doesn't really help with this analysis so this was one one because for the simplicity the jumps will still work the same and they can cross the subroutines easily so you can use the new instructions to kind of form kind of the sub codes in the code but jumps will like go whatever they want and it doesn't really help with analysis outside of that and it doesn't really help to do kind of fancy compilation by fancy compilation I mean you can take like subroutine and compile it to like native code and something and then use the the system call stack to to implement subroutine calls but because there is possibility to like jump through over or like jump out of the subroutine and go somewhere else that's really that doesn't fit into this model so uh but I'm not sure that's where the reason that the the chain didn't went through maybe there were some other reasons um yeah I mean he's he's updated that proposal again since it was last rejected I don't know if you've seen those up yet yeah uh I kind of noticed but uh yeah I I'm not sure this is like the I mean the the AP is kind of being updated and I'm I have a little trouble to keep track like which version we're talking about right now uh but I know there's some changes but this is like still kind of something we should consider for future upgrades or or not because I'm not sure like if that's candidate for for anything right so I just have one question are there any uh technical barriers for implementing 3074 I'm really about that numbers can you tell like which VIP it is also oh this one I have no idea honestly maybe someone can help okay no you're not helping um no I text I don't know really uh so I think like on the technical level probably not so many I think it's mostly like social level which is problematic or like this like some way you can trick people to do something and there is no way back or but I I am not an expert on this one actually so I don't think I can answer this you got to be a dictator here if you had to dream up in the store too what would it be or say like you're not changing the existing memory you just get to do memory from scratch how would you go about it but you you mentioned a story right or M store like it's in like just like oh we're doing memory differently here yeah um I mean that that's that's a good question um so like we didn't put anything like any kind of draft but we we have some thought about that and there was some some input from vitalik as well recently about how to kind of model that um I think this like multiple Dimensions you can try to kind of describe it like Juanes that current memory allows you to just just use whatever index you want you will just pay more gas for it and that looks kind of calculated and so kind of the memory automatically expands to the to the use and there's a kind of different way of doing that so you kind of have to explicitly inform the VM up front like okay please allocate moment more memory for me and and if you use something that is outside of the allocation it will just terminate execution right and uh the second one is this is the model that webassembly uses right so it's like you need to kind of allocate memory up front and you can't use it if it's not allocated and uh so this is like one way you can select from I think at least solidity was happy with this automatic allocation but I'm I'm not sure I can confirm that is anyone from solidity here okay I mean so it is kind of happy that like memory automatically expands to new indexes and you don't have to maintain that like know how much you did allocated or so it would be fine to have the the evm when you have to kind of declare to evm that you need more memory I'll be good or not yeah so uh no static and analog statically analyzing the maximum memory size and it is a challenging problem at the moment and you know if there was something in the eof to specify the maximum memory size so probably quite useful so uh okay uh so if I get it right you would prefer the system when you have to kind of explicitly say how many how much memory you would use or something like that it's not absolute necessary because in for instance solidity is extremely facile and very easy to analyze but there are other drinks we don't okay okay got it yeah so this is one aspect and that kind of we don't have a winner here so far and like from evm implementation I would prefer to somehow lower the the housekeeping of memory so whenever you execute one of the memory instructions like this like M load and store like most of the time evm is spending just to calculating the cost like if it's like new instruction like if the index index is not like absolutely huge or something like that and just like accessing the memories like this is this is nowhere in the on the profile right so uh I think like to to keeping the housekeeping lower uh maybe combining the explicit allocation and do the like cost by memory Pages or something like that would just have but we didn't prototype any of that so far so like kind of rough ideas what you can do quite interesting stuff if you have memory pages in the in VM implementation this is a very similar problem to the sbus on the PlayStation 3 for example you you have sort of the minimum register size was 128 bits um so so the evm is extremely similar to the to the spu on the PlayStation and as that was a that was an interesting challenge as well okay that means like PlayStation one cvmo PlayStation's a bit quicker definitely VM right also just declaring all my questions are the lowest like they're the fallback ones anyone can interrupt and take priority um well there's someone beautiful um are there any um Hardware implementation of evm or maybe fpga Asic but you know off and if there is what were their biggest hurdle asides from M store I'm guessing because that's a pain but otherwise I mean async on like memory access level or the storage access level um yeah I'm not sure I can help here but uh I I know like some people try we're trying ex we're experimenting with having like async way of accessing storage oh Asic okay okay uh wow uh so we had a pro we had a project called evm jet which just was compiling evm byte code into let's say x86 like native code and the performance was great but the cost of compiling that was also big so that's kind of the trade-off and at some point we just scrub it it's somewhere around but uh I think it's a difficult time to decide like which contract you want to compile to native code if you don't have to I I you might have misunderstood my question sorry uh let me restate it so has there been anyone implementing a physical Hardware machine that executes EV yeah so that's got nothing to do with jit so okay sorry just purely you get an OP code it decodes it okay it executes the code yeah what I wanted to do okay yeah I kind of wanted to put it in perspective in the sense like that seems at least to my opinion that seems like more advanced because I don't know about this stuff at all that like doing even jet compilation which is already hard it's like compilation is not hard but it's like time consuming so you have to just squeeze this if you if you have Hardware yeah uh like even if you had a hardware like that the gas costs nowhere reflects like the performance of it right so I'm sure how much you will say you'll save like you you're like machine computational time but it would not I think it would not improve the network unless this like like most of the people use it but I don't know if anyone tried that I'll be definitely interested project to see how it works Greg Colvin has infamously said that the AVM is a gas counting machine that does computation as a side effect do you think there could be any benefits to reducing the Precision or the Fidelity in terms of like how gradual uh you're doing your gas accounting and so like paying for more gas things up front or even say like the memory case would be one case where uh you pay for expansion or the escalation like the curve that it follows isn't actually like a smooth perfectly smooth curve naturally it sort of like has a flat region or like a sort of linear region then it goes like jumps up and then it jumps up again uh do you think more things like that could be fine in the long run or do you think we should be really good at counting really small units of gas um I think depends a bit like what kind of instruction substance you mean I think for memory we should like take a look like yeah how to improve gas gas housekeeping for these for like like purely computational ones um I think it's not so big deal right now so um the one thing is that the instructions actually do quite a lot because they are like two 56-bit precision so let's like this is not like single CPU instruction you're doing right it's like just like like four plus loading so it's like 20 instructions you do like your your CPU will be doing for the single instruction it depends what distraction it is but uh it's actually quite a lot so you kind of can hide the latency of gas computation there so kind of the CPU is doing the the computation itself and also calculates gas so the overhead of disabled gas calculation it's not I mean if you have really efficient evm implementation it's it can be like seven percent maybe ten percent so this is not like huge amount and the same for the stack checks and all of that but yeah so I I don't know what like for evm I would keep it as this I think it's not so bad definitely the simple simple gas tools will have but I wouldn't change like to be some kind of different Precision or whatever uh but we also don't want like complicated gas rules that doesn't blink anything so the the memory is unfortunately like another this like example one once more which means you just compute this like 32-bit chunks of memory which like you need to do some additional computation to to calculate the gas cost if that was would be per byte it would be simpler and the effect would be the same right so you don't want to over design it definitely but I think like in general it's kind of it's okay now for most most basic blocks you can calculate the gas costs up front um and just just calculate the whole basic block and obviously things like a store and so on the variable but um but um for you know for many many basic blocks you can you can as this can I probably tell you you can you can pre-compute it yeah you can do that uh like with one like like comment that it's like for the basic gas ghost some instruction has like basic cost and then like like variabic variatic gas costs depending on the arguments and something like that yeah we did try that like even the VM implementation and it it brings I think some performance but uh I think we kind of scrapped the idea because because you need like additional analysis phase to like should pre-calculate that and you have to and uh so a quick quick like description how it was done in evmo and there was like the old interpreter that was doing this and the analysis cost was really big and we kind of transitioned to like simple design but efficient design of evm which doesn't do that anymore and the new one is actually faster than old one but to be fair the old one didn't get so much attention recently so maybe there's some like performance you can gain from it but it won't be really big one if you have efficient evm so like Simplicity wins so far at least in like the client client perspective right yes certainly my experience is the evm is a tiny part of the cost of the whole system anyway so which possibly answers the sort of why don't we have a um an fpga evm which would obviously be trivial to do 1153 Otherwise Known t-store T load uh one by let's see years ago do you have any thoughts on that and it's specifically to the memory problem would that reduce some of these pressures on reforming memory because you know you've got this transient storage it's not hitting disk it's pretty cheap how do you feel about 1153 so um I'm not sure if I'm on the same page with this one but does it like have the same kind of like map uh map structure that this storage has right so uh yeah like for me the the issue is that you have this like map structure there so it's like it's like this is like chunk of memory you actually have like hash map or like whatever the implementation is because as I remember it was like doing the same you have like unlimited number of 256 bit slots you can assign to so the the evm has to kind of have a map of that which it can scrap at the end of the transaction right um do you want it in Shanghai it's like me personally I I don't know it's like I'm kind of kind of been affected by that um so like how actually I Vision a VM is like this kind of below that so it kind of mostly focus on that like single call so that this Transit storage it's it's like problematic in the way that I have to kind of Outsource it somewhere else so like the client of like client has to provide some way some API to actually access it because like for for my VM at least it's that I just start the AVM context on the when you enter the call and I end it there so I don't have anything that lasts above that so but yeah I'm kind of transitioning to like this the transaction level VM execution um I think like the the ultimate question is like usability of that and like if there's like strong enough number of use cases that will that make it uh like desired right and I think that some people really push hard for it um I have a follow-up question on that do you think the the cost of a TS profit do you want to anyway yeah go ahead do you think the cost of uh or the potential cost of a Tea Store would be that much lower than the s store I mean the basic one is kind of like 100 right for the currently for the extra like the minimum we can get if this is like accessed slot and something no I mean yeah maybe what are the numbers in there like the number is sure but like this thing like in the machine would it really be that different like from my perspective it's not any different to access a store uh because I kind of have a buffer of like this cache of this s store and I'd like for like Yeah from like the like the Corey VM site it's not much different uh but I think it's like so the difference is when you have to actually go to the database on disk or not and like this is guaranteed not to be the case so right but so you don't have to do any database lookup at all so so yeah probably it should be cheaper but I know how much yeah do you think another alternative solution would be to just fix the pricing of a store um and that's load I think historically we did fix the pricing of and store in every heart for credit exactly if you see the like as store implementation that's like like the multiple lives of like different revisions of evm so I don't know maybe we can't get it right so we need we need a replacement for it yeah uh I don't know how to fix it like more uh it's already super complicated so maybe that's an argument Pro um yeah I can't be sure I mean I would be sure if that there was a group that actually tried to fix the store so it's it's competitive feature than the the transit storage but I think this not such a group so far so maybe we just have to pick one option off of one so I don't know how much easier would live pay if the AVM was 64-bit or does it not really make much of a difference to your work maybe my colleagues can help me with that we did experiment with flip assembly and uh for some use case that evm is used for it's it really helps when it's this this big word size so all is like balance calculations all of this like fixed point or automatic it's really hard if you so if you need to emulate like bigger numbers in the smaller like this like more like smaller like 64-bit word size it's just it's really horrible and when when you have like simple design like interpreter and stuff so you need like to drop a lot of instructions to emulate that and it was really bad on some workloads so I I we can't confirm it's like the based the the best word size but for some use case it really helps