Panel: Evolving the EVM

[Music] say everybody I'm chasing out for a half and I asked to moderate this panel because I've been working on EBM and he was him lately and I know there were there are no other experts besides these panelists so he saw Martin's talk yesterday and well it was on Crimea but it mentioned the precursor to premier which is he was ohm and that started in December 2015 by the summer of 2016 the first comment was in April but by the summer there was a pretty working prototype for the EVM to ewaz 'm transpiler then so that was the EVM 2.0 so after the 2.0 proposal came the 1.5 proposal from Greg and Pavel and you just saw hobbles talked earlier about EVM C which is sort of the the API to plug in and be able to swap between awasum and an EVM 1.5 and then came earlier this year was Julia yesterday also saw Alex Alex's talk about Julia which he and Christian designed to upgrade solidity and be able to make solidity target the EBM 2.

0 the next versions of the EBM 2.0 and 1.5 and then and since then also pavel has made a lot of progress on the the jet vm so it's sort of been backwards where first EVM 2.0 was proposed then more progress on EVM 1.5 I hope this makes some sense so I I think I'll ask our panelists what is what is he was and what is bbm 1.

5 what I arrived I guess he was him had made some progress substantial and a few things struck me one is people were sort of excited because gee whiz you could you could run you know C++ contracts and he was them and as a C++ expert I said why on earth would you want to write contracts and C++ haven't haven't people lost enough money on the blockchain already and the other thing that struck me was why on earth would you want to hand over to an outside committee the definition of anything to do with the core consensus protocol and I looked at Eve you know the current EVM and said there's an awful lot of white space for more op codes and this thing's not broken it just it needs a little work so I set out to say what what do we need to do to this to bring it up to modern standards and make good use of modern hardware and so I got to work on that and I got a lot of help from other people on the C++ team the documentation would not have happened without Christian and so the team put a fair amount of work into that we've got a couple of the IPS Martin has put a lot of work into the EU Azzam proposal so they're sitting there and we'll need to make some choices and we might throw both of them away and say oK we've learned a lot what should we actually do we might choose one of them we might stick with what we have and ask and we advance our compiler technology to compile what we have in to code yeah that runs better and Pavel can speak better to how possible that actually is yeah I would be very happy to have any of these but to add it more constrained to the control flow would help a lot there and I believe who can do much better in grid-like EVMS if you have that but you know just a step back so last year when you came around and even 1.5 came around it was still in a point of time where web assembly was not finalized at all right and there was no knowledge at least we didn't have any knowledge when it's gonna be finalized and since then this year the first version came out so that problem went away and you know like Beck a year ago we had no idea when it's gonna be finalized and how it's gonna look like when it's finalized and so there was a big concern and I think because of that even 1.5 made a lot of sense to maybe bridge the gap or have like a you know back-up plan assuming that EVM 2.0 would be finished in time but we cannot release it because the web assembly isn't finished and then if he could finish even 1.5 quickly enough it could be a good bridge between the two but that problem went away today you know the earlier this year so how do you feel about the brokenness of evm since did did anything change I actually I think he wasn't gonna die why do you think that because there's been so many attempts to get a binary format running in browsers and they've all failed you're saying webassembly is gonna die no one's gonna die whatever I said that's a bold prediction but we can step back and say what are the problems with the current evm 1.

0 I mean one problem is that the gas limit in each block is not enough to do everything people would like to deploy contracts to do is one example is the Blake to be pre-compile there's a proposal for these native pre compiles and pre-compiled solve the problem of contracts that people would like to deploy but they might take you know a hundred million gas when the current block limit is the current block gas limit is 6 million gas so how does EBM 1.5 or or webassembly solve this problem well of assembly allows you would allow you to can just compile code directly to web assembly so you most likely don't need native native contracts because you would just write them and whip assembly but it's partly just that it's too slow you know I mean pavel was working i remember on one of the pre compiles that you were like pushing all the compiler flags as far as you could and trolling through multi precision libraries to find one that was mostly an hand-coded assembly you know we just can't get enough speed out of the VM for these free compiles but then how is 1.5 in in 2.0 how are those coming faster than then 1.0 i'm just like my little grade school example you do a multiply and you're doing one instruction on a 64-bit pair of registers as opposed to you know long division or long multiplication on a you know collection of registers I think that the current if you have is quite big difference in terms of speed comparing to native code so we we cannot actually effectively encode the algorithm we want there for example some hash functions and and that makes them if if you like to implement them in pure smart contracts that make quite expensive and you have to pay for that you have to pay a lot for that because it's just the current EVM is not capable of Express enough to have comparable speed comparing to native code and I believe that's what for example web assembly gives like it's it's at least comparable like if you implement the same heart function in in C and web assembly at least you have compare both of them and not having like times time ten to two 100 times slower performance but actually if you if you take a step back to like the first version of EVM and look at why do we have or why did we had an identity contract just for achieve memory copying that maybe shows that we didn't had everything thought through properly and we started to introduce these pecan pies especially the one for copying memory that means loading and storing memory was too expensive yet we still wanted to do it so we introduced the pecan pie and another bigger issue which Craig mentioned several times already is the bit with everything is 2056 bit and there was a proposal even before the 1.

5 to have 64-bit arithmetic syn EVM and you have folded that into the same D proposal as I still there and but if if we if we just look at these two problems that it's quite wide for arithmetic and we have we started to introduce all these pecan pies just to get around that that probably shows that we didn't figure out the prices properly and which webassembly espousal said it's resembles the instructions much more closer to traditional computers so there's a much probably much easier way to figure out what the real cost for those instructions are and by figuring out the real cost and we can probably avoid having pecan pies it's worse than 10 to 100 but my graph was scaled by square root and the slowest exponential operation compared to the fastest native code was ten thousand to one but that was on EVM to blossom right axe it was actually go versus C++ compiled straight to assembly so another advantage of another motivation for the USM proposal was to be able to break contracts in other languages that target web assembly as a as a compilation target versus only targeting EVM so we have the the EVM - II was ohm transpiler as a prototype we don't yet have the e wasum - EVM transpiler so the reverse which would make the evm 1.5 proposal equivalent to almost the II wasn't proposal just then you could still write languages write the contracts in languages that target webassembly transpile those two EBM 1.5 have asked before how we what would it take to write the EVM the II was him to EVM 1.5 transpiler and Gregg said it would be easy Martin said good luck good luck at all me with it's not impossible I wouldn't and would never say it's impossible you said it's gonna be somewhere it was a fire escape in Berlin I mean was I sober and also one of the motivations for just skipping EVM 1.5 and just and because the original proposal was just going straight to 2.

0 the EVM 1.5 proposal came later and one of those reasons was because well it must be hard to write a JIT a compiled VM and then and then you know Powell wrote a prototype of a PBM JIT vm is what was that easy problem so actually the prototype of that it's still a prototype it was it was it was done even before the launch of a material it was one of the performance benchmark project that we want to have to actually assess what can we do in the future in terms of smart contract performance but yeah it's it's it still struggles with some some cases and as I said we can do much better in this case but and the required step is it's at least discount referral restrictions and subroutine support directly in the in the EVM byte code that would allow even more optimizations and on the other hand like JIT compilers are hard I mean the the network consensus depend on that and like the risk is like we might might get hard or it might be never finished in terms of removing bugs and finding educators because that's that's much more complex construct comparing to interpreter I mean another problem with with just-in-time compilers is that I'm not sure if there is a just-in-time compiler that provides a fixed upper bound in terms of resource consumption and this is a very important guarantee that we need in order to do to do the the gas calculations properly right I mean usually just-in-time compilers generate code that is faster and takes less resources but we don't have a guarantee or do we well as I said we can't do a JIT it's it's exploitable we have to it has to be a compiler that runs at deployment time not at run time which means it can be a full compiler depending on how long we want to take to load a block then my understanding is storage is the main constraint there anyway but me I remember in my testing I came up with one performance bottleneck and you said it's not a priority I don't think I can get to it and the next day you had it fixed yeah this is a bit different issues of immaterial weak actually care about the worst worst cases because this is what what the cost must be for and and so this affects more complex optimizations but also the big big integer libraries that actually try to squeeze the easy cases first but this is not what what we point to like we don't care if we can divide quickly for small numbers because what weaker is to have the worst case covered so yeah that would be much more much more difficult to control that within the drift because it's like you have the big at least in the in the in the in the in the EVM rate that depends on LLVM you have a big bucket library that does that for you and it's really hard to tell what it's actually doing but yeah I guess they are different approaches to that and for example it was and has some JIT prototypes that are not depending on of course one of my bigger concerns is not technical theater of these either of these programs technically does the job I'm much more concerned about who controls to specification and I really believe the the etherium community should completely control that specification that the web browser space is not the etherium space and i would not want to get wet with the with the wasm group moving in the direction they need to move and us shaking our heads and going no we don't want to go in that direction yeah I disagree with that because I think I a much rather it's much more pluralistic to go with a larger community a larger body of people standardizing and coming to consensus on a virtual machine instead of just using a virtual machine that can only be was created to only be used in one Pacific use case and if you look at the browser use case is very similar to the blockchain use case we need secure portable and size efficient byte code right exact same concern we have in the blockchain space I agree and and furthermore like it's an open it's a it's open to participation you can go to the web assembly community meetings you can voice your opinions you can submit proposals on github it's very open and in you know it's easy it's easy to get involved that and within the blockchain space I know of least three other blockchain projects outside of aetherium that are already prototyping and actively have wasum running in in their systems so we're seeing a lot of momentum I think pick up around it in I think that's sort of just going to be the way it is because it's like once there is the we start to have consensus around VM everyone is gonna be the obvious choice everyone's going to use it and it's going to be a recursive feedback loop right it's gonna be a feedback loop where since there's more people using it we're going to get better tooling for it faster we're gonna get better implementation etc but it's not like hypothetically if intra-syrian 2.0 it's not like that vasin would introduce a new update and that magically would work on a theory 'm as you mentioned in your talk both 1.5 and 2.0 have a verification code which has to run prior or deploying the contract and that verification code verifies the you know according to the awasum specification which is the current list of op codes in web assembling and so if they introduce new codes they wouldn't work without us making this decision that we want to support them so I don't really see that as a risk that we would be exposed to random new instructions being supported by a Tyrian Baudette our review first I'm more concerned so we come along and there's an issue with wazzle I mean bugs bugs show up in specs or if not a bug an ambiguity and we resolve it one way and it works for us and we can't wait yeah we if something's a little weird in a browser it's not a big deal and the committee will get around to it but if there's anything that breaks consensus we have to fix it immediately and then eventually it gets around the committee and they go no we don't like the way you fixed it we're gonna do a different fix yeah and I just feel like over time we will wind up forking away from that standard and we will lose these benefits of shared design and tooling anyway in fact we're a fork to begin with we're a subset so I I mean I spent a couple weeks trying to get C++ into Azzam I succeeded but it wasn't easy and that I think that's misleading it's a subset but the only subset being with the we don't let floating-point operators yeah that's the only subset but you have to convince the compiler not to do that yet it should be pretty easy I mean if you don't use floating point inside the compiler can decide that it's gonna use the floating point unit just because it feels like it fortunately we're out of time so we'll have to kiss bye good floating points versus what about Julia sorry what about Julia I think Christian you're gonna cover Julia a little bit in the flexibility of solidity talk not too much I mean Alex talked about it in quite detail so well it's a very active debate even went up five versi was um hopefully we can do the magic of translation come to a united front and move forward with the evolution of the with evolving the EBM thank you [Applause] what do we do with them [Music]