# Ewasm: Ethereum-flavored WebAssembly and Ethereum 2.0 - Part 2 (Devcon4)

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2019-10-09
- Duration: 42:08
- Topics: blockchain, smart contracts, distributed ledger, Science & Technology
- Watch: https://streameth.org/watch/yt-W4T4Q_SUQt0
- YouTube: https://www.youtube.com/watch?v=W4T4Q_SUQt0

## Description

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/4/ewasm-ethereum-flavored-webassembly-and-ethereum-20-part-2

Ewasm is a candidate for the future Ethereum engine to replace EVM with the rollout of Shasper. Ewasm stands for Ethereum-flavored WebAssembly and it encompasses a broad range of initiatives being led by the Foundation Ewasm team including building an execution engine for Ethereum 2.0, adding support for a host of languages including C++, Rust, and AssemblyScript, and lots of related research and tooling to make Ethereum development easier and more powerful than ever. The team is in the process of launching a public testnet and releasing tooling which will be officially announced in this breakout session. In addition, members of the Ewasm team will introduce the technology, walk through the new stack, and give demos of the bleeding edge development tooling we've built around Rust, AssemblyScript, and other frameworks. We'll have an hour-long workshop where developers can download the new tools and get their hands dirty, building and deploying their first Ewasm-compatible smart contracts, with the team serving as mentors.

Speaker(s): Alex Beregszaszi, Guillaume Ballet, Paweł Bylica, Hugo De La Cruz, Casey Detrio, Paul Dworzanski, Jake Lang, Lane Rettig, Jared Wasinger
Skill level: Expert
Track: Developer Infrastructure
Keywords: eth2, eth 2.0, updates

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 4 was held in Prague, Czech Republic on Oct 30 - Nov 2, 2018.
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

up next we have Paul and Guillaume who are going to present on Watson engines get away okay hello my name is Paul I'm going to talk about webassembly engines for awasum those are they one two three four five six the first three or four we have working at in some in some capacity it seems that there's a big push to use the Firefox in the chromium web assembly engines they have they have various sort of tiers of engines they have their baseline engines which are just single pass linear paths to compiled to machine code then there are the optimized versions but so I was asked to talk about web assembly engines but I just want to talk about what web assembly is in general so there's 150 page specification and it specifies a syntax of the language sort of grammar so how to construct programs and on top of this definition of the syntax they define a validity which says you're guaranteed to return or pass some arguments and it's guaranteed to do certain things and then finally they define execution execution is defined as rewrite rules what is that okay so somewhere in some web assembly program we have these two - app codes kant's 0 and call 0 what does it mean what does it do imagine 0 ok so first of all web assembly is given to you as a module it's a web assembly module dot wasman file it's a set of functions it's a that's a memory it's some abstraction that lets you do function pointers that's called a table some things to initialize these tables in these memories things to import an export and you have this module which is a set of functions so it Maps well to an an ethereal account which is also account code which is also a set of functions and you can call you have imports and exports so different modules can call between each other but somewhere in one of the module and one of the functions we see this what is it what does it mean so Const 32-bit Const and call zero call zero means call a function the function in this module which has index 0 so imagine that's the function that has index 0 that's what assembly code you don't have to know what it means but it's some chunk of whatever that you can execute when you see this code somewhere else in that module so this is how a web assembly program executes we see this these two app codes and then we execute these app codes by rewriting wherever we see this we replace it with that chunk so what is this chunk we take everything in this function loop to get local we copy it we paste it here we've used something called the frame this is just what it says in the spec I'm just mechanically doing what they tell what they say in the spec to do it says well then we have in these brackets we say locals there's a parameter it takes that constant zero we copy and paste it here then we wrap all of this code in something called the block that's just what it says to do so that's what I'm doing I'm just rewriting that I'm deleting it and I'm replacing it with that then what happens then we we rewrite the thing that says block with this I just read the specification I'm just doing what it told me to do then once I rewrite where it says loop and I punch and I put in labels 0 and then I copy and paste all of this this text including the loop parts into here I wrote it in small text so it could fit what happens next this get local so we're sort of going going along we we saw a black we saw a loop then we see a get local app code what does that mean what does it do it says to take that counts zero that's the first local there could be more and copy and paste it delete where it says get local and paste into it where it was I 32 can 0 then what so we're sort of going along and then we see these three app codes what do we do with these three app codes to rewrite rule again we replace these three app codes with the sum the ad with the sum of the two so we replace it with a count one as you see it's just rewrite rules the whole semantics the whole execution semantics is we're just rewriting chunks we're capping and pasting text what's next we have a T local which means we take whatever is above it put it into the local cons and then we also paste it here and we delete where it says T local I'm just rewriting stuff I'm not doing anything controversial it's just what the spec told me to do then I'm doing a less than unsigned operation and replacing it with the 1 because 1 is in fact less than 3 so anyway this just keeps going and going and finally I get to this and this is my last slide for the Oise imagines talk so what's the point why did I just waste your time with this sort of rewrite rule stuff I went from this somewhere in my code and I and I just rewrote it a bunch of times all the way down to this and that's how we executed web assembly these rewrite rules so what's the point that's how the spec defines it it's just rewrite rules nobody implements their engine like this people implement their engines with swift steps there could be one stack there could be two stacks there could be three stacks when I implemented the engine I did it with three stacks for for various reasons there's stacks for these function call frames there's I have a stack for the function call frames I have a stack for the labels and I have a stack for the for the operands other people keep their frame their function call frames and their and their control flow labels in the same stack there is advantages to doing it my way because if you keep these in the same stack you have to sort of every time you return from a function you have you have a linear time if you're nested in a bunch of functions so that could be a slow down the point is everyone implements their engines however they want to implement it and people do it differently but they're the whole goal is to make web apps they want to have like you know alien fighting games and in their browsers and things like that and if Crash's if it fails who cares but if everyone's implementing things their own way then maybe someone's going to have a bug someone's going to introduce an invariant that they're gonna ignore later on and something's gonna go wrong and if it's a web app who cares but if it's adapt when there's a lot of money on the line then we might have problems so I think we have to focus and spend a lot of time making sure we implement it right to audit these engines these you know we talk about Firefox and chromium they want to have some micro optimizations for their benchmarks that they're interested in but but you know we do we want these micro optimizations so I'm just asking questions about do we trust this stuff the spec says to rewrite stuff no one's rewriting it everyone's just doing it their own way so what's the right way to do it I think we have to audit and keep a close eye on everything so that's the web assembly engines talk so as lean so I'm giving the next talk as well it's called turbo awasum increasing transaction through butter blossom is our code word within our team of increasing transaction throughput this is joint work between Dielman ID and other people on the team of course have had good conversations with us and so the big idea is what is what are we doing now a theorem execution at serial execution as you all know we're disk i/o bound they say and we have max 20 transactions per second what does it mean what a serial execution mean we're executing transaction one then we're executing transaction 2 then we're executing transaction 3 and so on into the last transaction what does disk i/o bound mean this isn't to scale by the way but if you took some operating systems course you've seen some image where you're doing some work and then you're waiting for IO and you're waiting and you're waiting and if it's this guy o bound the disk these these sort of i/o ranges dominates the work ranges and so we're waiting and waiting and waiting for disk IO to come back and it comes back and we do work and we do work and it worked and now we're waiting and waiting again and so we're doing 20 transactions per second and I don't know when sort of engineers see this kind of thing they're bothered why can't we fix improve this because this is awkward and we're engineers and we know how to do these kinds of things so that's Geum and I had some conversations about this so aetherium shards we might have the same thing shard one might also be limited to 20 transactions likewise with char - likewise with all the shots so some use cases like these plasma on ramps off ramps state channels payment channels whatever might not be usable if we only have 20 transactions per second so sharding does scale help us scale in some sense but is it meaningful we still can't use you know if a million people want to get out of this payment channel we still unusable so let's try to talk about increasing throughput on each individual shard and maybe cross shards so when people say why can we use sharding they start talking about independent universes independent galaxies things are independent what does it mean what does independence mean so I guess - transit so we'll define what independence means - transactions are independent if they do not touch the same state location this is an illustration transaction one in transaction two transaction one touches the upper-left the transaction two touches the two bottoms and you can consider these transactions independent of each other so with inch so crushed in different shards we're guaranteed if they say that a transaction in shard 1 and a transaction in chart 2 are independent of each other so we can that's the whole idea they're independent galaxies we can execute them currently but how much transactions within the same shard so the focus of this talk is within shard transactions into trash our transactions across our transaction is the transaction for example from shard one - char - okay so what is someone that wants to scale do an engineer usually will go to perhaps Wikipedia and look up models of concurrency and they'll read about actors models and process calculus models and maybe we can use these things and people are using people are looking at this I spoke with actors with capabilities the gentleman that invented the premia witch Definity is using Vanna goreck is using these ideas process calculi are chained rolling doing great work fantastic work and they're talking about paralyzing and increasing transaction throughputs there are they're also using these idea of Independence with premia they're called vats or with the actors and capabilities in general they're called bats shardis equivalents of that in some sense and process calculi they call it namespaces so everyone's using independence so you know a good scientist or engineer says what is this independence thing let's define what this means and let's take it as far as we can take it because you know we're engineers we're working at the margins let's see let's see what we can do okay so we're going to define what independent subset of a block is an independent side a subset of a block of transaction is such that each transaction is a subset such that each transaction in the subset is independent of all transactions outside of that subset that's a tough definition that's a toughest definition of this talk for example an independent subset is transactions two and three they're independent of all transactions outside of the subset transaction two is independent of one transaction three is independent of one so these two are an independent subsets just to clarify that's because transaction one okay we do not write to any location that the set of teks two antiques transaction transaction two and transition three fright to correct yeah so we have some sort of maybe you can have a visual proof that you see that transaction one writes to this and it's independent based on this the definition of Independence which was in a previous slide which is a relationship between two transactions and an independence partition of a block is of transactions as such is a it's partition into independent subsets partition we know this partitions partition of a set is is a breaking it into subsets such that their union is the whole sudden there pairwise intersections empty so the the independence partition of this sort of black would be one subset is this just this transaction a subset with this transaction and other subset is these two transactions and we noticed that we might be able to run these concurrently because they're independent of each other just like shards are independent of each other okay so how do we how do we build this independence partition for three transactions we could just look in point and say look these are independent but if we have a whole block of things it might be difficult so we have some algorithms to partition the pool transaction pool or block of transactions into independent subsets what is access lists first of all there's a IP 648 there's a push with each transaction you say I'm going to touch these state locations and only these state locations if I violate this then then my transaction is invalid so there's a push for access lists and shards so there's there's two cases we can either we can do it with access lists or without access lists let's talk first about with access lists so I'm gonna do a visualization and it it is it might be tough so we have our block we order our transactions from one just forget about anything below transaction zero transaction one all the way to st. transaction 60-63 we notice that transact and then we write the same transactions on this column we notice that transaction 0 and transaction 0 interact which are dependent on each other so we put a orange square there and also 63 whatever this is based on accesses we take these access lists we compare see if they intersect with the with you know 10 second 0 in 63 yes they do 4 0 in 63 so we put a a orange square there and we can partition this block of transactions into independent subsets so this subset this this is upset you know this chunk of transactions is independent of all other transactions why because there's no orange you know things colored in here so this is maybe the kitty cat app this is a decentralized exchange this is some mixer this is some ICO these are one-off transactions and we can execute each of these sort of chunks independently of each other because of this independence property just like shards are independent yeah I got it okay likewise if you have many more transactions you can break it into independent subsets so this is just an idea to paralyze a given block we're not doing it yes so that's the big so you see these independent there's many so we can do it we can scale this okay without excess list that's awkward we currently don't have excess list and etherium so we might execute a transaction see if it sort of hinders our concurrency so if it touches a bunch of these independent subsets then we won't include it of course there's a DA stack worst case will go to serial execution but this is one possibility to scale the main chain and it's all based on independence the simple idea that you know independent universe's galaxies we're just taking this as far as we possibly can like we're maybe scientists or engineers so then each independent subset we execute on its own CQ perhaps we've already known this since since e IQ 648 this is nothing new but this but this sort of act this this looks like the sharding picture where shard zero shard one to shard n but each one is sort of not shard we're sort of dynamically creating shards and we're solving two important problems within a single shard and cross shards we we can use these ideas so we vom and I are sort of trained in computer science science and we sort of talk about operating systems and when you take an operating systems course you learn about threads and preemption and we have this disk i/o bottleneck so our idea is to use threads so each thread corresponds with an independent subset so we start executing thread 1 which is independent you know the top left corner of independent or whatever it starts executing it asks for disk i/o there's a scheduler in operating systems as you know it'll preempt this thread while it's waiting for i/o and schedule this thread so it's doing work this this this thread starts waiting this independent subset is waiting for for i/o preempted this one is doing works or essentially we're trying to use 100% CPU so we're trying to eliminate this i/o bottleneck whether it's disk i/o whether it's network i/o whatever it may be and we're just using a things from operating so we can just use a regular operating system with P threads or whatever this stuff is available now or do it you know with many CPUs so hopefully we can use 100% of hardware that's the dream of like you know computer scientists use 100% of hardware I think so yawn play clean up so as quick maybe a reminder so the question thank you was about ball neck so i/o was very well explained that I always make in a theorem 1.0 it's disk i/o it's apparently it's debated whether it's the biggest bottleneck but it's definitely up there in ECM 2.0 if you start having stateless clients if you need to get your state from the network it's not so much this guy oh well altum Utley will be this guy oh but it's not so much this guy has network latency and things like that but that means that you will spend a lot of time waiting for your data to arrive or to be written and as a result this is this really makes sense to try to get the the computer or the the miner to do something while this is happening so what we want to do with this with this work like that was the preliminary research work what we want to do is to is to increase story to extend the definition the definition of independent independence between transactions do you want for example imagine you have like let's say an IC or a crypto Kitty kind of kind of profile where a lot of transactions correspond to the to the same into the same contract can you also generalize the independence to two cause within the same contract can you for example use something like SIMD or you know some MapReduce kind of kind of programming paradigm so that you can make sure that every single thread or every single transaction touches a different area of the state and run them concurrently knowing that they won't they wanted to hear so that yeah that's that's what we're looking into we also want to look into other other ideas for example gas calculation so you heard before about the metering or the Sentinel contract something that will scan your contract and add calls just to use gas to make sure that gas get properly accounted for what we would like to do maybe is like to see if we can explore what we would like to explore possibilities to actually pre meter the contract so reduce the need to do this because first you have to scan the contract but then every time you have to make a call and that's kind of inefficient so we want to see if we can just have a simple gas rule see if we can have an upper bound or a formula we just look at at your binary we say okay this is roughly what it's gonna cost and charge that we one of the interesting things that really where wisdom really brings a benefit it's the replace contracts contracts call with function calls so right now when you call a contract you have to reinstate a lot of things like you basically I'm talking about yes you create pretty much a new VM a lot of data structures but ultimately this is what you want to do is is a function call you're not actually calling a contract on a different computer you're coming something on the same computer so why not make it a function call so you would have something like imp you know like pseudocode or sudo python import that function from a contract address and just get everything loaded and you can start doing lots of things that get inspired by operating systems like you know manage modules like you like operating systems manage libraries if you see that a module gets loaded very often you just leave it in memory so that when you load it you it's already there you can do something require modules to have the full list of contracts to basically like you had access lists for state locations you could also enforce the same thing for modules we also get inspired by two turbojet unfortunately the two bogus presentation was at the concurrent time in in a different room but yes so they try to replace all the state try or at least try to optimize the way it stored the weight success maybe that's still a suggestion from the name escapes me Alex there at least say thank you mark a very smart guy how to maybe have all those contrasts all those states in a like linear contiguous space why not with protection of course yes and we also want to use some of the features of wisdom that are on the roadmap they are not they haven't been released yet or at least not officially agreed on yet but you have mutexes you have SIMD so for those who don't know SIMD is a single instruction multiple data so the processor has one instruction that does the same thing several times it uses the parallelism that is inside the processor and yeah that's what we're and we're looking into [Music] [Applause] Thank You Kim and Paul there was really intense big applause again for them one addition to all of this is we are considering all these different improvements and we're lucky if you're in a really lucky position that we can consider adding these improvements today wasn't test net or spinning up a new it wasn't tested and add these improvements to it but hopefully if we managed to at any of these they're going to be a really good test bed to have them fully specified and finally implemented in the main net now next one on stage is Casey d3o Casey has been around forever he's really into research and he's more into keeping it to him alive and in to improve etherium and his talk will be about a new idea how you could do scaling on a much bigger scale and we may also consider having this on only wasn't at some point big applause for Casey thank you it's not exactly new idea it's just a dream 2.0 the Jasper serenity research which I heard in the news recently that the etherium 2.0 research is stabilizing finally stabilizing which is good to hear because maybe now we can answer one of the most basic questions just how do how are we going to deal with a large and growing account state this is one of the main problems in scaling even if we wanted to scale 1.0 we would have to deal with the account state [Music] sorry and actually doesn't have really anything to do with you awesome because he was them is just an execution engine and the execution reads and writes to the state so if you want to implement an execution engine then you've got to decide how you're gonna handle the state so I guess it kind of falls on us to decide that so we wanted to say a little bit about it this talk it's not going to be highly technical this is supposed to be an overview for you know of like the developer experience and the user experience and the challenges and changes that will have to be made in order to scale aetherium so just the goal is having a a lot of users lot of transactions and transactions and where the gas price remains cheap if the gas price is if the gas supply is limited and you have a lot of users then the gas price goes sky-high so how do we keep the gas gas prices cheap again well if you don't want to sacrifice decentralization you could just run all the validator notes on all transactions on 21 validator nodes on supercomputers but if you don't want to trade off do you centralization then ideally you'd be able to run a validator note on you know any consumer laptop that way you can just keep adding more laptops and network and scale so to solve this dilemma our hero sharding chess perma card face [Music] what's the plan phase one we collect a lot of data blobs we have a pretty comprehensive spec for doing this you know it's like eight different teams building it out it's the beacon chain they say you know some of these prototypes should be functional soonish and then then there's phase - well phase two we think we're gonna use yozma but we still I mean we're not really sure how we're gonna do phase two we still have to iron out some details but there is good news because phase one is actually the hard part so phase one is the consensus protocol the consensus protocol comes to consensus on the order of the data blobs coming to the consensus protocol is actually you know very complicated because the outcome is non-deterministic every validator has a different view of the network you know data blobs arrive in you know different orders and different validators you have all kinds of hairy game theory issues with you know malicious actors and network partitions and it's yeah it's it's it's a challenge phase two relatively speaking is much more straightforward you all you have is it's a deterministic system the order of the data blob is already known you have one block you process it you get you know the next block comes you process it and so forth so with if phase one is behind us and you only have to worry about the execution engine and Phase two next then you're actually you know not that far from the finish line we learned yesterday that Jasper is actually kind of lame it can be a bit of a buzzkill my two main complaints about Jasper are that for one it won't shard it won't it won't scale contracts that exist on the main chain you know Jasper is going to be excuse me serenity will be a new you know parallel universe of 1,000 empty shards and users will have to migrate to them you know I don't know redeploy contracts transfer state somehow but when it launches it'll be a ghost town get it Casper ghost own secondly shards are gonna have the gas prices will be independent on each different shards so you know in theory this is not really a problem because if you end up on a really popular shard and the gas price is expensive then you can just you know move to a cheaper shard where there's not as much activity I think you know this is I mean yes in theory it's kind of like telling people you know who live in San Francisco and are complaining that the city is not scaling the supply of housing that well it's no problem you should because you can just move to North Dakota one point no problem of this kind problem in general 1.0 2.0 is that there's a too much state users pay a one-time Gatsby they create an account in the state tree and that account is there forever and all the full amount all the miners just have to keep all this these you know junk around indefinitely so what techniques do we have what approaches we have to reduce the state we have two of them stateless clients and storage ran with stateless clients there's a single 32-byte storage root and when you send a transaction to the network so miners Valladares have only the 32 byte storage route and when you as a user send a transaction to the network you have to supply the merkel proof of your account so you can prove that your account has such-and-such a balance and you can send either these merkel proofs have to be up-to-date so i'm have a visualization of that next but in contrast storage rent validators basically users pay validators to do this job to keep the account in their state and to keep the merkel proofs up-to-date and when you have storage rent within an eviction or sleep and awake like a if accounts don't pay rent then they get evicted from the tree but then there's ways that they can be a can revive their account and come come back into the tree then I mean basically those techniques are very similar to how stateless clients work so it's kind of like with storage rent there's two classes of users there's like first class people who can afford the rent who the validators handles all of their merkel proofs and the second class which is all the poor people who have been evicted and will have to supply their merkel proofs in order to reawaken their accounts with stateless clients there's just one class it's everybody you know in coach everybody has to supply their merkel proofs yeah it's not a new idea either just you know this is from the etherium analysis report from lisa authority back in 2015 and it was even you know discussed in bitcoin before then so yeah the problem with keeping your Merkel proofs up-to-date is that at the top is the stake road and then so at the top of the tree at the bottom are the leaves these are where the accounts are so your account is one leaf and then next next to you is a another account and that's somebody else's account but the branch the the proof data that you want to supply is this Merkel branch from you know your leaf account up to the state route and in that branch are these intermediate tree nodes now these intermediate tree nodes change when the guy next to you makes a transaction so it's not so if you go offline and then you come back it doesn't matter that you didn't make any transactions it matters that you know other people are making transactions and now your proof is out of date so you have to go back in history and kind of reprocess these transactions to get your proofs up to date yeah so people really don't like either statelessness or storage rent the reason they don't like statelessness is because again the problem of keeping your merkel proofs up-to-date also somebody who flirts and smokes weed a lot such that when I wake up from Crowley if I just want my brain wallet to work I don't want to have to you know you imagine if 50 years later your proof would have just been changed like you know within the first year after you went to sleep so if those blocks are still available somewhere then you're okay but the question is you know what happens if those blocks are no longer available then well you're screwed and that's kind of why people also you know you say setup there could be some service that says I promise I will store you know all the old blocks even if you come back 50 years trust me they'll be here and people say well I don't want to trust these rickety you know layer 2 services I want you know about to have some guarantee that validators will be storing my my account obviously people dislike rent because you get evicted if you don't pay also capacity is limited so the you know fees can spike high it breaks user experience that we've you know come to expect that a contract will still be there there are workarounds for this like if you know again this sleep in awake but that's just you know adds its complexity which maybe you can tuck under the hood from the implementers point of view if you're starting from scratch then in my opinion stateless is obviously the way to go it's clean simple it's ideal about validator only has to store a 32 byte State Road rent is messy and complex there are lots of parameters you have to decide well you know I mean do you set it at 16 gigs or 32 gigs and then you know how do you do the fee market so forth I think some people even the stateless is almost too simple so they just like you know engineers who sometimes like complexity and they just can't resist from adding a rent feature onto the stateless I mean if you're not starting from scratch so if you have like if you're in 1.0 today then it's probably easier you already have a whole tree that the miner is forced to to store it's probably easier to you know add on a rent feature and you know start trimming the accounts then you know swapping out the whole thing and switching to stateless so lastly point is that change is coming here currently minors have this full burden and while it's you know it seems kind of easy because you know somebody else's I don't know if you're using in inferior or made a mask or a light client it you know it's relatively easy to sink if you're running a full note it's still difficult to sink what is going to happen is that it's not sustainable for miners to keep storing all the state so validators are the gist space is going to be minimized the core of the network you'll be able to sink very quick so lifer a validator will become great you know the process of sinking and processing blocks will become very streamlined but on the other hand if you are a user or a wallet client life is going to get somewhat painful sinking is going to be harder scraping you know if the data to you'll have to manage your own data you have to come up with your own proofs unless you you know can pay the rent so that's it I mean you know while it developers are gonna have a tough time okay thanks Thank You KC big applause for KC again [Applause] so thank you all for being here today we're gonna pull up the the URLs again please join the Gator room try the test net the URL for that it's II wasn't that material the doric all the demo what Jarrett has shown should be visible they're joined Gator again get the discussion started we're gonna have the CVM panel now focus on EVM we probably gonna be free after that if you guys have any more questions that's all the details you need to know thank you