J1 SAY 07 Alex Beregszaszi Why eWASM

so yeah before we start has anyone heard about webassembly before it just raise your hands and anyone heard about he was him anyone used he was him how did you use he wasn't it's not ready yet okay so yeah so what he was amazed it's it helium flavored webassembly or rather we can try to use webassembly in it helium so my name is Alex or hexagon github mostly I contribute to solidity and the awesome project but I also from time to time work on atrium GS and CPP Tyrael and you would see with all the other talks that probably people from all these projects I kind of involved in II wasn't and I try to gather everyone in these projects to join it wasn't so finally after like two years we can release something you may have seen it in the agenda that's gonna be I guess three four hours today the entire afternoon is dedicated to you awesome so I'm going to talk about a small intro I guess 15 minutes and after me Martin who's sitting on the left gonna take over and his talk gonna be really interesting because he has the flexibility of not dealing with it here iam and he can do whatever with webassembly and he can do really nice things after that we can I have a demo of he wasn't and delivered by Jared and after the demo you gonna probably understand what it does and you're gonna get a bit more explanation how it works internally so EVM C is one part and here is another part and finally ever it's going to talk about the K framework and how someone can implement he wasn't made the K framework then finally a coffee break I think it's gonna be well deserved probably two hours at that point and after the coffee break you can have at least one hour of panel discussions and Q&A so I don't think we have time to do a Q&A between any of these talks but we're gonna have a lot of time to the Q&A after the panel so if you have any questions either for the first talk or the second one please come back if you don't stay here for the entire time please come back for the panel and ask your questions then okay we just take a step back first and look at the history have we ended up with Webb assembling so like in 2009 when Bitcoin was created there was a Bitcoin script which was able to do a couple of things but quickly enough they have removed some of those instructions some of those things Bitcoin could do and stepping forward a tiny bit more Bitcoin was even more restricted so they took in the client they decided that a couple of function a couple of script templates are gonna be the one accepted by Bitcoin and those templates are like four different templates sending Bitcoin in like four different ways and that's it you cannot do anything else so obviously people weren't happy with that so a couple of forks were created the first one was named coin to extend the functionality of Bitcoin but it quickly turned out that Forex may not be the best idea so a second option was to hijack one instruction in Bitcoin script called up return and because anything but after up return is ignored so you can put whatever data you want there and do whatever you want well not much actually but you can put references to other things and so like colored coins were implemented but you couldn't do anything else with Bitcoin so finally in 2015 each earring was designed and released but quickly it was realized that maybe not everything was designed in the best way so in a tea room we have costs for each instruction and there are a couple of really useful things a contract would want to do namely hashing or finding out who signed a message and if you implement it in the EVM itself in it hiriam and measure it with the rules we have for gas search for instruction cost it's got to turn out that it won't fit into your block because the cost of it is more than a block cast limit so people came up with this idea of pecan pies which are basically just discounted contracts so we have fixed costs for the contract and they do a lot more than they should do for that cost and I think all of these were like issues and we try to fix those issues and we are going to try to fix those issues with webassembly so hopefully 2018 gonna be the year for webassembly okay a bit about EVM itself I think everyone in the room probably knows most of these things but EVM but basically we have 256 bits stack items we have a lot of high-level instructions we have a couple of basic instructions and I don't really like the high level instructions like one of them is sherry which is in sherry but it's super high level it doesn't really have to do anything in a VM all of that are these high level things are in the pre comp eyes which are nice either but at least they're not in the instruction set another problem with the VM is we have only a couple handful languages working with the VM and I mean it must be clear based on all of these it's not really modeled after an actual computer it is just a magical computer I don't feel like any of those but there are like three main problems which probably should be fixed one of them is the large stack items and that actually is a problem because you cannot easily map that into a single computer instruction it has to be multiple instructions and that means in every single computer every single client implementation you could have different set of instructions doing that so there's no real simple way to come up for a fixed cost for it because every single client could have a different actual physical that a really big problem is we have those high-level instructions it's even harder to come up with proper gas goes for those and the last thing is we do all of these gas calculations all of these instruction costing at run time it's event again really slow so hopefully we are simply going to fix all of this it's just an order it tries to map a normal computer so it has 32 and 64 bits stack items and operations it doesn't really have super high-level things and one interesting fact is it has been designed by a w3c working group with over 600 people but it actually has been agreed on and it has been finalized at least version one you know just by thinking it's it's designed by committee it still has been finalized it's supported by all the major browsers and at least our six other implementations of it um I guess like to implementation is see one and go one in Oh camel a couple of others it's supposed to have a lot more languages supporting it's a lot more languages can be compiled web assembly and yes as I mentioned it tries to really model a regular CPU so it should be really easy and simple to map every single instruction to an actual CPU instruction ok did we change anything about assembly like this is the first question ever so we say we do it wasn't okay so how different it is to web assembly we didn't change web assembly at all we took the same web assembly you get and we don't change it the reason we can do this because web assembly is quite flexible in an eve of assembly bytecode in any little piece of code you have written and compiled web assembly you can import external functions you can import external features and everything it helium has all those things to access the state modify the state are implemented to external functions and we call this vacation the idiom environment interface or AI for short and that's the only addition they have to webassembly we don't add new instructions we don't remove instructions and now you may ask what do we do with you know parts we dislike in webassembly well we don't remove them we just have a process of validating the contract at deployment time and we just simply reject the contract if you don't like it so for example if it tries to do what we believe would be non-deterministic a certain floating-point operation we can just reject the entire contract well the fact for now is we just reject any contract which tries to use floating-point at all this may change in the future we may be able to work around it but right now we just rejected it this just also shows it's quite flexible the other big thing we have done is metering all those contracts at deployment time the reason for that is we don't want to change the VMS so we can actually do runtime metering if you have to do this before it gets to the vm so that's an example of all these external interfaces I've mentioned so that's like one interface get sender get call value etc it is an example contract we just load the storage item for the sender address we increase it by the the value sent and we store it so it's like a mapping function you can imagine compiling disco to web assembly in any language could be map to this kind of behavior so the next really important part is the metering and the weight is done in EVM it's a runtime you drink so whenever an instruction is executed we have to calculate how much gas it's gonna cost we have to do deduct it and if we run out of gas we have to handle it as well however VMs are flexible in this so they could do it differently they don't actually do it differently but they could there's only one VM which does it differently which is evm jet which kind of does the same thing we're gonna do with web assembling which is we are just taking today yeah that jump des yeah so basically if you are familiar with IBM instructions and jump destinations any code between the jump destinations will be executed as they are so you can just break up the code by the jump destinations and calculate the gas usage for each of those blocks practically we do the same thing for Watson we just call it branches so anything between branching instructions we just calculate at once so as an example here this is a example wasn't code in like a text representation so it's the if statement it is the condition and the two sides so we can just calculate all of the cost of this and this and this and insert these simple statements and we don't have to do runtime metering so what I'm gonna have a much wider language support I mean that's what we claim obviously it has this text format you have seen here you could write what some contracts this way but you don't have to you can also write them in C or C++ or rust all of this is working already but there plans to support compiling go to web sembly and a couple of other languages unfortunately even though it's called web assembly and it came from the browsers javascript cannot be compiled to it yeah I mean that's probably funny but one thing which probably going to be coming up is a question what can you do with solidity because most of the contracts generally are written in solidity they going to be compiled able to you webassembly yet is the same text format as in the previous example basically this is function and you do whatever you want in that function and you can import atiim methods like this so as I said this is one of the options to create contracts probably the best option here's another one to do it in C I guess it should be familiar to anyone writing C the most important part why is any of this good at all I think mostly in the past year the main reasoning here was is for scalability but I think the main reason here is to have a more flexible system than what we have currently with EVM as you can see we have like imports and we don't have high-level instructions in webassembly so whatever new features we have to get to webassembly can be done we via imports and if we have to remove something we can't just change the deployment time validation contract and we can say this new this feature we had so far can it be used anymore and we just reject contracts having those with EVM it would be a lot more work to do any of these and of course a lot more languages and most importantly right now a lot of effort is spent on creating EVM implementations for every single language for every single client they have to create an EVM implementation and for every language someone is designing they have to also be able to compile to EVM so if we kept out EVM entirely here and just rely on all these other people creating compilers and VMs then we don't have to do it like the last point that this is better foundation for the future is more like for the extensibility part it should be really easy and simple to extend it I mean you may ask what can you do with the current EVM that this really comes up and we don't really know the answer to this at all hi he wasn't gonna be deployed right so that's main question well it's gonna be deployed on the main chain and if so will it coexist with EVM or will it be deployed as a shard and if if it will be deployed as a shard will it have EVM support at the same time we don't know but either way we have this project called EMM - awesome which can be used to run AVM bytecode on a pure it was a VM so whichever of these options gonna happy and we have a solution for those that's just a summary of where we are at the moment so basically we have finished implementation and CBT room and there is an implementation go atrium ongoing at the moment we just need to decide on two final tiny I guess it's tiny design decisions and once we done that it's really just a metering contract left but of course the majority of the work left there is testing and figuring out whether we made any mistakes in the design so if you're interested in it wasn't either really more about it or contributing to it please check the github and there should be the design document and all that resource code if nothing is clear there or something is like later you can join the Gator channel and hopefully we're gonna be able to answer all your questions there thank you [Applause]