 Hi everyone. My name is Holger. I'm working within the EthereumJS project, which is a JavaScript project of the Ethereum Foundation. And today I would like to talk a bit about the state of the JavaScript ecosystem, as I see it, because this will be very much EthereumJS centric, but I will try to look a bit beyond the EthereumJS and also look at other libraries, which are there. Thanks, Ralph, also for having me. I'm actually living in Vienna. I attended lots of Ralph's meetups, and this was actually one of the reasons why I actually dig so deep into Ethereum, that Ralph always made such great presentations. So thank you for that. I also, during my talk preparation, at some point I put an asterisk on this ecosystem thing or on the title, and actually added to the title that I would like to talk about this in the light of a future sharded Ethereum, because I thought this would be maybe a bit more future proof and a bit more interesting. I will put everything a bit in a comparison. How is the JavaScript ecosystem now and how could it look like or how is it already developed within a sharded context and what is already there and what will be there in the future. So what is EthereumJS? Maybe a quick question. Who knows EthereumJS? Okay, fewer than I thought, actually. Okay, so EthereumJS is kind of historically evolved a bit out of community contributions, and now it's sausage. github.com. And we are mainly doing base-level infrastructure components in JavaScript. So what is not EthereumJS, for example, is Web3JS, which is a very popular library to connect to Ethereum nodes. But we maybe do stuff like we have a virtual machine implementation with a Merkle tree implementation in JavaScript, an RLP library for data serialization on a networking level, so stuff like that. One main focus of us is, most for sure, the virtual machine, because this is used in popular death tools, for example, like in the remix IDE or in Truffle, in the Truffle development suite, all virtual machines is actually executing the transaction in the background. There are roughly 20 actively managed repositories, and mostly done by the Ethereum Foundation now, but there are also other, some repositories which are done by other people, like the Blockstream library. For example, there are some people from Augur, I think, are doing these libraries. We have one repository called organization, which is for project management stuff. So if you've got ideas, what we could do better, or if you've got suggestions, you can go there and just find an issue. And I just revived this a bit, because it was a bit orphaned. Yeah, but now it's a bit more active again, and we will have a look there and we can go into a threaded discussion. Yeah, maybe you can change some stuff. We also have a digital channel for our communication, which is located at Ethereum Slash, where you can also go there, if you've got questions on the libraries itself. This is a bit the agenda I came up with for today. So I will look at four centric blockchain specific topics on version machine, the consensus layer architecture of clients and developer tools. And I will talk a bit about what is the Ethereum 1.0, what is the current state, what JavaScript libraries do we have and also, you know, what are the characteristics for current Ethereum 1.0 structure. And then I will move on a bit to Sharding and at some point it was obvious what it would take for Sharding and at some point I also had to come up with stuff because there are also areas where there is not so much there. And I just, I don't think about, imagine with myself what could be there in Sharding. Okay, I'll give a short Sharding introduction. This talk is not primarily about Sharding, but just to give you an overview what the state of Sharding is right now. Sharding a lot changed lately at the moment. We've got an official work in progress specification, which is the Casper and Sharding chain version 2.1 specification. This was a long time, this wasn't some notes, documented notes that Ethereum just moved a couple of days, moved to a dedicated repository on GitHub, on Ethereum, slash, East 2.0 specs. So now it's easier to find that's already a win. And this is the main specification which turned out now be the primary print for implementing Sharding. And then we've got these East 2.0 implementer calls which Ralph already mentioned. And I can highly recommend to look at these notes from these calls. And because these are highly, or you just listen to the call itself, but it's a bit quicker to look at the notes than the notes are also very, very detailed. And give a very good overview of what this talked about at the moment, what are the main topics, what are the research topics, if you want to dig that deep into that. So there's also a repository for that East 2.0-PM. And you will also stumble on it if you follow the reddit channel in our Ethereum. The main thing going on on the implementation side is from a team called Prismatic Labs. I don't know who knows Prismatic Labs, just to get a bit of an idea of, okay. So Prismatic Labs is just a team which formed out of nowhere in New York. And they were so good that after a couple of months they got a really substantial grant from the Ethereum Foundation, like several hundred thousand dollars, I think. And now they are doing the main implementation of Sharding at the moment on a repository called Prism. And if you want to really look into the code for Sharding, then that's the main place to go into the Prism repository. You can just search for Prismatic Labs on Google. And Prismatic Labs are really what they also do a really solid implementation. But what they also do is they buy weekly updates on their blog. And that's not just only telling what they're implementing right now, but they're talking a lot about the context on what they're implementing, they're implementing that and explaining the background structures of these as well. So these blog posts are also highly recommended if you want to go into Sharding. On the Sharding introduction level it's getting a bit more difficult because so much changed so lately. So if you Google, for example, Ethereum Sharding Medium, you won't find some medium articles on Sharding. A lot of these articles are kind of outdated because Shardings have changed so significantly. And some might be worse to read. I have nothing to recommend specifically, but you have to look at, especially at the dates of the articles. Because if the article is nine months ago or so and even six months ago, then it's kind of outdated. And otherwise, if you can wait a couple of weeks more until you want to really get deeper into Sharding, you can also wait for the DEF CON 4 talks being recorded and published because Sharding will be the mega topic at the DEF CON presentation and there will be lots of talks in Sharding. So some history on Sharding. Yeah, actually I thought about should I talk about Sharding history or not as it's going to be, but then I thought I can't talk about Sharding with not mentioning the history because actually it was just June 2018 that the Sharding and the Casper argument changed completely. And then this was a time where Vitalik was in the Cordiff's call and it was Cordiff's call number 14. And that was kind of decided or published that before the structure was that there was a Sharding manager contract, which is a contract in Solidity or Vipirings, the other contract language. And this contract was managing validators for the Shards and doing the Shard relevant stuff. And also Casper, the Casper FFG, was also mainly put into a contract, the Casper FFG contract. And this changed completely. And now there's a separate dedicated chain just for Sharding. This is called the Beacon Chain, kind of the central heart now of Sharding. And this unifies a lot of things. This unifies the Shard management and also puts Casper FFG, which before was for giving finality to the main chain. So this was a proof of statement mechanism for just validating or finalizing blocks on the main chain. And now this concept is generalized and the Casper concept is also taken, the proof of state concept is also taken for validating Shards and for getting a unique or unified view on the latest state of the Shards. So before we had some kind of data structure that was also kind of realized by the research team, they were just implementing on various locations the same stuff like validating stuff and finalizing blocks or Shards or whatever. And now we have a much cleaner architecture which is also less intrusive because it's not directly connected to a contract of the main chain which is then executed to the editor at the beginning of a new block cycle. Then there would always be Shard processing or Casper processing, which was just very tightly connected to the main chain and which also had some limitations on scaling because now we can do much more Shards. I think it's now going up to 1, we cannot directly do 1,000 Shards because it's much more separated structure we have now. So there's no mainnet bottleneck, bottleneck mirror and much better scaling. So it might be, I don't know how it was for you if you heard about this earlier. For me it was a bit frustrating because it was another delay of Casper involved and everything is delayed. But I'm very, very sure that we come up with a much, much more solid structure for Shard and scaling for the next decade or even two decades. So some overview on the structure we know in Sharding and Sharded Serium we have the main chain and this is more or less unchanged except that it forwards staking requests to the beacon chain. So you can deposit, I think, 32 ETH in a contract on the main chain and this is kind of then burned or put aside or something. And this is then forwarded to the beacon chain and then you are participating in the proof-of-stake mechanism in the beacon chain. And this is then used for validation of the Shard state. So the latest blockage of a Shard is then put into the beacon chain. This is called a crosslink. So that in the beacon chain we have a unified view of the state of the different Shards. The Shards state is kind of validated so that we can work with this latest state. And then we've got a Shard chain. We've got a third type of chain and there in the Shards chain which can be rethought kind of very much from the bottom up. We've got the actual data, we've got transactions and we've got some kind of machine running, executing transactions and doing all the stuff we had before on the main chain. And we still will have on the main chain. Some picture on this, so there's a main chain at the top which provides the input for staking. Then there is a chain for this beacon chain. One main topic for the beacon chain is also to provide random numbers generated in a distributed fashion. This is also a highly discussed research topic like how to generate random numbers and how to generate them from within a distributed nature. We can do this unbiased so that they're good random numbers which can be taken for taking from the validator pool some validators which actually do the validation processes because otherwise you can have various types of attacks if you just have some pseudo random numbers which can be guessed before. And then with the Shards chains below it's okay if you don't get everything from every block from this picture. There are the Shards chains below which actually provide the data and by the end of staking is executing transactions. This is actually not not my, not my diagram I put checks, took this from Xiao Wei, which is a researcher at the Ethereum Foundation. Okay, there was some introduction to shorty. I'm now going in the first topic with which is a virtual machine. And this is again a bit the agenda for that. So what are the current characteristics for for the virtual machine and so at the moment we've got a stack based 256 bit virtual machine. So this kind of bit different than the normal design of current computers with 64 bit with over 100 codes and these codes are kind of like dedicatedly invented for for the serum machine. So this was all written up in the yellow paper. And there are codes for for arithmetic operation and specific specific of codes like address or balance, which are requesting the current address or the current balance, or codes for calling into other contracts and many more. And the thing is also their code count is continue growing. So now in Constantinople, we've got two more. We will have two more codes like what I've talked about. This is X code. So the thing is actually getting more complex over time as well. One thing is also they are pre compiled in the current virtual machine, which means that you for some operations are the cost intensive. And you just can't do them in a in a contract in a Solidity contract or something. And so for for something like a hash generation, which for example, for example, here in sh a 256 hash, which is kind of the hash standard used in the serum. This would be too cost expensive. So there would be too much gas used for that. And so this is then implemented natively in the code of the different note implementation like in JavaScript or in in go or in in Rust. Yeah, these pre compiled also adds complexity to the to the whole virtual machine level. The other characteristics are that the virtual machine has to be deterministic, which means it's always have to come to the same result. So this is the pre definition of a blockchain. And it is in the serials. The context is tier and compete. So can more or less help in everything you would expect from a computer. One example here in JavaScript. One example on upcodes, for example. So you start you start with a Solidity contract. Solidity contract is compiled into bytecode. These by codes represent represent actually the different upcodes plus some values in hex written in hex 0x. This means this is a hex value, hex a decimal value. And this upcode is kind of forwarded to a virtual machine and then executed. If you look at this, this is actually some part of our JavaScript virtual machine implementation. And this is this is the whole implementation in NodeJS for the block hash of code. So this is just plain NodeJS code is provided the number. And then JavaScript blockchain object. A block is requested from a JavaScript block hash blockchain object with this number. And then the block hash is read and passed back to the virtual machine where this is put on a stack or on memory and then this is operated onwards. And there are more operations onwards on this. This is kind of just as a short example how we have implemented this stuff. This is an example for pre-compile. Just to give you a nice idea of that. The hash pre-compile I talked about earlier. This is also the whole pre-compile. And this, the main thing is just here down there that this actually just it's just calling a JavaScript function as a 256. It's just using the native JavaScript code or in Go it would be analog to call this hash function. So this is pre-compile. And when we do new development for new, for a new hardware, for example, not for Constantly Noble, we have to do this for XCodeHash. And then there are tests, external tests, which have to pass so that every client stays in consensus. Yeah, this is our JavaScript virtual machine that's called EthereumJSCM. So every, more or less all our libraries are kind of pre-fixed with EthereumJSCM. And this is actually by then, at the moment, it's a by then some compatible virtual machine. Our Constantly Noble is currently working progress. I hope that we can finish this in the next two, three, four weeks, but I won't promise. So this would be good, actually, because then developers can use this or then remix can deploy this so that people can use Constantly Noble features in remix, for example, on Truffle. So we are kind of in a hurry because we know that developers use this for the work and to test their contracts, for example. This, so our virtual machine works on a browser and yeah, like I said, use cases are for example, Truffle and Linux. This also has a relatively clear structure. If you want to dig a bit deeper into virtual machine and you know how to read JavaScript, then one way would be, for example, to go into our repository. This is relatively clear to read on a file level already. We start on run blockchain. We run JS, then run block JS is called on a specific block, then the block is separated into transactions and then run transaction is called and all the pre and post processing is taking place. Like calculating gas costs or stuff like that or emitting lock events or stuff like that. And this is going down until the code level like the file is, I think it's called up FNF at end up functions chairs or up FNS chairs. And there you can really see the code of the different of course, like I presented for you. So if you're interested in digging deeper and see the virtual machine, this is one way you could go. Actually, this is much better than reading the yellow paper. I started with the yellow paper and I just got completely desperate after sometime because I couldn't read it. Yeah, so what are shouting specific needs for a virtual machine? There are no so much specific needs. But since we are starting fresh with sharp chains, we now have the freedom of choice and there's no real need for backwards compatibility. And since the current virtual machine design is not so optimal in terms of performance and then also in terms of design complexity, we can start fresh here. And this is where it wasn't comes in. Yeah, so most for sure on the shirts, it would be it wasn't as these standard language or these standard virtual machine for for executing these contracts. It wasn't as a is a deterministic subset of WebAssembly. So WebAssembly is kind of like a native language standard for the web, which is kind of a kind of major browser vendors like Mozilla and Microsoft and Apple and I think everyone worked on WebAssembly. This is now incorporated in the browser and we use and we will use a subset of WebAssembly, which makes it deterministic. So the results are always the same. And at some specific interfaces that called Ethereum environment interface the I just providing some functions which can be called get address that block hash, which are which are a bit similar to the one presented earlier. And you can see a bit some WebAssembly code there you don't need to be able to really read that just as an impression what's going on there and this is kind of like a standardized set of instructions. And this allows actually for for faster code execution. So probably won't be the need for pre compiled so hard folks get much, much easier. Are also less frequent. And the one, one of the main benefits is that there's a promise that smart contracts can be developed in traditional languages. So, don't have to rely on solidity anymore. And we can also use a whole tool chain from WebAssembly WebAssembly is a huge effort. And there's a whole community around this WebAssembly stuff. And we can use all the tools like colliders and developer tools or whatever. There will also be much more on this DevCon for. Yeah, if you're interested in that, check out also the DevCon talks. And there's a dedicated it was a team at the Syrian Foundation and all the code produced there you can also find in the top dot com slash northern. And one thing which is particularly interesting within in the JavaScript context is a language called assembly script. And this is actually I found the super exciting stuff. This is a restricted set of typescript. So, so type script if it is a super set of JavaScript with types. And this is a restricted set of typescript. I'm not TypeScript expert I just read this from the documentation that there's no any type which just losing TypeScript a bit again to to allow different types again. So to make make it a bit more comfortable is JavaScript with this a bit on the low ground. I'm not sure if I'm correct here. This is restricted a bit. And send a script compiles down to WebAssembly and actually creates very small binaries, which can very well be used in a blockchain environment. And there at the moment there experiments within the e-walls and team to make assembly script and officially supported e-walls on language. So, and this will mean that you will be able to actually use JavaScript or TypeScript to do your smart contracts. I think this is this is pretty exciting here at the right there's some some code how such a country could look like these are just experiments from the to randomly from the e-walls on repository. So don't take this as a quote how things will look like just as an idea how things could look like. There are also there's also some code you can find in the e-walls on repository and GitHub. And there's kind of some more or less, I think it's more or less the official ID for WebAssembly development environment for WebAssembly at WebAssembly.studio. And you can also go there and send this script is actually an officially supported language there as well. So you can open a template in the same script so that there you can see this is just not some side product from someone, but it's kind of getting getting real. And this will hopefully allow, yeah, contract in JavaScript. Okay, that was everything to the virtual machine topic now move on to consensus and to to coordination of how the blockchain is created. What what if we get now. We've got the ET hash proof of work algorithm and mining. And proof of work is hashing together some random values from a large data set called the DAG. And the result is to be below certain threshold, depending on the difficulty. And the DAG also this data set is changing frequently. So this makes this memory hard and relatively hard for for Essex to work on. And I'm not super much proof of work experts. I'm not sure about the specifics about progressive proof of work and what's in the discussion there, but generally, that's generally the idea. And this is distributed to the network via RPC. And the main main message here is get work to get somewhere. And then the miners submitting the work with the submit work. You get a mining or reward for your mining and this leads to one of these off second block times in JavaScript. We also got an ET hash implementation. This code is taken from this. From this library, it's called ET hash. Which is a working in implementation, which is also good for learning. If you just want to look into this algorithm and get a rough idea what's going on there. But it's also slow because it's JavaScript. You want to have this a bit more performance. There's a whole set of bindings library, which just binds this to the C plus plus implementation. Just called note dash ET hash. But since I'm not super much a proof of work expert and also not so super mature and expert for these libraries. You have to look at this yourself if this is useful for you because I'm not not that sure about that. Probably mostly mining is used with other clients that like parity of views because there you've got the performances where mining is taking place. But we put implementation in the JavaScript for this as well. So now insurance. Like I said, we know it's a beacon chain. And so before this whole this whole blockchain validation was kind of like some algorithm was in the main appliance. Now we've got separate proof of stake chain. Which is explicitly responsible for for all this proof of stake mechanism. And so the proof of stake validation mechanism is similar to the original customer mechanism. Like I talked about before. So there's a block there. You've got a pool of validators. So everyone was given this 32 is getting into a pool of validators. Then there's this with the help of this random number generation that someone selected as a block proposal, which can propose block. And this block proposal this block actually contains mainly contains information about the charts. So it's like I said, it's called the cross links. So there's a confirmation of the latest state of the charts. So that we have a unified view on the different on the different charts, which will pop up. And the block proposal is proposing a block. And then a committee of a testers is selected. And these testers confirm if this block is valid. And if this block is valid, then there's this proof of stake thing, then the proof of the proposal at the reward. And if this is not valid, then then proposals. State gets slashed or at least partly slashed. So that's kind of the customer mechanism mechanism from before, but on a generalized level. And this validation mechanism is still used for main chain finality, which gives. You can also talk about that. You can also see talks about this on, you can see the former customer talks, which are still very much valid on concepts like finality or something. Finality is just some stronger guarantee that a block won't revert on the blockchain, but I couldn't explain this much further. And with this contact of shouting, we've got minimal main chain changes. So there is this additional deposit contract, which is just a contract which at one point gets deployed. And there is one new client method called prioritize, which is given a block hash and a value for this finality thing. And this won't be very complex method. This is just one method which has to be added to the clients who implement main chain logic like GSR parity. So in other words, the main chain stays unchanged, much less of a risk for the actual running main chain. We also have some implementation of a beacon chain in JavaScript, which is called load start chain. So if you want, if you're into JavaScript and want to get an idea of shouting, you can also start there with this time I changed the systems. I think this is a consultancy team. And I had some look at this. This is not so far in its development stage. This is just some, some basic provides a basic implementations of the various state objects, which are relevant in the beacon chain context like the cross link. The red code for a cross link or a block in a beacon chain or the crystallized state, which is another concept of state changes. Yeah, but it's, it's not going very much farther and it's not implementing the actual logic of the beacon chain how everything is processed there. So you get the first idea, but if you want to look into code, I recommend to look at this prismatic labs code and this prism implementation, even if this is in go and you may be not. And prismatic labs is pretty, pretty new. Actually, that now released their first release on beacon chain. And as in the last week, you can read a blog post on this, and they named it very humbly version 0.0.0. And this is extremely humbly because there's an extreme amount of work already done in this. This release, but many things are just some things work and some things just other are just simulated, but this is kind of actually, I think the first release where you can see shouting and action and then this kind of a bit similar like when you're you're starting a G's client on the console and see a look at all the, all the console output. And you can now you can with relatively easy steps like it's like half a page of instruction. And then you actually really see a beacon chain client in action. And this actually makes them all these, these concepts like crossings and are everything which is going on and all the terminology much more. This is much more grass because if you read the specs and you're, you're kind of like often or at least was for me was like that. You're often lost again and again because you just can't really say why what is it. What's what's what's all the stuff on what they crystallize state and if you see this in a in a lock output and see actually some interaction this gets much, much more real. So maybe this is one of the best things to start and get excited about sharing this in the latest blog post just described how you can start with it. Okay, so now, now it's about, I will talk about the client architecture and how these are client will differ in a sharded and not sharded. Yes, and client is also, I will talk about this a bit more later, but the client means really the sharp clients in a sharded context. And this is very much work and progress and then there are many things which still need to be determined. So, yeah, so this is, I will focus a bit on on the networking layer and some other things, but they're, this is one of the topics where there's much very wide in the open. So what are the current current characteristics of of current clients for assume. So, so we have the machine one execution engine, which I already talked about this kind of slow uses pre compiled, there's a small community to move forward on on on with. Current clients are always stateful. So, say for just means you need to store state and some amount of block hatches or all the blocks. And this is, this is true both for for all types of nodes like for full clients for fast and even for like you have to store state with, which leads to long download times and a large disk space use on your hard drive communication flow on the other hand is at the moment is relatively easy, because you're just communicating inside the blockchain and then in between accounts so we can create you can call into other accounts. And this is what proven this is how it works now for some years. Yeah, in the short word, it's getting more complex. And the networking communication is done by a deputy to P, which is a, which also some some protocol which is just developed for a serum. And this can also be losing with what we see is an lippy to P, which is a standard protocol. But I'll come to this later. In JavaScript, we also, we know also if a client implementation, or at least this is in development, which is, which you can find the series as client. So kind of like a classical main client. And this is in development since April, 2018, and led by the pool. And we'll implement fast and light sync. And we actually at least at a state where, where blocks assumed and in fasting mode and light sync mode. And you can already run this if you go to our repository over there. So this won't be a consensus critical client because of the limitations of JavaScript. But we want to use this both for education. So if you just, if you're in JavaScript and you want to know how client works, you can go to, you can use our client to know something about the serum ecosystem. And we want to use this for experimentation. So we have very loosely covered components with the generalized and unified structure. So there are classes like class protocol and then subclasses is protocol and LES protocol. And in the future, Whisper SHH protocol, or there's a generic class server and subclasses are the X server or the P2P server on for the networking layer. And this is this mainly work on VINI who makes this very loosely happening, very highly reusable. And so we can, in the future, the hope is that we can do lots of research on this around networking, around sharding by just, for example, exchanging the networking protocol or something. And one thing I'm especially excited about this, that this is implicitly hardening the other CMJS libraries. Because the CMJS is historically very much running just in simulation context. Like in remakes, it is just not the actual blockchain run on this, but some test transactions on some test code. And by developing a client or machine would implicitly also run the real main net transactions. And this is one of my hopes that actually we do this. We get the, especially the virtual machine closer to the real thing by having to process the real main net transactions and seeing if this confirms or if this goes along with the results of the other implementation. So what do we have for shard clients? Like this is not too confused with the beacon chain node. So these are the clients for the shards. Like I said, there are very many to be determined. And this is very much open research. And I ask our researcher, Xiaowei Wang, on this. And so because I'm also not an expert on this. So we will have involved in an execution engine, like I already said. There's a lot of research going on in stateless clients. And I think they're promising research results already. So that you won't have the need to store state, which makes it which will make us use the clients actually much more usable because you just can start the client and then you're on the network. There are some this is there's this not super pure. There's not just a super pure concept, but there are also some kind of mixed versions where you have to download some minimal state. Yeah, but there's a lot of research going in this direction that you just are quasi stateless. So you don't need to download state anymore. And we have got before we've got just communication between accounts and now we've got cross chart communication. And this is also one big research topic. So how do transactions come from one chart to the other? And how is this communication taking place? The main question is there, are we doing this asynchronously? Are we doing this synchronously? I mean, we're doing this within one transaction and you get the result within this one transaction, which would be much would be what you would expect and what would be much more convenient for users. But this has some special challenges. And there's also at the moment, I think it's there is a new tendency in the synchronous direction. There's also a post on the research forum about that, you know, or some some proposal from Vitalik, how you can do that. But this is also very much work and research and progress. And we will use the Slip P2P library for the network communication. And on the shouting JavaScript side, I will focus just on the Slip P2P section and I will do two more slides on the P2P because everything else is just very much work and progress and research and progress. And the Slip P2P is relatively settled that there will be a Slip P2P as a networking communication technology. So just some, I would just give some short introduction into the P2P. This is a bit like, so this is actually the networking stack of Ethereum and this is doing the, we use a transport on the serialized data layer. Like there is a discovery process where this is all this distributed nature with having peers which has to connect to each other through the discovery process. And in our implementation, this is called, which is called depth P2P or Ethereum. This is called DPT or you have got a distributed peer table. Then you have to transport the data and the classic Ethereum is called RMPX. So just really make up some communication channel and then do some back and forth hello and having a channel ready to actually transport data. And then you get the application data and applications still there on the low side. So this is in the classic Ethereum, this is called the EASE protocol or the ADS protocol. We just actually transport blocks or transport transactions or request transactions from other peers. This is dedicated to construct for Ethereum in the classic word and now we've got the Slip P2P project, which is just also like a bit like WebAssembly, a generic community effort for just building up network layers. And we can very easily use this now for the networking communication in a sharded Ethereum. This is also a bit like a much larger community. It's also works in a browser which is also a big advantage so that it will be easier to make clients for the browser, which is also a big thing. Yeah, and if you're interested in the networking layer, you can go to github.com. Slip P2P where we'll find a specification of this technology. You will find reference applications in Go and in JavaScript as well. Networking is really hard stuff. Yeah, and so I just... Yeah, but it's kind of interesting to take a bit into that because this is very much all these peer-to-peer mechanisms which are just very relevant for Ethereum. Yeah, at the end there's also boils down to some Node.js code where events are emitted. I don't know if you know... Node is the event framework and you have... On the left we've got the FCM.js. Slip P2P implementation on the right, the JS. Slip P2P implementation. I won't explain this code here. Just at the end there are just some events emitted peer added, for example. In the network, you know, there's always stuff taking place. Like when your peer was added, your connection to the peer was lost. And then you can react on what happened there. And actually on the Slip P2P of that peer added as an event and in the Slip P2P of that peer discovery as an event. So there are some similarities there. Yeah, but I won't go deeper into that. Just to give you an impression of what's there, what will be used in the future. And you can effort Slip P2P and create the specification if you're interested in that. The last topic I have on the page is developer tools. This is the topic which is completely in the open. Because I think developer tools are just... This is just often the topic which is coming at the last of the chain. The infrastructure is growing and then at the end the tools are coming, building upon the infrastructure and providing tools which make life easier for developers. Like an IDE or a compiler or whatever, or just tools for connecting to the network. I just would like to take one example of a tool we have today. This is the overview. One example of the tool we have today, which is the Ethers.js library. This is actually not an Ethereum.js project, but done by a third-party developer. And this is a very popular JavaScript library. I've gotten lots of traction in the last months. Because there's a third-party developer doing very solid implementation of a wallet with account management. Getting JavaScript objects from an ABI, from a contract interface. Connecting to a serial node through different providers, through this classical JSON RPC mechanism, or through MetaMask. There are similarities to this Web3.js library. There are some other functionality provided in this Ethers.js library. You can deploy contracts, you can execute or communicate with contract methods. Yeah, this is well-tested and documented. And this is also using TypeScript. We are behind on that. So this is also kind of the library I'm looking at where I want to have inspiration which we could do better on some fronts. If you now look at our... If you now have a look at the charting and just try to imagine how would this library look like in a charted Ethereum world? Where would this library have to change? Yeah, you find that there is just very much still in the open and on the charting front. So for example, I'll ask me the question, what would be the ABI format in a charted Ethereum? Which is E-Watern contracts, for example. And then I just found only one reference when Googling on the E-Watern repository on the organization on an issue from 2016, actually. And I'm just quoting this, since E-Watern changes the work size from 256-bit to at most 64-bit, it's important to state whether it follows the same ABI for contract data passing or defining the one more appropriate to its work size. So, completely in the open. Yeah, and probably there were some changes, but this is an example for something which is just completely undefined and not yet determined on the charting board. On the question of connecting to a node, what would have to change there on the functionality side? You can ask yourself the question, connect to which chart? The unified functionality to connect all charts available in the chart network. There are also new infrastructure challenges. So, imagine an Infero. Infero is actually a service where you can connect through an ABI to an Ethereum node without having to run your own node, which is very useful for developers and for different kinds of purposes. And, yeah, imagine Infero for 1,000 charts and Infero has to maybe 1,000 blockchains or so. So, there are really new infrastructure challenges on that. There's a question, what language or will be used actually to talk to a node, what API? At the moment, we've got this defined JSON, obviously, API with all these different methods to talk to a node and likely this will also change in a charted world. So, will there be unified API for charts or will the charts have some specific functionality which also needs some specific language to talk to? And how will this affect the tooling world or the OO ecosystem and the standardization of all this stuff? And lastly, there's the topic of contracts. Yeah, now we've got E-Wasn bytecode instead of EVM bytecode. Compilation from various languages, not just Solidity. Will Solidity even be compatible with E-Wasn? And, yeah, I look for this in the E-Wasn API queue and the answer actually was maybe. So, yeah, we will see what this will bring. Probably there will be some cross-compilation stuff, so you won't have to be afraid that your Solidity knowledge will be worth nothing anymore in the charted world, but there will definitely, probably there will be a shift to the other languages and this is also very much in the open how this will play out, where the other languages become dominant or is this just a branded idea to use these other languages in the other languages just to generic for these smart contracts? Hopefully not. Yeah, very much in the open. Yeah, then there's a change between the AQIS contracts and eventually an updated ABI. Yeah, so lots of open questions there. Yeah, lots of open questions. And if you're interested in these open questions, you can also directly go to the research forum at E3 Research, this URL over there, and really dig very deep or directly dig into the actual discussions on various topics like cross-chart communication or random number generation and really see what's discussed there. For me, this is often on a level that I can't really follow what's going on there because at some point too much mathematics, but it depends on what expert you are. You can go there. So many open questions, but there's also happened really a lot in the chart world and I'm really excited about charting. If you, for example, look at the implementation of prismatic labs, you really see an enormous amount of work already being done. Yeah, I think it's on a very, very good track and I'm really excited to see what this will bring for the future of Ethereum. So yes, this was my talk for today. Thank you very much. Any questions? I haven't heard much about main chain changes. I don't know where it works, but it's definitely in the works. Okay. Now my main question is, will Ethereum be transition? Will it only be very sharp lines or will the main chain lines also transition? I haven't heard much about main chain changes. Actually, this is one topic which is a bit orphaned at the moment. I have the impression of what will actually change on the main chain because everyone is just so focused on the beacon chain and on the chart chains to some part. At the moment the main research is actually going on in the beacon chain world. And I have no current idea if the main chain will also transition to the PTP. For me the main chain changes in the future are still a bit black box. I'm also not sure about this proof-of-work-to-proof-of-stake transition. I didn't find a lot of this as well on the main chain or will this always stay on proof-of-work? I hope not. Yeah, many things are not there at this point. So do you think it would be feasible to run a live client into location in a browser in the future? There is work in this direction. And this would be much more feasible with this blockage ray-back turn, which is always delayed. The CRP from Morales mentioned. And one blocker is also this PTP networking layer with which to live PTPs would be much easier. But as I said, I'm not sure this is coming to the mainnet at some point. Maybe at the moment we're kind of in a transition period which takes a bit long and it's a bit hard to always give this answer a way for charting. But in a chart-to-work, many things will just be much easier and different. I don't know if this is so satisfactory to just stay away for two years and charting it there. But it's definitely the case that the mainnet has lost a bit some focus or work on the mainnet. So yeah, I'm not sure. And related to this live PTP, this is not, as I understand, is it exclusive to Ethereum or is this a generic implementation? No, it's a super-generic implementation. It was mainly developed for IPFS. I don't know if you know that. This is kind of the interplanetary file system, which is a distributed file system. Also very generic where you just can store files in a peer-to-peer manner. And live PTP is just extracting the best practices of what people experience with developers trying to implement their own network instead in an internet environment. I mean, the live peer-to-peer and other ways of distributing blockchain data or whatever, transactions or blocks or charts or whatever, isn't exclusive to be used with one library that can be like a multitude of different peer-to-peer protocols in place at the same time. I think you kind of ducked with live PTP very much to your needs because the general specification is giving you helpers because it's also very modular and you can take some parts of it and then the duck some stuff also to your needs. But I'm also not super networking expert. I think there's one thing called MDNS, one module which will be used for discovery or something very much on our shaky ground. Any other questions? I think you mentioned random knowledge. When the knowledge generates before and you said there's some more research right now, I'm just interested in you talk that it seems very complicated for me that our system is fairly live and something where in the closed computer system we don't have a source of entropy before MIME so I don't know where you would produce anything close to a random number. I'm also not a photographer but there's one repository I think which is independent from Ethereum which is called the RAM DAO which is kind of random number DAO like DAO and losing all the money. And this kind of like a distributed organization where people are putting this entropy and it's also implemented like this in an easy shape that actually people are putting this entropy inside this in their not proposals or attestations but I know for this what I got is that you have to do this randomness on a distributed way by putting this entropy from outside into the chain by validators just running your validators in the chain Yeah, that's all I understood. Everybody tries to do something that seems to be random and then we manage it all together and then it is random The idea is that those validators have to commit to values beforehand and then after a while there's no way they have to reveal and because they have to commit it and because they all have to do the same thing they basically there from the area south is random except if all of them will collaborate against you but if there is one validator which is honest then it's a good random opportunity it just requires to be one of them to be honest which is I think good enough And you can have a look at this research for a moment I'm not sure if you are dedicated to random number generation I also had no real feelings for this before but it seems to be a hard topic and this is actually one reason for the PPC chain at all to have this random number generation solidified I'm really still using the event because I thought it would switch to the special signatures like... maybe this there is a 2D question for me I heard both of the words but I'm not sure that this is enough in the context so to answer this I got the random number so because of what we have moved to the infinity I've created some signature scheme to generate the number instead of the random number I have no idea if this is still the plan or not so the infinity is an alternative which is kind of very hard to say also comparatively there I wanted to know if you ever looked into we still have a problem of examining the network like there is some... in terms of logic source there is still only Intel scan who can grab some values especially going into internal transactions with smart contracts there is some kind of complexity and it seems like EthereumJS would be very suited for a back end of like a data aggregator for blockchain explorer I don't know it might be a bit of a limited thing or like a topic but so you did never I think many libraries which are run on the web using some similar websites like make a mask or also blockchain stores for representing accounts for representing transactions so I just can give you this very general answer that if the existing solutions aren't satisfactory then you probably could use also EthereumJS libraries to build some things better oh yeah my question was if there is in the team because you said you're going to build some focused work and for me like I work mostly front end so having the data would be so awesome but I just cannot scan from some things and if there will be an infrastructure project like providing more information about those hard to access data points what I'm actually using at the moment is for accessing the blockchain it's kind of the setup that I use either Web3.js or Web3.py and I connected to Enfuro actually what I mentioned earlier where we just access just a simple API access to the blockchain and then I request there with three methods information about the block or something what I found most convenient what I do know is how much I'm trying to advocate I'm also somewhat far from the front end side so this may be a good question but how would Nostics use your ATM implementation to other layers of the efficient stack like networking and so on can I just plug in the difference like networking to the ATM so you mean the virtual machine or the client okay because the virtual machine has nothing to do with the network layer this is just a virtual machine just a code execution where you just get the the bytecode that gives the bytecode in and it will be able to end some cash and the result you can actually that's nothing to do with anything you know what would have to do with anything else where things are really coming together and where for example they are reconnecting to Nostics and exchanging data and on top of that there is a blockchain and there are blocks with the virtual machine I'm not sure if they have where to start this application there is this project working on a complete client in JavaScript it's completely in development so you can run this with the Node command line command and this is starting to see the blockchain in the fast mode and get the blockchain up to date and not super fast but also not super slow but I can't give any estimation where we are what is the relation between the real JS team and the ganache team which used to be part of the human JS is there overlap of the developer in the completely separate teams? no this completely separate so the ganache is far from trouble spinning up a simulated blockchain environment and they are often kind of requests from the ganache to us because they are using our base libraries but there is no overlap between I have a very basic question about sharing because it's changed recently a lot I couldn't keep up with everything so how is now when you want to move data or transactions to a specific chart how do you make sure that these transactions are not in conflict with data on other charts so the question is how do you make sure the charts are not conflicting each other except by executing all the charts on one master chart? one general thing is there is very much work in progress not very much really but what type of contents do you have? for example if I reference data on a different chart and I assert that the data should have a certain value and on this different chart there could be a change of state without me knowing about this on my chart in the meantime so therefore if I reference data in a different chart then I somehow must make sure that between now and then the other chart commits to the beacon change there is no state change in that particular value of the different chart so how is that ensured between I mean that's what the beacon change is for the chart synchronized depending on computer clock time I think there is loss in the beacon change which are 80 seconds this is synchronized really by time but I I'm not sure about this I think this also has very much to do with the synchronous where the action mechanism so if you're doing a cross-chart synchronous then at the end obviously at least you're sure that at the end different actions are every chart has one step further but for me it's it's good to have this discussion to generalize the question a bit if I take charting in a very traditional database I always have a key against which I chart so let's say all those customers between 1 and 1,000 are on this chart and if I am to know something I know which chart to ask so the question would be against what is a chart what kind of property so maybe that's it I think I'll have a life I think it's less less like the charting of we just randomly stack things apart and then can use a system as it was before this is more like I would say one application would probably stay on one chart as much as it can because it will be some kind of difficult to take in force and I also still know a few pictures about the benefits this is actually integrated and about the limitation there very often discussion of the clear picture of the different questions before we go to socializing we have one small announcement from Sotan my name is Sotan I just want to talk a little bit it's gonna be 3 minutes maybe can I just create