New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

J1 SAY 11 Jake Lang Hera The eWASM VM

Ethereum ParisTue, Oct 9, 2018, 12:00 AM

Transcript

my name is Jake and named after my github profile and we're gonna be taking a closer look at the internal workings of Hira so here ax is the only EOS and VM right now that is capable of executing the EOS and contracts and soon there will be later assume there will be more later and some of its principal features are the ability to interface with the EVM C API and that means that there is a much higher degree of modularity allowed because it is not dependent on the implementation of the client and so it takes advantage of the ability to execute webassembly contracts to gain support for more languages and the ability for a contract developer to use a much larger variety of tools to develop contracts on the etherion platform so the reason that webassembly is much more performant than EVM one is again as x''k has mentioned the 32 or 64-bit word size and little-endian this which is very resemblance of native machine architectures which allows much faster interpreters and even faster JIT compilers to be made because less of the execution time is spent on translating the opcodes and more time is spent on runtime analysis and optimization so here we'll take a look at the way here communicates with both the host client and binary and so as we could see here Hira communicates with the host client as I said with the EVM C API and it uses binary into directly acute was in contracts so binary on handles the instantiation and execution of Wazza modules and obviously that means that as there some of the functionality that is an EVM one has to be supported in a different way than with otherwise so for this we have the EEI or the etherium environment interface the EEI is a set of functions that are exposed to the Oise module or II was in contract that cover some of the functionality that would normally be covered by high-level instructions in EVM one so wasn't quite support those types of high-level instructions and so we have an implementation of the EEI that imports the function specified and allows a contract programmer to you access that functionality through said methods so if I were AC developer who wanted to write an e wasman contract I would have a header full of the function prototypes for for the e I methods and that would allow me to build a contract that one compiled hawazin will correctly access the e I methods and another aspect of the e aí is that it's pretty agnostic to implementations of the Oise MVM so in our case binary on which is a interpreter for wasum so that there can be multiple implementations of the Oise and VM running with Hira for example if i wanted to use another interpreter such as webbot it is not much work - it is not much work to implement the EEI for wabbit in pretty much the same way and you will be able to you multiple waz I'm infrastructures for handling execution know that with here of being not much changed so the current limitations of here are the synchronous EEI implementation which is a obstacle in the sense that it means that there is no browser support at the moment because in order to implement browser support the you need an asynchronous EEI implementation because the j/s engine will not block to let the web assembly module execute you actually need to have a callback entry points to well implement it in the contract as well which makes it much more difficult so at the moment here only works with native clients so there will be no browser support and a performance speed bump would be the binary an interpreter because while interpreters are not nearly as fast as yet compilers and they well at the moment we only use binary n' and the last roadblock is BMC support so at the moment CPP etherium the C++ client is the only aetherium client that fully supports the e vm c API and yet has limited support of it and there are no other clients that support UMC obviously this will change in the future but at the moment it's just something we have to deal with so in the future we have a couple features that we want to add to Hira including support for alternative wasn't VMs as i mentioned particularly JIT compiler such as Wathan because that will present a massive performance increase and later down the road we will implement a wasn't vm abstraction layer which will allow you to use multiple wasum infrastructures interpreters and shits with Hira with very little work needed to be done to implement support in Hira for said wise i'm infrastructure and the other planned feature we have is EVM towas and trans compiler integration so at the moment hero will fall back to EVM one and execute EVM one op codes if invalid was an input or EVM one input is detected but we have a planned feature that will enable Hera to automatically trans compile EVM wanna codes to Waze them and execute those instead which means that we won't have to fall back to EVM one in the case that they're in the case that there is sorry in the case that EVM one up codes are detected so anyone have any questions no question alright so I'm not sure this is a good question but there there are internal transactions right when I call one contract from another contract and if one would be written and he wasn't and I would call an old contract that is a solidity contract already on chain how does he handle that I mean I don't know if that's a good question well if you're talking about Annie was on contract sending a message call that causes another contract to be executed well at the moment like I said it will it will fall back to EVM one and execute that execute what the message specifies except like I said we will be able to transpile it automatically so yeah was more interested about is hero responsible for fetching the state of the other contract fetching the contract data reinitializing which VM to run it on based on the code that it finds and then kind of put the message in and take the result well here is responsible for choosing which VM to run it on and here ax can access the state of another contract or or storage through the EVM C API there are specified methods that are exposed to the VM that allow it to achieve this and access this information so the message passing is actually the responsibility of the of the of the host client so so if you pass a message it actually goes out of the VM and it's up to client to decide what to do the message so both if you you azzam and a VM has more or less the same way of handing messages I mean it wasn't it has compatibility with with all the message design so if you you just pass pass bytes and so on so it can be received on the other side even if it's some kind of already deployed contract I mean it's it's it gets probably a bit more complicated if you want to create new and so on because you need to supply the different byte code existing in new contracts but that's like a minor minor issue to think about so yeah so it's it's mostly at the current design its the responsibilities is on the client side however you can you can you can create a bit more clever VM within the AVM C interface because it allows you to fetch the data I mean the code from from the state so you can optimize your VM in the way you will not fall back to client side and try to speed up execution by by not going not switching context but it's some kind of optimization that is possible but yeah it's nobody tried that yet but so so so to simplify yeah you can you can you can call vm 1.0 contracts provided you I don't know you go with with the solidity ABI or or you have to agree about about the convention of the content of the message yeah but it's nothing is blocking you from from doing that alright so does anyone have any other questions about here there will be a Q&A from 10 starting at 10:00 to 5:00 this afternoon so maybe we should do that there yeah so yeah that's about it at the moment here is it's in a working state and the EEI properly charges gas for method for execution of methods that would usually be covered by op codes so we do have a working a wizened vm and the next step is to add more support and modularity for different laws and infrastructures to better take advantage of the massive tool chain we have from using web assembly for execution of contracts so thanks for listening [Applause]

Automatic transcript — names and jargon may be misspelled.