 Hey everybody, I'm Casey and I asked to moderate this panel because I've been working on EVM and E wasm lately and I know there were there are no other experts besides these panelists So You saw Martin's talk yesterday And well it was on primea, but it mentioned the precursor to primea, which is E wasm and that started in December 2015 By The summer of 2016 the first commit was in April, but by the summer there was a pretty working prototype for the EVM to E wasm transpiler. So that was the EVM 2.0 So after the 2.0 proposal came the 1.5 proposal from Greg and and Pavel and you just saw Pavel's talk earlier about EVMC, which is sort of the the API to plug in and be able to swap between E wasm and and EVM 1.5 And Then came Earlier this year was Julia Yesterday also we saw Alex Alex's talk about Julia Which he and Christian designed To upgrade solidity and be able to make solidity target The EVM 2.0 the next versions of the EVM 2.0 and 1.5 and then since then Also Pavel has made a lot of progress on the the JIT 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 think I'll Ask our panelists what is What is E wasm what is EVM 1.5? I guess E wasm 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 C++ contracts and E wasm 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 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 to bring it up to modern standards and make good use of modern hardware and 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 E wasm proposal So they're sitting there and we'll need to make some choices and We might throw both of them away and say, okay, 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 into code. Yeah, that runs better and Pablo 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 we can do much better in JIT 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 WebAssembly was not finalized at all, right? And there was no knowledge at least we didn't have any knowledge when it's going to be finalized There's no idea and since then this year the first version came out So that problem went away And you know like back a year ago We had no idea when it's going to be finalized and how it's going to look like when it's finalized And so that 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 backup plan Assuming that EVM 2.0 would be finished in time But we cannot release it because the WebAssembly isn't finished And then if you could finish even 1.5 quickly enough it could be a good bridge between the two But that problem went away today. Well, you know the earlier this year. So how do you feel about the? brokenness of EVM since Did did anything change? I? Actually think you want I think he was I'm going to die What 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 going to die. Yes Wasm's going to die whatever I said, I don't know That's a bold prediction, but maybe 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 because One example is the Blake to be pre-compile there's a proposal for these native pre-compiles and pre-compile 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 six million gas So how does? EVM 1.5 or our WebAssembly solve this problem Well, WebAssembly allows you would allow you to can just compile code Directly to WebAssembly so you most likely don't need native Native contracts because you would just write them in WebAssembly. Yes, 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 in hand-coded assembly You know, we just can't get enough speed out of the VM for these pre-compiles But then how is 1.5 and in 2.0? How are those? becoming faster than Then 1.0. I can 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 issue we 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's makes them if you like to implement them in pure smart contracts that make them 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 hash function in in C and web assembly at least you have comparable for them and not having like times 10 10 to 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 pre-compines 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 a pre-compine and And that are bigger issue which Greg mentioned several times already is the bit with everything is 256 bit And there was a proposal even before the 1.5 to have 64-bit arithmetics in EVM You have folded that into the same the proposal as I see it there But if if we if we just look at these two problems that it's quite wide for arithmetics and we have we started to introduce all these pre-compines just to get around that that Probably shows that we didn't figure out the prices properly and with web assembly as Pavel 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 pre-compines It's worse than 10 to 100 my graph was scaled by square root and the slowest Exponential operation compared to the fastest native code was 10,000 to one But that was on EVM to wasm, right? Actually, it was actually go versus C plus plus compiled straight to assembly so another advantage of another motivation for the you wasm proposal was be able to write contracts in other languages that Target web assembly as a as a compilation target versus only targeting EVM so We have the the EVM to E wasm transpiler as a prototype We don't yet have the E wasm to EVM transpiler so the reverse Which would Make the EVM 1.5 proposal equivalent to almost the E wasm proposal Because then you could still Write languages write the contracts in languages that target web assembly transpile those to EVM 1.5 I've asked before How we what would it take to write the EVM the E wasm to EVM 1.5 transpiler and Greg said it would be easy Martin said good luck Yeah, good luck. You told me it would be easy. It's not impossible. I wouldn't would never say it's impossible You said it would be easy Easy It's gonna be some work. It was on a fire escape in Berlin Was I sober I don't know 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 JIT compiled VM and then and then you know Pavel wrote a prototype of a EVM JIT VM is Was that easy Pavel so actually the prototype of that it's still a prototype it was it was It was done even before the launch of Ethereum. It was one of the Performance benchmark project that we want to 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's 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 this control flow restrictions and subroutine support Directly in the in the EVM bytecode That would allow even more optimizations and but on the other hand like JIT compiles are hard I mean the 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 education 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 a fixed upper bound In terms of resource consumptions and this is a very important guarantee that we need in order to do to do 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 runtime 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 I mean 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 bit a bit different issue. So in in in Ethereum we actually care about the worst worst cases because this is what what's 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 we care is to have the the worst case covered So, yeah, that would be much more much more difficult to control that within the JIT because it's like you have the big at least in the in the In the in the in the EVM JIT that depends on LLVM you have a big Bucket library that that's that for you and it's really hard to tell what it's actually doing But yeah, I guess there are different approaches to that and for example He was him has some JIT prototypes that are not depending on on the on LLVM You know, of course one of my bigger concerns is not technical either of these Either of these programs technically does the job. I'm much more concerned About who controls the specification and I I really believe That the Ethereum community should completely control that specification that the web browser space Is not the Ethereum space and I would not want to get wedged with the With the wasm group moving in a 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 am 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 or 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 By code right is exact same concern we have in the blockchain space Actually, I agree and and furthermore like It's an open. It's a It's open to participation. You can go to the WebAssembly community meetings you can voice your opinions you can submit proposals on GitHub It's very open and you know, it's easy it's easy to get involved That and within the blockchain space, I know of at least three other blockchain projects outside of the Ethereum that are already prototyping and actively have Wasm running In in their systems, so we're seeing a lot of momentum. I think pick up around it And I think that's sort of just Going to be the way it is because like once there is We start to have consensus around a VM everyone's just going to be the obvious choice Everyone's going to use it and it's going to be a recursive feedback loop, right? It's going to be a feedback loop where Since there's more people using it. We're going to get better tooling for it faster. We're going to get better implementations Etc. But it's not like Hypothetically if you introduce EVM 2.0 It's not like that a Vasem would introduce a new update and that magically would work on Ethereum As you mentioned in your talk both 1.5 and 2.0 have a verification code Which has to run prior deploying the contract and that verification code verifies the You know according to the E-Vasem specification, which is the current list of op codes in WebAssembly And so if they introduce new op codes, they wouldn't work without us making this Decision that we want to support them and so I don't really see that as a risk that we would be exposed to random new instructions being supported by Ethereum without our review first Now I'm more concerned So we come along and there's an issue with Vasem I mean bug bug 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 You know 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 that a committee and they go no we don't like the way you fixed it We're gonna do a different fix 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 wasm. I succeeded, but it wasn't easy And then 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 Yeah, that should be pretty easy. I mean if you don't use floating point inside The compiler can decide that it's going to use the floating point unit just because it feels like it Unfortunately, we're out of time. So we'll have to keep that's fine. Good loading points What about Julia Sorry, what about Julia? Julia, I think Christian you're gonna cover Julia a little bit in the flexibility Solidity talk Not too much. I mean Alex talked about it in quite big details Yeah, well, it's a very active debate Even 1.5 verse E wasm. Hopefully we can do the magic of Transpillation Come to a united front and move forward with the evolution of the with evolving the EVM Thank you