 Up next we have a panel on EVM, which is the Ethereum virtual machine. There's obviously some overlap here with the Iwasm topic, including those of us on the stage. Unfortunately, we had a couple of other non-Iwasm 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, the topic is EVM, as I said. We may touch upon some Iwasm stuff, but we'll be focusing more upon the Ethereum 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 introductions? Greg, do you want to start? Yeah, I've put a lot of work into what's now called ALIF, is it? EVM 1.0, and put a lot of work into specification for making fairly quickly some improvements to get better performance, better formal trackability for the EVM that could be got, that we can get into place much more quickly than the full Iwasm development. Those got sort of set aside for the last year. I don't know why, but they did. Greg, that's a really interesting topic. We'll come back to that in just a second. We'll come back to that. Yeah, we'll just do a quick intro, and then we can start with that. We're just doing an intro. Yeah. Okay, so that's what I did, and I'm working on plans to get that going again quickly and well integrated with EVM C work and Iwasm work. So we can sort of front run on that and get people going and off we go. Thanks, Greg. Pavel? Hi, I'm Pavel, and I'm working for Ethereum for some time. I was mostly interested in EVM. Long time ago I even created a project to compile EVM code to machine code, some kind of JIT solution, and that also inspired some small but important changes in EVM spec before Ethereum even launched. And now I'm trying to bring some cooperation to EVM-related software by introducing this EVM-C product to allow quickly swap VM implementations. And I'm also cooperating with Iwasm team. Casey, I really got my start as a core developer on Ethereum.js, the JavaScript client, well, virtual machine back in 2017 for Byzantium. And I also try to help with security and testing, fuss testing, finding consensus bugs. And I try to help out with contribute to research on Ethereum 2.0 charting. My name is Alex. I started off with Ethereum.js 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 in a lot of EVM works, like both of these, and ended up contributing to EVM-C and ended up contributing to Iwasm in the end. But I'm still also very interested in improving the EVM. So actually with Pavel, we submitted a couple of EIPs, which are accepted to Constable and Pavel also submitted his own EIPs, and I was really excited of the EIPs Greg was doing regarding EVM 1.5, but they are much bigger EIPs than what we have submitted. So that's basically about me interested in EVM as well, not just Iwasm. Cool, I'm Lane. I'm also on the Iwasm team and a member of that team since the beginning of this year. I think my interest in things like instruction sets and Iwasm and 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 Ethereum machine that we're building from the bottom to start. Cool, so let me actually, I'll come back to EVM 1.5 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 may want to pass on there. Someone else want to talk to that? I mean, it started from the beginning. There's a section of the yellow paper which describes the EVM, and so it's an essential part of even the concept of Ethereum. We have smart contracts and that's what initially distinguished Ethereum from others and EVM is what did it. And not to be too nasty, but part of my job is to be a nasty old man and grouch at people because I've been in the industry a long time and the EVM we have was designed by cryptographers, not by virtual machine experts. So it has certain problems which I ran into 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 analysis my whole career because I didn't see that taking a 10,000 or 100,000 line 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 IIs. Smaller than the 64K segments on MS-DOS that we used to have to write in. I remember squeezing a relational database into a 64K segment. It suddenly starts to make sense when you've got, you know, an awful lot of money hanging on 24K of code to spend a lot of money doing anything you can to prove it right. And the current VM makes that very difficult. WASM makes it a lot easier. But when I arrived, WASM was not yet a thing. There was a dream. I don't know exactly where it was in the roadmap, but it was not. There was no spec for it. It was finished. It was not a minimal viable product. It 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. Day of the Dead. It's a day after Halloween now. There was an accident with Laundrie Bleach, so it's been to hell and back. And I never again want to be awakened on a Caribbean beach during the vacation to discover that yet another million ETH has fallen down a rat hole because there was an online bug in your program. And so that's my goal right now. And 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 WASM 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 WASM code so there's not going to be any real conflict or trouble for customers as we move into WASM. I sort of see WASM as becoming the assembly language of Ethereum. I think just halfway your interesting line, I kind of felt like that you're seeing that WASM is ready now, we don't need EVM, but then you iterated on it and I think it was really interesting what you said in general. I want to hear a bit more about that at some point. Let me 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 going to... Hold on, hold on. Wait till I share the second half of my thoughts. I'm paraphrasing Nick Johnson here. It's well-designed, however, it's a theoretical sort of virtual machine. So you get these interesting things like these 256-bit words. So even if you want to do very simple integer math, it's very inefficient 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, WebAssembly is very close to actual hardware. Does that sort of address your concern, Boris, or do you still think it's... Okay, cool. I believe what I heard said... Exactly, okay. Okay, so just to restate what Boris said for, I guess, recording and Internet peoples, 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 called the Dynamic Jump, which back in, I think, actually, 50s, Fortran had, it was called a computed go-to, in which you can do some sort of arithmetic 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 does this jump go? And the answer is it can go anywhere in the program. And when I... I've done one round of optimization, I think I 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 Dynamic Jump, you don't know what level of the stack you're at. I'm going, shoot. Um, and stronger words than that. And then I started going, okay, how do I fix this? And discovered it's like, there's no basic sub-routine, 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 making sub-routines and the idea was, well, you can make those out of Dynamic Jumps. And if you ever look at the code that Solidity generates for calling a function, it's pretty ugly. So my next... A follow-up question, Pavel, you said earlier that you suggested some small but important changes to the EVM before, you know, Genesis launched in 2015. Was the Dynamic Jump on your radar? Yeah, that was the problem. So even before it was, the situation was much worse because now at least you have specify what are possible destinations for jump. So you have special jump-desk instruction. So these are valid places where you can jump to. Before that, there was no such thing so you can jump 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 at least allows some way of compiling EVM bytecode to machine code because on this machine code level you are not allowed to do... I mean, there's a new way, but that would be horrible. So yeah, that was the change. The jump destination. I joined quite late during the process and also I didn't know much as I know now and didn't have college to change it to something like better or behaving. Although we had JVM example when there is... it's fixed... how... what the stack height can be when you enter the function. So kind of... yeah, 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 at least one nerd in the room. Yeah, we'll save tons of time for audience questions. Another problem is that you can... you can optimize this. The compiler can look and go, well, yes, you're using 256-bit registers, but there's instructions like AdMod and MulMod so you can say that really I'm operating 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've figured out a way to fix that looking at the work that's being done on the IELE, virtual machine, other people at runtime have been working on but I haven't had time to talk to anyone and write any 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 I don't know if Brooke is still around or not. She's an amazing formalist. She's going to be humble there. Before you go any further I just wanted to reflect on one part you said that maybe specify the actual width of the data you want to apply the computation on. There's just one thing to work mentioning here. Currently the instruction set looks like there's a single instruction which can have an immediate value and that is the push instruction. No other instruction can have immediate values. Every single other instruction is just operating on the stack. There were a couple of different proposals to augment other instructions to have immediate values or have like multi byte codes to encode different behaviors and there was a big resistance to do that. People said that it's going to make the current verification tools have to be changed and we cannot afford that. There was a real big pushback and what you suggest I think how would you imagine it to be implemented if say like the additional addition upcode would have an immediate value specifying the bit it's operating on or you would have a multiple byte code upcode but we have this pushback that people don't want to have changes there. You can simply call mod after you pulled that data in because you know you only need so many bits and you want to detect patterns in the VM that there's like a mod before and then there's a calculation and you charge less. If some data came in and then you mod you just thrown 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 but since gas is charged for even the mod instruction it is more expensive so people don't use it. So we have to change the gas model so that that actually helps in the way it was intended to help. So we talked about one thing that we kind of have consensus that we could change and maybe we'll change which is removing dynamic jumps. I'm curious what other things if you could change one thing besides that in the VM what would you change? Maybe we could just let you guys all have an answer. I guess we have overlapping answers. The big one is to remove dynamic jumps have cold frames and this will give a couple of different benefits. A lot of those Greg explained but another immediate benefit people actually going to feel is you can address more of the arguments to the function much more easily than right now and it also makes compiler code generation face easier. People have a lot of pain with Solidity giving this random awkward error message stacked too deep and it is giving it in various different ways in different locations and it's just a lot of work to work around that with the current EVM model. So I think this is the core which is blocking so many things so that would be my number one. KC, do you have one? No, I'd rather just switch to WebAssembly. Pavel? For me it would be all of this let's say soft errors that you can get I mean when you divide by 0 you get 0 it doesn't make sense when you access data that isn't there you get 0 and like all of these for first it makes application harder not easier although like some people said now it's defined what's going to happen but it's mathematically doesn't make sense and it's also like very dangerous and we have examples of this being broken in deployed production ready smart contracts so yeah that would be my change so I would just terminate execution if something like that happened. Greg, up to you and feel free to use this as an opportunity to introduce your idea for 1.5. And I'm with KC in this part of why I asked the question on scheduling because I know that I can much more rapidly implement EIP 615 Which one is 615? That's the proposal to get rid of dynamic jump, introduce sub-routines and a few other op codes to clean that up it would be a separate there's separate things you could do like what Pavel mentioned those might be work you don't want to do there's a EIP 616 to put in Cindy it's not clear if we want to do that or just wait for Wasm but so for me I'm working with Boris and Brooke to just raise the money and put the plan together to do that just because for personal reasons I decided I didn't want to do it under contract with the foundation directly but wanted to have more control over the project myself and this is EVM 1.5 what you were referring to the collection of these two yeah and 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 and EVMC means if we wrap it up that way they can get it they can plug it in they can use it and everyone 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 much more quickly so there's kind of two schools of thought right now about the state execution engine in Ethereum one is we should focus all of our resources on you Wasm and sort of as 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 try to deprecate EVM and we should accept that it's going to 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 Wasm I have encountered but how many EVM 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 get E-Wasm out how many more EVM will be out there how many existing tools exist for analyzing EVM one code how many new languages are being created basically there's already an ecosystem growing up around that and 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 the Sinclair issue if we start announcing E-Wasm and everybody stops building smart contracts the Sinclair issue like both E-Wasm and EVM 1.5 I'm curious what are the backwards compatibility concerns with say removing dynamic jumps I know with E-Wasm there's various proposals to add backwards compatibility which might help alleviate the Sinclair issue that Boris mentioned so I'm curious if you guys could maybe fill me in on that and then we can for EVM 1.5 there was simple idea to do some pre-processing on the deployment time so it don't allow dynamic jumps anymore I mean we don't allow to deploy let's say EVM 1.0 contract at some point but the ones that are there they will be there all the time I have an addition to this so we have these two translation tools originally named EVM 2.Wasm but now we have a new version called Y-EVM which compiles EVM bytecode to Wasm bytecode now it is not really optimal because of the very same reason but with EVM 1.5 we implement it then we would have a much more optimized compiler so I think there's like an overlap between these things I'm not fully, personally not fully sold on the 616 EIP which is the SIMD but 6.1.5 I think it's a low-hanging fruit and if you combine it together with what Pavel said that okay we disable the 1.0 deployment and it's only just this 1.5 which is the 6.1.5 it's so many numbers anyway it's just about the removing dynamic jumps so if we enable that forcefully and disable deploying old contracts the solid compiler already supports it I think there was an implementation you made in Aleph it's likely it's a low-hanging fruit which I think could be, I mean it would be really optimistic to even have it after Constantly Noble but just right people have to be convinced but definitely this single step does help the transition to E-Wasm as well if you want to keep backwards compatibility between the two the code is in is in there we've moved it to the side but it's still there I think it's not there anymore over didn't you have your legacy anyway it's JIT it's somewhere down in there it can be pulled back out it was implemented, some testing needs to be done but it doesn't I can work alone for 6 months and have something then we need some more help on some other stuff but it's just not that hard to get that going and depending on scheduling I think it can be done more quickly than E-Wasm 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 evolve? is it 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 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 it was 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 dev ops and developers if you never actually have to maintain stuff in production a research engine needs to be built differently rather than optimizing for people who actually have to ship code in production and it feels like there was a large movement for whatever reason to do 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 Everett, do you want to introduce yourself? I'm Everett Hildenbrand I'm a formalization of VMs and stuff like that I had some meetings before this but one thing I've worked on formalizing is the WASM VM but not as much recently because I've been busy with things but don't be shy you also did KEVM so one topic can you speak about IELE one thing that came up was this other virtual machine would you mind taking 60 seconds to tell us what that is what is the difference between the different EVM and WASM? so IELE is a VM that we designed for we being runtime verification designed for the Cardano network and it has a lot of similarities to LLVM we had some LLVM experts on our team who helped us design it and we mostly tried to avoid building in anything that would make verification difficult so things like M-Store 8 or other issues with the EVM we 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 int type in the VM but then we have kind of a more complicated gas model to account for that just want to reiterate the question because you were late the question was why didn't EVM improve over time and Boris explained a couple of reasons I wanted to add a single reason which also Greg mentioned that lack of resources a lot of resources were shifted to EWASM and there weren't any resources left on EVM and at the same time the research team also shifted their focus and they weren't really interested in getting anything done in EVM so there was nobody to propose, except Greg to propose ideas and then there was nobody to execute those ideas it really had to work alone on improving the EVM so there's been some conversations even here at DevCon the past couple of days that maybe while we wait for Shasker sorry Vitalik, eternity to become a thing and be alive and reinvesting in Ethereum 1.0 or 1.5 or Ethereum next generation or whatever you want to call it could this be part of that conversation improving EVM and if so what would that look like maybe I can add one side to that I think the Ethereum 1.5 Berlin plan Ethereum no regrets Ethereum and G, all these different names refer to the same thing and there was not really about the EVM 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 stage of where the discussions are it wasn't the EVM execution time which was the bound or the reason we need to make those changes so I think we can keep them separate and that's what Greg kicked off with his EVM 1.5 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 want to I have a comment actually about why it's difficult to update the EVM and I think it's actually just because it's you start with something that's the EVM which was kind of designed ad hoc it wasn't like they took some existing VM and then made it blockchain capable and it was just designed from the start and then as the hard fork started piling on the logic behind various different parts of the VM got more complicated so the recent Constantinople hard fork the rules for storage allocation just I mean like literally tripled in length how many different cases we have to handle and it's like different depending on which fork you're on and it's a major pain so I think part of the problem with evolving the EVM is maintaining backwards compatibility so having the ability to support the new EVM execution model and the old EVM 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 can be a major barrier as well basically the backwards compatibility issue. Can that be avoided at all when you move to you as in that we still got all these 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 opcodes which really aren't they really have nothing to do with the virtual machine that I could easily as the evolution goes say okay let's pull all of that out of the VM deprecated and move it up to the environment interface because we can't the functionality is there we've got to deal with it One note on the backwards compatibility and EVM itself that promise actually was broken I believe with Spurious Dragon or Tangerine Vista whatever the coding was back like two years ago where cost gaskas were increased and before that I think it was never explicitly said that gaskast cannot be increased but a lot of contracts assumed that and once you increase the gaskast so one example in a contract Mexico to another contract previously they made like a fixed calculation in a contract in many cases and once you bumped up the cost in some cases they just failed I tried and they were done so we broke that backwards compatibility promise at that point but all the proposals since then just reduced the costs so like this S store change you mentioned that reduced the cost but I think because you broke that promise and a lot of 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 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 a contract is increased so much in cost that it kind of breaks the user experience and you know it's an important contract 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 complexity if we want to say deprecate old off codes or something like that and at that point what do you tell the owners of the contracts who use those off codes if you want to deprecate it and say we want to remove this that we can start to evolve it to something that's a little saner or a little more modular or is more compatible with other VMs who knows but there's just there's not something built into to the system that says we're going to at some point be able to say know your contract is no longer going to be able to execute on them there's a there's a 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 well it has to keep working forever it has an address it can be called okay can I just mention a strange example to this call code which which was quickly fixed by introducing a new code called delegate call just right two months after launching Ethereum because call code was supposed to do what delegate call is doing but it wasn't yet we still kept it and nothing is using it because it's useless yet we still have it the best we can do both the best we can do for any VM is when you deprecate it you have to keep supporting it in old code but if they try and put a new contract on the blockchain 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 outcodes or changing the way existing outcodes work increases the complexity of the code base because the code has to support the old fork roles the next fork roles and 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 roles and resetting resetting the genesis block at a more recent snapshot I'm not sure why so many clients and users are obsessed with being able to process all the way from the genesis block and then through all the fork rules and then currently but what do you do about contracts that have some logic about how their funding is 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 you know you start at the snapshot of a state after the fork then that client sinks starting from that snapshot and it only has to support the new fork roles at that point you call into a contract that was created before that on a previous fork its logic is broken on the new fork potentially so maybe you've locked up someone's funds or yeah so I said you can't you really can't deprecate stuff or it's really hard to you can only change things again the intel chip started out as a hand calculator and that code still runs it doesn't run very well those opcodes have actually become pretty slow and there's a good reason not to use them anymore but that hand calculator is still in there and to some extent we sit here bitching about it and it's just tough shit suck it up I want to save some time for audience questions maybe ten minutes left for that let's go ahead and do that anyone have a question or comment complaint Boris always Boris so one of the things I want us to think about is I'm starting to think about the different components of what is Ethereum just as we're maybe thinking about what is Web 3 and how much we're integrating and EAPS and other stuff like that with IPFS and so on the EVM goes beyond Ethereum public mainnet so today Microsoft released a new EVM the E EVM 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 thoughts that I'd love to hear the panel's ideas on I'd actually like to ask you a question because nobody wants to ask for Boris sorry Boris it's too hard can you clarify are you asking specifically about are we going to support the other 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 can we apply those changes that they make to our EVM as well but so maybe this is not relevant and in fact various things called EVM are going to 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 just an idea so from my perspective that's one of the main goals of EUASM 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 EUASM largely serves that goal that's all I'm saying so in EVM over the years they have been a couple of other chains using it and most of those chains have made additions to it in form self new upcodes to access data so one example I think is rootstock they had like six upcodes there were a couple of others I can't recall right now but all of these maybe 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 languages supporting EVM which at a time was religious solidity so they fork solidities to support those things and I don't really see any communication between any of these other forks or users of EVM at the moment I think we have to overcome that issue first get like a discussion flowing between the different EVM forks between like the main net in form of EIPs and as well as like the language designers compiler authors in the Ethereum space and once that is solved you can then consider how to make bigger changes and get those changes down to them but we have those channels closed for some reason so yeah so for me it's yet from my perspective it's mostly communication issue I mean it's so easy to fork and then never go back for the upstream project whatever direction the communication should go so like everyone is having like own EIP repo with EIPs like with different names even if the network has what I found out like last week there's like coven network improvement proposal something and so this information is not exchanged 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 great I personally hope like we can get EVMC in Sputnik VM Ethereum Classic I haven't checked the details what changes they have they support all of that but seems quite close to our needs so that would be interesting to try it on Ethereum network any other questions? yeah we have another one so I wanted to clarify that Microsoft EVM implementation is for SGX environment so basically the gas calculation doesn't make sense there basically they want to enable it on Azure and you can just send code and get the verified computation off-chain which is pretty interesting but I guess the gas calculation doesn't make sense there that's my question great did you have a follow up question here you did the KVM work I've had some conversations and worked with seed whoever he is there's a man who's jitter tag is seed I don't know who he actually is but we've had a lot of communication he's working on a LAM formalization forked off of UHE's formalization and we've talked a bit about where the current the current EVM gets in the way of that kind of thing and how my proposals are intended to help seed is was quite excited and contacted me it's like when did these go in they would help so much but I'm wanting as a formalist what your opinion is of how much would it help and how bad is it right now well nothing's crashing and burning it's not too bad but it's quite a pain to update KVM especially anything regarding the gas calculations because I mean you have to do things in a very specific order and 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 wasm which is most of the execution but just not the modules and EVM took I want to say I mean depending on how you count between you know 8 and 14 months and wasm was closer to the 6 month mark maybe so I think that just that alone and the wasm definition is just shorter and it's cleaner and it just makes more sense and it it just feels more coherent and it all kind of presents itself nicely together instead of feeling scatterbrained I don't know to band dynamic jumps oh to band dynamic oh that one specifically how much is that proposal oh my gosh that would help so much oh yeah like oh my gosh that is a single like when we made our own like EVM 1.5 I called it EVM prime as a kind of just a toy but I changed the EVM type of thing and that was the very first thing I did was 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 while and stuff like that and it makes static analysis tools way more effective like worlds and worlds more effective and then it makes verification efforts a lot easier as well so dynamic jumps are terrible can we hire you for what we can do one last question do we have one last two more audience questions can I have a question to Greg alright nevermind sorry audience I'm gonna be quick Greg you mentioned that at some point that EVM might be 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 would translate it to wasm 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 that's also somewhere way out in the future we don't know where it is you know and then when wasm on the main chain solid, formalized ready to go and your compiler to compile from EVM to wasm is ready to go there's not any big problem to migrate code there is no migration that's just the way that it gets executed right no one no one cares whether you compile it to wasm then compile the wasm to machine code or interpret it or compile it right to machine code that the user doesn't care about that as long as it gets executed correctly but short term we want to just get it working and a little bit longer term just a little longer term we now have a formally verified subset of C we've got I don't know is it a subset or all but LLVM has been formally verified so we can have a formally verified EVM 1.5 execution we can have specifications but I wouldn't say it's verified it's just a specification okay so as usual what we want to do is promising 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 for the different ways to do it and then we still plan to switch to does that leave us with more legacy we have to keep because all of this stuff is on the main net or is it a better position but I don't think we should answer this right now we should just think about this a bit more or did we have time for one more question from the audience a two second answer is just as wasm gets more stable you stop you cap off EVM 1 and say it's it's still on the main chain you have to support it it has to be supported forever I'm saying it can be supported with the compiler and you stop evolving it so you don't keep creating backwards compatibility so we have a next panel at some point we're going to stop there thank you guys very much thanks for listening