 So we're sort of getting everything in order here. I'm Jacek. I recently joined a company called Status, which works with Ethereum for mobile devices, right? So they're trying to bring Ethereum to mobile phones, IoT, whatever that might be. Today is going to be a slightly technical talk. I'm going to go over what it takes to build an Ethereum client, because this is a project that we just embarked upon not long ago. See if we can get some slides up. A little bit about my background. I'm head of the research department there at Status. I cut my teeth in the early 2000s, and this was an absolutely amazing time to do computer science, right? It was the time when distributed systems were coming around. It was a lot of talk about how to start using the internet in a more interesting way. You name it, like if it was BitTorrent or Emule or all these technologies. That's about the time when these things came about, right? And at the time I was studying distributed networking. And I remember the day when I read the Cord paper. Now Cord is an interesting early distributed hash table, and just struck me how amazingly simple that design was, right? Basically, you build a ring of nodes, and by doing a binary search on those nodes, you can essentially pass a message to anyone on that ring in logarithmic time. And this was fantastic, right? Because on the internet, we had all these computers connected, and suddenly there was a way to reach any of them in a fairly scalable way, right? Instead of trying to spam the network or using a centralized service, you could suddenly go fully decentralized. Other stuff that came about in this time, and again with BitTorrent and Emule and those protocols was something called Merkle Trees. Now they were researched in the 70s much earlier, but a lot of new cases were being brought up, right? You would take a file, you would hash the individual pieces, and from those pieces, you could build up a tree of hashes and gain either a very granular view of the correctness of the file or a very much more compressed one, which would cover the whole file at the same time, right? So you could zoom in and zoom out of this correctness. And this technology being a tree means that you could also build on it, right? So once you had one, the hash of one file, you could join several files together in yet another hash. So with a single hash, you could sort of represent the whole myriad of files, right? And finally, a technology that I've always been very, very interested in is compilers, and specifically virtual machine-based compilers. So I used to work on a language called Lua for a while. Yeah? The microphone, is it on? Yeah, I think it's on, hopefully. Let's see where we are now. Full screen mode, yay. All right, so there we have the ring, a bit of cryptorite merkle trees. That's where we are. Excellent. So virtual machines was like a big interest of mine, because with them, you could build programming languages. And as any computer scientist knows, like building a programming language, that's one of the most fun things you can do. And a recent development in this area is obviously LLVM, which is like a compiler-builder's toolkit. You can just take LLVM, add a parser or an AST to it. And basically, you can build your own language in a very short time. Very, very cool. Putting all these things together, right? You have the DHT for distributed systems. You have crypto with merkle trees and encryption and so on. You have LLVM, which provides a virtual machine, where you can execute basically any kind of code. And suddenly, we arrive at the Ethereum, where we are today, and where I am today. So today, we're going to be talking a little bit about, actually, no, we're going to talk a lot about the client, how to build sort of a, or what the components really of an Ethereum client are. So if you want to build your own one, this is like a roadmap for it. Or if you want to join us in building ours, that's great as well. We're open source. We're on GitHub. We're going to be talking a little bit about charting, which is one of the techniques that the Ethereum Foundation is coming up with in order to deal with some of the scalability problems of Ethereum. We're going to very briefly touch up on NIM, which is a nice little programming language, very expressive, very moldable. And finally, I'm just going to mention StatusOpenBounty, which is an approach to developing open source software, where people that have a problem to solve can sort of post bounties. People that want to solve these problems receive the bounties when they finish them. And it's all done in a trustless and decentralized way through cryptocurrencies. Now, who am I to talk about this? Well, I started just recently looking into this very problem, but I have a great team of people that have been looking at this. And we met maybe a month ago to go over it. And this was sort of the grand plan we came up with, right? Now, building an Ethereum client seems like a big problem. But then you can start sort of breaking it down into little pieces. And I'm going to go over these little pieces as far as here. Because this is sort of what you need to do in order to build an Ethereum one client. That's sort of your base, right? The idea, however, for Status is that we're going to use this base to develop shouting, proof of stake, all kinds of other technologies that are upcoming on the Ethereum sort of horizon, right? So you start out with a set of core services, like things that every really blockchain client has to cover. Obviously, you need your cryptography in place. In Ethereum, they use a lot of AIS, elliptic curve cryptography, and obviously a lot of hashes for all those Merkel trees. We use a technique called Bloom filters. This is sort of a way to compress data and optimistically determine whether an item is present in a particular set. And this is basically an optimization to allow you to tell whether you need to download something in particular. You need to figure out something for storage, right? If you look at the Ethereum blockchain today, I think it's about 60 or 70 gigabytes of data, roughly. This is growing. And obviously, shouting is one of the ideas that the foundation has to sort of solve this growth problem. Finally, every client, like there are currently three or four clients in production in Ethereum. They have this RPC interface that they use to communicate with the outside world a little bit. So those are sort of core layer techniques that you need to go into. Once you've passed that, you need to start talking to the world. And funny enough, this is where the distributed hash tables from my background and from the early 2000s come in, because they're basically using a network called Cademlia, which is a development of CORD, which allows you to do node discovery. So basically, you connect to a single node. That node tells you a little bit about what the rest of the network looks like. And you can start connecting to all these other nodes and figure out where to get your data from. Trees or tries. Very fundamental data structure used in Ethereum. Just these are sort of the basic things that you need to build a fully functional client. U-PMP. This is this technology that allows you to bypass, get out on the network when you're in the private network, right? There's a router somewhere, and if you're running on a local network, you probably need a U-PMP client to get out to the internet. When you've done all that, all those basic services, you move on to the sort of the protocol layer of Ethereum. Like, you've set up your cryptography, you've discovered a couple of nodes, now you need to start talking to them. So the first thing you do, you need to generate keys, which is a tricky problem in itself. Better with this one? I'm fine with either. Is it needed? Is this better? Yeah, much better? OK. All right, so part of the cryptography we're using right is public key cryptography. So you need to generate keys. You need to be able to sign messages. You need to be able to generate key variants, as well, because you don't want to be using a single key. There's a lot of these little details that you need to dig into, right? Handshaking, you've discovered the nodes through this cadamlia-based protocol. And you initiate a handshake process, which is signed using elliptic curve cryptography, E-C-I-E-S. And you start talking to the other nodes. And because this is a distributed service, the nodes on the internet, they might be running different versions of things. They might be older, newer. They might be implemented by somebody else. So there's this protocol that they use called FP2P, which allows you to discover features. That the other clients have, OK? Finally, there is this piece called RLP, Recursive Length Prefix, which is an encoding. It's basically this kind of length prefix data structure that you can send to the other clients. And it's recursive because what we will be building with this RLP structure is trees of various forms, right? They're going to be Merkle trees, but they're also going to be structures that are recursive in nature. All right. You've connected to the clients. You've established what protocol exactly you're going to be talking, which version it is, whether it's an old client, a new client. And now finally you can start developing the blockchain. And again, blockchain comes back to these earlier techniques that we mentioned before that were developed long, long ago. It's basically a huge Merkle tree that keeps getting added on to. So when you think some pieces of data, the transactions that form blocks, kind of like a file, right? And you create a new file, which is a new set of blocks. You can join these two together using Merkle trees and form a chain that goes back all the way to the first node in that tree. This is a huge chain. I mentioned it was about 100 gig, right? And the next thing you'll be up against is a synchronization mechanism to sort of download these 100 gigabytes of data that you need in order to follow the chain all the way to the beginning in what, 2014, 15, I think. So sync mechanisms, there are a couple of out there. They get optimized over time. There's something called light sync. There's something called full sync. There's something called warp sync. Every client has a little bit of their own way of doing this. And you need to be aware that you're going to be downloading a lot of data, which obviously for a mobile client is tricky. The last piece in the feature sort of area of things is something called Web Tree, usually. As it turns out, I mentioned that Ethereum is made up of the blockchain, like the economy part of it. But there's also code running there. And as soon as you have code, you end up with functions. These functions can be reused by other people. And Web Tree is basically a layer that allows easy access to well-known features that are already deployed on the blockchain. All right. So far, so good. I'm going pretty fast here, right? This is a 20-minute presentation. So I'll be happy to talk to you about all of this later. Any questions so far? Cool. Keep going, yeah? All right. Shouting. Shouting. And here I can actually cheat a little bit. But I'll tell you about that in a minute. So, shouting. What's shouting? Well, you mentioned that we have 100 gigabytes of data, right? And that's a lot of things to process, especially if you want to put Ethereum on a mobile device where 100 gigs, all right. Mine has 128, which is pretty cool, right? But not all devices have that kind of storage. And this is after four years of Ethereum. Imagine what it's going to look like in one year, five years, 10 years, 20 years, right? All that data, it stays there forever. So there are many approaches to solve this because there are obviously many ideas out there, right? The current one for Ethereum, it's called the layer one solution, which means that we're going to modify the protocol itself a little bit. And we're going to create something called subchains, which are kind of like new Ethereum blockchains starting over, except that they're tied to the main chain in a particular way, right? So imagine, if you look at the security of a blockchain, it depends on miners, and there being lots of miners verifying that the blockchain is formed in a particular way and that the transactions are signed and that there's no double spend and all this thing. And the more miners there are, the more secure it becomes. If you were to take Ethereum as it is today and simply split it up into 100 pieces, say, you would also split up the security of it into 100 pieces, right? You would have to put all that mining power into many small chains, and each of these would be much less secure. This is kind of like a fundamental principle because this is where the idea of using many different coins to provide security in a system like this breaks down because there's only so many miners out there that are willing to do all this work. So what shouting does is that it does create subchains, which are separate chains that run practically like in a separate address space, but periodically, they also report their state back to the main chain. And it's the main chain via proof of stake that provides security for these subchains. So the way it works at large is that you post a bond to the main chain if you want to create blocks on one of the subchains. And then you work the subchains just as if they were separate chains, right? And this bond can later be used by others to detect any fraudulent behavior. And the idea is here that you have a set of collectors that all together provide security for these subchains, and anybody can detect that some of them have been fraudulent and use that bond to sort of motivate them to do the right thing. OK. Good for me is that there's a whole talk on this subject by Mike Swan, Kevin also. I met him a few days ago. I really encourage you to go there if you want to find out more about shouting. He's one of the researchers developing this solution for the Ethereum Foundation. So I'm not really going to go any more into that. You still with me? All right. Nim. Now, the project is called Nimbus. And part of that, it comes from there, right? Not only is Nimbus a type of cloud, but it's also a programming language. And we picked this little nice programming language because we like it. There's like no, like at the end of the day, there are so many good programming languages out there. But this one is really nice for researching things because it's very Pythonic, but at the same time, it compiles down to machine code. It's very fast to write code, but it also has very good performance at the same time. And again, short presentation, I'm not going to go too deeply into this. But other features that interest us might be that the language has very strong meta programming capabilities. It's very easy to create little DSLs inside it. So our hope is that we can sort of leverage on that to create nice descriptive implementations of various things that we want to research in the future, which will hopefully be as legible as this little snippet here. Last topic, Open Bounty. Yeah, so there's a big world of developers out there and a big world of companies or people wanting to get stuff done. And they don't always know each other and trust each other. So the blockchain is like this perfect fit for this. If you can somehow post your project online when it's done, you sort of get rewarded in cryptocurrency. That's great. So one of the things that status is doing is sort of using Open Bounty as a process to get stuff done more quickly. And in the development of Nimbus, this is one of the things that we're going to be using. So as parting words for today, I'm going to invite you to come to us and look at the different things that we're developing. It's not only Nimbus itself. We're also developing iOS and Android client for Ethereum. And this is sort of a great way to join the organization and at the same time get rewarded for it. We have a booth out there. If you want to find out more about the project, there's a new URL up there. I'll be happy to write it down for you after this presentation. And that will be all for me for today. I'm also going to stick around for questions if you have any. Come on. I think this is for this part, the Nimbus, right? Sorry? The Nimbus, Nimbus. Yeah? Yeah. So the Nimbus is still under development or already completed? We started development about two months ago, which means that we made that roadmap. We got some of the cryptography done. We worked a little bit on the VM. But other than that, it's like an open field. Is that it's a Nimbus? A demonstration? No, it's not working yet. Not at all. Like, our plan is to get a sort of an Ethereum 1 working client done by the end of Q2, roughly. That might take a little bit longer, a little bit shorter give or take. There's an excellent team of five people working on it already. And as I mentioned before, everybody's welcome to join the project as well. It's all on GitHub. It's all under a permissive license, Apache. And the idea with Nimbus as well is to build it in a very modular fashion so that we can pick pieces out of it and maybe bring it to even more resource restricted devices such as, I don't know, IoTs. And imagine a turnstile in the MRT, right? And shouting and a couple of other technologies that the Ethereum Foundation is developing is going to be very helpful in that because part of that solution is bringing in a way to avoid downloading that whole state and doing everything a little bit more on the fly. Other questions? Yeah? How does your Identica project fit into this? Which one, sorry? Identica? I'll think that that is a project for developing identities on the Ethereum world. That's more like a DAP, which is a distributed application. And it's a specification. And it's completely separate from all this. This is infrastructure for running the network. Identica is like an application, right? So it might come there. Imagine ERC-20, right? That's like a standard for building tokens. But the Ethereum Foundation has essentially nothing to do with that. Anything else? How much money did you guys raise in your ICO? I wouldn't know. I guess you can make. I think it's in the bounty document, whatever. No, in the fundraising document, how many east they've finally gathered. So you can do the math. Yeah? So what are the differences between the Nimbus and Status IAM client? So right now, the Status IAM client is using GET, which is the Go implementation. The long-term plan is for Nimbus to replace that. So Status IAM is sort of the UI, the wallet, all that stuff. But underneath, it's running all on these decentralized technologies using the protocols that make up this decentralized Web3, if you want to call it that way, right? So there's the blockchain. Right now, we're using a protocol called Whisper for communication. The final piece in that puzzle is Swarm, which is kind of like a storage layer. So you sort of get decentralized execution, decentralized storage, and messaging, right? So this is the stuff underneath Nimbus itself. All right, so I'm going to finish there. You're very welcome to pop by the Status OpenBounty booth. It's somewhere down there. I haven't had time to look at it yet. I'm going to hang around there for a while. No, I'm actually going to hang around here for a while. I just want to chat about anything. Otherwise, thanks for coming.