 Hello, everyone. Yeah, so I'm Paweł Balica, and this talk will be about EVM and EVMC, which is a portable API for Ethereum virtual machine. I'm a software developer. I'm specialized in C++, and currently I'm working mostly in the CPP Ethereum project. And I also am the author of EVMJIT, which is an alternative EVM implementation that translates EVM bytecode to native machine language. And I also try to come up with the API for EVM that is called EVMC. So this talk will have two parts. First one, I would like to explain what exactly am I talking about and what I mean by EVM API and EVM interface. And in the second part, I would like to show what have been done so far, what we want to do in the near future, and explain some design decisions we made so far to be able for you to better understand why things look as they look at the moment. So EVM, the Ethereum virtual machine, one of the most important components of Ethereum software and Ethereum ecosystem. So it's, in short words, a virtual machine that actually can execute small programs or small scripts called smart contracts. And yeah, where it is. Every Ethereum client, at least full nodes, have EVM somewhere inside. Usually there is one implementation of that, but we have some examples where EVM clients can actually have more of them. And CPP Ethereum is one of the examples here. But the problem I would like to address is the fact that EVMs are somehow embedded inside the client. You can have more or less indirect access to it, to EVM, through JSON RPC, some test RPC systems, VM tracing, storage, backlog, and so on. But what I try to address is I would like this composition to look more or less like this one. So this thin layer that actually connects EVMs to Ethereum clients to be very well specified, very well documented, and to be also usable from different programming languages. And also what we can add to this scheme is to be able to actually plug in the same EVM implementation to different clients. OK, so EVMC is one of the possible solutions to this problem. And it's exactly what I meant before. It's EVM API that uses C language to connect these two now separated components, the EVM Ethereum virtual machine to be connected with Ethereum client. And why C language was chosen? Not because it's the most beautiful one, but it happens that C is actually accessible for many programming languages. The obvious examples are C and C++, but for many popular languages that are around, you can actually at least use some C libraries and use execute functions from C libraries from that languages. I tried all this stuff with Go using the CGO tool and also in Python using CFFI library, but I'm sure there are other examples when you can at least use C libraries in more high level, more abstract languages. And second important part of that is we want to have polymorphic interfaces there. So we would like to be able to switch between different EVM implementations and runtime. Not that we want to build a client with this one and decide on the build time what actually implementation we would like to use. Yeah, we want to have a switch that the user can actually use to decide what kind of backend they want for its task. And third important part we took account of to make some design decisions is composability. So the composability means actually we can do something like that. When having some concrete implementations of EVM, we can add more and more layers on top of that that actually delegate the execution to the lower layers. But on the upper layer, you can make some additional decisions what actually you want to send your code to. So for example, if we consider interpreter and JIT like EVM, you might want to actually have a top layer that actually decides if the code should go to the JIT one or to the interpreter one. And the top layer can actually, for example, count the number of executions of a particular code. If we have some hot code that is executed in many transactions, we might want to actually translate that using the JIT EVM to some native machine code and speed up the execution. But that may not have sense if the code is not frequent enough to actually pay the cost of overhead of doing the translation upfront and not having, yeah, may not make a lot of sense. The second example of such composition can be having actually different languages in smart contract. If we consider the proposed EWASM and EVM 1.0, we can just add very simple layer atop of that that actually can recognize if the smart contract uses the WebAssembly-like language or EVM 1 bytecode. So how actually this EVMC looks like? This is actually the single file, a single C header file. And it includes declarations and functions and structs. And also all the documentation is this file in the form of comments. So this is actually the only source you should care about. And I paid attention to actually have good enough documentation to understand how it works, just reading the single file. And at the moment, this is part of my EVM-G project. And as long as I am experimenting with that and the API is not finished yet, it's included in this project. OK, so the whole design has some kind of two parts, two sites. And one is related to the client side, and one is related to the EVM itself. On the client side, what have to be done, you need to implement some context class. And context class provides virtual methods and can answer questions coming from EVM. And these questions are something like get me the balance of given account or get me the storage as given storage slot for given contract. All this information cannot be provided to the EVM upfront because we don't want to send the whole state to the EVM to execute smart contracts. But the EVM need a way to actually extract this information on demand. And on the second side, on the EVM side, there is EVM class. And EVM class, it's quite simple. There is a way to actually construct the EVM instance. And there is a way to destroy it. And the core function is actually an execute function. When the information what is to be executed is encoded in a new message object. And also, the context is provided for the execution. And EVM uses this context interface to ask for more data if needed. So in case you would like to implement new client, but you don't want to, in the same time, implement EVM there, you would like to use some of EVMC compatible EVMs available. What you have to do? Your job is to implement the context class. And there are eight virtual methods that have to be implemented. And you have also encode your information what to execute in the message structure. And if you would like to, for example, implement the EVM, but you don't care about the rest of the Ethereum client, like network stack, not storage, database, and so on, all you need to do is to implement the create and destroy pair of functions and the execute one. So not to be confused, this design operates on the object-oriented concepts. But on the way, you will do that. You will have to translate it down to the C. So it gets more obscure and complex. So what we have so far with this. So as I mentioned at the beginning, the C++ client have actually two EVMs. And one is classic interpreter. And it actually does not use the EVMC, but we plan to do it in the next, in the near future. But EVMJIT, the JIT-like EVM, uses the EVMC interface. And it's compatible with the recent hard fork of Byzantium. There is also the HERA project, a prototype of Ethereum client with Iwazem backend. And there is also a prototype of EVM implemented purely in C language. I also prepared some time ago a prototype of GEF with the EVMJIT plugged in and the Python client with EVMJIT plugged in. This still needs some work. And it requires updates to the current status of the code. But it's quite fun to play with that. And what we want to do next. The missing piece of EVMC API is VM tracing. And this is a showstopper for a moment, because we cannot replace existing VMs completely because this missing feature is important in other places. We would like, if this is in place, we would like to move the CPP interpreter to use the EVMC interface as well. And I also plan to release experimental GEF with EVMJIT as a virtual machine there. Recently, also, someone considered to using this interface together with a fast testing project. OK, that was all for mine. Thank you for your attention. And in case some questions, I'm available for whole DEFCON around. Thank you.