ETH2.0 networking

EDCON 2019 · 12 Apr 2019 · 9:30

Zak Cole reviews networking work for Eth2, including a wire-protocol prototype and the difficulties of supporting different client languages. He demonstrates a multi-node test environment and discusses bandwidth, delay, gossip subscriptions and block propagation, emphasizing controlled experiments for identifying architectural weaknesses.

Speakers

Topics

From EDCON 2019, hosted by EDCON.

Transcript

so up next we have the founder and CEO of white block Zach Cole he's also part-time rock star out of LA here he comes walking in crossing the Pacific Zach's gonna talk to us about e 2.0 networking thanks hello I'm Zach from white block we've been working on networking quite a bit most recently we work we've been working with the great Matt slipper and defining the wire protocol so let's see so I'm gonna go

over some of the things we've done and some of our next steps so let's let's go over the wire protocol so the process of defining the wire protocol was a little bit arduous because a lot of people seem to misunderstand exactly what a wire protocol does it shouldn't really be responsible for like serialization it should be agnostic mostly to TLS it's really just a link between two nodes that they used to communicate between one another you're pretty much just like shuffling bytes so it's different than an API because it's you know really agnostic to all that and then the protocol developers mantra that's the application layers problem so the application should be handling a more

advanced logic but all you're really trying to do is like build a road there that's pretty much as far as we've got with networking stack into dotto there is Lib P to P which is the networking stack that was used in IP FS it's used all over the place it's pretty great framework for peer-to-peer communications we spent a good portion of last year testing gossip sub unfortunately a lot of these implementations are still nascent obviously so not every client implementer team was able to just use Lib PTP natively prismatic and lighthouse and anybody that's writing and go or rust for example they can

easily plug and play Lib p but teams like artemus and loads start lebreton and j s and java can't really use lib PTP at the time right now because it requires a you know additional development because the support in those particular languages just aren't available so rather than being bottlenecked by waiting around for lib p2p we decided that we were just going to we're just going to build our own you know protocol for testing purposes only so we wrote hobbits or there and back again which is a reference to the hobbit anyway so it was lightweight it's meant to be modular

it's really just for testing purposes so we didn't make it to say hey this is what you guys should do it's just that at a certain point as we're developing these consensus mechanisms and these new systems we're really not going to be aware of how our systems are gonna perform until there's a functioning network there so rather than be bottleneck we just used hobbits and we implemented it in Artemis and we're currently implementing it in lodestar and we got them all up and running and talking took us about a week to develop and implement it was a joint effort between white block consensus and also the guys at chain safe also Dean I don't

know Dena Inman he's I'm not sure who he's with now I think he's with status he's just kind of a troll so we got it all running on white block ported it over so white block is our testing framework so we're building out 50 nodes with Artemis with 16 validators this whole process I kind of just skipped through it but it like provisions all of the nodes assigns them to their own VLANs configures them with IP addresses and you can see that we do you get nodes and you can see a large array of all of the nodes you can see each one of them have their own IP address so they're all logically separate separated from one another and also separated from one

another like layers 2 & 3 like tcp/ip so everything's running we got it all up everything's gossiping with one another is a pretty tremendous feat because I didn't think we could do it but we did it in like a week so that was pretty cool it's not really been battle tested yet as far as the client is concerned and all that additional logic so we can also offer well here's here's console one so you can log into the console on each note and observe like what's happening there we created bacon chain a teeth Paris this is kind of like a crappy visualizer that we've been using but it works so far we really wrote all that code in like 10 hours or so and it

worked so for the network layer we can ping between two individual nodes so you can see there's no network configurations that have been set so this is just you know latency in a in a in a box like an isolated space so now we can apply different network configurations so that allows us to emulate links between all these nodes so that way they actually replicate real-world performance so you could say like node one is in Tokyo or node one is in Los Angeles etc and they'll actually perform in the same way they would we have a variety of network testing utilities as well so this is like iperf so that's used to test like the quality of traffic between two nodes in terms of

bandwidth and this here we're applying delay so this is just kind of a basic demo but we're playing 100 milliseconds of latency between all of the nodes and then we run WB ping so you can validate that that's actually working and yeah so we have a hundred milliseconds so the idea is we want to observe how consensus mechanisms and how application performance is affected by various environmental conditions because when you test in a box or in a local area network or like run unit tests for example you're really only understanding how the application is going to perform on one monolithic node but in a

synchronous distributed systems like blockchain it's really important to understand the entire network because they're operating at its operating as a singleton so application performance when engaging application performance you really need to be consider you really need to consider that and it's also important because aspects of eath to are reliant on time and anybody knows anything about time you know it doesn't exist especially in a computational environment so when these issues are actually present and available things go wrong pretty quick and so what we want to do next is we want to continue our tests for gossip sub to identify whether or not it's going to be an appropriate

mechanism for block propagation or gossiping within the network like I said because timing is an issue we want to understand whether it's appropriate to use gossip sub because you have a particular amount of time in which you need to subscribe to a particular topic and begin identify your peers within that shard or topic and then begin broadcasting messages that relate to that topic and if you can't do it in an adequate amount of time you're gonna you're gonna find some sort of deadlock or application failure which is pretty bad so we really want to make sure that everything works and walk through it and you know approach this in a deterministic way we use an iterative process where we identify the metrics we'd like to observe the environmental

conditions that may affect them and then we apply them in various test series so that way it's in a controlled it's in a controlled manner so the results are more objective and we're also trying to find what is the best block propagation mechanism so let PTP has a lot of this stuff natively we're working with protocol labs on evaluating all of these because Lib BGP is awesome but who knows it could just could everything could break and we don't want to end up in that situation so we're gonna just take a more objective approach and analyzing and evaluating all these things or movie we have single client test nuts setup

now a lot of people are running them it's been pretty exciting but we want to move toward a multi-client test net because that's when things get really interesting so I think that we should just like you know mess up everything break stuff when we can because it helps us identify the weak points in our architecture and allows us to optimize our design so let's see I don't really want to show a white block here so all right any questions or comments from anybody guys please no yeah that's it I just want to keep it short and sweet like me so love you guys

[Applause]