 Good morning. My name is Zaharkira Jop. I work at Statos on Nimbus, which is a client for Ethereum 1 and Ethereum 2 client for resource restricted devices written in NIM. And today we will be talking about the Ethereum networking spec, how it evolved and what was the various design rationales that went into it. So the first and the major difference between Ethereum 1 and Ethereum 2 is that we are transitioning to LibP2P, which is a protocol developed by protocol labs for the purposes of developing IPFS. It's matured out of this project. And I figured I should start with few words why this transition was made and why we decided to move to LibP2P. And there are, I would say, two major reasons. The two most important promises of LibP2P. And the first one is that it promises to take Ethereum to many new places, where it wasn't quite possible to use it before. And the reason this is possible, because all communication in LibP2P is carried over these so-called LibP2P streams, which in turns are layered over, let's call them physical connections, which could be an arbitrary network connections established between two nodes. It could be a TCP link in a classical case. It could be some UDP scheme, like Qwik, which will give us very good censorship resistance in the future. It could be the web sockets in the browser. It could even be snail mail. But let's don't forget that protocol loves the people who created LibP2P. They want the system that would work on Mars. So one of the key features of LibP2P is that it's not only allowing these streams to be multiplexed over a single connection, but a node in the network can relay the connections for other nodes. And a single physical link can carry many logical link between arbitrary nodes. And we call this multi-multiplexing in the LibP2P sense. And it will be the major key enabler for creating things like Ethereum light clients running in a browser. And the other significant reason is Gossip sub, this framework in LibP2P for broadcasting data. As we know, a lot of the traffic in cryptocurrency network like Ethereum is about broadcasting blocks. And now with Ethereum 2, the majority of the traffic is actually broadcasting the attestations. The attestations are the votes that the participant in the proof of stake consensus exchange with each other. These votes allow them to reach finality and to crosslink the state of all the various charts, including E1. So, we know that from experience and from just theoretical reasoning that floods up the system where every message reaches everybody in the network and it's fully broadcasted on every step, just one scale to the scale that we want to reach with Ethereum. But LibP2P comes with a significant cost. It took quite a lot of convincing for the teams to jump on ship because when you look at the large list of components that you have to implement, it could be a little bit intimidating. The reference code written in Go is spread over multiple repositories and it's a bit hard to make sense of it. So, we were, many teams were worried whether we would be able to make it on time. But luckily, the implementation teams have risen to the challenge and we now have LibP2P implementations written in Go, Javascript, Rust, Python, Java and NIM. And I've missed to add the C++1 developed so far not for Ethereum 2 purposes, but it exists as well. And I should mention that our own one written in NIM should be perfectly usable in CNC++ projects in the future. And what's more important is that during all this implementation are currently at the stage where they can talk to each other during the interop walk-in, we demonstrated networks where all these clients were able to reach consensus over LibP2P. But that's obviously not the end of the road. We have a lot of work to do ahead of us. The LibP2P spec that we created for Ethereum 2 is actually divided in, you can say, two or more phases. We identified some initial targets, some initial minimal set of common requirements that all the clients have to implement in order to be able to talk to each other. But these are not the underpins of a secure system. For launching mainnet, we would be changing a lot of the protocols to more modern cryptography, more modern way of doing this, we'll be adding new transports. And even this is not where the road ends. Overtime, there will be a lot of new high-level protocols defined for things like lead clients, for the communication within shards and so on. So just to give you an example, here is a comparison between this minimal interoff spec and what we expect to do for mainnet in just few months. We will be changing the encryption framework, the keys that are used to identify the nodes. We'll be switching to the subprot, changing the subprotocol on the negotiation, on the scheming, LibP2P and so on. Here we are introducing compression. You can say that the end-styres take on every single layer, there will be new developments. So in closing remarks, I would like to stress out that what we are creating here would be very valuable, not just for Ethereum. We are creating this system, in so many programming languages now, that could serve as the foundation layer for any kind of distributed applications in the future, and that's centralized. When we are ready, it will be very easy for many developers to just take over the shelf implementation of LibP2P for their language and build something amazing with it. LibP2P is not just for Ethereum, but our effort will make it much, much stronger. I feel that the next part of the talk will walk us through how do you connect to the network, what are the individual steps. The first thing you need is a discovery mechanism. Now, I did mention that LibP2P is going to go through further evolution, but one area where it didn't quite meet the needs of Ethereum right now was discovery. Since Ethereum has been solving the discovery problem for a while, and we have identified some unique requirements that we want to have in the network, the existing LibP3 solutions for discovery didn't quite meet them, so instead we decided to unite the efforts for Ethereum 1 development and Ethereum 2, and it introduced a new discovery mechanism called Discovery V5, which will be used in both networks. So the key features that are missing in LibP2P at this point is, first of all, the capability advertising. This is where a node can make sure that it can be found on the criteria that it supports a particular protocol. For example, this could be a node that supports a right client protocol and it can act as a server. And the other feature is topic advertising. Now, this is more about that this node has access to some resource. So it could be the fact that the node is currently connected to a particular chart, so you can sync the information on this particular chart and you need to find nodes which are already connected to it. And within Discovery V5 there is this general purpose mechanism of attaching arbitrary data. So it's both extensible in the future for adding more relevant information and it's quite easy to adapt it to the needs of LibP2P already. So after we have found other nodes on the network what we usually do is we'll start listening to the broadcast, the gossip sub-traffic as I mentioned. And here I've listed the few particular gossip topics that are relevant for following the progress on the beacon chain. And we have a topic where new blocks are produced. We have another topic where all the attestations are being sent and currently in interop we use a single topic for that, so that's enough to monitor the whole network. But what we plan to do in the future is to introduce separate topics for each individual chart and then you'll be able to choose whether you want to listen to the traffic for finalized blocks or the traffic for attestation on a given chart. And then there are a few topics which are beginning much slower amounts of traffic. These are just for announcing exits when a validator wants to exit the network or for thrashings when something behaves badly. And again here I would like to stress out that if you have a LibP2P implementation you don't have to write a full-blown plant. You can just implement an SSZ decoder and you can tune in to the gossip of traffic and start obtaining useful information. All right, but now that after we have connected LibP2P goes through a process where it negotiates the protocols that you can use to exchange messages with the other clients. We call this request a response kind of the domain of the spec. And so far it involves only few requests which are important for syncing the beacon chain. But before you start with this when you connect to another node you start by exchanging your status information with this node. And the status information includes four bytes in the identifier which is kind of acts as a marker for the particular software version you're using. For example, you can imagine if there was a hard fork and these four bytes will be modified in a way to indicate that you are now following different rules. And you can also be on a different network. You can be on a testnet and this again will be written in this four bytes identifier. And the other piece of information that is exchanged is what is the finalized route currently working on and what is your headlock. And obviously this is important because it allows the clients to determine who should be syncing information, who is... All right, I have to be much quicker. All right, the next request is... The status message tells you whether you have to sync. So the next request is your request box by a given range. And you usually do this when you are quite a bit behind. It's intended for historic blocks. And it's optimized in a way that the clients will be able to implement cold storage of the beacon chain. You have a database with random access and the range queries are supposed to hit only this database with cold storage for historic blocks. We also have a way to request recent blocks which is your request then by their hash. What we usually do is you connect to the network, you start listening to the attestations, you notice that certain blocks, for example the attestation in referencing a block that you are missing, so you request the missing ones. And this is a little bit like syncing backwards instead of forward. All right. I'll just then finish with... Here in the end I've left some links for anyone who wants to dig deeper in this spec that I have discussed. And thank you for...