 on the C++ EVM. Louder! I work mainly on the C++ EVM. This is my friend Martin if you want to introduce yourself. Hi, I'm Martin Busy. I'm working on prototyping Iwozum and I also work on Ethereum JS. Hi, I'm Paweł and I'm working on a small sub-project called EVMJIT. It's a kind of just-in-time compiler that translates EVM bytecode into machine code using LLVM project. Hey, I'm Christian Reitwiesner. I'm the team leader of the C++ implementation and I'm also working on Solidity, which is basically the main user of the Ethereum Virtual Machine. Hello, my name is Alex Brexassi and I work with Martin on Iwozum as well as with Christian on Solidity and I'm really interested to improve both EVM1 and the replacement of it called Iwozum. 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 they intend for that to be heading in. Shall we start with Martin? Sure. So, the last couple months I've been working on something called EVM to Iwozum, which takes EVM code in trans compiles to WebAssembly. And we are now passing all the virtual machine tests and the official test repository. And we also have an online demo if you want to check it out. What is a transpiler? Oh, it's good. So, we have two types of bytecode. We start out with Ethereum virtual machine bytecode and we want to transform it to a new type of bytecode, WebAssembly. So, the trans compiler you can think in math terms as a function that maps this one input, EVM, to a new output, WebAssembly. WebAssembly is a new binary format that's designed and metargeted for the web browser. And the interesting properties that it has and we're interested in it is it's very fast and efficient, it's portable, it's size efficiency, so it's easy to press, easy to load. And it also has most importantly built in, it's designed to run the web, so designed to run in entrusted environments. And that maps closely to what we're doing. So, yeah. All right. Who next? I can be next. So, the EVM JIT that Ethereum virtual machine implementation, I'm carrying off, it's fully compliant with the EVM from the launch of the Ethereum. But the problem I was trying to solve for about couple of months is how to bring this implementation to other clients. So, what I was working on is a new C language interface for Ethereum virtual machine in general, what we call EVMC. And it's like quite simple C interface and you can pack your VM implementation with and bring it to other projects that might be interested in. So, just before the conference I was able to pack EVM JIT 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 execution time but mostly to bringing my project to other projects. 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, the C++ client and Python client are able to use the same interface for EVM JIT to be operational on the blockchain. So, it's still experimental but very promising. That's really cool. So, that's basically the idea is to have a common interface between the client and the virtual machine and in the end be able to swap different virtual machines and we're also planning 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. Like this. 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? Alex. Is it me? All right. Yeah, you will learn about EUASM later on. It will be the first presentation today after lunch and I invite everyone to listen to it because it will be very interesting but I can tell you upfront a few details which connects to this panel that mostly we have been working on two different things. First of all, as Martin has mentioned, EUASM is a different byte code. So, we need multiple languages to compile code to this byte code because you don't want to write byte code by hand. And secondly, you want to run this byte code 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 already for EUASM. And on the VM side, actually, we are really grateful to Pavel and his work on EVMC because we have implemented a VM on EVMC and that means EUASM can be used with C-Plypso's Ethereum without any major changes. Thank you, Pavel. Why would you want to write contracts in C? You don't really want to write contracts as an end user in C but there are certain contracts which probably make sense to be written in C. And I don't really want to go into a lot of detail. You will see a bit more in the presentation. But just think about the pre-compice we already have, the four pre-compice like SHA256, RIPE MD-160 and EC Recovery. You want those to be written in a highly efficient way and those should be included by all the VMs and you don't really want to have them as a pre-compile anymore in the future. So those are written in C right now and they are a limited set of code which you can much easily verify. I wouldn't advise anyone to write a really complex contract in C unless they know what they're doing. Solidity is hard enough, it turns out. The thing is also that a lot of code already exists in C, especially cryptographic libraries. They are already in C, 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, that's the assumption that they have all tested. It's not always a good assumption. When people complain about solidity being too hard though, I point out that most of the world's most reliable software has been engineered in C. Most of your paychecks probably come out of an Oracle system which was written in C so that in the end it comes down to engineering discipline more than anything. I really think the EVMC interface is really a powerful idea that's going to help us quite a lot in pulling together the different work, providing the diversity we've talked about without... Speak up, Greg. While organizing the work, we can have a diverse number of implementations of Ethereum without them being in separate silos that can't run together, that can't talk to each other. So I think you can even do more about that, like having multiple implementations so VM itself, you can build quite complex structures of that. You can decide upfront which implementation you want to use for this particular code or just select them randomly to avoid any crashes. How's that? You can implement some kind of VM that actually composites other VM behind it. So is it going to be part of the EVMC 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. You can write a VM that composes other VMs but still exports the same interface, EVMC. No, I mean, like typically you start out running an interpreter, you notice the hotspots, you hand those off to a JIT for faster execution, you may do the compilation on a separate thread because it could take a while. Is that part of the interface or will that be a level up? It's all possible with this EVMC interface. So basically the interface only defines the entry points and the way the VMs can ask for data from the blockchain and that's very generic and it only gives you the bare minimum you need and because of that you can compose multiple levels if you want it. So the composition would be that or not your level. If we wanted to we could abstract that but we haven't yet. No, it works on the same. It works on the same level because basically you just get in the contract to execute and then you can initially run it as an interpreter if you wanted and you can change it over. Right, great. So what's the timing on this? I'm always asking and it's always fuzzy and changing. Yeah, so for WebAssembly specifically 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 12th revision. 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 EAP. As we stand with the prototype we have most of the major components implemented. Next big thing we're going to be pushing out is the test network. Once again brought to us by, facilitated by EVMC since we can just drop the WASM JIT interpreter into all the other clients. Yeah, so that's pretty cool. That's great fun. Have we used up our 20 minutes yet? You have six minutes left. We have six whole minutes. I have a question. I cannot see anything but the most blinding white lights I've ever seen in my life. Did you want to say anything about security, Christian? So the original EVM was designed from the ground up to have fixed bounds of source consumption and these bounds should coincide with the gas usage. What do we know about existing EWASM implementations in that regard? Regarding security in the virtual machine, I think the number one biggest security issue though is the trusted computing base. That's continually expanding with every pre-compiled that we add. So the point of WebAssembly from a security perspective, and it is from a security perspective, is to minimize the overall trusting computing base. Now security from the metering perspective is done by EVM to WASM, 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 WebAssembly flow control. So it's easy to do static analysis on the flow control and inject metering statements at the beginning of each possible branch condition that will meter it. The same applies to memory usage. So it provides the gas model and the memory model as far as metering is going to work the same way. With that a benefit that it's decoupled from the EVM by default. So it's not, we have a nice separation of concerns there. 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. We can examine that. And then we can have a separate module altogether examining and looking at our trusted computing base, which would be the WASM VM. So two folds there. Minimizing the trusted computing base, 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, for example memory will probably be paid with regard to the memory of the, so 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 WebAssembly. You use expand memory, and there's initial memory allocation so 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 an L-format if you're familiar with how, you know, L-format initializes programs. And then whenever you need more memory, there's an opcode expand memory. So it's very clear where all the memory expansions can happen. And, yeah, that's where we inject our metering. So that's sort of like an S-break opcode. Like the S-break in old Unix. Oh, I'm not familiar with that. Yeah, you have to tell me about that. It is similar to that. Okay. S-B-R-K. Yeah, just a quick note on the metering part. So it's entirely coupled from the execution time. We have the input bytecode, which doesn't have metering, because we don't trust the input compilers. So anyone who compiles C-wasm, we don't really want to trust them to include metering in the 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. So this kind of works like how a JIT works. Like the LLVM JIT we have for EVM. But we do this upfront before execution. So it should be much faster. And another interesting point, Greg. So you were thinking about doing the metering in another thread, correct? Yeah, I don't think that's going to work. But I don't think it's going to be any faster. Oh, okay. 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 a basic block. But like doing a call costs enough that's saving a bit of time doing the metering on the call. I was just going to say, we sort of can do that now. It's a little bit hacking, but we sort of get the separation concerns to free because whenever we call out to the interface to do the metering, that's going to be possibly running on a separate thread. But I don't know how much that's improving our performance either. How cheap are your threads? Right now we're using the 8 to prototype. So we get eight threads by default and they're allocated when it starts up. So they're fairly cheap actually. Thanks guys. Thank you very much. Thank you all. Thank you very much.