 So, next speaker will be Jashek Cieka on how to build your own Ethereum client with the development story of Nimbus. And you need to, actually you can go now, it's called. We're good. All right, hello everyone. Anya Tsek, come from status, he's a hurry. I'm working on this Ethereum client called Nimbus and if you wanna follow along the presentation on your own laptop, I think that URL should work so you can just skip ahead and do what you want, right? So, we're gonna talk today a little bit about what goes into building an Ethereum client, like what you need to, what should interest you if you want to become a client developer for Ethereum, right? And before we go there, I wanted to look a little bit at where we're coming from, right? As blockchain developers. And I don't know if anybody recognizes this, anybody play that? Yeah, all right, cool. So, I mean, this is absolutely perfect. Sid Meiery had such a great thing going here that every technology we invent basically builds upon stuff that we've already done before. So, in blockchain that will be writing mathematics, currency code of law, there's engineering, all kinds of things, right? But there's one thing in particular which is very important to blockchain development. And that is cryptography. And the reason we're sitting here today and are able to have this conversation is because of some pretty important people that made sure that we have cryptography available to us as open source developers, as people in general, right? Because not long ago, like around the time when I was learning about the internet, crypto was considered a weapon. You wouldn't be able to export it, you wouldn't be able to use it, you wouldn't be able to know how it works as a private person, right? And back in the day, we had these people, these cipher puns, and they would do everything they could in order to make sure that this technology would become available for people to use and profit from. They believed that privacy and encryption was so important that they would commit civil disobedience in order to get us there. And the funny example of this is in the US, for example, Philip Zimmerman, they had these laws there which said that you could not export crypto, but if you printed a book, you could take the book with you and that was protected by freedom of speech. So all kinds of tricks like this they would do, they would move to offshore platforms and really find ways to make sure that this technology spread to us, right? The other big thing that happened when I was growing up was this. Anybody recognize these fellows? Right? FreeNet, immensely important project that back in the day. They started with the idea that information should be available on the internet for anybody to store, upload, and download without others being able to block it. You could say that they were one of the first people to think about, not really the first, but they thought about the internet as a shared storage or a shared repository of information, right? Followed came lots of other projects that each contributed important things to blockchain technology as we know it today, right? Merkle trees, they would use them to identify files, distributed hash tables, they would use them in order to communicate with lots and lots of nodes efficiently and know where to find information, right? Peer-to-peer networking basically. Execution, now this is a little bit more recent. This is an interest of mine. I don't know if anybody recognizes this fellow. LLVM, now this is like the compiler developers' dream. It's a toolbox with all the toys you can imagine. You can build your own compiler in like five minutes. And the blockchain that we're developing for in Nimbus has a virtual machine on its own. So it's kind of another one of those prerequisites that you have to have in order to build an Ethereum client today, right? You have to know a little bit about how virtual machines work. You have to have the technology available to you or build it yourself. And all these things happen around the 2000s, 2010 maybe, and then they sort of stagnated and the machine learning people came and become very popular and all this faded a little bit. Until one more new thing was thrown into the mix of these previous technologies, right? And can anybody guess which one of these it would be? Economics, yeah. Economics, very well. It wasn't banking, that died off as well. Economics and incentives. I like to use this example simply because it's one that everybody knows more or less. This is basically the barter version of a blockchain. You give pieces of files to somebody and the more you give, the more willing they are to give you. The important part here is that there is an economy involved. There are incentives that are aligned for you to share a file in order to get other pieces of that same file, right? So with that, we have more or less the things that like the basic building blocks in order to get going in the Ethereum client space, right? Cryptography, networking, some form of execution specifically in Ethereum but it's really true for all blockchains except they're more or less static and some form of incentives, right? So Nimbus, we started this project early 2018. Around the time Ethereum 2 research was still very in its early days. Not a lot was known about it and we knew that we have a lot of work to do in all these areas that we were working in. Now we chose NIM, which is a language that doesn't have very much already done. It's a fresh language, not so many know it. It's an advantage for us because we can affect the language's design, how it's used, how it's developed but it also means that we had a fairly large amount of work to do to develop these base components of encryption, networking, these things that I've talked about, right? So we started basically working on Ethereum 1.0 because at the end of the day most blockchains are roughly the same. Like if you look at them in an abstract way they do mostly the same things. So for networking Ethereum presently uses a protocol called DevP2P. It's a protocol that allows multiplexing, allows it has a DHT for example to look up other clients. It has an encoding so that you can send information blocks back and forth between clients. It's a fairly standard peer-to-peer protocol but it's specific to Ethereum, right? For cryptography, a lot of the stuff that we do is based on these fellows, elliptic curves. In Ethereum 1, it's SecP256K1, the same one as in Bitcoin. We use them to sign things mainly. There is other cryptography involved as well in the DevP2P layer which simply encrypts the traffic going back and forth between the nodes but it's shall we say less important. The important stuff is in the elliptic curve cryptography because basically when you wanna send a transaction what you do is that you generate a private key for your elliptic curve. You sign the transaction and you send it to the network and the network knows it's your transaction by the public key. Your public key is also your identity on the network. On Ethereum, execution is pretty straightforward. For every block that we execute on the chain, right? We start with a certain state. We receive the block on the network. We apply the virtual machine state transition function and we come out with a new state. Obviously if this was done willy-nilly, there would be problems because you could spam the network with transactions or execution that would go on forever. So in Ethereum we have this concept of gas. You pay for what you use and what you use is tied to the type of instructions that you execute. So for example, an ad will be very cheap because it is cheap transaction on an ordinary CPU. Whereas if you do something that involves storage it'll be pretty expensive because the storage on the blockchain stays forever so you're basically paying for storage for eternity. So far at least. Might change soon. Finally, we have incentives. This is the spice that makes blockchains work at all, right? Because we have many people trying to establish what the present state of the network is and since it's a distributed network this is a difficult problem when people are honest. When people are not honest it's a very difficult problem and the trick lies in aligning what your interests are and the interests of the community. So we try to place ourselves somewhere up in this quadrant when we design the rules of the protocol. We try to find something that is beneficial to you and beneficial to the community. Basically, the economy is such that when you follow the protocol you benefit from that. You get rewarded. If you try to break the protocol either you don't get rewarded, you kick off the network or in a theorem two, you will also lose money basically you'll be punished. And we need to do this in order to deal with these situations where some parts of the network think that we've gone along this route. Other parts think that we've gone along this route and maybe somebody else thinks that we've gone there. Now, Ethereum two is practically all the same and everything different. If you consider Ethereum on a prototype then Ethereum two is going to be the product. So it's still a blockchain. It still does all the same things. Create blocks, you have cryptography involved, you have incentives and there's a peer-to-peer network. And at the end of the day you have something which looks like a computer which emulates a computer you could say. But on the inside everything has changed. The networking library has gone from devP2P which is really a prototype of a peer-to-peer library. We will be most likely using libP2P which gives you access to a lot of interesting features. You can suddenly use the network over alternative transports, maybe the quick protocol, maybe UDP, maybe even the mesh network who knows. The virtual machine, what used to be an Ethereum specific virtual machine and quite a quirky one at that, 256 bits word length. Again, most likely we'll change into Wasm which is currently gaining popularity all over. And this is fantastic. This enables a lot of new use cases. You can run stuff in the browser directly. You can run stuff on a phone maybe. You can run stuff basically anywhere that you find the Wasm environment. We change the curve that we use and we change it for a simple reason which is linked to the other change. Ethereum one is a proof of work blockchain. It's the kind of blockchain that uses a lot of energy in order to reach consensus. You have an algorithm which basically loops a hash function and it's not useful to do that work beyond getting the consensus. So it wastes a lot of energy, right? We're hoping to switch that to proof of stake. And in proof of stake, what's important is that you have a lot of people participating. And what this new elliptic curve does is that it allows you to sign some piece of data with multiple signatories without growing the size of the signature. Now this is pretty cool because it means that we can allow a lot more people to participate in the network. The possibility to participate like the number of participants in the network is no longer tied to the amount of data that you need in order to sign a transaction or really your vote in the consensus. So we can grow the number of people that vote without losing efficiency. Oh yeah, there we go. That's what's gonna happen. The design of the Ethereum 2 network is a little bit more complex. In Ethereum 1, you can think of the blockchain as a single thread of execution. Things happen in order and you can execute one thing at a time. There's no parallelism. And one of the biggest changes beyond the consensus algorithm change in Ethereum 2 is the fact that we'll be able to run shards. And you can think of shards as threads basically. They're parallel, no, maybe even processes is better. You have parallel worlds of execution. Each has its own state, each has its own memory, each has its own execution engine and each runs completely separate from the other. And in the middle, you have a beacon chain that acts as a coordinator to coordinate what is the consensus of all these different shards. So the way it works is that the shards report to the beacon chain where they are in their own state. And on the beacon chain, we have validators. Those are the entities that replace the miners in the traditional proof of work network and they attest to this state of the shards. And the way they do that is that they rotate between the shards and they look at the shard and try to come to agreement on what is the current state of the shard at this moment in time. And it's called the beacon chain because this happens every six seconds. So six seconds pass, a number of validators go to a particular shard, they look at that shard, they determine what is the current state, what is the longest chain, according to the rules of the protocol and then they sign that information onto the beacon chain. And this is also where communication between shards happens and is coordinated. So basically you can think of it as some form of inter-process communication, this coordination mechanism. Nimbus, we've developed a couple of things. As I said, the theorem 2.0 project is still in heavy research. A lot of things are changing all the time and we're basically following along in the development of the protocol and we're implementing it together with a couple of other groups that are doing the same. So the goal here is that once a theorem 2.0 is launched there will be several clients running. Ours in particular is focused on light devices, such as phones, such as routers, things that don't have that much power. If you wanna try it out, we have a simulator right now. It runs this beacon chain process, it runs a number of validators and it simulates them looking at the shards trying to come to consensus about the state. Another little fun application we did was a chat. If you're familiar with the theorem, one part of the theorem is the blockchain but there are two other parts, whisper and swarm. You can think of swarm as a big hard drive, basically free in it but modernized, so you can store data there in a censorship resistant way. And the third part is whisper, it's a communications protocol, basically a messaging protocol that aims to make it difficult to detect who you're talking to and when you're talking and whether or not you're the recipient of a message. So it gives you anonymity on the sender side, on the receiver side and it does so fairly inefficiently by gossiping to everybody. So this is just a fun little test case that we built. And I wanted to show you a snippet of NIM, which is the language that we're writing this application in. Now NIM is a compiled language, it's statically typed. So we compile down the statically typed language to machine code on the platform that you're running. You can see that it looks a little bit like Python-ish, uses indentation, not brackets, for those that care. There are some interesting things in this language specifically. One is that it has a very good metaprogramming facility that you can use to generate basically code on the fly based on what you pass into the functions or macros, right? So for example, here we create an Ethereum node. The Ethereum node is the thing that connects to the network and deals with all the protocol matters. We add to it a capability to run the whisper protocol and whisper here is a type. So we can basically pass a type into this function and that function will therefore have available all the things that are needed in order to run the whisper protocol, right? Try to scroll a little bit, maybe that works. No, I'm not gonna be able to scroll. Down here, I just wanted to show a for loop just for the syntax, it's very, yeah? Okay, perfect, yeah, yeah, I'm almost done. Down there, there's a for loop as well. I just wanted to show the syntax of it, right? Our client, we're sponsored by Status, which is an open source company trying to bring Ethereum to mobile and they're doing a bunch of other things as well. We're sponsored by Ethereum, the foundation. So we're cooperating with them with the researchers there to bring this project to the world. In turn, we are sponsoring NIM, and if you want to join us, we're also using Gitcoin, which is basically a bounty program where we put out work that we'd like to see done and you can very easily participate in that work. And that's it. The big reason why I'm working on this is because what I started with was technologies from 20, 30 years ago. Nobody had an idea what they would lead to. And nobody has an idea of what the technologies that we developed today will lead to in the future in 10 or 20 years. But I'm pretty happy that I'm able to do an open source such that it will be available to those next generations as well. Cool. We have time for one or two questions. Any questions? Yes. Hello. Hello. Very impressive. So I have two questions. The first one is for BOS signatures. Are you using an existing library or are you writing your own? We're currently using MilagroCrypto, which is an existing library. There exists a number of them, one in Rust, one in Go, is being developed. We'll likely write our own once the research has settled and we find it useful. Right, right. And then the second one is for eWalsm. I've seen a bunch of projects, for example, Parity's Substrate to actually interpret WebAssembly rather than compile it to machine language because of security concerns. And that makes a lot of sense. So my question is, are you compiling it to machine code or are you interpreting it? So for Nimbus, we haven't yet developed it. For Ethereum in general, the plan is to start with pre-compiles, which are basically snippets of code included with the client. And the way it will be rolled out is gradual. So I expect that the question of whether to pre-compile or interpret will settle by then. So I guess smart contracts will be interpreted by default and maybe the pre-compiles will be... For example, yeah. All right, thanks. Any other questions? No, thank you very much then. All right.