# Ethereum 2 Network Spec and Structure by Zahary Karadjov

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2020-10-09
- Duration: 14:13
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-srAUIsEmqMA
- YouTube: https://www.youtube.com/watch?v=srAUIsEmqMA

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/5/ethereum-2-network-spec-and-structure

Zahary Karadjov speaks about the Eth 2 network spec & structure.

Speaker(s): Zahary Karadjov
Skill level: Intermediate
Track: Consensus layer
Keywords: evolution, libp2p, eth2, technical

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

good morning my name is a hiker drop I work at status on Nimbus which is a client for eat theorem 1 and helium 2 client forestry resources take the devices written in me and today we will be talking about the etherium networking spec how it evolved and what was the various design rationales that I went to into it so the person the major difference between a theorem 1 and a theorem 2 is that we are transitioning to the p2p which is a protocol developed by protocol labs for the purposes of developing ipfs it might short 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 the p2p and there are I would say two major reasons not to most important promises a flea p2p and the first one is that it promises to take a theorem to many new places where it wasn't quite possible to use it before and the reason this is possible because all communication in the p2p is carried all over this so-called the p2p streams which in turns are layered over let's call them physical connections which could be an arbitrary network connections that establish between two nodes it could be a TCP link in a classical case it could be some UDP scheme like quick which will give us very good censorship resistant in the future it could be the WebSockets in the browser it could even be snail mail let's don't forget the that protocol loves the people who created the p2p they want the system that would work on Mars so one of the key features of Lippett appears that it's not only option 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 lipid Opie sense and it's easy with the manger key enabler - for creating things like a tea room light clans running in the browser and the other significant reason is gossip sub this framework in the p2p for broadcasting data as we know a lot of the traffic in a cryptocurrencies network like aetherium it's about broadcasting blocks and now with the theorem to the majority of traffic is actually broadcasting the ad stations the other stations are the votes that the participant in the proof of stake consensus exchange with which is each other these votes allow them to reach finality and to cross link the state of all the various charts including each one so we know that from experience and from just theoretical reasoning that floods up the system where every message reaches everybody in the network you see and it's fully broadcasted on every step just one scale to the scale that we want to reach with the theorem but the p2p comes with the significant cost it it took quite a lot of convincing for the teams to jump on shame 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 bit hard to make sense of it so we were many teams were worried whether we'll be able to make it on time but luckily the limitation teams have rising to the challenge and we now have the p2p implementations written in go JavaScript Russ Python Java in him and I've missed at the C++ one developed so far not for helium two purposes but it exists as well and I should mention that our own one there's an enum it's a should be perfectly usable and seen C++ 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 interrupt walking we demonstrated networks where all these clients were able to reach consensus over the p2p but that's obviously not the end of the road we have a lot of work to do ahead of us and the leap p2p spec that we created for a tearoom - is actually divided in you can say to treat two or more phases we identified some initial targets some initial minimal set of common requirements that all the clans have to implement you know in order to be able to talk to each other but these are not the underpinnings of a secure system for launching maintenance 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 over time there will be a lot of new high-level protocols defined for things like light clans for the communication within shards and so on so just to give you an example here is a comparison between this minimum winter of spec and what we expect to do in form a net in just few months we'll be changing the encryption framework and the keys that are used to indentify the nodes will be switching to the supports changing the SU protocol negotiation scheme in the p2p and so on you are introducing compression quite you can say that the entire stack 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 a theorem like we're creating this system of Oh between 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 lipid to be for their language and build something amazing with it so the p2 is not just for a tea room but material our effort will make it much much stronger all right so I figured the next part of the talk we walk us through how do you connect to the network like what are the individual steps the first thing you need is a discovery mechanism now I did mention that the p2p is going to go through further revolution with one area where it didn't quite meet the needs of a tea room right now was a discovery since a tea room has been sober absolving the discovery problem for a while and we have identified some unique requirements that we won't have in the network the existing repeat fit solutions for discovery didn't quite meet them so instead we decided to unite the efforts for a tea room one development and here on to I need to introduce a new discovery mechanism called discovery five which will be used in both networks so the key features that are missing in the p2p at this point is one first of all the capability advertising this is where a known a node can make sure that can be found on the criteria that it supports a particular protocol for example this could be a note that supports the 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 for example it could be the fact that the node is currently connected to a party shirt so you can sync the information on this particular chart and you need to find nodes which are already connected to it and we didn't discover 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 Lippe 2p already so after we have found other nodes on the network what we usually do is we will start listening to the broadcast the gossip sub traffic as I mentioned and here I've listed the few particular gossip gossip sub topics that are relevant for kind of following the progress on the beacon chain and we have a topic where new blocks are produced we have a other topic where all the other stations are being sent and current in interrupt we use a single topic for that so that's enough to 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 like whether you want to listen to the traffic for finalized box or the traffic's for at the station 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 where a validator once talk to the network or for slashings when something behaves badly okay and now again here I would like to stress out it if you have a lip p2p implementation you don't have to write a full-blown plant you can just implement an SSD decoder and you can tune in to the gossips of traffic and start obtaining useful information all right but now that after we have connected the p2p goes through a process where it negotiates the protocols that can use and to exchange messages with the other clans we call this request response kind of the domain of the spec and it so far it involves only few requests which are important for syncing the beacon chain and 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 NT fire which is kind of acts as a marker for the particular software version you are using for example you can imagine if there was a hard fork in 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 test net and this again will be written in this form right in the end fire and the other piece information that this exchange is what is the finalized route actually currently working on and what is your headlock and obviously this is important because it allows the class to determine who should be thinking information who is right I have much quicker all right the next request is after the status message tells you whether you have to sync so the next request is your request box by 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 database with random access and the range queries are supposed to hit only this database of cold storage for historic works we also have a way to request recent blocks which is you request them by their hash what you would usually do is you connect to the network you start listening to the other stations you notice that certain blocks for example the attestation is referencing a block that you are missing so you will request in the missing ones and this is a little bit like thinking backwards instead of forward all right I'll just then finish with [Music] hearing the anti I've left some links for anyone who wants to dig deeper in this respect that I have discussed and thank you [Applause] you