Improving the Ethereum Virtual Machine (EVM 1.0, 1.5, 2.0) Panel (Devcon4)

up next we have a panel on EVM which is the etherium virtual machine there's obviously some overlap here with the e azam topic including those of us on the stage unfortunately we had a couple of other none II wasn't panelists who were not able to make it but we do have Greg with us thrilled to have him join us for this part and just to be clear this is the topic is EVM as I said I mean we may touch upon some some you want some stuff but we'll be focusing more upon the etherium virtual machine what it looks like today the road forward challenges that kind of stuff so cool I'll moderate but why don't we kick off with the introductions Greg do you want to start yeah I've I put a lot of work into the what's now called Aleph is it ADM 1.0 and put a lot of work into specification for making fairly quickly some improvements to get better performance better formal tractability for the VM that could be get begot that we can get into place much more quickly than the full US and development those those got sort of set aside for the last year I've a month I don't know why but they did okay what's that that's a really interesting topic we'll come back to that just does that come back yeah we'll just do a quick intros and then start with that or not we're just doing intro yeah okay so that's what I did and I'm working on plans to to get that going again quickly and well integrated with the EMC work and he was some work so we can sort of front run on that and get people get people going and thanks Greg Hyman Paulo and I working for to you for some time and I was mostly interested in EVM a long time ago I even created project to compile a VM code to machine code some kind of jet solution and that also inspired some small but important changes in IBM's back before it's even even launched and now I'm trying to bring some cooperation to to be emulated software by introducing this Eve EMC product to allow quickly swap VM implementations and I am also cooperating with you wasn't team I'm Casey I really got my start as a core developer on a theory MJS the JavaScript client well virtual machine back in 2017 or Byzantium and I also try to help with security and testing fuzz testing finding consensus bugs and then I try to help out with contribute to research on you know Durham 2.0 sharding my name is Alex I started off 52 mgs as well working mostly on the VM in JavaScript but at the same time started to work on solidity trying to fix bugs and then actually adding features so that resulted a lot of DVM works like both of these and ended up contributing to a VM C and ended up contributing to he wasn't in the end but I'm still also very interested in improving the EVM and so actually with Pavel we submitted a couple of the IPS and which are accepted to constantly Poland Pavel osis submitted his only IPs and I was really excited of the IPC greg was doing regarding given 1.5 but they are much bigger IPS than what we have submitted and so that's that's basically about me interested in EVM as well not just he wasn't cool I'm Lane I'm also on he wasn't team that a member of that team since the beginning of this year I think my interest in things like instruction sets and he was a man EVM comes from just a deep curiosity of starting at the very bottom of a system and kind of working my way up there's a lot of amazing work being done at higher layers layer 2 layer 3 etc but really understanding this virtual machine this aetherium machine that we're building from from the bottom to start cool so let me actually I'll come back to EVM one-point-five stuff in just a sec I promise I just want to kick off with an introductory question which is maybe Alex you could take this one just what is EVM how did this thing come into existence what is it supposed to be or do I mean you want to pass in there someone else wanted up to that I mean it started from the beginning there's a section of the yellow paper which describes the VM and so it's it's an essential part of even the concept of etherium we have smart contracts and that what that's what initially distinguished etherium from others and the VM is is what did it and not to be too nasty but a part of my job is to be a nasty old man and yeah Grouch Grouch of people because I've been in the industry a long time and DVM we have was designed by cryptographers not by virtual machine experts so it has certain problems which I ran into when I when I went into it when I got here and said this thing needs to be a lot better some of the problems affect performance even worse some of the problems make it very difficult to formally analyze the code and that's something that's important to me I sneered at formal and formal analysis my whole career because I didn't see that taking ten thousand a hundred thousand my program and then writing a million line proof was going to help anything now we're looking at programs which are even smaller than what we used to write for our Apple two's smaller than the 64k segments mmm estas that we use staff to write in I remember squeezing a relational database into a 64 K segment it suddenly starts to make sense when you've got you know an awful lot of money hanging on 24 K of code to spend a lot of money doing anything you can to prove it right and the current VM makes that very difficult Lassa makes it a lot easier but when I arrived wasm was not yet a thing there was it was agreed I don't know exactly where it was in the realm map but it it was not there was no spec for it it was finished it was minimal minimal Viable Product was not even there so I set out to say well I don't want to wait that long and I'm getting back to doing that but that's basically what the EVM is right now and part of the troubles we're running into it and what I joke here's the t-shirt from Cancun they day the dead it's a day after Halloween now there was a accident with laundry bleach so it's been to hell and back and I never again want to be awakened on a Caribbean beach during the vacations to discover that you know yet another million eath is falling down a rat hole because there was a long line bug in your program and so that's my goal right now and sees me so I'm just trying to get together some people and some money to pursue that in parallel and trying to get in coordination with the Lassen team so we can get that done more quickly onto the main chain and we're going to be able to compile that code to Assam code so there's not going to be any real conflict or trouble for customers as we as we event Eliza I sort of see laughs and it's becoming the assembly language of Ethier i think just half a your interesting line i kind of felt like that you're saying that was him is ready now we don't need a DM but then you iterate it on it and i think it was very interesting what you said in general i want to hear a bit more about that at some point then you just add a tiny bit more color to the introducing EVM idea as you said Greg right EVM is sort of the implementation of the yellow paper right it's the state transition machine in the yellow paper and it's a really interesting unique really well designed virtual machine and I'm gonna hold on hold on wait till I share the second half of my thought it's I'm paraphrasing and paraphrasing Nick Johnson here it's well designed however it's a theoretical sort of virtual machine right so you get these interesting things like these 256 bit words so even if you want to do very simple integer math you know you're it's very inefficient right because you have all these kind of wasted bits and it doesn't resemble anything like an actual hardware instruction set whereas in contrast to something like webassembly web assemblies very close to actual hardware is that sort of address your concern Boris or do you still think it's okay cool exactly okay [Music] okay so just to restate what what Boris said for I guess recording and Internet people's the EVM is a very well-designed VM using technology that sort of comes from the 1960s and that we could develop a much better VM today using modern technology it also has a very clever feature yeah called the dynamic jump which back in I think actually 50s Fortran had it was called a computed goto in which you can do some sort of rithmetic that says where you want to jump and then you jump why is that a bad thing because when you're doing formal analysis you get to that point in the code and you want to say well where's this jump go and the answer is it can go anywhere in the program and when I I you know I'd done one round of optimization I think about doubled the speed of the interpreter and then I wanted to do the next round to apply some techniques that I'd invented in optimizing the interpreter in the Oracle kernel and came around and went uh-oh and I showed it to Christian and he said well of course because of the damage jump you don't know what level of the stack you're at I'm going sheep and stronger words than that and that's then I started going okay how do I fix this and discovered it's like there's no basic subroutine you know just a sub instruction and even in the 60s and even in the 50s most computer architectures had some sort of instruction for for making subroutines and the idea was well you can make those out of the dynamic jumps and if you ever look at the code this solidity generates for calling a function it's just it's pretty ugly so my next sorry I gotta follow up question Pablo you said earlier that you suggested some small but important changes to the EVM before you know Genisys launched in 2015 was the dynamic jump on your radar yeah that's what's the problem so even before it was the situation was much worse because now at least you have specified what are possible destinations for jump so you have special jump this instruction so these are valid places where you can jump to before that there was no such thing so you can drop anywhere including data from push even so you can execute code in push data and like so before it was impossible to have any other translation further translation of EVM bytecode so that this like allows some some way of compiling EVM byte code to machine code because on this machine code level you are not allowed to do I mean this own way but that would be horrible so yeah that's that was that was the change and destination it kind of like a joint quite late during the process and also I didn't know much as I know now and like didn't have courage to to change into something like better behaving although we had like JVM example when there is like it's fixed it's fixed how like what what the stack height can be on when you enter the function what yeah so kind of like yeah this is this is missing definitely we're getting deeply technical here I don't know some people are probably excited and some people are just we have to have at least one nerd in the room yeah we'll save tons of time for questions another problem is that you can you can't optimize this the compiler can look and go well yes you're using 256 bit registers but there's instructions like add mod and mall mod so you can say that really I'm operating but at 250 I'm only using 64 of these bits the compiler can generate 64-bit code but tough we're still going to charge you gas as if you were working with 256 bits I think only in the last month I think I figured out a way to fix that looking at the work that's being done on the I le virtual machine through procore and other people of runtime verification I've been working on the lab and that time to talk to anyone and write up right in the IP on that but basically to charge the gas based on how wide you actually know what you can tell is the maximum with the register you need so there's basically things that can be fixed and we think Boris who just spoke up there and I don't know if Brooke is still around or not she's she's an amazing formalist she's going to be humble there before you go any further I'm wanted to reflect on part mm-hmm you said that maybe specified the actual width of the data you want to apply the computation on and there's just one thanks to you two worth mentioning here and currently the instruction set looks like s there's a single instruction which can have an immediate value and that is the push instruction no other instruction cap can have immediate values every single other instruction is just operating on the stack and there were a couple of different proposals to augment other instructions to have immediate values or have like multi byte codes op codes to encode you know different behaviors and there was a big resistance to do that and one of the reasons people said that it's going to make the current verification tools have to be changed and we cannot afford that so there was a real big pushback and what you suggest I think I would imagine it to be implemented if say like the additional addition up code would have an immediate value specifying the bit its operating on or you would have a multiple byte codes and up code but we have this perspective people don't want to have changes there you can simply you can simply call mod after you pulled that data does you know you only need so many bits and and you want to detect patterns and in the VM that there's like a multi four and then there's a calculation then you charge this yeah if if some data came in and then you might you've just fouled away all those bits and it means a compiler like solidity will have to generate code to take advantage of that and solidity is actually today generating code like that if you're using smaller data types mm-hmm but since gas-discharge for even the multi distraction it is more expensive but so people don't use it right so we have to change the gas model so that that actually helps in the way that was intended to help so we talked about one thing that we kind of have consensus that we could or should and maybe will change which is removing dynamic jumps I'm curious what other things if you could change one thing besides that any VM what would you change maybe we could just love you guys all have an answer I guess we have overlapping answers the big one is to remove dynamic gems have cold frames and this will give a couple of different benefits a lot of those craig explained but another immediate benefit people actually going to feel as you can address more of the you can address like different the arguments to the function much more easily than right now and it also makes compiler code generation phase easier people have a lot of pain with solidity giving this random awkward error message stack too deep and it is giving it in various different ways where where is different locations and it's just a lot of work to you to work around that with the current EPA model so I think this is the core which which is blocking so many things and so that would be my number one case you have one no I'd rather just switch to assembly for me would be all of this let's say soft oils that you can get I mean when you divide by zero if it's zero it doesn't make sense when you access data that doesn't isn't there you get zero and like all of these sorry for first it makes verification harder not not easier although like some people said like now it's defined what's going to happen but it's mathematically it doesn't make sense and it's also like very dangerous and we have examples of this being broken in in deployed production ready smart contracts oh yeah that that would be might change so I would just terminate execution if something like that happened mm-hmm Greg up to you and feel free to use this opportunity to introduce you yeah and I'm with Casey and this part of why I asked the question on scheduling um because I know that I can much more rapidly implement a IP 6 1 5 and we're 26 1 5 that's that's that's the proposal to get rid of dynamic jump introduced subroutines and a few other opcodes to clean that up it would be a separate there are separate things you could do like what Powell mentioned those might be work you don't want to do there's a VIP six one six to put in Cindy it's not clear if we want to do that or just wait for Azzam but so for me work I'm working with Boris and and Brook to just raise the money and put the plan together to do that just as personal reasons I decided I didn't didn't want to do it under contract with the foundation directly down but wanted to have more more control over the price checked myself and this is this is EVM 1.5 what you're afraid yeah the collection of these two yeah I guess Boris is telling me getting out talking to some fair number of other clients are going if we can quickly get this stuff we'd really like it Andy BMC means if we wrap it up that way they can get it they can plug it in they can use it mm when wasm is available they can get it they can plug it in they can use it and just try and try and get past this problem yeah much more quickly so there's kind of two schools of thought right now about the state execution engine and ethereal one is we should focus all of our resources on us um and sort of its Casey alluded to before like that should be the emphasis right now but there's clearly another side another way of looking at this which is that we should not we should not we should not try to deprecated EVM and we should except it's gonna be with us for a while and we should be investing more in it I'm just wondering Greg maybe you want to make the case for why that's worth doing even in light of you blossom I haven't counted but how many VM contracts are on the blockchain now what rate is it growing at is it quadratic or exponential if it's exponential however long it takes to Yeti wasm out how many more EVM will be out there how many existing tools exist for analyze EVM one code how many new languages are being created they'll basically there's already an ecosystem growing up around that you know so it doesn't help the community to just say well don't bother because at some point in the future we're going to throw that away yeah the Sinclair issue like both awasum and GBM 1.

5 I'm curious what are the backwards compatibility concerns with say removing dynamic jumps I know I know II was um there there's various proposals to add backwards compatibility which might help alleviate the Sinclair issue that I am Boris Boris mentioned so I'm curious if you you guys could maybe fill me in on that and then we can well fulfill EBA 1.5 to a simple idea to some progressing on the deployment time so we don't allow dynamic jumps anymore I mean we don't allow to deploy let's say evn 1.0 contract at some point but they want our dead they will be there all the time I have an addition to this so we have these two translation tools originally named EVM two wasn't but now we have a new version called ye VM which compiles even bite kit was invited good now it is not really optimal because of the very same reason but would would even 1.5 we implemented then we would have a much more optimized compiler I think there's like an overlap between these things I'm not fully personally sold on the six one six the IP which is the simple editor but six one five I think it's a low-hanging fruit and if you combine it together with what Pablo said that okay we disable the 1.0 deployments and it's only just this one point five which is the six one finds so many numbers anyway it's just about the that could be moving dynamic jumps jump so if we enable that forcefully and disable deploying hold contracts the solar compiler already supports it I think there was an implementation you made in allit it's likely it's a low-hanging fruit which I think could be I mean I would optimistic to even have it after Constantinople but just right people have to be convinced but it definitely this single step does help the transition to tui was amiss well if you want to keep backwards compatibility between that's mean yeah the code the code is in is in there I think last time I looked you you've moved it to the side that it's still there I think it's not there anymore over didn't you have your legacy anyway it's it's chip it's somewhere down in there somewhere they can be pulled back out it was implemented some testing needs to be done yeah but it doesn't yeah I can work alone for six months and and have something then we'll need some more help on some other stuff but it's just not that hard to get that going in depending on scheduling I think it can be done more quickly than you ask them can be can be delivered so it was related but slightly higher level question why do you guys think EVM has been so slow to be evolved as a technical is it political is it something else because no resources were put into it I think one of the issues that we have is we look at a couple of things I see a split split between researchers implementers and people who are attempting to ship bug-free production code on top of the world computer all of which that are happening at the same time and again always a hard call to say when you should ditch old and go to new and everything else like that but if the people who do research never have to do production implementation it's the same issue between DevOps and developers if you never actually mean to have to maintain separate production a research engine needs to be built differently rather than optimizing for people who actually have to ship code in production it feels like there was a large movement for whatever reason to new new and we should not be afraid to keep fixing old stuff maybe there was another perception that fixing a VM was hard but if you just bring in people with vm expertise it's not that hard my opinion we have a late addition to the panel everyone introduce yourself I'm every Eldon brand I've been working on formalization of VMs and stuff I gotta had some meetings before this but one thing I've worked on formalizing is the Waze and VM but not as much recently cuz I've been busy with things but don't be shy you what's a big ke VM oh yeah so one thing one topic can you speak about I yell eat a tiny a little bit we feel confident to do that one thing that came up was this other virtual machine would you mind taking 60 seconds to tell us what that is and how it's similar or different to the VM it wasn't so y la is VM that we designed for weaving runtime verification designed for the Cardinal Network and it has a lot of similarities to LLVM we've had some VM experts kind of on our team who helped us design it and we mostly tried to avoid building in anything that would make verification difficult to the VM so things like hem store eight or other issues with the EVM we kind of tried to avoid it's a registered based machine so people have different opinions on that I don't really care either way and it supports out-of-the-box unbounded integer arithmetic so you can just use a proper end type in the VM but then we have kind of a more complicated gas model to account for that just when I reread the question because we were late the the question was why didn t vm improve over time um and Boris explained a couple of reasons I wanted to add a single reason which also Greg mentioned that lack of resources and a lot of resources were shifted - he was him and there weren't any resources left of IBM and then the same time the the research team also shifted their focus and they weren't really interested in and getting anything done an EVM so there was nobody to propose except correct to propose ideas and then there was nobody execute those ideas it's really had to work alone on improving the EVM so there's been some conversations even here at Def Con the past couple of days that maybe while we wait for Jasper sorry of italic eternity to like become a thing and be alive but there there is value in reinvesting in etherium 1.

0 or 1.5 or 30 in the next generation or whatever you want to call it is this could this be part of that conversation improving idiom and if so like what would that look like maybe I can add one one side to that I think we say a Tyrian 1.5 billion plan interim no regrets each human ji all these different names refer to the same thing that was there was not really about the VM but other parts of the network which may just make sense to do them separately because they're not that interconnected at least at this level at this stage of where the discussions are it wasn't the DVM execution time which was the bound or the reason we need to make those changes so I think we can keep them separate and therefore Greg kicked off with his idiom one five proposal and if you keep them separate you can also do them in parallel and maybe get them in more quickly but that's just my addition to it maybe Casey you wanna secure I have a comment actually about why it's difficult to update the EVM and I think it's actually just because it's well you start with something that's EVM which is kind of designed you know ad hoc ish it's it's it wasn't like someone they took some existing VM and then made it blockchain capable they you know it was just designed from the start and then as the hard fork started piling on logic behind various different parts the VM got more complicated so the recent constantinople hard fork the rules for storage allocation just i mean it like literally tripled it tripled in length how many different cases we have to handle and it's like different depending on which pork you're on and it's it's a major pain so i think part of the problem with evolving the EBM is kind of maintaining backwards compatibility so having the ability to support the new e vm execution model and the old e vm execution model is just going to complicate the clients to the point where working on them to update them for future hard Forks is getting more difficult over time so i think that could be a major barrier as well basically the backwards compatibility issue cannot be avoided at all you move D you azzam that we still got all these weird all this weird stuff it gets moved up to your environment interface and even with the current even with the old VM I would love to take a whole lot of those op codes it's really art they really have nothing to do with the virtual machine and I could easily as you have with machine goes say okay let's pull all of that out of the VM deprecated it and move it up to the environment interface you know again the functionality is there we've got a we've got a deal with it one note on on the backwards compatibility and medium itself and that promise actually was broken I believe it spurious dragon or tendering this or whatever the coding was back like two years ago where cost gaskets were increased and before that I think it was never explicitly said that gas cost cannot be increased but a lot of contracts assume that and once you increase the gas costs so one example when a contract makes a call to another contract previously they made like a fixed calculation in the contract in many cases and once you pumped up the cost in in some cases they they just failed I try them they were done so we broke they're backwards compatibility promise and but all the proposal since then just reduce the costs so like this s toward change you mentioned that reduce the cost but I think because we broke that promise and a lot of the okay the two languages don't they take that into consideration I think it would be possible to do like a cleanup of the gas gas rules in in some cases may definitely result in increased costs for a given contract or a decreased cost but it shouldn't break contracts entirely but it is a say a political question at that point if if a contract is increased so much in cost that it kind of breaks there the user experience and you know it's an important country even if we just ignore the complexity of the gas model which is arguably where a lot of the complexity in this happens there's still complexly if we want to say deprecated old off codes or something like that and at that point what do you tell the owners of contracts who you know use those op codes if you want to deprecate it and say you know we want to remove this that we can start to evolve it to something that's a little saner or or a little more modular or is more compatible with other VMs who knows but it there's just there's not something built into to the system that says you know we're gonna at some point be able to say no your contract is no longer going to be able to execute on them that wasn't what people signed up for when they signed up for aetherium initially there's there's this joke that goes Intel we put the backwards and backwards compatibility and we're stuck with that any contract that works that got put on the chain has to keep working forever unless then look well it has to keep working forever it has been as an address they can be called ok can I just mention a strange example to this ecole code of code which which was quickly fixed by introducing a new up code core delegate for just right in two months after launching deuterium because code was supposed to do what delegate call is doing but it was and you have to still kept it and nothing is using it because it's useless yet we still have it how can we move it the best we can do both both the best we can do for any VM is when you deprecated it is you keep you have to keep supporting it null code but if they try and put a new contract on the blockchain that uses that uses a deprecated feature they can't put it on the blockchain anymore so yeah deprecating stuff is definitely hard but about Everett's comment that adding new features or new app pose or changing the way existing app codes work increases the complexity of the code base because you the code has to support the you know the old for crawls and then you know next work rules then the next one and you get all these conditionals all that you can actually get rid of that by just only supporting the new fork rolls and resetting you know essentially like resetting the Genesis block at a more recent snapshot I'm not sure why so many clients and you know users are obsessed with being able to process all the way from the Genesis block and then through all the court rules and then currently but what about a contract that has some logic about how their funds are supposed to be paid out you reset your Genesis block you essentially forget their code structure or something like that and then what happens to those funds sitting you know you start at the snapshot of the current of a state after the fork right then that client sinks starting from that snapshot and it only has to support the new fork rules at that point you call in to a contract that was created before that on a previous Fork right it's logic is broken on the new Fork potentially well so maybe you've locked up someone's funds or yeah so I said you can't did you really can't deprecated stuff or it's really hard to you can only you know change things again the the Intel chip started out as a hand calculator and that code still runs it doesn't run very well that those op codes have actually become pretty swell and there's a good reason not to use them anymore but that hand calculator is still in there and to some extent you know we says you're bitching about it and it's just tough suck it out I want to save some time for ID ask questions let's speak maybe ten minutes left with that let's go ahead and do that anyone have a question or comment complaint or it's always force so one of the things I want us to think about is I'm starting to think about the different components of what is etherium just as we're maybe thinking about what is web 3 and how much we're integrating and eeap's and other stuff like that with ipfs and so on the EVM goes beyond etherium public main net so today Microsoft released released a new EBM the EE BM written in C without gas calculations that is designed for private networks so how much from the perspective of an EVM specification do we broaden to support and work with other chains like the way I see it we might have a very large EVM community that might want to work together and fix some of the resources issue so just some some thoughts that I'd love to hear the panel's ideas on I'd actually like like to ask you a question because you there's nobody else nobody wants to ask yeah can you clarify a second very can you clarify are you asking specifically about are we going to support the other E or I don't know I mean we can certainly build formal models of those other ones and then we can look at them and see ok can we apply those changes that they make to our EDM as well but ok so so maybe this is not relevant and in fact various things called EVM are gonna live in their own worlds it just feels like it might be a way to actually broaden our community and get high quality code together so she's an idea so from my perspective that's one of the main goals of you was it is that we're stepping into a much broader community so the other EVMS should all die no I didn't say that but I'm saying if that's our goal I think that he wasn't largely serves that goal that's all I'm saying mm-hmm in EVM over the years there have been a couple of other chains using it and most of those chains have made additions to it inform self new up codes to access data so one example I think is good stuff they had like six sub codes there were a couple of others that kind of Cocoon right now but all of these may be for the lack of the platform to communicate these ideas they are Forks they're not compatible and when they made these changes they also had to change the language is supporting EVM which at a time with religious solidity so they for solidity to support those things and I don't really see any communication between any of these other forces their users of EVM at the moment I think we have to overcome that issue first get like a discussion flowing between the different EVM forts between like you know the maenette in front of a IPS and as well as like the language designers compiler others in the theorem space and once that is solved you can you can then to learn how to you know make bigger changes and get those changes down to them but we we have those channels closed for some reason so yeah so for me it's it's yeah from my perspective it's mostly communication easier and it's so easy to fork and then never go back for DFC project whatever direction the communication should go so like everyone is I think like own a IP repo with VIPs like with different names even cover network has what I find out like last week there's like cover network improvement proposals something and so this information is not exchanged this is I don't know how to fix it maybe you have some ideas but yeah definitely to having some some platform to communicate that would be would be great I personally hope like we can get a VM see in spotting VM which is by its even classic I haven't checked the details what what changes they have they support all of that what seems quite close to our needs so that we interesting to to try it on to your network any other questions yeah I wanted to clarify that Microsoft IBM implementation is for SGX environments so basically the gas calculation doesn't make sense they're basically they want to you know enabled it on the other and you can just you know send code and get the get the verified computation off train which is pretty interesting but I guess the gas calculation doesn't make sense there it's negotiation you did the KVM work I've had some conversations and work with seed whoever he is there's a man whose jitter tagged his seed I don't know who he actually is but we've had a lot of a lot of communication he's working on a lamb formalization forked off of a cheese formalization and we've talked a bit about where that the current the current EVM gets in the way of that kind of thing and how my proposals are intended to help see this was quite excited and contacted me it's like when did these go in they would help so much but I'm running as a formless what your opinion is is how much would it help and how bad is it right now well nothing's crashing and burning so I think it's not it's not too bad but it it's it's quite a pain to update KB I'm especially anything regarding the gas calculations because there was I mean you have to do things in a very specific order and it's it's kind of annoying that you have to do that I don't know like for reference maybe I can say how long it took to formalize EVM versus how long it took to formalize the fragment of wasum which is most of the execution but just not the modules an EVM took I want to say I mean depending on how you count between you know 8 and 14 months and and wasum was closer to the six-month mark maybe so I think that just that alone and the wasum definition is just shorter and it's cleaner and it just makes more sense and it it it just feels more coherent it all kind of presents itself nicely together instead of feeling scatterbrained I don't know Oh - van dynamic - oh that one specifically how much does that proposal oh my gosh that would help so much oh my gosh that that is a single like when we made our own like EVM 1.5 I called it EDM prime as a kind of just a toy like how would I change the EVM type of thing and that was the very first thing I did was it was just okay all jumps are actually labeled and you only can jump to the jump labels or something like that and then on top of that we put structured control flow like if and wael and stuff like that and and it makes static analysis tools way more effective like like worlds and worlds more effective and then it makes verification efforts a lot easier as well dynamic jumps are are terrible like can't we hire you for what we can do what one last questions we have already asked questions can I hit a question to Gregg oh sure all right never mind sorry audience I'm gonna be quick Gregg you mentioned that at some point that EVM might be the the general description of the contract itself but it's not the way it is executed it's just translated to something else maybe I got it wrong but that's what you mentioned like in the first five minutes that maybe you were translated to you Azam at some point instead I'm saying we can do the work now to get a better EVM ready and going on the main chain because sharding all of thats also somewhere way out in the future we don't know where it is you know and then when Rasim is on the main chain solid formalized ready to go and your compiler to compile from EVM to as and that's ready to go there's not any big problem to migrate code there is no migration that's just that's just the way that it gets executed right no one no one cares whether you compile it to us and then then compile the license of machine code or interpreted or compiled what right to machine code that the user doesn't care about that as long as it gets executed correctly but short-term we we want to just get it working and a little bit longer term whoa excuse me just a little longer term we you know we now have a a formerly verified subset of C we've got I don't know it's a subset or all but LLVM has been formally verified yeah so we can have a form of a formally verified EVM 1.5 executions of s mutations mm-hmm we have specifications but I wouldn't say it's verified it's just a specification okay so as usual grigory's problem seeing a little bit more than exists but I want to put in another just question and we shouldn't answer it right now just leave it hanging if we just culminating all these discussions we had if we keep adding these changes to EVM yet we have to keep backwards compatibility you know to a certain extent or the different ways to do it and then we still plan to switch to uoit's them does that leave us with more legacy we have to keep because all of this stuff is on the main net or you know it's a better position but I don't think we should answer this right now we should just think about this or we did we have time for one more question from the audience okay a two second answer is just as well as against more stable you stop you cap off EVM one and say it's a tail on the main chain and you have to support it it has to be supported forever I'm saying it can be supported with the compiler and you stopped evolving it so you don't keep creating backwards compel it okay so we've a next panel at some point thank you guys very much thanks for listening you