# EthereumJS - Our Roadmap for 2019 (Devcon4)

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

## 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/ethereumjs-our-roadmap-for-2019

In this talk we will give an introduction to the EthereumJS ecosystem and the various libraries we are maintaining and provide an outlook on future developments. We will tell you about the state of our virtual machine implementation and plans on Ewasm integration and we will retrace the progress on our client project. We will further talk about where we think we can contribute to the latest sharding research efforts and explain why we get more and more excited about TypeScript, what AssemblyScript is and what all this has to do with progress and future integration of an Ewasm virtual machine. This will be a combined talk by various members of the EthereumJS team.

Speaker(s): Holger Drewes, Jared Wasinger, Casey Detrio, Vinay Pulim, Alex Beregszaszi
Skill level: Intermediate
Track: Developer Infrastructure
Keywords: ethereumjs, roadmap

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

hi I'm a hugger I'm team lead for the UCS team which actually is a JavaScript team was in the serum foundation and I'll give you a short introduction to what we have to what we're doing and then the other team members will introduce some some parts of the roadmap for for 2019 as what's the serious assume jaysis maybe this github organization that get up accomplish is serious and what Lane said we we mainly do base level infrastructure components in JavaScript so this is an implementation of the virtual machine deftly 2 p.m. limitation miracle tree implementation and so on and we've roughly have got 20 active minute repositories there so lots of work and mostly it's done by the serum foundation there are some other minute repositories from other people just as an introduction we do monthly ecosystem updates on reddit since some time so if you want to stay up to date what we what we are up to what we're doing at the moment go and read it and have a look out there what's going on I just provide in repository organization so if you've got for general project management stuff so if you want to suggest something which we could do better on new projects we should do you can go there and just file an issue there and then we can start a discussion there and we've got all mandatory jitter channel at a cerium slash assumed raise and you can go there for tech related questions or forgetting contacted in first first place as well so what are the characteristics of our libraries we initially developed from nodejs and then we distribute many of our libraries as well as is five modules for the browser so for example the VM is a browser first library and it's also actually run in in various tools like remix or meta mask or truffle as many development tools our libraries are high-quality libraries we've got unity tests you know unit tests for all the libraries all our CI integrated and we have two test coverage above 90% in most cases and this actually is really needed because yeah like like I said the libraries are very much used in production and also in security sensitive contexts and we do like behind a bit on on modernization of our libraries we are very much aware of set like using modern JavaScript features like promises and would be a very much callback based so and in your six classes and stuff like but we have this on the plate as well and we will do updates on that as well and another part is typescript integration where Alex will we'll talk about more later actually many of the work being done is actually coming from a community and we are highly community-driven projects and I'm always very much amazed that every now and then some super high quality pull request comes in like implementing Merkle trees or doing a super high quality new client RPC server and this is just coming out from from nowhere and I actually want to take the stage and say thank you to all you guys who contributed to our libraries and thank you and I've got very much this on the plate that we should more emphasis on this or that we should emphasis on this even more we do get it getting better and review times we are not there where we want to be but I have this very much on the plate that we won't even prove there I just introduced in labeling system as well and we've got a new corporation with good coin so many ways to contribute to our libraries and and also talk to us at Def Con just remember our faces and very happy if if we get an exchange later about what we can do and what we can do better actually um these are some of our libraries I don't want to dig in there too deep the virtual machine transaction library miracle patricia tree various utility libraries and an implementation of base level protocols like the ROP library for example and many others just to give you a short overview but you can look at the organization getup organization for for a better overview on that and there was already my introduction we have many speakers today and next is Jared who will give you some update on the virtual machine thank you so hi I'm Jared wah singer I have done quite a bit of work on the etherium Jas implementation of the virtual machine as well as other projects the virtual machine is designed to be a web first library it's embedded in tools like remix and used in other tools like meta mask it captures ëthere iam J theorem state transition rules as defined by the official test suite and it provides we like to think that it provides a modular implementation of the various blockchain components like the block blockchain the VM it's so that the community can make use of them in the browser and with nodejs applications so just to give you an idea of what we are doing regarding updating to Constantinople we've implemented all a IPs in the VM where we're still waiting for some additional testing around xt code hash and we thank the testing team so much for doing the hard job to provide those tests to us we also have a few edge cases in the create to opcode that we're working to fix and we're thinking that a release should come around two to three weeks from now in addition thanks to generous community contributions we have a brand new API test suite for etherium Jas and that has brought our test coverage to 93% so you know like like the whole the the theme of this conference I'd like to think is that we're trying to put the spotlight back on the community and I think that this demonstrates that and you know as Holger said we've just gotten so many community contributions and it's so wonderful so just to kind of give a brief outlook on what the future holds we're looking at integration with a wasum which is the execution layer for aetherium 2.0 but there's a few difficulties here that I can kind of touch on so II wasum defines an API that isn't exactly compatible with the browser in the sense that it's synchronous whereas the browser anybody who's program j/s knows that everything is async so we have a few possible solutions we're looking at one is to rewrite the VM to be synchronous I don't personally think that will work for various reasons but another approach could be to implement a translation tool and I won't go into too much detail because we could we could go a whole day on that so if you want to know more about this I would invite you to go to this link I have under more resources and we would very much welcome contributions on this front so if you want to if you want to contribute on this if you want to do something please reach out we're on git er is generally a good place to find us I'm gonna pass this off to Vinay who works on the client hi my name is Vinay and working on the etherium JavaScript client and so why do we need another client so our goal is not to actually build another consensus critical client like death or parity instead we want to build a working client to help harden some of the other existing JavaScript libraries like the VM and that merkel patrician tree etc another goal is to provide an R&D platform for new features like lit PDP support the etherium 2.0 stateless clients for example and then in you know future research efforts and finally I'm wanted to provide an educational tool javascript is really friendly to a large community of developers and it's a great way to to learn about the details of how a theorem client would work and so in terms of the architecture is heavily inspired by Bitcoin which is the Bitcoin JavaScript client and I'd like that it's it's heavily event written and based on a set of loosely coupled components which leads to a very extensible design for example through plugins and in terms of the road map currently we have a proof of concept of a client that could sync to me net and other networks through fast and licensing protocols and also a prototype of Lib p2p obviously that's not used to things to other clients because they don't support it yet but within the theory and jeaious environment it does work and also browser support and by the end of the year we want to hopefully provide reliable mean that change sync and with this includes block validation in transaction execution as well and then integration with a high which is a test setup to test a sync functionality and the goal about but a mid of next year is to have a proof of concept of a 2.0 stateless client and an alpha release of the current client so now there's enough time we're do a quick demo this is a video this is just furniture about the Wi-Fi impairment here so all of this code is downloads is available on github and feel free to run these examples yourself so this is an example of the JavaScript client syncing to the rinkeby network launching including light serve functionality and you can see here it's listening on both our LP x and our LP x and lib p2p transports and we'll save the live PDP URL for the next step in the demo and you can see it's downloading blocks so now we'll move on to the more fun stuff which is this is an actual demo of a browser that's connecting to the client we just launched over WebSockets which is available through the PDP and so we'll launch the clients in the console we don't have a UI yet but you can them here we're pasting in the URL that we copied in the previous step and so directly from the browser we're gonna connect it to that client and start downloading blocks and this this uses the local storage in the browser via indexeddb and you can see here this is just some of the raw data in the database so yeah so that's it so yeah it's great I know I'm again on the team of contributions there's ton of work left to do so we're hoping to get the community to help contribute them with it move things quickly so I'm going to hand this off now - Casey I'm Casey I started contributing to a theorem just last year for Byzantium so implementing Byzantium features in 2017 and I wanted to just highlight one of our research project - duze on the theory MJS team i'm also now working with the EU azam team so that's why we're get into this phase - because most etherium 2.0 R&D efforts right now are focused on phase 1 which is implementing the beacon chain there's another team chain safe who's working on a JavaScript implementation of the beacon chain called lodestar but as a member of the II wasn't team we're not so concerned with phase 1 we're focused on Phase two which is the going to be the execution engine of Jasper so one of our two days is prototype phase 2 right now there's a lot of ideas bouncing around for how - what the specs should be for the phase 2 execution engine all phase one does is orders a set of data blobs and that's actually the hard part so it's actually easier - if you have an order set of data blobs then should just process them as transactions and that's what the goal is for prototyping phase 2 one of the ideas being bounced around for phase 2 is stateless clients and it's actually probably the most this simplest you can do clients just has 32 bytes state route and I mean the trade-off is that then transactions become much larger because they have to include the merkel proof of all the touched accounts hopefully you can see this this is a visualization of the merkel patricia tree which is the tree that's used in aetherium current aetherium 1.0 so this is an example of an advantage of when you have lots of libraries and tooling and javascript you can do neat things like visualize them fairly easily and in the browser which really helps with debugging and and explaining how things work so to conclude why do we want to prototype Shaftesbury jeaious because there's already a lot of base libraries in jeaious and also you know user interface tools for example if we have to change the transaction format for a three-room 2.0 then getting those working in javascript libraries let's other projects like my crypto and made a mask in different wallets more easily test out these UI changes also there are mature networking libraries for example the p2p lib p2p is being adopted probably as the networking library for its theorem 2.0 and it's not doesn't have a mature implementation in every language but it does have pretty decent one in JavaScript also if the phase 2 execution engine is awasum then it's very convenient to have a native JIT powerful you know webassembly JIT engine from the browser so we get that for free implementing in JavaScript and of course I mean Java scripts everybody's favorite language so obviously should implement it in JavaScript and that's what I'm gonna pass off to Alex now [Applause] Thank You Casey so my name is Alex I've worked in the theorem GS for a long while but today mostly I'm focus on e massaman and this already compiler and anyhow I do have a couple of things to say here so there are a lot of 2.0 things flying around nowadays so just gonna talk a bit about the term GS 2.0 and what death may look like but first just take a step back and you know what is it Tim GS currently a lot of the API is in idioms es are fully synchronous a good example for that is the wallet and one particularly except from the wallet itself is random number generation that is expected to be fully synchronous today a lot of people run into issues trying to integrate it into mobile devices for a random number generation would be asynchronous but compared to that a lot of the code in atrium J's is fully asynchronous as it was mentioned before so one example for that is the VM that's fully synchronous um maybe we should have a bit more consistency between the libraries and you know choose one way or Dadar also a team chess was mostly written like two years ago and it has been upgraded and improved but only incrementally it hasn't been it hasn't had like a big wave right so maybe we should we should consider doing like bigger changes and you know improving it from the ground up while doing test improvements we may you know decide on choosing a different language so in the team there's like a bit of understanding that they may be going to typescript would give us some benefits [Applause] okay with typescript that the main benefit there is types types and types one big part of it Ria's today is with dealing with types and having a lot of code to ensure that the data is valid if we do that because we don't have types and and there were a couple of bugs with that so this example here is from 2015 the back in 2015 it was the famous yttrium J's bug where in 1 in 256 instances the public key would be invalid and some ether was lost during that process so the interest example we are concatenating the x and y components of the public key and in a case of the x component because it's represented as an array if the x component starts with a 0 byte that is just ignored we wouldn't have had this problem with typescript because all of like x and y component would have been a proper type also don't be afraid this comet is from 2015 the code has improved it doesn't look like this anymore some other reasons for typescript it is practically a typed extension of JavaScript so it should look familiar to everyone who has JavaScript testing favorite language and it can also be compiled to JavaScript and it can be mixed with JavaScript that means Java code can be imported as a result we don't need to rewrite everything at once we can do it step by step I have an important thing to mention here is assembly script so assembly script is a subset of typescript which can be competitive webassembly kisi has mentioned the bottom as like a future potential execution engine and so assembly script and supporting typescript nerium Jason having assembly script would enable us to write smart contracts in JavaScript and have it only wasn't and what doing this right be an opportunity to make things right and did it redesign it well ok what's the future like so today there's already an incomplete implementation of the EVM in typescript and it's not done by this team it's done by someone else and our own initiative is called et MTS but it features the chess team well the single person working on it has done a lot of work in rewriting the code inside yep I think we shouldn't hey I think we shouldn't have all these competing projects and we should just combine our efforts and have one complete fully tested comprehensive idiom typescript implementation so I think that's the future thank you [Applause]