The EVM: Leaner, Meaner, and Closer to the Metal

[Music] I'm Greg Colvin I spend my time for aetherium working on the virtual machine working on improving its performance and working on designs for possible successors to what we have in order to solve some of the performance problems that were running into if this works there will be another slide how about that the first problem you run into an any sort of optimization work according to my old friend Jerry Schwartz is one all benchmarks are bogus you'll never have a set of benchmarks it actually represents the real world but if you don't have benchmarks you will just go in circles you'll you'll never make progress so the benchmarks I'm working with are a few algorithm kernels that are relevant to what we're doing RC 5s and old and useless cipher but it's a good example of a cipher that uses a lot of 32 and 64-bit arithmetic a lot of complex logic and Blake to be is still an important hash function it's also a lot of 64-bit logic blum blum Schaub is a cryptographic rant random number generator I think it's one of the slowest in the world it operates on big registers so we could use the 256 bit registers of the VM effectively an DC mall also can use big registers effectively and then I have a few tests of act individual EVM operations and those are small EVM assembly programs to try to isolate individual opera ratios and this is a graph of what I got with the whole thing and it's a bit complex but what you can see down along the bottom is the different benchmarks and along the right are the first three are some major clients EVM is our go client parity is Russ client EVM is the C++ client the rest aren't clients yet but EVM to wasm is part of the Azzam research it's a program that takes EVM code translates it into Azzam code and then I fed that to Google's v8 engine which generates assembly code EVM JIT Pavel was just talking about it generates assembly code directly from EVM code and then the native C++ is I rewrote the benchmark programs in C++ instead of solidity or EVM assembly and compile those to assembly so pretty clearly the C++ wins the race and pretty clearly exponentiation is pretty hard for everybody which isn't surprising but it's a little concerning there there might actually be possible exploits by writing contracts that do exponentiation and get charged only a few gasps but take a whole lot of time and rc5 looks pretty hard because rc5 works on dynamic shifting and EVM does not yet have a shift operator and so it gets imitated with exponentiation and in between things are relatively regular and the speed you could actually predict by the language that the client is written in oh where did that come from the next slide I can't see the screen these glasses on so to simplify it this is looking at one angle it's a harmonic being of the performance of each client yeah and it shows pretty much the same thing so clearly the interpreters are not as fast as as going straight to machine code by any route yeah and clearly some interpreters are better than others but they've all been good enough so far for our purposes and of course I love car races as examples last year somebody in the audience shouted out that instead of used in classic cars burning tons of gasoline I should be using Tesla and Tesla's are nice it's George Hallam here are you here George George would agree that rather than a Tesla this would be much cooler this is a 68 Mustang hatchback under the hood is actually some powerful electric motors and the trunk is full of lithium-ion batteries and if this works where's the button we will see how this does against the Tesla is ready sound just no such luck but there goes the Mustang Tesla doesn't have a chance it did just missing but after a quarter-mile it had gotten to 140 miles an hour that's a lot so what what keeps those interpreters from reaching native speed and the first answer is their interpreters so they've got that overhead you can work hard you can reduce the overhead but generally you can't do better than about three three or four to one compared to native code um for our particular interpreter the 256 bit registers slowed us down because real hardware has you know 32 64 bit registers and the unconstrained control flow hurts us a lot and I'll get to that the 256 Hertz if you remember you know grade school math adding multiplying you know two numbers is pretty easy you can do it in your head if you have you know four numbers suddenly it gets a lot harder and it's quadratic so it gets worse and worse 256 squared there's a lot control flow the jump operator an EVM I mean you know go twos are considered harmful but at least you know if you say go to label it will go to one in exactly one label in the EVM you say go to whatever's on the stack so there's no way of knowing often statically where it's going to go so you could have a nice little program like this and F calls G and H and returns and it calls AI and returns etc nice clean structure no trouble no trouble to understand static analysis anything no trouble what's it actually looked like to the EVM that's what it looks like to the EVM so if you're trying to do formal analysis if you're trying to write a compiler if you're trying to do anything with it again the number of paths goes up quadratically and you're in trouble because pretty much if you can't do it in linear time or at least n log n time on the blockchain you know that deployment time or at runtime you can't do it so how do we do better well EVM JIT is already doing better I won't back up but if you look at the slide the EVM JIT is actually pretty close to the native speed you know it does very well on the wide arithmetic and not so well uh narrow arithmetic and complex logic but it's a very good chip I've told Pavel he gets to be the electric Fox he's tired of these little you know three and four letter names that don't mean anything this is a racing team out of Latvia that's a completely electric dragster and here it is winning the European world record there it goes drag races are fast it's not impressive is it it's over hello 275 miles an hour just a few seconds love these things so we've got we've got two research programs who'd have been going on how to improve things they've been nicknamed EVM 1.5 and EVM 2.0 which doesn't really mean anything except those are the nicknames yeah and for 1.5 that's that's a suggestion to extend the current EVM by adding adding new op codes and requirements so we forbid those unconstrained jumps you just we will not allow you to do that and we we then have to provide a way to do the things that you otherwise do with those jumps so there's up there's up codes for subroutines and then we've got to get away from having nothing but 256 bit registers so we've got up codes for native scalars and op codes for sim D because real hardware has all this silicon devoted to sim d registers and if you go to google and type sim D crypto you get a lot of results so it would be useful to make that hardware available and at deployment time there's a validation phase that goes through the code and make sure that it actually does follow the rules what a concept and then 2.0 [Music] well gee it provides opcodes first got your control flow you know it's stricter than 1.

5 it actually looks like a high-level language with if-else and such and it provides opcodes for native scalars it's Cindy provoke the Cindy's coming later but there's a Cindy proposal and it also has a validation phase where it validates control flow and stack discipline and type safety so they're they're very similar at that at that level so we've got some technically very very similar proposals um they both provide for for very fast compilations a native code it could be done as the JIT yeah we've come to realize etherium cannot do jets there they are actually exploitable that is if you find or write a contract which takes a long time to compile with the JIT but requires very little gas to run and you start hammering those contracts you can you can do a really nice you know do s attack so if you're going to do any compiling you've got to do it up front at deployment time and Marvin's notion of transpilers I think is very important here um 1.5 could be transpiled to 2.0 yeah 2.0 can be transpiled to 1.5 1.

5 or 2.0 can be transpiled to 1.0 either of them can be transferred to the JVM you can make up new ones pretty much you know you can compile any VM you wanted to some other VM and he also has a notion of gas injection so you put little pieces of code into the right places to count the gas and what this means to me is it doesn't matter what execution engine a client chooses because on the blockchain you can put a contract that translates into that execution engine so these are these can be completely independent choices and we could actually choose to support a number of VMS if we wanted to and independent parties could decide to support a different VM but a transpiler on the blockchain and away they go gee I'm almost out of slides and there's no sound that's really too bad so what what is the big deal about native performance and what's the big deal about being lean and mean and close to the metal well we saw the electric dragsters here's like a real top fuel dragster they run on a mixture of diesel fuel and nitro methane and just about a month and a half ago not too far from Ming's place in Michigan this guy got the world record and it's over 338 miles per hour and a quarter mile these guys pull about 5 or 6 G's which is about the same as an astronaut taking off in the space shuttle but there's a problem with going fully native in the save world we call it undefined behavior hello no that's the less come here okay play play there it goes what's going on my screen we'll try it again dudu the driver actually walked away unscratched I love this guy we'll give you one more and it turns out I'm done so I knew it audiences love explosions [Music]