 I'm Danny Ryan. I work with the Ethereum Foundation on the research team. I do a lot of work on ETH2 specs, research, coordination of client development, and all sorts of fun stuff. Today, I'm going to give you an update on what's going on, because there's a lot going on. It's kind of hard to keep up with, and hopefully this will help give you the lay of the land, and also help you become acquainted with some of the fun and interesting talks that are going to happen over the next few days. So a lot's going on. But first, I always like to talk about the architecture of ETH2. The simple single blockchain of Ethereum 1, so it's not very simple, but a lot of us have a good intuition for it, and I hope that we can carry a good mental model of the intuition of ETH2 moving forward. So we divided production and implementation of this into phases. The initial phase, phase 0, called the beacon chain, is a pure proof of stake blockchain that uses CASP Refugee as its core consensus and build blocks. Has validators, and it has this loose tie to the existing Ethereum 1 chain to handle deposits. There's a couple of roles that validators do on this chain. They build blocks, but just as importantly, if not more importantly, they attest to blocks. So every epoch or unit of time, validators are called upon to vote on what they see as the head of the chain to give weight to the fork choice and don't allow a small minority of pertosers to take over the chain. So that's phase 0. It is a simple proof of stake chain. It doesn't do that much, but it is the core infrastructure upon which we build additional phases. Phase 1, we have the shard chains. The shard chains add data, and I'll talk about that nuance in a second. So instead of just the beacon chain being built, we have these other shard chains being built in parallel. These shard chains are also cross-linked back into the beacon chain. And when this happens, it serves a few purposes. One, it roots the fork choice of the shard chain into the beacon chain, which becomes kind of canonical, a canonical reference. It also serves these points of cross-links serve as the point for asynchronous communication between shard chains. So with phase 2, we take the sharded infrastructure, and we actually add a state and execution and a layer 1 interpretation of shard chains and data. And I'll get in a little bit more into what that means a little further down the line. So Ethereum 2, it's not that complicated. And the next part of phase 2 would be to get rid of the proof of work chain, and roll ETH 1 into ETH 2, which we can talk about a little bit later. So Ethereum 2, not that bad. Sometimes I think about it abstractly as this kind of concrete object that we're building in an abstract void of space. Sometimes I think about, sometimes like these massive space habitats. And this Stanford Taurus is particularly apt because you have this core central component to the space habitat that serves as the infrastructure, the energy generation, where light is refracted into the outer Taurus, which is where the actual people live, the user level activity. And so to build this thing sanely, you can't just like build the whole thing on Earth because it's too big, you have to build it in space, and the obvious place to start is this core system, this core central infrastructure, building it out until we finally have paradise user activity. So those are the phases of ETH 2. So what's been going on with specs and research? We froze the spec July 1st, phase zero of the spec, that is. And today, later today, we're doing a deep dive on the spec, should be a good time, I think it's an hour workshop digging into that. This point really marked the transition towards production for client and implementation teams. It finally gave them something very stable to work towards, and I'll give you an update on their progress soon. A lot of consensus tests, handwritten tests that help us make sure that clients come to consensus with each other before we actually get to production and networks. Shout out to Proto Lambda, he did a lot of work on this, and it saved us huge headache, debugging things on networks. Been a lot of work on efficient Merkel proofs. We have these pretty cool tree structure called simple serialized tree hashing, which allows us to take generally objects and fit them into Merkel trees. So we've been working on how to efficiently make proofs about these, which will be relevant to execution environment, state execution need to, and light clients, and all sorts of other cool things. A lot of work's been going into decentralized staking pools. This is kind of a little known component of the protocol, but all of the different things that a validator must do, their duties, we've been designing in a way that is multi-party computation friendly, and there's a talk later today on that about decentralized staking pools. This is kind of a little known area, so go to that talk, check it out, and some of you all should probably start building these, the multi-party, all the things. There's been a lot of academic analysis, audits, and formal verification. I want to thank Yan Zhang, who's been doing a lot of work on formalizing Casper refugee in this new context of proof of stake. A lot of audits have been going on, and runtime verification's been doing some great formal verification work, both in the deposit contract, and recently created a model of the KB Conchain, a formal model in which we plan on verifying properties of the protocol, such as safety, liveness, and other things. There's a short talk during the climate summit tomorrow if you want to hear more about the KB Conchain. Networking's back out a lot of love recently. It kind of existed in just a proto form until a few months ago. Shout out to Nimbus Lighthouse and Protocol Labs, members of those teams stepped up and helped drive this, which was critical to getting initial interop of our clients working. And I do just want a quick side. Yay, LidP2P. There's been a lot of, quite frankly, flood around LidP2P, whether it's a suitable choice. And as teams have been taking more ownership over their domains of this project, and finally integrating them in, we've had a great success, and I'm excited to continue to use it. Phase one spec, Justin Drake's given this thing a lot of love recently. It's now, quite frankly, pretty elegant. Mirrors the phase zero specification, a lot of work on testing, ironing out some of the more nuanced details, and exploring some opportunities to maybe increase the amount of cross-linking that happens to help facilitate cross-track communication. So something that's, in the past six months, the lay of the land in the direction of what we call phase two, which is that state and execution of ETH2, has radically changed. And actually, it's not state and execution, it's stateless execution. Casey from the EWASM team put out a post in April about using, kind of reframing how we think about this highly scalable system. So at its core, what ETH2 does is it solves data availability, and it's a data availability engine that comes to consensus on anywhere between like one and 10 megabytes of data per second. And so reframing the phase two conversation around how we can more abstractly just use this highly scalable data layer instead of having to bake all of the execution and things into layer one. Now what does that actually mean? State and execution in ETH1. This, it's very limited view of the world there, but in consensus, we have this strong notion of state. You assume when you're processing a block that you have access to all state. And you also have a strong embedded execution engine, where we have these formal and hard-coded rules and notions of account and account model. And so your change just has transaction data and executes using these rules upon that state, transitioning that state within the consensus. But in ETH2, we're moving to a more abstracted model where instead of having the hard-coded state execution rules and having the entirety of state available within the consensus, we're moving to this abstracted model, which we call execution environments or EEs in which state, the notion of state, the notion of account and the notion of execution upon that can be defined in a more abstract way and can be defined actually not in the core consensus, but at the user level. And so we have these, each of these is execution environment, which is a chunk of code, wasm code, which would specify the rules of execution within that realm, within that domain. And you can actually deploy more of these. The actual model on the cost of either burning or locking capital, just to avoid these, is still up for debate, but it would be expensive because you're deploying code on this globally accessible thing called the beacon chain. And so, where's the state? The state does not exist in the consensus. The state actually exists, the state that you need to operate blocks, which these blocks you know are a little bit fatter than previous, because now instead of just transaction user level data, we have what we call witnesses, which are the components of state required to operate on that block, so it's kind of like the database and proofs that that data is valid against the state root. And so when you update a block, you're actually not modifying the state within the consensus, you're just updating the state root, which is kind of like the digest of the state. You can do a lot of really cool and interesting things here and from my perspective, what this allows us to do is instead of us guessing what Ethereum can or should be in 20, 30 years, this allows us to naturally extend and upgrade and modify execution as there's innovations on that layer. And the really nice thing is that it gives us a clear trajectory and model on how ETH1 can actually be slotted into ETH2 and has given us a more of a concrete idea of how to handle that upgrade and trajectory. So ETH1 actually can become one of these execution environments where essentially the EVM interpreter written as WASM can become the exec code within this execution environment and the state root, the existing current state root within ETH1 would be forked in here along with the ether balances. There's a lot of work going on on evaluating EEs, evaluating stateless execution, trying to understand and capture the complexity of ETH1 as an EE. And there's a workshop, I think. There's a couple of WASM workshops. On the last day, there's a fishbowl conversation about all of this, so check it out. Cool, a lot of work going on on Light Clients. We have a super light sync protocol on the order overhead of Bitcoin SPV. Been a lot of work on incentivized servers. Zolt is giving a talk soon after this about that. Starting now, the load star's been digging into it and there's a lot of LES work that will inform ETH2. Learn more, there's some talks. The client journey a lot has transpired in the past year. We've gone around the sun once and clients have also gone from early fledgling prototypes into what are beginning to look like production grade systems. The journey was, if you've been following, it was difficult for a while because they were beginning to work as we were still writing specifications. But as I said, we've definitely moved into that production engineering phase for phase zero. Something particularly exciting that happened recently was Interop, thank you, Joseph DeLong and Consensus for putting this on. At the time when they came up with the idea, I was a little skeptical. Sounded a little bit crazy and I wasn't sure if it was gonna actually be a good use of our time. By day two, we were quite ecstatic about being all together and getting things to interop because we were making incredible progress. So I think all seven clients that showed up successfully interopped, I think that's actually five of them right there. And Parity Shasper, which could not be in attendance, has also begun to work through some of these exercises. Beyond that, discussions on sync and ironing out other coordinates of the protocol. Fun little side projects. I think we had a test net with 2,000 validators on a few different machines, which was particularly exciting. So some initial load testing. And this was a fun one. This is a couple of Raspberry Pis on a small network with beacon chains running on them. Mami, later today, I think on this stage, is giving a talk about the Raspberry Pi. It should be a pretty fun one. It's about the load of ETH2 and the expected requirements and actually getting it to run and build on these small devices. So what is coming up for clients, optimizations? So one of the, I think probably the most obvious place for optimizations is first, BLS signature processing. We process a lot of signatures. We have a lot of validators, and even though we can aggregate these signatures, that's still a high source of load. So we've seen people begin to open up the BLS implementations and optimize them, seeing some gains, order of magnitude gains there. What else? The tree hashing structure. We have a lot of hashing that goes on, and if you do it naively, it takes an incredible amount of load, but fortunately, much of the tree doesn't change. So there's a lot of caching optimizations going on. Stabilize, we need to bring these things towards production stability and grades such that they can run essentially forever, unstopped. And usabilitize, that's not a word, but the usability, UX, getting these hands, getting these things in the hands of users and making them actual products is, instead of command line tools that someone that built them can sophisticatedly use, more usable and real products. This is, some people are actually doing some independent work on validator clients right now to actually like make nice GUIs and there's some promising things in that respect. This guy. Right, so we're also doing some buzzing efforts. Guido recently, a while back, built out kind of a core infrastructure for handling differential buzzing of clients. Recently, Medi from Lighthouse has taken over that, integrated a couple clients in and is figuring out how to randomly throw all sorts of junk at these clients to see that they all handle these crazy inputs the same. What this does is it takes, we have our consensus test, which we're all the scenarios that we could think of, but fortunately with randomization, we can come up with all sorts of scenarios that we didn't think of and find the edge cases before production. So, what's next? As I mentioned, we're in that production phase, we're moving phase zero towards production. A lot of the conversations since Interop has been about continued test nets. So both private, doing some private load tests on clients, but also opening up towards public test nets and incentivize test nets. So, keep your eyes peeled for that. If you're thinking about being a validator, this is your chance to get your hands dirty. And be an active, when these public test nets come out, be an active participant. If it doesn't work, tell somebody. If it's hard to install, file an issue. Like, if you have an idea for increasing the usability, either open up an issue, suggesting it, or go and fix it. So, this is definitely an exciting time, this last mile getting these things to production. So, be active and be engaged with it. Phase one and two, R and D. The specs for phase one are coming. I mean, they're in a place in which people are prototyping. Props to the Quilt team yesterday. They did a demo of phase one and a minimal phase two built on top of Lighthouse. And beyond that, a lot of work going on, just kind of refining this idea of execution environments. It's quite a large design space. So, we're trying to hone that in the coming months. Developer tooling and dialogue. So, as Casey from Waslam likes to say, this seems to be a humanist process, a human focused process. The reason that Ethereum is so great is the developers and community that we have out here. And so, making sure that the transition from ETH one to ETH two enables and enhances the experience of developers is very important. If this goes according to plan, we can kind of rewire and rework some of the interfaces and things behind and underneath our current tools and developer interfaces such that developers can continue using the things that they use to continue building on Ethereum and making it great. Here's a quick glance at the ETH two track. I'm sure you have it in your app, but there's a quick view if you want it. Lots of fun stuff. Putting ETH two to work, that should be fun. Checking out how we can use finality on ETH one to enhance the security. All sorts of stuff. Check it out. I'll be at the phase zero deep dives today. We'll be digging into, I know we do this high level thing where we just show it all. Where I kind of go through it very simply, but we're gonna dig into the different components and help you read and understand the spec today. I want to highlight the 2.0 client summit, which is tomorrow. We have a number of clients working on this problem as you're aware, and they're gonna be doing these like 12 to 15 minute talks, discussing different components of the design, different challenges at hand, and after that, there'll be a panel talking about upcoming test and test challenges, et cetera. That's all I got for you today. Building the future. Thanks for having me.