J1 SAY 13 Panel entire eWASM team discussion and Q&A

nice to meet everyone my name is Lane I'm a member of the Azam team I'm gonna try to moderate by firing some questions at this all-star panel here and of course giving you guys a chance to ask questions I thought maybe we'll start can everyone can we just go down the line I'll pass the mic down and we can each just quickly like one sentence say who we are where we're working on so yeah so my name is Lane and other than moderating this panel I'm working on various you want some things like testing hi everyone my name is Hieu and well I'm part of the it wasn't team I'm working mostly on the test cases hi I'm on Pavel I'm supplies plus software engineer and I was taking care of implementations of achieving virtual machines from from sometime and yeah I'm trying to my best here and also in the project I'm Casey got spearheaded getting a theory MJS compatible with Byzantium and then was testing different clients before Byzantium and then he wasn't since then mostly hello Martin I worked on an Atheneum Jas and Eve awesome both in the beginnings of those projects now I'm working on premiere which builds extensively after the groundwork laid by ewha's him I'm Everett and I'm working on K wasum which is the K formal specification of the wasum 1bm I'm Jake and I primarily work on hero VM and yeah it was him is what I work on and hi my name is Alex I work mostly on solidity and he was him and he wasn't work on design the VM and the system contracts usually hi I'm Jared I mostly work on testing Eve awesome and then in the past I worked on aetherium testing and aetherium j/s hi I'm Guillaume I'm working in the go theme it's ready to go team on get four for a serum and I'm going to port he wasn't into the go clients awesome thanks for the intro guys so as I said I'll kick off with a couple of questions and try to keep some softball questions in the beginning and then pass the opportunity to the audience to ask questions I thought so we've heard a lot today from many of these folks about what we're working on and where we're going I thought it might be nice to rewind a little bit and just look at how we got here and I was actually hoping I could ask Casey to talk a little bit about you know you hear terms like EVM 1.5 EVM 2.0 kind of what those things mean and how we arrived in this kind of awasum world today I can't speak on all those points and just give my perspective after because the Thermage asset was you know written by Martin and when he you know grew more interested in research than maintaining the client then it fell to somebody else to sort of you know keep it up to date with the latest works with with byzantium and so I you know picked that up and then then the next project was also it was II wasn't colonel which Martin had also started and then that became prime eeeh Crimea hypervisor and I had to backtrack in the in the in the repo to rekindle he wasn't colonel and that was how I started learning about you awesome I mean in addition to I was he asking and I mean Alex also Alex and Martin you know co-created awasum but then it's sort of I mean it languished because people were working on other things and it languished because it was you know it was it was like 90% done you know with the other 90% still left to go and and so yeah since since then you know that's what we've been trying to do is you know kick start that process and then um finish it up and make it a you know like a working client in a usable Testament and so forth I think you'll see a common thread in Casey's comments of other people picking up my slack I just want to say thank you everyone yeah yeah I got ya what was the question difference between me vm 1.5 thanks self alright back asleep after this it was sitting at about the 90 percent point and Martin and I were discussing it and I was just looking at how could I extend 1.0 to get some of the same benefits without a complete shift to a completely new VM and so I worked on that got a prototype implementation done a couple of the IP threatened and at midnight somewhere in early June Christian told me that that project was cancelled so here we are so so from my perspective evn 1.

5 is something intermediate step so it adds some it makes that the end source code and structure of the program I mean it makes the program more structured so you can at least have the information where the problem can jump in and jump out and have some requirements for how how items are handled on the stack so you cannot if you go to subroutine and you go back you cannot leave some items on the stack on handles and so on so it makes it work more or less as a regular regular native code so yeah it's it's it's almost like adding some requirements that already on existing virtual machines to a bit bit wild evn one punto awesome thanks Pavel I can add a little bit of historical context to it so like when he wasn't the first prototypes if he wasn't started probably two and a half years ago to two and a half years ago and webassembly back then wasn't really like specified it was it was still in prototype stage and there was no indication when that's gonna be final and then Greg came along and it's an incremental step had to improve EVM so like Oh basically what Greg did he did all the logical steps needed to make even better and very similar steps were done in in wasn't I mean it kind of similar in several parts but then I think like early last year wasn't was finalized and suddenly there was no issue anymore when will wasn't be final and for some other reasons there weren't enough resources allocated for even 1.5 I mean this is just a historical context I don't know the reasons why it was abandoned sorry our synchronous message passing here is a little slower than it should be alright since he's close to me Pavel I'm gonna fire one at you you mentioned in the context of EMC JIT as an option for implementation can you talk a little bit about how far along that is and sort of how well that works and whether that's a reality or possibility so I would actually cool it down a bit so I'm not so sure like JIT is like available at the moment I would like to know more I mean there's definitely a lot of research to be done in this subject and for example we want to make sure like to actually know what the requirements for JIT would be to be available in there and this specific environment as blocked rhiness so like can you actually put it there and make sure and nobody will find a way to actually attack the JIT itself yeah so for my perspective that's that's something we can we can try on as a as a toy at the moment and definitely a lot of the lots of research has to be done in this subject and maybe there's there will be some like stop sign at some point and that yeah that we cannot move further because we cannot guarantee some some properties of of process of getting the code so that's that's more less my my perspective on this subject so at the moment we can we can spin off the test net with some dates as one of the VMS or the only VM to test performance and that is nice to have but that doesn't mean we'll be able to ship it soon so anyone else want to add anything on the jet topic okay oh yeah so I had a question because I know yeah okay yeah I know we did we had there were benchmarks done on the hold the mic close to your mouth yeah yeah okay so there were benchmarks done on the precompile compiled the wasum and i know that without the JIT it takes forever because you have to load up all the waz M code so would not if we can if there's some reason that we could not run it to Ridge it would that be kind of a showstopper for for wasum or yeah and so what that was a number of you know we have at the moment so if it wasn't it was like 20 seconds to load to load it right it was the pairing pre-compile compiled you know to wasum where as native code it takes you know 50 milliseconds I mean as as chitta dois some it takes 100 milliseconds but as interpreted was um it took 21 seconds to execute to interpret the the code and I think there you probably can find a middle ground too if you're worried about the security of cheating because there's some sort of attack against fighting like a weak spot in the JIT where it's gonna be really slow or something you can probably take approach that other engine sees like v8 where it does a mix between jetting and interpreting and it's the hot spots which is a more complex I guess um I probably wouldn't have those problems so what others actually argue about that is if you have like fixed strategy about when to interpret when to J it you can always can be played so yeah I don't have my own you know about that but there's some arguments I I collect it over time but wouldn't the worst case in that scenario just be interpreting which is our baseline worst case if you have like one that is running your strategy for JIT and one that is just straight interpreting does that become your worst case because you could just stop at a point in the program where you decide okay I need a JIT from this point because it's a hot spot or whatever and then you spend all your time yeah so the way JavaScript engines work usually is like it doesn't JIT something till it's been hit multiple times so yeah you could see it like okay that's been hit once and or hit twice and they'll start cheating it while it's still interpreting it so I think that's like a reasonable thing you could do but couldn't you have like a case where say you have a cache for all the jaded code and somehow you figure it had to put code into the hot spot which isn't really properly used and you fill up the cache with that and then you do heavy another contract which needs to be jetted and is actually executed and it's heavy and you need to keep cheating at every single time because it's not in the cache good so what part is not in the cache well taste one which you actually use so you find a way somehow to pollute the cache wit with other things which aren't really used or shouldn't be in the cache hey Greg you should be on the panel I already refused I would be face down on the table most of the time if we are talking about running full nodes strategies like jetting code after it gets caught cashing code which got run these are highly vulnerable to denial of service attacks they're only going to be appropriate for like clients what denial the service techs are you worried about it exactly just filling up like Jeff had to rip the JIT out of the gas client in Shanghai oh that was a multiple there was several different attacks and one was look do I have to explain or do you have to do your job I'm just saying that I don't necessarily buy that a proper G is going to necessarily by itself be exploitable I think that as EXO co is bringing up with the cash you probably can set good default behaviors for how to deal with stuff like that like if you're feeling up the cash or you notice contract filling up the cash you can clear it and mark it as something you don't want to JIT I don't know would that solve your concern I'm actually not concerned at the moment yeah okay me neither just answer you know my answer to Jarrod's question would be that yet is it is a showstopper if we can't JIT because I mean one of the you know major benefits from Wazza is not so that client implementers don't have to add new pre-compile I mean it'd be endless you know we come about for this Bri come about for that the major benefit of azam is you know it's the the precompile to end all pre compiles but it can't do that if if they can't be executed in a you know as as a JIT as native code so I think in general we shouldn't rely on clients using Jets in the first place and the gasket should be calculated in a way which map like interpretation more closely than jetting and if whatever you try to compile fits into the block limit based on that then you already know it should be able to run on every single interpreter and if you manage to somehow do a jet properly to do that you get a gain on your client but we shouldn't jetting shouldn't be the baseline we design everything on cool alright let's shift gears slightly I have a question for Guillaume actually this is the Toria T so go go implementation of blossom sort of Azam how realistic is that how far away is it how much progress has been made what sort of challenges remain right so at the moment we are trying to reconfigure or at least reuse some component that always already exists that's called wagon it's it's a virtual machine that was initially intended to execute go program I mean translate them into wisdom and then run them the machine itself is it's a significant amount of customization I'm currently pushing a couple PRS it's not really complicated but it's all a matter of getting my PRS integrated really cool thank you okay Alex in your talk you talked a little bit towards the end if I remember correctly about could've roadmap from here how we actually get you awesome into production aetherium I thought we could just quickly touch upon that again what I know that not everything is decided but what is the roadmap from here look like and how do we to an etherium world where we actually have a sort of he was an engine running and you know maybe touching upon charting that kind of stuff yeah I guess like the first part is to finish the design be a couple of questions still open there and once we do that of course you have to finalize the here the current VM hopefully we're gonna need another VM potentially the one in go the big parts left out after these so these are like pretty much finished outside of go but the metering so like the system contracts and one of them is a metering contract that should be finished that's one of the big remainder parts obviously we need to do a lot of more testing we only have like a basic set of test coverage at the moment and there are different ways to increase the test coverage we could just write actual tests manually we have been doing that so far but we would like to perhaps accelerate it and one way to do that is rely on the current ATM state tests by the way we can use those we need the AVM to wasn't trans compiler and preferably that should be a system contract as well so that's one of the reasons if empty wasn't actually makes sense right now to focus on in order to make use of all the state tests we have and now using all the state tests will not give us a total coverage even if DVM state tests would have a total coverage on a VM which probably they don't have but we have a couple of other things we have to test some other options for that we have first testing which case is involved with so once all of these testing things are finished hopefully by the time you gotta have a lot of other customer contracts and potentially and like private and maybe a public test net and as mentioned the VM two of them is probably a part of that we can already either enable EVM to azam on the test net or just rely on the on the client to have EVM as well as he wasn't and so potentially we can have public test net which has both and then comes the actual question how should this become mainstream and I don't think we have actual answers at the moment initially probably again going back two years the idea was that we would just launch on main chain probably that's less likely to happen at this point so one idea to launch is to make it wasn't part of charts and the main chain gonna be the control chart and gonna stay on EVM all the other shirts gonna be he wasn't that's one option and there's no decisions on any of any of these yet you mentioned two design decisions that aren't finished yet what what are those two design decisions we still have to finalize well one of them is really simple well I guess they're they're even more than these but these are the two which are on the plate at the moment well I think even like after today's talks like Crimea talk we might consider some other changes but so one one simple one was maybe clarify the return value of all these interface methods and maybe unify them so all of them should have some kind of indication whether they succeeded or not or and we just need to specify this that's that's a tiny one there's another design decision we need to solve regarding revert in return which currently so we have this revert and return in an EVM which abort execution and said the state whether it was a successful execution and return something or whether it was a failure and we also want to return something currently how that maps into he was amazed they are just interface methods and they said a buffer and it's up to the contract to actually stop somehow it would be nice to change that so they would behave similarly to the VM and so that I think this is the major one left cool any other thoughts on roadmap from anyone else on the panel okay cool let's take some audience questions who has was a question for us Thanks so I had two questions first of all thanks for all the talks it's been really nice to you to hear the updates the first question was around exactly how metering works because you said at you can kind of look at different branches of the code and you also mentioned this system contract that's called out to so some more details there and another thing I was wondering about is how does he was and relate to other implementations of you know blockchain if I'd was I'm kind of like parity was on for instance I can try to answer the metering the metering question I can try I might I might get some things wrong but basically an EVM when you execute an OP code before executing it you just calculate how much gas the OP code costs and deduct that from how much gas you have available to execute and sometimes it's a variable it's dependent on current parameters of the state like if you're setting some storage location it was unset before then you have to pay extra to use memory that wasn't there before but as Alex said in his in his talk this can be if this can you know be expensive because in between each off code you're saying like calculate the gas calculate the gas calculate the gas so instead you can take every basic block of code which is just basically code that will be executed in a straight line and calculate the gas cost of the entire basic block and deduct it all upfront which is what the metering approach is doing instead so you find all the basic blocks of your code which are code chunks that will be executed if you enter the front of the code will chunk all the code will be executed one instruction after the other you insert the metering instruction the beginning was just basically checks you know will I be able to execute the entire block or not and if you are able to then you deduct the cost of the whole block then you just execute normally and then the way this works is instead of instrumenting your runtime to be able to handle that that deduction of gas like we would if you had a direct semantics of metering you call an external system contract called the metering contract which just basically keeps tabs on how much gas you have available and deduct it from its store of gas so it's just a hard-coded precompile or system contract that has yet to be released I believe are fully developed it's still in progress I think and maybe over time you would update it and that might constitute a hard fork I think maybe you can clear that up just just one addition to that like the really exciting part is that the metering contract itself should be compiled it wasn't and should be metered by itself and then we can charge for the deployment cost based on how much it takes to meter the contracted deployment so I can try to answer the question about how II was um relates to other webassembly initiatives such as parodies webassembly so II was um and parodies equivalent attempt to achieve similar things like executing Waze and contracts in place of EVM one and parody claims to have there was some stuff going on there test net in about two weeks I think we don't actively collaborate with parody at the moment on web assembly stuff but we attempt to do similar things what other webassembly initiatives did you have in mind when you were asking the question again well about the design decisions parodies webassembly initiative isn't quite as documented so at least I personally don't have much vision into what they plan to do differently than we do and as for Definity Martin can probably add on to this but premia which is one of definitive projects is on a different layer it's a higher level than just the web assembly instruction set so it can take advantage of the ability to execute webassembly contracts but it doesn't have to be bound to aetherium specifically yeah sure so you azam P wasallam and I also believe losses adopting they all have a similar sort of format for their interfaces premia takes quite a slightly different approach with the object-oriented interface that has references so that that would be the to be I think the big difference right and just is there any parity people that can talk more about P wasum presumably you know whatever blockchain defied wasum implementation or you know if it's not documented then it's just implementation but presumably there's some host functions you know and the you know the client provides those host functions and then other than that you know it's just you know all Wow's them you know the vows of instructions are all the same it's just how the interface is defined so how they you know the host functions are defined so as a smart invention if like party and he was him and probably else day they follow likely the very same kind of structure so probably it will be easy to compile a contract to any of those but premier is quite different so probably you you couldn't you wouldn't be easily able to come by the same thing to all four but one component we really want to share between all of them and I don't think there was any anyone against that so far is the metering and figuring it had a metering should work and the actual metering implementation probably should be multiple of them but the specification should be very similar if not the same I think also EVM tourism will probably work through all of them fairly well like things would break in Crimea for contracts calling other contracts just because the call semantics are different but like an individual contract I think could be ported over if you had multiple contracts and you expected them to talk the same way you might have to also insert some shims but yeah so there's I think several different components that can all be shared in between yeah awesome thank you for the awesome question cool what other questions do you guys have any audience hi one of the non-deterministic spots in the bacillus back is like how much stack could grow in its limit and I'm wondering do you have like a solution for like limiting the stack depth or you want to limit it via means of gas metering yeah I think we can just eliminate by gas metering if it becomes a problem like there's a tax against the stack based attacks and we can just up the price of calls and calls indirect fair enough hi everyone I remember a time where webassembly was was also mainly discussed in terms of scalability issues of resolving part of scalability I think I remember one blog post some years ago where there were numbers like it wasn't good to speed up execution by five to ten 10x I think was were the numbers and in your taxes wasn't that much of a topic anymore do you have any new benchmarks which contradicts the old numbers or is it just does it just differ with with the shouting plans and so it's it's not so imminent anymore or what are your stances on this I think there's one relevant answer to this as well is the birth of premier so premier follows the the descaling the scalability have so basically all the scale of Italy scalability research only was him resulted in premier by the way premier is designed is not really compatible with the current aetherium and I think kind of the reasoning for he wasn't shifted from scalability to more like I think there was a couple of points we have listed and some of the talks and namely that it's a much much better base to work off because you can much easily much more easily extend it introduce new interface methods or reject old ones etc and we don't have to deal like with the basic of the basis of the VM and I think the other important part which we need to figure out there is the instruction set should be much closer to the bare metal so we should be able to much easier or with much bigger confidence figure out actual gas costs to all those instructions and it's not even it's not even an actual fixed number it's more like the relation between all the different instructions you have assembly which we need to figure out and you said like it was a 5 10 10 X increase and speed I think that's still there namely just one single reason a 64-bit based and not 256 based and that should have big improvement in general so yeah that's in my mind I don't consider it was them to be a pure scaling initiative in the sense that it does not aim to achieve scalability on a very fundamental level other than cleaning up the and making it not this 256-bit word size monster it's um it definitely is helpful and will make the etherion platform much faster because you can do things that you would normally not have been able to like computation that would usually be handled by the pre compiles and so again I consider it more of a speed initiative than a pure scaling initiative yeah webassembly doesn't really help with scaling directly because the bottleneck with scaling is disk IO the estimates where okay yeah webassembly is five to ten times faster than then EVM I mean that's true when you're looking at a benchmark I mean it's way higher than that if you know if you compare it to a JIT it was them but if it's just a if you're just executing CPU that's not the current that's not the bottleneck with scalability I mean the bottleneck is is disk i/o and webassembly doesn't really speed that up so it doesn't directly benefit scalability yeah so I guess to address the scalability sort of funny term or not funny but like so you know what assembly makes things more performant but true scalability is allowing us to scale horizontally so being a like charting is scalability yeah so I think sometimes people get that slightly confused so I think someone said premia wouldn't be compatible with current aetherium and if I understand correctly that's because in aetherium the internal calls are synchronous and you can call out to any contract that you want but in implementing sharding wouldn't we need to kind of implement make things asynchronous and potentially roll those other changes in as well to a point that it can allow for parallelism or as I'd like off the table in in a fundamental way yeah I think that that's a really exciting possibility so I can't Mayberry in the future even anything we could have like a primary yard yeah why not you just have to get everyone on board and yeah implemented okay you guys have to each ask one question and I know you know who you are any more audience questions in the back like very futuristic but do you think you can limit speculation by making like transfers and things more expensive and subsidizing more complex contracts and things which developers are building versus just standard like token transfers and things like that yeah sorry could you repeat the questions a bit noisy yeah maybe can you do speculation in like the etherium Network by prioritizing more complex contracts and things like that developers are building apps versus standard like speculation token transfers and things are that so okay to make sure I understand the question kind of incentivize people to build quote-unquote real applications user facing applications as opposed to just ER C 20 type token transfers is that the question well at the moment I think that's kind of fundamentally difficult cuz with the current proof of work system the transactions that actually get mine into the block is well dependent on the miners because they choose which transactions from the pool to mine in proof of stake this will might be different but yeah in proof of work it's definitely very fundamentally hard to incentivize different types of computation I guess you would start with figuring out which types of computation is which on a quantitative level I mean I don't see a specific way to determine just by the on the bytecode level which computation is important and which computation isn't yeah I groove Drake I mean it's it's not the level we'd like to address such misuse I mean it's not a technical issue and like building software recognizing intentions like if you want to speculate you're you're talking all you if you want I don't know buy a coconut vendor machine it's yeah it'll be quite hard I mean you don't want to apply I don't know a I to that so yeah I don't believe it's it's that's that's this this basic platform level it's it's it's the place you and would think about addressing this issues cool yeah I just add one quick thing I mean I think we have to remember that etherium is designed to be a general-purpose computer and it's a slippery slope right if we were to begin you know prioritizing one type of program or transaction over another I think it's a slippery slope from there to just general censorship and I think that the computer is built to be censorship resistant in the first place I think that to the extent that that prioritization occurs I think it may occur at a higher level I don't agree I don't think it's a technical question I think you'll see a lot more things like bounty is there's going to be some announcements about kind of bounties and prizes here over the next couple of days that will incentivize teams to build some really exciting applications that need to be built I have a question for Everett which one's easier to formally verify EVM or or it was them well I don't have any data yet because we haven't verified me was in contracts I know that the wasum spec is a lot less ambiguous than the yellow paper is so that's like a major plus for implementers [Music] there are some weird opcodes in evm like em store eight which make verification kind of a nightmare so actually in one of the one of the branches of our repository we just disallow the EM story opcode so that we don't have to do any reasoning about it and that makes verification 'el a lot faster so there's a bunch of little things like that in EVM that make verification a lot like kind of a nightmare whereas wasum was developed while wasun has a isabelle model of it already I'm developing a model and it was developed by someone who you know understands verification so they're going to obviously have had a lot more feedback into the design of wasman from the start that makes it more amiable to to doing smart contract verifications so I think it I mean once I have more data I'll be able to say for sure but I would say like wasum at this point but once again I don't have data to back it up yet any other questions from the panel you guys have any other questions you want to talk about okay I've got another one can would anyone be able to speak we have an audience question sure you go first is there a future possibility where the e azam interpreter would take advantage of like special features in the underlining hardware for example I don't know you can use the GPU to do video transcoding well maybe web assembly in general there's like a proposal to add Cindy so that yeah yeah I'd like to add on to that a little yeah in addition to the existing proposal for vector processing and web assembly well if you have a JIT compiler like bobbum WAV m it takes advantage of LOL LVM JIT so when it translates it to hardware instructions LLVM JIT can understand that these instructions you can automatically vectorize and take advantage of certain hardware features like MMX and the SSE extensions yeah so so I just will repeat the same if you have smart compiler that it can translate code patterns in webassembly too and to utilize some advanced feature in the in the hardware itself I think that that comes to the the question whatever we will use this solution and if it's not some kind of do s attack vector so that's that's the main issue but if you would use a jet like full optimizing compiler as a JIT back-end it's available at the moment so it's nothing stopping to using vectorized abstractions not too sure about more exotic features like I don't know AES or something like that for encryption it's probably harder to to get access to it by injecting code particles in there in webassembly which is how it works you just kind of go step back provide some pattern that matches the implementation of the hardware instruction and compilers recognize this pattern and replace that with a much more efficient Hardware distraction and the cost of that is also and the size of the code on the web assembly side you have to keep in the state anymore audience questions as in this in this classic evm there are this different ways of a contract calling another contract like call and delegated call and statical does these calls translate one-to-one into the bottom world or is it done in a different way and I didn't addition I also this question was I think it was posed during one of the talks as well how can can these different DVM types calls interact with each other the second part when you say different EDM types you mean like an EVM 1.0 bytecode contract calling and he wasn't one or vice versa maybe a third question does this also translate to the upper level languages like solidity in some way but that's it that's another question yeah all the the various types of calls call call code delegate calls static call those translate one - one two - the II was some interface methods the host functions the there is a call instruction in web assembly which is how you invoke another function or you know function from some other was a module but and you could imagine trying you know to map a aspect where you know that would be equivalent where that would map natively its is calling a different contract but it's it's much simpler when you know trying to have compatibility with EBM to just deal with that at the higher level at the host function level yeah so that actually is essentially what hermia does it just uses web assemblies native call and call interact and has no import there's no we imported in that would give you something like all delegate I'll call it just uses wasum semantics but yeah Britax backwards-compatibility yeah currently we do have these imported functions and it's basically execution starts with messages coming in so it's kind of like the same as premier but it's compatible with idiom so say you start executing it was in contract that is a message to the VM that this is the bytecode it's the song okay just bytecode and TC we need to execute it and then it can call in to external functions and say if needs to call an EVM contract it just goes up to the client itself the client decides whether I want to use here for this or what I want to use the interpreter which is already in client what I want to use EVM - awesome and then here and that an instance is started up it's run as EVM if it's EVM or it's - it wasn't if it's a wasn't bytecode and whatever the output of that is that is just memory which is sent back so they are the own silos you can just run them in any kind of chain structure there there's no even you could run like delegate call in a way that say you could run delegate call of it wasn't and EVM over the same storage the only thing is they have to access the storage in the same way in order to use this to get out and save the same data but I'm not sure if this answer is a question yep cool all right I think we're about out of time thank you guys very much for the great questions [Applause]