How to build your own Ethereum client
Sieka, Jacek
Early 2018, Nimbus was born - an exciting experimental lightweight client and research project for Serenity - the next major upgrade to Ethereum - and resource-constrained devices, such as mobiles. In this talk, we'll go over the anatomy of an Ethereum client - the cryptography, the peer-to-peer networking, the virtual machine, the latest research - as well as the language we're working in, Nim. Nimbus, a research project started by Status.im, is a client for the Ethereum blockchain. Its focus lies on Serenity, the next major update to the network, and resource-restricted devices, and is done in collaboration with the Ethereum Foundation. Having developed everything from scratch in a new language, we'd like to share our journey through the early stages of development, talk about current research in the space and future plans for the client. In the talk, we will cover topics such as: Cryptography Peer-to-peer networking Virtual machines Proof-of-stake implementation in Ethereum Sharding and beacon chains Nim, the programming language we're building the client in
 So next speaker will be Jashek Sjeka on how to build your own Ethereum client with development story of Nimbus. Actually you can go now, it's recording. All right, hello everyone. I'm Jacek, I come from Starris, I'm working on this Ethereum client. I'm a client called Nimbus and if you want to 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. So we're going to 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. Before we go there, I want to look a little bit at where we're coming from 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 very 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 a 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 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. They 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. They each contributed important things to blockchain technology as we know it today, right? They would use them to identify files, distribute at 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 developer's 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, right? 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? 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? Photography, networking, some form of execution, specifically in Ethereum, but it's really true for all the blockchain except they're more or less static and some form of incentives, right? So Nimbus, we started this project early 2018. From 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 Nimbus, 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 languages 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 block chains 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 than the... The important stuff is in the elliptic curve cryptography, because basically, when you want to 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. Okay? On Ethereum, execution is pretty straightforward. Foreverly blocked 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. For example, an ad will be very cheap, because it is a cheap transaction on an ordinary CPU. Whereas if you do something that involves storage, it will 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. 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. The trick lies in aligning what your interests are and the interests of the community. 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-bit word length. Again, most likely will change into Wazm, 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 Wazm environment. We changed the curve that we use. And we changed it for a simple reason, which is linked to the other change. Ethereum 1 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. It's not useful to do that work beyond getting the consensus. So it wastes a lot of energy. 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. 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 going to 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 is no parallelism. 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. There are 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. 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 Ethereum 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 Ethereum 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 want to 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 Ethereum, one part of Ethereum 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. You can store data there in a censorship resistant way. 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. It gives you anonymity on the sender side, on the receiver side, and it does so fairly inefficiently by gossiping to everybody. This is just a fun little test case that we built. I wanted to show you a snippet of NIM, which is the language that we're writing this application in. NIM is a compiled language. It's statically typed. 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. 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. 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. Down here, I just wanted to show a for loop. 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. 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. 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 it 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. 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 to your own? We're currently using Milagro Crypto, which is an existing library. There are a number of them, one in Rust, one in Go, which is being developed. We'll likely write our own once the research has settled and we find it useful. Right. And then the second one is for E-Walsum. 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. Okay. Thanks so much. Thank you so much.
 So next speaker will be Jashek Sjeka on how to build your own Ethereum client with development  story of Nimbus.  Actually you can go now, it's recording.  All right, hello everyone.  I'm Jacek, I come from Starris, I'm working on this Ethereum client.  I'm a client called Nimbus and if you want to 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.  So we're going to 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.  Before we go there, I want to look a little bit at where we're coming from 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 very 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 a 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 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.  They 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.  They each contributed important things to blockchain technology as we know it today,  right?  They would use them to identify files, distribute at 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 developer's 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, right?  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?  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?  Photography, networking, some form of execution, specifically in Ethereum, but it's really  true for all the blockchain except they're more or less static and some form of incentives,  right?  So Nimbus, we started this project early 2018.  From 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 Nimbus, 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 languages 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 block  chains 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  than the...  The important stuff is in the elliptic curve cryptography, because basically, when you  want to 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.  Okay?  On Ethereum, execution is pretty straightforward.  Foreverly blocked 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.  For example, an ad will be very cheap, because it is a cheap transaction on an ordinary CPU.  Whereas if you do something that involves storage, it will 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.  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.  The trick lies in aligning what your interests are and the interests of the community.  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-bit word length.  Again, most likely will change into Wazm, 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 Wazm environment.  We changed the curve that we use.  And we changed it for a simple reason, which is linked to the other change.  Ethereum 1 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.  It's not useful to do that work beyond getting the consensus.  So it wastes a lot of energy.  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.  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 going to 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 is no parallelism.  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.  There are 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.  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 Ethereum 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 Ethereum 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 want to 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 Ethereum, one part of Ethereum 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.  You can store data there in a censorship resistant way.  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.  It gives you anonymity on the sender side, on the receiver side, and it does so fairly  inefficiently by gossiping to everybody.  This is just a fun little test case that we built.  I wanted to show you a snippet of NIM, which is the language that we're writing this application  in.  NIM is a compiled language.  It's statically typed.  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.  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.  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.  Down here, I just wanted to show a for loop.  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.  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.  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 it 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.  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 to your own?  We're currently using Milagro Crypto, which is an existing library.  There are a number of them, one in Rust, one in Go, which is being developed.  We'll likely write our own once the research has settled and we find it useful.  Right.  And then the second one is for E-Walsum.  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.  Okay.  Thanks so much.  Thank you so much.
How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_0_143.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_144_1439.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_1440_2375.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_2376_4055.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_4056_4775.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_4776_6023.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_6024_6479.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_6480_8279.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_8280_8855.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_8856_9959.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_9960_10463.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_10464_12155.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_12156_12995.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_12996_14423.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_14424_15131.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_15132_16319.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_16320_18095.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_18096_18143.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_18144_18191.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_18192_18263.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_18264_18323.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_18324_18395.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_18396_18443.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_18444_18539.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_18540_18695.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_18696_23243.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_23244_23375.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_23376_27587.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_27588_28751.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_28752_30203.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_30204_32867.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_32868_33959.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_33960_34703.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_34704_37643.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_37644_37691.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_37692_37739.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_37740_37787.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_37788_37835.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_37836_37895.png How_to_build_your_own_Ethereum_client_The_development_story_of_Nimbus_wbpEU_o0dd0_37896_38020.png
So next speaker will be Jashek Sjeka on how to build your own Ethereum client with development story of Nimbus. Actually you can go now, it's recording. All right, hello everyone. I'm Jacek, I come from Starris, I'm working on this Ethereum client. I'm a client called Nimbus and if you want to 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. So we're going to 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. Before we go there, I want to look a little bit at where we're coming from 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 very 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 a 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 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. They 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. They each contributed important things to blockchain technology as we know it today, right? They would use them to identify files, distribute at 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 developer's 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, right? 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? 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? Photography, networking, some form of execution, specifically in Ethereum, but it's really true for all the blockchain except they're more or less static and some form of incentives, right? So Nimbus, we started this project early 2018. From 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 Nimbus, 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 languages 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 block chains 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 than the... The important stuff is in the elliptic curve cryptography, because basically, when you want to 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. Okay? On Ethereum, execution is pretty straightforward. Foreverly blocked 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. For example, an ad will be very cheap, because it is a cheap transaction on an ordinary CPU. Whereas if you do something that involves storage, it will 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. 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. The trick lies in aligning what your interests are and the interests of the community. 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-bit word length. Again, most likely will change into Wazm, 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 Wazm environment. We changed the curve that we use. And we changed it for a simple reason, which is linked to the other change. Ethereum 1 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. It's not useful to do that work beyond getting the consensus. So it wastes a lot of energy. 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. 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 going to 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 is no parallelism. 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. There are 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. 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 Ethereum 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 Ethereum 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 want to 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 Ethereum, one part of Ethereum 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. You can store data there in a censorship resistant way. 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. It gives you anonymity on the sender side, on the receiver side, and it does so fairly inefficiently by gossiping to everybody. This is just a fun little test case that we built. I wanted to show you a snippet of NIM, which is the language that we're writing this application in. NIM is a compiled language. It's statically typed. 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. 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. 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. Down here, I just wanted to show a for loop. 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. 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. 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 it 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. 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 to your own? We're currently using Milagro Crypto, which is an existing library. There are a number of them, one in Rust, one in Go, which is being developed. We'll likely write our own once the research has settled and we find it useful. Right. And then the second one is for E-Walsum. 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. Okay. Thanks so much. Thank you so much.
into building an Ethereum client, like what you important to blockchain development and that is find information, right? Peer-to-peer networking bit about how virtual machines work. You have to are incentives that are aligned for you to share right? So Nimbus, we started this project early 2018. From the time Ethereum 2 research was still in all these areas that we were working in. Now, is other cryptography involved as well in the the block on the network. We apply the virtual out with a new state. Obviously, if this was done Ethereum specific virtual machine, and quite a proof-of-work blockchain. It's the kind of design of the Ethereum 2 network is a little bit separate from the other. In the middle, you have what is the current state, what is the longest such as phones, such as routers, things that NIM, which is the language that we're writing as well. We're sponsored by Ethereum, the work that we'd like to see done, and you can very technologies that we developed today will lead to