 I'm Joe Long. I work for the Pegasus team on the Artemis client. And today, I'm going to talk about our architecture. Our architecture is designed, actually, before I get started, let me say something. I want to talk about something that's kind of close to my heart. I'm going to take about three minutes and talk about this. And so if you're new to the space and you haven't been in Ethereum 2 for a while, I just want to say welcome. It's kind of like drinking from a fire hose. I think the first time at DevCon 3 when I saw what they were working on, I was like, wow, that's something that I really want to be a part of. And being able to come and speak at DevCon about our own ETH2 client that I've been working on, it means a lot to me. And so I think some people might be asking occasionally why Ethereum 2 is taking so long. And from that perspective, I would point you to the DevCon 4 talk from Vitalik, his keynote, where he described kind of the pitfalls and research decisions that we were going through for the researchers. And that's a really good resource for learning kind of like all the individual paths that we took to kind of get to where we are now. And I think in 2016, people were still talking about using a tenement consensus and to think like how far we've come since then. And the Ethereum 2.0 researchers are in my view some of the most intelligent, hardworking, and thoughtful people that you'll find in this space. And in the hardworking aspect, I want you to challenge you to interview any Ethereum 2.0 implementer or researchers, spouse or significant other. And they'll tell you how much they hate the Ethereum 2.0 mistress. And so maybe a few weeks ago, we achieved Interop, which is very exciting. We were able to get seven clients communicating. And that's very difficult because research is never easy and there is no clear path to victory. And we are so close to the beacon chain. This is, in my view, the Apollo program of blockchains. And I just wanted to recognize all the teams who are here who are just kind of like dedicating themselves to this. If I say your team name, you stand up, OK? Don't be weird. OK, Artemis. Hey, stand up, then. Adrian, you too, dude. Yeah. Lighthouse. Lighthouse. Lighthouse. Lighthouse. We got Lighthouse in the house. All right, cool. Nimbus. Nimbus team. Thank you very much. Loadstar. We got any guys from Loadstar. All right, they slept in. That's cool. Harmony. I saw you guys, yeah? Great, great job. Great job. Shasper. I don't know if Waitang is in the room. Hey, Waitang, dude, I've never seen you in person. That's nice to see you. Trinity. Yay. Prism. Excellent work, y'all. Yeth. Dean's not here. OK, cool. All right. And the Ethereum Foundation, the researchers, and WhiteBlock, if y'all would stand up too. I just want to say, great material support. Thank you. They've sacrificed a lot to be here, and we're definitely very close. So now I'm going to talk about the real stuff. Yeah. So this is an overview of our stack. So we chose to use OpenJDK11, which is a Java framework. And this is our piece right here that we've written Artemis. And these are some of the libraries that we used. 20 is built, is run by the Apache Foundation, but it's basically Antoine right there. And JVMlibP2P, that's the Harmony guys, Antoine, specifically, yeah, really great job, and Web3J. So 20 we use for our typing. One of the problems with Java is that there are not great primitives. And so we wanted to be able to do some of these SSZ functions and more advanced functions using a bytes class that wasn't the Java byte array. And that's what that was for. And JVMlibP2P is, in the Ethereum 2.0 stack, that's how you communicate with your individual nodes. It's a pretty interesting library. Web3J is like Web3JS, but for Java, right? It is just kind of this ability to call out and talk to individual contracts. And we use Google Commons. And I'll get to that in a minute, but that's mostly the event boss. And then also how I mentioned types are not great in Java. So we had to have an on sign long because we needed 2 to the 64th minus 1 size integer. And we definitely don't have that in Java. The best we can do is 2 to the 63rd minus 1. OK. So talking about Google Commons, the reason that we chose to use Google Commons is specifically for this here, the event boss. This event boss allows us to have asynchronous communication in between individual services within Artemis. And so you can see these individual services chain storage, our proof of work chain, that's kind of like interfacing with the ETH1 net, beacon chain and validator. Beacon chain is the core spec that you'll see in the Ethereum 2.0 spec. And of course, we need a validator. So we can exchange these modules and multiply them and have fewer. And you can see we have our config and logging. I think everybody has that. So why choose Java? Oh, that's a really controversial question. So one of our thoughts when we were beginning was specifically in Pegasus, we're targeting some of the enterprises and interaction with Java for them comes much more natural. If you've worked at a bank or an insurance company or any kind of Fortune 500, you'll find that many of them are holy Java shops. And we wanted something that would be extensible for them. Additionally, Java provides, if you've worked in Java, you'll find that Java provides ability to build large, non-monolithic pieces of software. And so additionally, we were able to allow it allows us to do some of the event bus asynchrony. So what's so special about an event bus? So these modules, let me make sure. OK, cool. That's my next slide. Good. So these, I have two that say, what's so special about an event bus? These modules allow us to do individual jobs as services. And by using an event bus, we just are creating a service adapter. So if I want to put a message onto this bus, I can put it onto the bus. And other services can subscribe to that message bus. So I have a diagram. It's really handy. So you implement a service adapter. And you can, in your other service adapters, you can subscribe to some of the notifications that these other service adapters will be making. So in our design process, one of the considerations was we have products inside consensus like Infura that we are going to need data center scalability. We're allowed to have data center scalability by allowing ourselves to deploy multiple of these individual services. So if you can think of some complications that you will have with a client, one might be, I need to validate blocks. And many of those blocks could be spam. Well, by our design in this beacon chain, we can power on multiple of these modules. And we can validate these spam blocks, or reject them, of course. Another instance might be if you want to aggregate signatures. These are things that take a finite amount of time. And if we're going to do many of them, we will want to be able to deploy a service that allows to do many on individual services. Yeah, so that's pretty much our architecture. It's lovely. Right now, we're using Event Bus. Long term, we're going to use a GRPC interface. But that is some time away. We're focusing right now on productionizing. And after interop, we have dropped in JVM libp2p, which is exciting for us. Announcements. OK. So we're going to build a sharding client starting soon. And it's going to be in Kotlin. That's what that logo is. If you're not familiar with that, some of the advantages of Kotlin is that it compiles to machine code. It transpiles into JavaScript. It also runs on JVM, which allows us backwards compatibility with our beacon chain client. So we're really excited about that. The other thing, and I'm glad Harmony's here, because we're merging teams. Yeah. I think we had conversations where the world maybe doesn't need two Java clients for Ethereum 2. So let's combine our efforts. And so we're going to start that. We're already in process. And we're going to work conjointly on a single sharding client. And we still don't know what we're going to do with the beacon chain clients, how we're going to integrate them together. Cool. That's it for me. Thank you all.