Panel - Evolving the EVM

[Music] so I'm Greg Colvin I work mainly on the c++ evm louder I work mainly on the c++ d BM this is my friend Martin if you want to introduce yourself hi I'm Martin busy i'm working on prototyping he was on and i also work on the new MJS and new hi I'm pavo and I'm working on small sub project called a vm it's a kind of just-in-time compiler does translates a vm byte code into machine code using llvm project hey I'm Christina like listener I'm the team leader of the c++ implementation that I'm also working on solidity which is basically the main user of the etherium virtual machine hello my name is Alex Greig sassy and I work with Martin on he wasn't as well as with Christian on solidity and I'm really interested to improve both even one and the replacement of it called he wasn't so what I wanted to do this morning is everybody got working so fast approaching the conference getting things done to talk about that I could no longer keep track of anything but my own work so I would sort of like to just hear from people what they've been doing the last few months and what direction what direction they intend have to be heading in um shall we start with Martin here so the last couple months I've been working on something called EVM tourism which takes EVM code in trance compiles it to web assembly and we are now passing all the virtual machine tests and the official test repository we also have online demo if you want to check it out know what is a transpiler oh ok it's good quick so we have two types of bytecode start out with atheneum virtual machine by code and we want to transform it to you a new type of bytecode web assembly so the chance compiler you can think in math terms as a function that map's this one input BBM to a new output what assembly and why web assembly the interesting problem ok so web assembly is a new binary format that's targeted that's designed and me targeted for the web the web browser and the interesting properties that has no ever interested in it is it's very fast and efficient it's portable it's sighs sighs efficiency so it's easy to press easy to load and it also has most importantly built in it's designed to run the website designed to run in untrusted environments and that mask so closely to what we're doing so yeah good x okay I can be next so the evm jet had Assyrian the virtual machine implementation I'm carrying off it's fully compliant with the vm from from the land of the cereal but the problem I was trying to solve from about couple of miles is how to bring this implementation to other clients so what I was working on is a new CC c language interface for film virtual machine in general what we call EV MC and it's like quite quite simple interface then you can pack your vm implementation with and bring it to two other other other projects that might be interested in so just before the conference i was able to plug a vm g to Python client it's still syncing the blockchain but I hope it can finish during this conference and yeah so it's I'm not focusing on optimizing the the execution time but mostly to bring in my project to other products so so we now have a plug-and-play interface for both the c++ execution engine and the Python execution engine yeah that's right so so the disciplines blast client and Python client I able to use the same interface for a vm g to be operational on the on the blockchain so it's still experimental but very promising that's really cool so that's that basically the idea is to have a common interface between the the client and the virtual machine and in the end be able to swap different virtual machines and we're also planning to to refactor the C++ interpreter to use exactly the same interface so you could seamlessly swap between just-in-time compiler and the interpreter and you can use the interpreter with all client implementations that support that interface very nice very nice like this [Applause] rock and roll that will be at the party later I have to go buy a guitar if anybody knows a good place what else here Alec enemy all right yeah you will you will learn about you awesome later on it will be the first presentation today after lunch and I invite everyone to listen to it because if you'll be very interesting but i can tell you up front a few details which connects to this panel that mostly we have been working on and two different things first of all as Martinez mentioned and was him is a different bytecode so we need multiple languages to compile code to this bytecode because you don't want to write byte code by hand and secondly you want to run this bite good on something and on the language side we have been working on getting C and solidity ready and we have written a lot of contracts in these languages all ready for wasn't and on the vm side actually be really grateful to have all and his work on EV MC because we have implemented vm on EV MC and that means he wasn't can be used with syllabus athyrium without any major changes Thank You papa why would you want to write contracts and see you don't really want to write contracts as an end user in C but there are certain contracts which probably makes sense to be written in C and I don't you want to go into a lot of detail you will see a bit more in the presentation and but just think about the precompiler you already have and the for pecan pies like sha-256 ripe em 360 and easy recovery you want this to be written in a highly efficient way and those should be included by all the VMS and you don't really want to f them as a pre-compiled anymore in the future so those are written in C right now and they are limited set off of code which you can much easily verify I wouldn't advise anyone to write like a really complex contract and see unless they know what they're doing solidity is hard enough it turns out yeah I mean the thing is also that that a lot of code already exists in see especially cryptographic libraries they already in see they have been tested they are working and if we can just take them without modification that's great the advance of crypto code is written in C and well long since well tested that's the Assumption fits the assumption that they well tested [Laughter] it's not always a good assumption when when people complain about solidity being too hard though I I point out that most of the world's most reliable software has been engineered in see most of your paychecks probably are come out of an oracle system which was written in C so that it in the end it comes down to engineering discipline more than anything so I really think the GVMC interfaces is really a powerful idea that's going to help us quite a lot in pulling together the different work they are providing the diversity we've talked about without ball speak up Fred without vulcanizing the work we can have a diverse number of implementations of etherium without them being in separate silos that can't run together they can't talk to each other so I think you can even do more about that like having multiple implementations of vm itself you can build a quite complex structure of that I mean you can decide up front which implementation you want to use for this particular code or just select the randomly to avoid any any crashes how's that you can implement like some kind of vm that actually composites other vm and behind it so is it going to be part of the vmc interface or the higher level that you do things like start out with an interpreter no you can use the same interface for higher level like you can write a vm that compose other VMS but still X exports the same interface vmc no I mean by typically you start out running an interpreter you notice the hot spots you had pad you hand those up to a jit for faster execution you may do the compilation on a separate thread because it could take a while yeah it's that part of the interface or will that be a lot it's all possible with with this vmc interface okay so basically the interface only defines the entry points and the way the VMS can ask for data from the block chain and that's very generic and it only gives you the bare minimum you need and because of that you can compose and multiple levels if you wanted so the composition would be at another level if we wanted to we could abstract that but we haven't yet now it works on the same I works on the same level as basically you just get in the the contract to execute and then you can initially run it as an interpreter if you wanted and you can change it over right all right so what's the what's the timing on this I'm always asking that's always fuzzy and changing yeah so for web assembly pacifically it depends on the wc3 working group but as it stands now it's implemented in all the major browsers and it's on the twelfth refreshing prototype so I think it's getting pretty close I would expect it in 2017 to finalize the spec after that then we can move on to finalizing our eat as we stand with a prototype we we have most the major components implemented next big thing we're going to be pushing out as a test Network once again brought to to us by facilitated by a PMC since we can just drop the wazoo the woz some chitter interpreter into all the other clients yeah so that's pretty cool it's great fun if we used up our 20 minutes yet you have six minutes left six whole minutes and I have a question um I cannot see anything but the most blinding white lights I've ever seen in my life did you want to let you know about security Christian so the the original EVM was designed from the ground up to have fixed bounds on resource consumption and these bounds should coincide with the gas usage what do we know about existing he wasn't implementations in that regard okay Oh so regarding security in the virtual machine I think like the number one biggest security issue though is the trusted computing base and that's continually expanding with every precompiled that we add so the point of web assembly from a security perspective and it is when Katie's perspective is to minimize the overall trusted computing base now security from the metering perspective is done by VM tourism or sorry it's done by metering injection so we can do static analysis on the code to find it's very well delineated in web assembly flow control so it's easy to do static analysis on the flow control and inject metering statements at the beginning of each branch possible branch condition that will meet her in the same applies to memory usage so it provides a so the the gas model and the memory model as far as metering is going to work the same way with at a benefit that it's decoupled from the evm by default so it's not we have a nice separation of concerns and I think that also provides extra security because we can think about these two components separately now we can think about okay here is our metering injection algorithm right we can examine that and then we have a separate team or separate module all together examining and looking at our trusted computing base which would be the awesome TN so two bolts there minimizing the trusted computing base that I think is the biggest lowest hanging fruit most bang for the buck right as far as increasing security in our network but do we know whether the I mean so for example memory will probably be paid with regard to the the memory of the virtual memory of the virtual machine and not with regards to the memory of the actual physical implementation I mean it's easy for memory because it probably won't scale quadratically but there could be some other edge cases that yeah could hurt us at some point so yeah the memory is very explicitly allocated with web assembly you use expand memory and there's initial memory allocations that the program declares up front in the binary format okay we're starting with this amount of memory here's what we're going to have in memory so it's actually kind of like a elf format if you're familiar about how you know l format initializes programs and then whenever you need more memory there's not good expand memory so it's very clear where all the memory expansions can happen and yeah that's what we injector me drink just like finesse break up code okay like the S break in all UNIX I'm not familiar with that yeah II have to tell me about that it is similar to it ok guess BRK yeah just a quick note on on the metering part and so it's entirely decoupled from the execution time and we have the input byte code which doesn't have metering because we don't trust the input compilers so anyone who compiles it wasn't we don't really want to trust them to include metering in a correct way and so when it gets to the execution time we will inject these metering statements into the right places in the bytecode and during runtime there's no need to do anything special all those metering statements are just calls to a specific function and so this kinda works like how and it jet works and like de la vm jet we have four EVM but we do this upfront before execution so it should be much faster and another interesting point great so you were thinking about like doing the metering in another thread correct great yeah I don't think that's going to work so will it work but I don't think it's going to be any faster now ok and that is it would save time on the very most expensive instructions which cost enough that it's not worth saving time and on long runs of just doing addition and multiplication and arithmetic you're not going to save enough to bother especially if you're going to push all of that to the end of the basic block but like doing a call cost enough that's saving a bit of time doing the need ring on the call I was just going to say like we sorta can do that now it's a little bit hackneyed but we sort of get get the separation concerns to free because like whenever we call out to the interface to do the metering that's going to be possibly running on a separate thread so but I don't know how much that's improving our performance either so ouchy for your stretch right now we're using the eight to prototype so we get 8 threads by default and they're allocated when it starts up so they're fairly cheap very cheap actually thanks guy thank you very much thank you all thank you very much thank you [Applause] [Music]