EVM-C: Portable API for Ethereum Virtual Machines
Devcon·Sun, Oct 7, 2018, 12:00 AM
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/3/evm-c-portable-api-for-ethereum-virtual-machines Pawel Bylica gives his talk titled, "EVM-C: Portable API for Ethereum Virtual Machines" Speaker(s): Pawel Bylica Skill level: Advanced Track: Developer Infrastructure Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 3 was held in Cancún, Mexico on Nov 1 - 4, 2017 Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
Transcript
you [Music] hello everyone yeah so I'm palpable Itza and this talk will be about DM and DM C which is portable API for a theory on filter machine I'm software software developer I specialized in C++ and currently I'm working mostly in the CPP aetherium project and I also I'm out the author of EVM jet which is alternative VM implementation that translates evm bytecode to native machine language and and I also try to come up with the API for for EVM and that is called TV MC so this talk will be will have two parts first one I would like to explain what exactly am I talking about and what I mean by by a VM API and EVM interface and in the second part I would like to show what would have been done so far what we wanted 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 etherium filter machine one of the most important components of ATM software and the ecosystem so it's in short words virtual machine that actually can execute small programs or small scripts called smart contracts and yeah where it is every every atrium client at least four full notes have a VM somewhere inside usually there is one implementation of that but we have some examples where EVM clients can actually have more of them and and cpp atrium 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 easy em through JSON RPC some test RPC systems VM tracing storage backlog and and so on but what what I try to address is I would like this this composition to be look more or less like this one so this thin layer that actually connects EVMs to theorem clients to be to be very well specified very well documented and to be also usable in from different programming languages and also what can can add to this this scheme is to be able to actually plug in this named EVM implementation two different clients okay so if EMC is one of the possible solutions to this problem and it's it's exactly what I what I what I meant before it's EVM API that uses C language to kinetic the these two now separated components the the EVM in virtual machine to be connected with a Syrian client and why why C language was chosen not because it's the most beautiful one but it happens that C is actually accessible for many 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 with go using the C go tool and also in Python using C FFI library but I'm sure there are other examples when you can at least use libraries in more more high-level abstract languages and second important part of that is we want to have polymorphic interfaces there so we would like to be able to use different to switch between different EVM implementations and runtime not that we want to build a client with this one and decide on on the build time what what actually implementation would like to use yeah we wanted to have a switch that user can actually use to decide what kind of back-end they want for its task and and third third important part we we took account of to make some design decisions is composability so the composability means actually we could do something like that when having some concrete implementations of vm 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 where actually you want to send your code to so for example if we can consider interpreter and get like a VM you might want to actually have and top layer that actually decides if the code should go to that the treat one or to the interpreter one and the top layer can actually for example count the number of executions of particular code if if we have some hot code that is executed in many transactions you might want to actually translate that using the DD VM to some native machine code and speed up the execution but that might not may not have sense if if you want if if the code is not frequent enough to actually pay the cost of overhead of doing the translation upfront and not having my may not make a lot of sense the second example of such some such a composition can be [Music] having actually different languages in smart contract if we consider the proposed EU Azzam and EVM 11.0 we can just add very simple liar on top of that that actually can recognize if the smart contracts uses the web assembly like language or EVM one byte code so how actually this EVM C looks like this is actually the single file a single C header file and includes declarations of functions and structs and also all the documentation is is is this file in in form of of comments so this is actually the 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 were and as long I'm experimenting with that and the API is not finished yet we it's included in this project okay so the whole the whole design has some kind of to two parts two sides and one is related to the client to the client side and one is related to the EVM itself on the client side what have to be done you you need to implement implement some context class and contact class provides to our methods and can answer questions coming from from EVM and these questions are something like get me the balance of given account or get me the storage at the given storage slot for forgiven contract all this information cannot be provided to the AVM upfront because we don't want to send the whole state to the AVM to execute smart smart contracts but DVM need either way to actually extract this information on demand on the second side on the AVM side there is AVM class and EVM class it's quite simple there is a way to actually construct the AVM instance and there is a way to to destroy it and the core function is actually 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 if EVM uses this context interface to to ask for a mooring 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 a V ender you would like to use some of EVM C compatible EVM is available and what you have to do your job is to implement the context class and there are eight virtual methods to that have to be implemented and you have also encode your information what to execute in in the message in the message distraction and if you would like to for example implement the AVM but you don't care about the rest of the etherium client like networks dark non 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 and complex so what we have so far with this so as I mentioned at the beginning the C++ client have actually two to EVMS and one is classic interpreter and it actually does not use the AVM C but we plan to do it in the next in the near future but evm get the treat like a VM uses the avians interface and it's it's compatible with the recent hard fork of byzantium there is also the hero project that a prototype of a tedium client with you as embark end and there is also a prototype of EVM implemented purely in the C language I also prepared some time ago a prototype of GAF with the AVM due to plug-in and the Python Python client with EVM jet plugged in this to 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 EVM C API is its 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 in other places we would like if this is in place we would like to move the CPP interpreter to use the idioms DMC interface as well and I also plan to to release experimental graph with a VM did as a virtual machine derp recently also someone considered to using this interface together with fast testing project ok that was all from mine thank you for your attention and in case some questions I'm available for ya for how they've come around thank you you [Music]
Automatic transcript — names and jargon may be misspelled.