 So before we start I'll talk a little bit about what we'll go over today. So talk about a little bit about who we are at White Block and what our role is in ETH2. Challenges to networking in ETH2 We'll go over a recap of the interop lock-in that we had in September and what our role was there and a roadmap as well as a Q&A at the end. So White Block is a team of engineers building tools to test blockchains, servited systems, protocols, what have you. We have a core product called Genesis. With Genesis you can fully automate the creation and deployment of a blockchain. You can configure network topologies, deterministically test how they'll react in real-world and worst-case conditions. We can do things like implement a network partition to force forking events and see how your blockchain will react and reconciliate that information and the reason why we're talking about it is because we will use its functionality to test interoperability in ETH2. So here we have everybody's favorite diagram, the networking old paradigm, right? So sorry, it's a little messed up. We just downloaded to PowerPoint and didn't have time to fix this. So you have a client querying server for information that it desires, server acts as the centralized point of truth for that information, right? Everybody knows this model. That's why we're all here. Cool, so then you have blockchain networking, which is very, very difficult. You have a bunch of nodes in the network that are tasked with challenge to communicate over a large network and communicate with unknown peers at that. So it gets pretty difficult. In ETH2 specifically, this means that you have nodes receiving messages of blocks and attestations and propagating them to other nodes. And they do this over an asynchronous communication pattern called GossipSub and we'll talk a little bit more about that later. So nodes will receive a message and pass it on to their interested peers. And the idea with GossipSub is that a message will efficiently propagate throughout the network once the originating node broadcasts it out. So nodes will request information they don't have from other nodes. So if a node has adequate resources, it learns of a new block. It will RPC request the node that has that information to receive it. Cool, so there are a lot of challenges in distributed networking. I don't know how aware you are of them, but we've listed very few of them. But we're actively at WebLock looking at these challenges along with ETH2 client teams, ETH2 research teams, and other teams in the space looking at them. So there's the issue of peer discovery. How do you as a node find other nodes that you want to talk to in a large network? The issue of distributed hash tables, so DHTs. How do you store information about those peers in the network? There's the issue of security. How do you increase tolerance to certain kinds of attacks that are prevalent in distributed networks like Eclipse attacks, what have you? The issue of block and attestation propagation for which we will use GossipSub. Again, we'll talk a little bit more about that in a second. The issue of boot nodes in the network, which are points of centralization, perceived to be points of weakness. Issue of cryptographic verification, checking to make sure that signatures are valid, hashes match block information. And then the issue of syncing. So how do you efficiently sync and securely sync information against other nodes in the network? So I'm sure that you guys have already had like your ears talked off about Lippie2P at this conference. It's been like a super hot topic at DevCon. And if you want to go, we're only going to cover it briefly. But if you want to go like more in depth about it, Raul Kripilani from Lippie2P did a talk about GossipSub like two days ago. I'm sure the slides are already up on Twitter somewhere and the video will be uploaded. But he did a really good deep dive into GossipSub. But we will cover just like very basically what GossipSub does so that we have a base to start off at. So GossipSub is an epidemic broadcast protocol. It's an implementation of a PubSub communication pattern. And it's designed in such a way that information will efficiently propagate across the network. So nodes will listen for information that they want and pass it on to their peers that want that information. Pattern will continue until all nodes that are interested in that information have received it and in the network. So GossipSub is an efficient protocol for propagating blocks and attestations in ETH2, which is why it's used as the ETH2 networking stack. So back in April, we actually did a few preliminary tests on Lippie2P. And they were not so great. But again, like Raul mentioned that Lippie2P is in alpha mode right now. So there are a lot of parts of it that still need to be like massaged and improved to make sure that it's going to be ready for phase zero launch. So we at WhiteLock will actually continue testing and auditing Lippie2P to ensure that it will be ready for a successful phase zero launch. I'm going to talk about that. Yeah, now we're going to talk about testing. Cool. Thanks, René. So why are we testing GossipSub, right? So the point of this is to really assess the reward performance of GossipSub under very adverse conditions. Dropping peers, bad bandwidth, packet loss, huge latency between the nodes, knowing that in the case of ETH2, we have six seconds per block. So if you want to really gossip everything, you would want to have three seconds to gossip the whole information between all the peers so they can decide and start voting correctly on the new block. One thing that we can really tweak during that testing is the different network topologies. So if you went to Raoul's talk, he said that you have a minimum of four peers, a maximum of 12. Is that really what we want to go for? Should we have more peers? Should we have a few better peers? Should we start working a little bit on some of the work he wants to do for Episub, where we're going to have optimizations, where we're going to prefer nodes which are closer to us, which have lower latency, which are more responsive? We're going to look into that. So to get to work, the first thing we did is when we did our pass in April, we used the Gold LPP2P daemon. This time we're starting from scratch with a company called the Agency Enterprise, and they're really great, they work really closely with protocol labs. So Adam Hanna has been building a LPP2P client, which is based on the Gold LPP2P core library, and it's a very simple client that just is going to output a bunch of metadata information about the message, right? When was it sent, who sent it, who is it for, how many hops do you see for that message, you know, how long has it been around, what type of, like, how long was the hop between those different peers? We also hired an academic on our team who's now doing literature review to look at the different topologies, everything should be done there. Namely, right now, we'd like to try also to do some discovery, you know, associations, so we can do an academic approach to just let the network self-organize. But it might actually not be the best way to organize the peers, so we're testing all those different aspects. So, yeah, talking about network topologies, we're going to strain it, we're going to create a sequence of peers, we're going to create a mesh of peers just like redundant hubs between each other. So, we're going to really see that, you know, from node one to 100, we're going to have to traverse all the other nodes to get to that one. So, this is in progress, you can check out those two repos, the first one here is our project management repo. This is all the issues kind of reflect the work from the team, you can take a look, contributions are very welcome, your feedback, any issues you see. The work itself, the benchmark tool is actually under agency enterprise, you can take a look at it, you can run it right now. The idea is that we're going to talk right at work and then deploy it on Genesis, we're going to run, you know, 30, 100 of those in parallel. And we had some unexpected good news, I don't know if I'm in here, but we got access to an academic facility to run all those tests, something called emulab.net. So, we're starting testing actually this week, we got a guy on this, we're going to publish all the raw datasets for every test suite on Google Cloud Storage, you can download those. They're, you know, 1.5 gigabytes each, so it's quite a bit of data. And then we'll also share the Python parsing script that we use to read all the logs, to make sense of them, to compile all the statistics, the median, all this data and we'll make that open source as well, probably under the PM repo. So, the idea is that we want to be completely transparent, make sure that our work is being reviewed by the community, that if you have an idea or a suggestion for a different type of testing, you can come to us, you can ask us questions. We can have a conversation about this and we can come together and collaborate on all those things. So, to switch gears, this is coming a little bit also from our work with Ethereum 2. So, just going to do a little recap on the interrupt workshop that we did in September. Here you can see these are stand-up in the morning, have Danny Ryan telling us how things are going, we're going by team. Here you have different teams working together, working on the same laptops. So, the purpose of Interupt for us was to establish communications between the teams to make sure that they had a good process to work together. Coming into Interupt, we just wanted people to just take one laptop, two clients, make them work and see if they're able to even just gossip a block, say hello, have some information. We had some great tooling from Porto Lambda from the Ethereum Foundation. So, he gave us a way to pre-generate a genesis state, like 30 seconds or one minute in future, that everybody could ingest, as well as a list of validators that would be associated with each client, and then he would give us the ability to very quickly set up this type of scenarios. Initially, what the clients did was only one client in the testnet would have validators, everybody else would be passive and just ingesting all the data. And as we got closer to the end of the week, everybody was able to have validators at the same time, so everybody was producing blocks. We had to get everybody going. A good caveat of this is that it's a little jurigged because we had to kind of go with the flow of those different clients. Some clients did not support Sync, for example, so if they started after the genesis time, they would not have a good time working with the others. So, also, to give you an idea, it was very manual. They would have a T-Max kind of window at first, start first client, look at the enode of that client, paste that into the stock script of the second client, start the second client, start the third client, et cetera, et cetera. Very manual, but for first try, that was a good try. So, we had a few panics, we had a few interesting crashes. We saw all the things that could go wrong. And, well, eventually they managed to get seven clients on the laptop, which is a pretty good result, much better than we anticipated going in. So, yeah, eventually what we want to do now is to actually productize this. So, recap of the success, we had seven clients talking to each other on a local machine. A little harder for us, we were using Docker, and now we want to productize what they've done into whether it's completely automated. So, for us, it was a little harder because each client is ever so slightly different. I'm going to go into that. The way we run things with genesis is that we pretty much take whatever Docker image a blockchain client has, and we just automate its creation and its lifecycle as part of a platform. So, it's very easy for us, once everything is in place, to go very quickly to a testnet and to just generate many of them. So, things that kind of took a bit of time to figure out. We saw that, you know, even so everybody's using LiP2P, when you have an address for a client, for a node in LiP2P, you can do a couple different things, you can have the public key of your client being published to all your peers, or you can choose not to do that, and when they connect to each other, that's when the public key gets exchanged. So, in that case, for example, some clients would just barf because they didn't want to have the public key of the other node in there. So, we had to start tweaking for that, like Lighthouse didn't like that, or should we have to change the start script just for them, etc. We saw also that they have a different ways of storing the identity key, the key that actually represents the identity of the node. LiP2P, by default, is going to use a pot above format, which adds two bytes to the beginning of the string that we store. Some clients like that has a hexadecimal string being passed, some like that has a base64 string to be passed, and some like that into a file. So, we had to account for all those different variances of the ways they would consume the information. All this, of course, works very well when you're doing static peering. At this point, I think we have two clients that do this V5, it might be wrong. So, that's something that we need to look at next. So, we're going to talk a little bit about that quickly. For us, it was kind of a great learning experiment. We're going to generalize our framework to make it much easier to accommodate those clients without changes as much as possible. So, discovery. I love Discovery V5. I need to make stickers for this. It's a big change for me if one, you know, and if one you used to have just the URL being broadcasted to all your peers, and you would have those cademia buckets where it would be organized. In Discovery V5, you now have the notion of Ethereum node records, which are still signed or still making sense. There's a little bit of security. You can do a handshake so you can kind of make sure you're not being spammed as much. But what comes with ENRs is now the ability for you to have in those key value pairs that can arbitrarily store in them a notion of topics. So, you can actually, when you come and, you know, broadcast yourself to others, tell that you're a NIFT2 node or you're a NIFT1 node or you're a Polkadot node. So, this allows other blockchains to also participate in a global DHT, this new cademia DHT, which is also simpler than it used to be. So, it's going to allow better security. Right? So, back six months ago, Felix Lange came to New York. And one thing that he mentioned is that Discovery V5 will only work if you have over a thousand nodes running it. Otherwise, the security is going to be compromised by Eclipse attacks very quickly. So, this is a huge effort, it's going to allow if one NIFT2 to also share some of the work and to share some of the infrastructure. So, really excited about this as a network geek. So, next steps for us. So, we're recipient of NIFT grant. We thank the IFM Foundation for helping us in sponsoring this effort. We're going to continue working on some of the tests for spec conformance in terms of networking. So, we're going to be able to replay traffic, send can requests, make sure that we're getting the response we expect across all the clients. It's kind of at the unit testing level, if you want. And we've been talking a long, long last about the LEPGP gossip testing. So, we'll continue editing that. We want to kind of have a hand in this, make sure that all the configuration parameters are kind of optimized for the workloads of IF2. And we're pretty close to being able to do a multi-client testnet with all the production ready clients. So, the idea there is that every time there's a new Docker image for Trinity or Lighthouse or Artemis or anything, we can pick that up, insert it into the testnet, try it out, see if it's behaving correctly. It's still able to finance the blogs, all this good stuff. So, not to put words into the IF2 client's implementer's mouths, but their heads down, finishing up all the work, all the details, all the H-cases, all the things that are kind of sticking out, really stabilizing the implementations. And we want to help them get the safety that they need to declare a phase zero release. And with that, they call your questions. You're asking how things went and who started first. Is it a spec effort or is it a... Yeah, so it's interesting. So, there's been, first like some, I mean they've been talking about IF2 for years, right? So, there's a lot of different initiatives and efforts by Vitalik. Eventually, the research team around IF2 kind of solidified with Danny Ryan kind of helping also get to a point where he could name releases of the spec, right? The spec was written by Justin Drake to be more in an executable format so he could actually become part of the testing. I think PortoLemda really helped as well to really create testing and tooling around it. And in parallel, all the... I mean, the implementation I'm most familiar with is Artemis, for example, right? And what happened is I had a lot of churn because lots of moving pieces came back and forth, right? So, SSD, for example, at three or four incompatible designs to each other until the point that they agreed on all of this. So, every little piece of the spec kept changing as part of decisions down the road. You mean the networking? Networking is not done, I think. So, there are a couple of things in networking. One is the wire protocol where we're getting to a point where we have a good idea. Gossiping is actually pretty easy because you just use GossipSub to just send all the blocks, all the attestations that you have. So, that is not too much of a problem. In terms of syncing, the team right now are talking about different syncing strategies. If you're familiar with IF1 and all the ways you can sync, there are so many ways you can do this. It's still something that is an active research. And our time is up. So, yeah, there's more. And there's no RPC interface for IF2 yet, as Greg mentioned yesterday on this very stage. So, when we did the first round of research, we found that the median time was pretty low and pretty good, but we had upliers which were really, really bad. So, it looks like the routing strategy is not always optimal. I think that's the only hunch I really have at this point. Okay, so, how we scale to thousands of nodes in our testing scenarios? Yes. So, right now what we do is we do small-scale testing about 30 to 50 nodes. Our first LP2P testing was 100 and required quite a bit of compute. Right now we are in touch with that research lab, it's going to give us pretty much infinite resources across the US continent. So, we'll see how to go about that. We run Docker containers, so we're pretty agnostic about the underlying hardware. We run on virtualized cloud software like GCP, Amazon, Azure. So, the idea is we just add more and more machines, about 100 nodes per machine to scale to that. We try not to do thousands of nodes. From experience, from practical experience, we certainly know to get already a lot of insights because we can really tear apart all the network connections. We can simulate a lot of latency. We can actually have nodes being simulated between New York and Tokyo, for example, to really show what happens if the transaction takes a long time to even come back to you. So, second part of your question, I'm going to get killed by this guy. Yes, he's staring me down.