Hi everyone. I'm David and I work for Protocol Labs. I'm a software engineer responsible and focused on the JS IPFS and the we peer-to-peer projects. Throughout this amazing conference, we have been seeing a lot of technologies and solutions to build decentralized applications, pushing the boundaries to a complete distributed scenarios. However, something that hasn't been covered as much is the networking level.
It is required to do a lot of magic, I might even dare to say black magic, to be able to do these peer-to-peer applications work in the infrastructure that we have today. Things like NATs, firewalls, lack of connectivity, completely offline scenarios, sensor networks are some of the problems that we peer-to-peer software developers have to overcome in order to build these decentralized applications. And it is not by chance that like both IPFS and Ethereum have built fully matured networking stacks from the ground up to solve these challenges. We peer-to-peer for the case of IPFS and dev peer-to-peer for Ethereum. And this is simply because there was no transport in the network that offered the primitives that IPFS and Ethereum needed.
Things like authentication and encryption, being able to cope with several network topologies in several different scenarios are some of the challenges that we must overcome and like face when we are building these systems. However, there is a key small key difference between the designs of these networking stacks. We peer-to-peer is modular. This modularity gives us the ability to increase our reach in terms of devices by using the capabilities that the system has to offer. Every single module in libp2p exposes a well-defined interface for peer discovery, for routing, for transports, stream multiplexing, encryption, you name it.
And we can pick the components that we want and bake our libp2p solution for a device that we want to run. This modularity gives us the opportunity to keep our primitives for authenticated process addressing intact. It is a very powerful construct to be able to address any other process in the network just by a public key so that we can find the process in the network and not only dial to it, but also make sure that we are talking with the right endpoint. So, this means that like we can go from the traditional physical network to a super connected graph with a physical and virtual overlay um physical and virtual overlay um that is not bound by the capabilities of the system. We can use things like Bluetooth to create some of these channels.
Even radio or audio can be transports. We can upgrade unreliable channels to become reliable with reliable ability upgrades. We can encrypt any channel that we want with secio, TLS, curve CP, and others. And this means that we can also enter in the ecosystems that don't have the full networking stacks that we are typically used to. Huge cases for this is for example the browser, uh which is constrained to just have web sockets, HTTP, and WebRTC, or Internet of Things devices that sometimes don't even have TCP stacks.
You have you are uh you have to rely on some radio protocol in order to be able to dial out of that device. For example, um the one very good example of how we peer-to-peer is a pluggable is that our friends from OpenBazaar needed and wanted to have a tour transport for uh their their use. And all they needed to do was to create a tour transport that fulfilled the same interface as the other transports on we peer-to-peer and they can just plug it right in. And once that is done, every other application that wants to use that transport can just bring it and you don't have to change anything from the code base of your application. The the primitives stay the same.
It is really powerful. Think like having full Ethereum nodes running in every single device with no limitations. So, um we think and we see that peer-to-peer and we peer-to-peer being able to converge and like to join efforts to make a way a much better ecosystem for the community that uses these network stacks. That peer-to-peer offers a lot of primitives that can augment this ecosystem. And since uh we already did the work as Juan mentioned earlier of getting IPFS running on the browser, we kind of like went ahead and asked ourselves, "What would we have to do in order to get an Ethereum node running on the browser?"
So, I'll just show like we started hacking something. Uh It is very in the beginning a very early stage. It's a humble beginning, but we want to show you the process the progress. I have two demos for you. So, looking for the demo one.
So, the first challenge is really getting the Ethereum VM working on the browser. Here basically, uh you might be familiar with the standard setup of getting a browser app nowadays running on the browser, uh you have to basically transpile everything. And then once it's transpiled, we can load it. And we prepared this really nice dashboard so you can see what's going on. And here we are going to get to like simulate the Ethereum blockchain.
We are going to create some blocks and we are going to process them through the Ethereum VM. There is always like since these operations are very CPU intensive, it takes a little bit to warm up, but once it's there, you can just run it rest of the chain. You can see we get Ethereum VM on the browser running blocks from the Ethereum blockchain. But there is more. So now I'm opening another tab and I'm basically connecting to the other peer that was opened before and I'm connecting these two browser tabs.
So instead of generating blocks, I'm just going to ask that peer to give me the blocks. So it happened seamlessly. Like I just said dial to this other peer, it found the peer and fetched the blocks from that network. So we can get the Ethereum VM running on the browser and finding blocks from other nodes. This is pretty exciting.
But there is more. So you can see I can pop more nodes and I can define each other very quickly. But now like the real interesting demo is like can we get these browser nodes uh connecting to the real Ethereum network? Let's see. Demo two, are you already playing?
Awesome. Okay, so same dance getting the the application to run. Uh but here we are doing something extra. We are going to run a go Ethereum node patched to the libp2p. So it has an address in the libp2p ecosystem.
And now instead of like simulating the blockchain, I'm just going to dial to that go Ethereum node and fetch the blocks. Like basically I'm using this go Ethereum node that was augmented with libp2p to connect to the rest of the network. Again, the generating the genesis block dance takes a little bit. This can be greatly improved specially with the recent work from Martin on Lwasm, I'm sure. Um but once that's there, we'll start receiving all of these blocks.
There you go. And you can see like this is like fetching from the real live network. It's pulling all the blocks in into the browser. Awesome. So, let me explain in a graph what and it keeps going.
Uh it might take a while if you have downloaded the blockchain before, you know, you might know that. Can we go back to the slides? Okay. Uh Okay. Thank you.
Uh Okay. So, what is happening? So, we know we have the Ethereum network that already exists and it's very well connected through the peer-to-peer. And then we uh added this Go Ethereum node patched with um we peer-to-peer so that does like a presence on the we peer-to-peer network. And then we throw the Node.
js node uh running we peer-to-peer as well. And then we have our browser that connects to this Node.js node that connects to the rest of the network to the other uh Go JS node like Go JS node the Go Ethereum node. So, you can see we already like using multiple transports here. Like I'm using TCP to connect Go between nodes and then like I'm using web sockets from nodes to the browser.
Next step, like I can connect several browsers together, right? So, what I'm going to do is just use WebRTC, the peer-to-peer transport of the browser. And like just to add it on top, what I can do is I I can connect the browser again to the Go Ethereum node. And this way like any browser that has uh common transport can dial to another node that supports we peer-to-peer. This is pretty exciting.
Like this means like we can have finally Ethereum in in browser running like full Ethereum nodes. And it's just on in browser. It's basically any device with any network capabilities. The network is not the problem anymore. I would like to give a huge shout out to Martin because Martin basically did all of the magic of getting Ethereum running on the browser.
I just had to collect the wires together. That was easy. Thank you so much for all the help. And like what you've seen here was basically like couple of nights hacking. It was actually very impressive how it was so easy to attach we peer-to-peer to go Ethereum and to bring the blocks to the browser and run them on the Ethereum JS VM.
It's pretty exciting. So we will continue pursue this endeavor. You can follow the development on the we peer-to-peer organization on GitHub, the dev peer-to-peer development on the Ethereum org and you can check all of those examples, all of that demo on a repo called JS Ethereum we peer-to-peer. I can post the links after in Twitter if someone is interested to check it out. That's awesome, David.
Thank you so much. Thank you.
Automatic transcript — names and jargon may be misspelled.