 Hi, I'm Holger, I'm a team lead for the SeriumJS team, which actually is a JavaScript team within the Serium Foundation. And I'll give you a short introduction to what we are up to, what we are doing. And then the other team members will introduce some parts of the roadmap for 2019. So what's the SeriumJS? The SeriumJS is mainly this GitHub organization at github.com slash is SeriumJS. And what Lane said, we mainly do base-level infrastructure components in JavaScript. So this is an implementation of the virtual machine, DevP2P implementation, MiracleTree and so on. And we've roughly have got 20 actively-managed repositories there, so lots of work. And mostly it's done by the Serium Foundation. There are some other managed 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 are up to, what we are doing at the moment, go and Reddit and have a look out there what's going on. I just revived a repository organization. So if you've got for general project management stuff, so if you want to suggest something which we could do better or 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 our mandatory data channel at isserium.js and you can go there for tech-related questions or for getting contacted in first place as well. So what are the characteristics of our libraries? We initially developed for NodeJS and then we distribute many of our libraries as well as ES5 modules for the browser. So for example, the VM is a browser-first library and it's also actually run in various tools like Remix or MetaMask or Truffle or many development tools. Our libraries are high-quality libraries. We've got unit tests for all the libraries, all our CI integrated and we have the test coverage above 90% in most cases. And this actually is really needed because, yeah, like I said, the libraries are very much used in production and also in security-sensitive contexts. We do like behind a bit on modernization of our libraries. We are very much aware of that, like using modern JavaScript features like promises and we have very much callback-based still and ES6 classes and stuff like that. But we have this on the plate as well and we'll do updates on that as well. And another part is TypeScript integration where Alex will talk about it 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 requests come in like implementing Merkle trees or doing a super-high-quality new client RPC server and this is just coming out from nowhere. And I actually want to take the stage and say thank you to all you guys who contributed to our libraries and yeah, 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 in review times. We are not there where we want to be but I have this very much on the plate that we want to improve there. I just introduced a labeling system as well and we have got a new cooperation with Gitcoin so many ways to contribute to our libraries and also talk to us at Defcon. Just remember our faces. I'm very happy if we get an exchange later about what we can do and what we can do better actually. These are some of our libraries. I don't want to dig in there too deep, virtual machine, transaction library, Merkle Patricia tree, various utility libraries and implementation of base-level protocols like the RLP library for example and many others just to give you a short overview but you can look at the organization, get an organization for a better overview on that. And that was already my introduction with many speakers today and next is Jared who will give you some update on the virtual machine. Thank you. So hi. I'm Jared Wassinger. I have done quite a bit of work on the Ethereum.js 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 MetaMask. It captures Ethereum 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 so that the community can make use of them in the browser and with Node.js applications. So just to give you an idea of what we are doing regarding updating to Constantinople, we've implemented all EIPs 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 create2op code 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 Ethereum.js and that has brought our test coverage to 93%. So like 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 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 Ewasm which is the execution layer for Ethereum 2.0 but there's a few difficulties here that I can kind of touch on. So Ewasm defines an API that isn't exactly compatible with the browser in the sense that it's synchronous whereas the browser, anybody whose program.js 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 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 contribute on this, if you want to do something, please reach out. We're on Gitter is generally a good place to find us. I'm going to pass this off to Vinay who works on the client. Hi, my name is Vinay and I'm working on the Ethereum JavaScript client and so what do we need another client? So our goal is not to actually build another consensus critical client like get their parity instead we want to build a working client to help harden some of the other existing JavaScript libraries like the VM and the Merkle Petition Tree etc. Another goal is to provide an R&D platform for new features like libPDP support, the Ethereum 2.0 stateless clients for example and future research efforts. And finally, I wanted to provide an educational tool. JavaScript is really friendly to a large community of developers and it's a great way to learn about the details of how Ethereum clients would work. And so in terms of the architecture, it's heavily inspired by Becoin which is the Bitcoin JavaScript client and like that it's heavily event-driven 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 roadmap, currently we have a proof of concept of a client that could sync to mainnet and other networks through fast and light sync protocols and also a prototype of libPDP. Obviously that's not used to sync to other clients because they don't support it yet but within the Ethereum JS environment it does work and also browser support. And by the end of the year we want to hopefully provide reliable mainnet chain sync and this includes block validation and transaction execution as well and then integration with a high which is a test set up to test sync functionality. And the goal about mainnet 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 going to do a quick demo. This is a video because we're not sure about the Wi-Fi environment here so all of this code is download is available on GitHub and feel free to run these examples yourself. So this is an example of the JavaScript client syncing to the rinkabee network launching including light serve functionality and you can see here it's listening on both RLPX and RLPX and libPDP transport and we'll save the libPDP 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 so this is an actual demo of a browser that's connecting to the client we just launched over WebSockets which is available through libPDP and so we'll launch the clients in the console we don't have a UI yet but you can here we're pasting in the URL that we copied in the previous step and so directly from the browser we're going to connect to that client and start downloading blocks and this uses the local storage in the browser via indexdb and you can see here just some of the raw data in the database. So yeah so that's it. So yeah it's great I know again on the theme of contributions there's a ton of work left to do so we're hoping to get the community to help contribute and move things quickly. So I'm going to hand this off now to Casey. Hi I'm Casey I started contributing to Ethereum.js last year for Byzantium so implementing the Byzantium features in 2017 and I wanted to just highlight one of our research project to-dos on the Ethereum.js team. I'm also now working with the E-wasm team so that's why we're getting into this phase two because most Ethereum 2.0 R&D efforts right now are focused on phase one which is implementing the beacon chain. There's another team chain safe who's working on a javascript implementation of the beacon chain called load star but as a member of the E-wasm team we're not so concerned with phase one we're focused on phase two which is the going to be the execution engine of Shasper. So one of our to-dos is prototype phase two right now there's a lot of ideas bouncing around for how to what the spec should be for the phase two 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 to if you have an ordered set of data blobs than to just process them as transactions and that's what the goal is for prototyping phase two. One of the ideas being bounced around for phase two is stateless clients and it's actually probably the most the simplest you can do. Client just has a 32-byte state route and I mean the trade-off is that then transactions become much larger because they have to include the Merkle proof of all the touched accounts. Hopefully you can see this this is a visualization of the Merkle Patricia tree which is the tree that's used in Ethereum current Ethereum 1.0. So this is an example of an advantage of when you have lots of libraries and tooling in JavaScript you can do neat things like visualize them fairly easily in the browser which really helps with debugging and explaining how things work. So to conclude why do we want to prototype Shasper in JS? Because there's already a lot of base libraries in JS and also you know user interface tools for example if we have to change the transaction format for Ethereum 2.0 then getting those working in JavaScript libraries lets other projects like myCrypto and made a mask in different wallets more easily test out these UI changes. Also there are mature networking libraries for example LibP2P, LibP2P is being adopted probably as the networking library for Ethereum 2.0 and it's not doesn't have a mature implementation in every language but it does have a pretty decent one in JavaScript. Also if the phase two execution engine is EWASM then it's very convenient to have a native JIT powerful you know web assembly JIT engine from the browser so we get that for free implementing in JavaScript and of course I mean JavaScript is everybody's favorite language so obviously should implement it in JavaScript and that's it I'm going to pass it off to Alex now. Thank you Casey so my name is Alex I've worked in Ethereum JS for a long while but today mostly I'm focused on EWASM and the Solidity compiler anyhow I do have a couple of things to say here so there are a lot of 2.0 things flying around nowadays so I'm just going to talk a bit about Ethereum JS 2.0 and what that may look like but first just take a step back you know what is Ethereum JS currently a lot of the APIs in Ethereum JS are fully synchronous a good example for that is the wallet and one particularly example in the wallet itself is random number generation that is expected to be fully synchronous today a lot of people running 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 Ethereum JS is fully asynchronous as it was mentioned before so one example for that is the VM that's fully asynchronous maybe we should have a bit more consistency between the libraries and you know choose one way or the other also Ethereum JS 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 rewrite so maybe we should we should consider doing like bigger changes and you know improving it from the ground up and while doing these improvements we may you know decide on choosing a different language so in the team there's like a bit of understanding that maybe going to TypeScript would give us some benefits okay with TypeScript the main benefit there is types types and types one big part of Ethereum JS today is with dealing with types and having a lot of code to ensure that the data is valid we do that because we don't have types and there were a couple of bugs with that so this example here is from 2015 the back in 2015 it was the famous Ethereum JS bug where in one in 256 instances the public key would be invalid and some either was lost during that process and so in this example we are concatenating the X and Y components of the public key and in the case of the X component because it's represented as an array if the X component starts with a zero 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 comment 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 as their favorite language it can also be compiled to JavaScript and it can be mixed with JavaScript that means JavaScript code can be imported as a result we don't need to rewrite everything at once we can do it step by step and what important thing to mention here is assembly script so assembly script is a subset of TypeScript which can be compiled to WebAssembly KCS mentioned eBosm as like a future potential execution engine so assembly script supporting TypeScript in Ethereum JS and having assembly script would enable us to write smart contracts in JavaScript and have it on eBosm and while doing this right we have an opportunity to make things right and redesign it well okay 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 Ethereum TS but the Eaters.js team well the single person working on it has done a lot of work in rewriting the code in TypeScript I think we shouldn't hey I think we shouldn't have all these competing projects we should just combine our efforts and have one complete fully tested comprehensive Ethereum TypeScript implementation so I think that's the future thank you