 So we're going to talk today about the CVC CASPER roadmap and it's going to be a little bit less action packed than the normal DevCon talk. So here is my little outline. I'm going to be talking about the roadmap as a research roadmap as opposed to an implementation roadmap or roadmap for developers. I'm going to talk about the relationship between my roadmap and the Ethereum roadmaps. I'm going to talk about our past and future work, somehow the roadmap is made up of all the stuff we've done and all the stuff we're going to do or planning to do. And then I'm going to give some resources and announcements. So CVC CASPER roadmap is, as I was saying, it's a research and architecture roadmap, the outputs of this roadmap or research and specifications. We don't like the goal of the roadmap is to produce architecture, to produce research in the form of distributed systems, computer science, like theoretical computer science. And then also to produce specifications, which serve as abstract descriptions of protocols, which if you implement anything that matches the specifications, you'll get all the benefits of the architecture. So somehow the CVC CASPER roadmap produces architecture and research and then it's up to engineers to implement the architecture in a way that works for them. And any way that you implement the architecture will inherit the properties of the architecture. So if we prove that this architecture has a property, then any of the many ways that it can be implemented will benefit from that property. And so the CVC CASPER research doesn't produce complete protocol specifications. It produces architecture level specifications, for which it's guaranteed that any implementation that matches the architecture will benefit from the features or the properties of these protocols. So we're kind of independent from the engineering effort. So if we end an architecture and then engineering kind of happens after. But it doesn't mean we don't provide support to software developers and help them interpret the architecture or we're going to provide support, even though it's not the roadmap to implement it. The roadmap is to come up with the architectures and to do the research. It's a research roadmap. It's all about building correct by construction consensus protocols. Correct by construction engineering is about designing your systems in a way that is guaranteed by the process you design them to be correct. It's about not the correctness. It's about the process that is used to develop these protocols. So we really formally state the design requirements and abstractly state protocol statements. And then we refine them in order to derive from the problem statements a solution to the problem that is guaranteed by the way that it was derived to be correct. And so we state the design requirements and then we derive a solution to satisfy them directly from the design requirements, which are in terms of abstract protocol specifications. So specifically, we're interested in not just any consensus protocols. We want scalable proof of state consensus protocol to have the same network overhead as Nakamoto consensus. We want to be able to have blockchains that work on an internet scale that don't have crazy overhead, like a traditional consensus protocol, but actually have the same overhead as Nakamoto consensus or comparable to the overhead of current Ethereum. So basically, we want to be able to meet all the normal requirements, all the traditional requirements of a consensus protocol, like safety, non-triviality, and liveness, and also a bunch of other requirements, like, for example, being able to make this ideal theoretically optimal overhead trade-off. And also, we're interested in scalability in move starting and basically, which we understand entirely in the consensus protocol framework, where, you know, if you went to the sharding workshop yesterday, that was all about that. So I'm not going to really touch on it now. So we have a really deeply formalistic approach to protocol design. We are formal from the very start. We never engage in trial and error in the normal kind of development fashion. We don't implement stuff until we know for sure that it's correct. We do a lot of math before there's a single line of code, there's a ton of math before there's a single line of code. It's a deeply, deeply formalistic process and it takes quite a lot of time to produce a specification this way, especially if you mean like a complete specification. But it's guaranteed to be correct because of the process by which it was derived. It's, you know, it's correct by construction process. And it's also guaranteed to have a certain aesthetic appeal that is like common in mathematics, where you kind of only make the minimum most natural choices and nothing more. And everything is kind of natural and elegant and everything is symmetric. And, you know, it has like this nice math problem, math feeling that you get from looking at any, well, any good field of math. And that is like one of the big appeals, I think, of the roadmap. Is that the aesthetic appeal is very, very high because everything is like derived from math objects in a way that's very careful and it doesn't involve weird arbitrary choices except for to the minimum possible. So that's the basic idea, like what it is. It's a research roadmap. That doesn't tell you too much, but before I go into the items of the roadmap, we're gonna talk about the relationship between the CDC, CASPER roadmap and the Ethereum roadmaps. So in some ways, we're completely independent of the Ethereum roadmaps. You know, where research roadmap, Ethereum roadmaps are a roadmap for deployment on Ethereum mainnet. But, you know, some ways, you know, CDC, CASPER research has, you know, made its way into Ethereum 2.0. And maybe it'll make its way into Ethereum 3.0. Question mark because it's not really clear yet what Ethereum 3.0 is. One of the things that is probably the most famous that came out of CDC, CASPER research is the latest message-driven ghost poor choice rule that is featured in the beacon chain. Another thing is to have made a proposal to add the CDC, CASPER, finality mechanism to the beacon chain. So somehow the CDC, CASPER research flow from the research roadmap flows into Ethereum 2.0 research, at least a little bit. In some ways, you know, so in some ways, actually the Ethereum roadmaps are not really independent of the CDC, CASPER roadmap, at least as long as we continue to produce stuff that they want to implement. And, you know, that's our goal. We wanna build protocols that people really wanna implement because of their simplicity, elegance, utility, properties, et cetera. So we have, but the Ethereum roadmaps are not in any way blocked on the CDC, CASPER roadmaps. You know, there's no one's waiting for us to finish our research before implementing protocols. So there really are, in some ways, very independent of us. Great, so now I'm gonna talk about CDC, CASPER, the CDC, CASPER roadmap in terms of, you know, what have actually we done so far and, you know, what are we gonna do in the future? Before I start, I'm just gonna mention that the CDC, the CASPER research started before the split between CDC, CASPER and CASPER FFG. CASPER research started off as proof of stake research into, you know, economically secure proof of stake where we can have like a equilibrium to follow the protocol that's really robust where we use security deposits in order to make the equilibrium as robust as possible so that we can have penalties to make it so that the equilibrium is not just an epsilon equilibrium, but like a very robust equilibrium. And then basically what happens is, at some point after you do the incentivization research, you realize you have to have some specific thing you're telling them that you want to incentivize, like a specific protocol. And so the CDC, CASPER roadmap really represents the distributed systems research that is going to be incentivized in proof of stake. It doesn't represent proof of stake research, it just represents consensus protocol research, like distributed systems research, although absolutely the product requirements in CDC, CASPER are driven entirely and determined entirely by the proof of stake research that came before it. So you get proof of stake research and then distributed system research where Vitalik and I split off into different protocols, the CASPER FFG versus CASPER CBC. And so this is gonna be about distributed systems. This is gonna be a distributed systems roadmap. You're not gonna see anything about river stake incentives here, not because it's not in some other roadmap, it's just that CBC, CASPER is specifically a distributed systems roadmap. So basically what is the roadmap? Well, any roadmap is basically everything you've done already and everything you're planning to do in the future. It's kind of like a map that over time, what you're supposed to accomplish to get to your goals. And so I'm gonna talk about all the past work that we've done. This is gonna be the milestones, like important milestones. There's lots of struggling behind the scenes that isn't listed here, lots of just a ton of work that isn't in here because just not all work ends up leading to a milestone that is like, especially in research, that is like something that you can present, right? So the first thing that really kicked off CBC CASPER research was, well, beyond just me hearing about and learning about CBC protocol design is the CBC CASPER message type. This is something Greg Meredith and I came up with in August 2016 when we were trying to come up with just the preliminary infrastructure so that we can state a CBC consensus problem. In August, just a month later, came up with for the first time this safe and non-trivial binary consensus protocol which I presented at DevCon in Shanghai. It used this idea of an ideal adversary to argue about security, which now we've replaced with this idea of safety oracle. And but it was like a real milestone, like a safe, non-trivial consensus protocol is like a real milestone. June 2017, so a few months later, LNDGhost was first specified. This happened when Carla, who just spoke, asked me how we're ever gonna turn from binary consensus to blockchain consensus. He was like frustrated and concerned. Carl and I were working together at the time on this binary consensus protocol. And I was like, I just gave it a try and somehow. Oh, sorry, I'm looking over here at the next slide. So actually before the Fortress Wheel came up, Yoishi did a formal verification of the safety of the binary consensus protocol in March 2017. And then in June, the latest message-driven ghost made its first appearance as a specification when Carl asked me this question. And I went and adapted the binary consensus protocol to the latest message-driven ghost protocol with very, very minor change. Then in July 2017 at the IC3 Ethereum Bootcamp, the LNDGhost was first implemented. I worked together with John Levy to implement it. I did most of the work, but he was definitely there in contributing. In November 2017, we came up with our first atomic cross-shard fork choice proposal that guarantees that cross-shard communications are atomic. It's like super important property. And this was actually the first sharding solution that ever came across. And you see Casper Research is this atomic cross-shard solution with merge blocks, which are blocks that exist on two chains at once and they are in the chains of both of them. So they have to kind of synchronize exactly at that height. And then later, quite a lot later, we came up with the cross-shard message model, which has the ability to send a message and not have it be received right away, but have it be received just in some time. You know, and this is much more friendly to prevent blocks from being orphaned. It's a much more realistic cross-shard communication model. And still we have atomicity, although a slightly different notion. It's more like atomicity at finality than atomicity just in the fork choice rule, the way that the merge block rule, the merge block thing, any fork choice rule at any moment, you have this atomicity property. With this one, there's a time when it's sent but not yet received, where the atomicity is not really there. But at finality, it's guaranteed to be there. Like you can never finalize a send without the receive being eventually finalized. You can never have a finalized not sent and a finalized receive. It would just be a violation of the protocol. That kind of, I mean, the protocol guarantees that that won't happen. So like if you follow the protocol, that's just impossible. In August of 2018, we came up with the first correct and complete safety oracle decision detector. And this is an Ethereum, Stanford, like math Olympics workshop. I don't really know what, I don't remember what it's called. Greg Price came up with this, who isn't in the community, but he's, you know, he comes to these hackathon kind of like your math hacking events. And we had a long history of struggling for a very long time before this one specification for detecting safety, especially because, especially in the cases of all the cases of equivocations, you know, of like who sees what equivocations, because it gets complicated when different validators see different equivocations and when you have to reason about the proof while they're equivocating. So it turns out this was a really challenging thing and we had a real professional mathematician like math Olympian solve it. September 2018, we did the first implementation of the CrossDark message system. And here's this gift that we have, that's really beautiful of the system. And basically what's happening in the bottom is that blocks are being orphaned in order to guarantee the atomicity of these communications between the two shards. In October 2018, we did our first specification of, sorry, for implementation, I don't know when the specification happened, I guess, of the multi-level shard hierarchy with message routing and shard balancing. So this is like taking it to the next level, right? Rather than just having two shards that communicate a little bit in between them, we wanna have many shards that do routing and we wanna not have a fixed shard hierarchy, we wanna have the ability to change shards. This is an example of a two-shard system with the root shard and the child shard changing positions. In some way, there's no such thing as a root shard and child shard anymore. There's only root blocks and child blocks at every moment in the forechoice rule, maybe one of them is the root. But maybe at some moments, there's both of them are the root. Like you see when they're sideways like that, that's like that moment in the forechoice where the parent has said, look, I'm not the root anymore and then the child hasn't picked that up yet and so they're both the children of the root. Actually, there is no root for that one moment. But then when the child eventually receives that message, what they have to do because of the nature of the forechoice rule, you know, the child becomes the parent. And then with single message hops like this that are atomic, you can implement routing which guarantees with the same animicity property that we can go from one shard to another through any number of shards. This uses routing protocol. This uses like a routing table system and the tables get updated as the shards change position. I mean, if the shards were a fixed position, you kind of have static routing tables. You have just do source routing, calculate from the source exactly what the route's gonna be. But because the shards are moving and the shards over here may not know about the changes in the shard shape over there, we need to have a dynamic routing table system in this solution. In November 2018 at Glass-Deppcon, I released this minimal CBC Casper protocol paper which described abstractly a family of consensus protocols of really, really formally. And this kind of represented a very general abstraction of what we had done before with like the binary consensus protocol or the blockchain consensus protocol or we had a whole bunch of other ones like integer consensus protocol. And then this kind of really abstracted them and formalized it in a way and when we wrote the proofs down in incredible detail, just way too much detail. And then next month we had the first formal CBC Casper light client specification which won't see the light of day until today actually. And this is kind of cool because originally the CBC Casper specification it has message nesting instead of message linking and so the messages just get really big and that's not really practical and people don't like to see that even though from the point of view of like the semantics in the math, like it's still a non-trivial, safe, whatever consensus protocol. So we have light client specification as of November, 2018, February, 2019, another one of these Ethereum, Stanford, Math, Olympic, hack things, which I knew what they were called. We came up with Daniel Cain with working with Greg Price who came up with the original complete correct safety detector slash decision detector. Came up with an efficient oracle making decisions which is a big deal because that other one is computationally quite inefficient. And this is also like yeah, quite heavy lifting that was done. In May, 2019, the first two liven strategies based on the leaders for CBC Casper were specified by researchers at the Casper Labs team. Actually Daniel Cain who is on contract with them and Andreas Fackler, they were both produced in almost immediate sequence like within like a week of each other as like a leader based CBC Casper liven strategy where a leader synchronizes everyone and guarantees that they go through the same states in order to make decisions. Also the same month but towards the end came up with the first liven strategy based on fault rejection for CBC Casper which is quite a different strategy that has to do with validators detecting whether each other are faulty and using information about the faults in order to come up with a liven strategy. Then the IC3 theory and boot camp in 2019 we came up with and did, oh, I forgot. I remember now, sorry, I should have mentioned. So the sharding specification for the cross shard messages was at the 2018 IC3 theory and boot camp and this is where Aditya came onto the CBC Casper team and like immediately started writing proofs and he really helped with the sharding stuff and has been helping with it ever since. And then the implementation happened obviously after the specification and that was I guess like June 2018 or something like that. So now in June 2019 we came up with like the efficient algorithms for LMD ghost, updating the safety detector and other kind of efficiency stuff to do with Casper. In July 2019, Sebastian Zaini came up with the first asynchronous probabilistic liveness strategy for CBC Casper which is, it's probabilistic and it uses the common coin model where basically everyone's flipping coins and then eventually they all flip the same coin and it ends up being live. The first partial synchrony thing, first partial synchrony specification for CBC Casper I came up with in July 2019 and this was also based on fault detection but now instead of fault being perfectly reliably detectable as in synchrony, they're not and so it's quite a lot more complicated. And then the, oh we got the first formal verification of safety and non-triviality of the full and light clients, the abstract ones. This is done by runtime verification including a bunch of people who you're gonna see listed later, so I don't wanna, I'll just save a little time here. We also had the same month, the first formal verification of efficient safety oracle detection by Rory Nakamura who's here also and also we had in the same month the first partial synchrony specifications for the leader protocols that Daniel Cain basically pioneered. And that's kind of all the major roadmaps, maybe milestones on the road map, maybe if not all, almost all, until today. But we have a lot of future work. We have to continue a lot of stuff that we were doing, a lot of stuff that we've done, you may be noticed that I haven't published and you haven't seen yet. So we need to, some of the stuff needs to be formalized, abstracted, verified, it's not really clear if all of this is, we haven't really done the kinds of verification that we love to have where you're paranoid, absolutely sure under any circumstance that is correct with all of it. We also have to abstract it, and so we can have the results that we have in the most general terms possible so that we're there as useful as possible for providing the most general architecture that, which basically provides the guarantees the most possible implementations. And we also have to do a lot of documentation in peer review of past work. You know, I claim we've done, but you guys can't really tell, at this point really, not that much. Here's some more past work, validated rotation, load balancing, sharding client strategies. These are things that are not done, but which are necessary for the scalable proof of stake or scalable distributed system thing. And I would say that we have, I mean, we have solutions to some extent, but it's not fully, you know, at the level of formality, completeness, et cetera, that we're used to and that we expect. We also have like just future work that is, just hasn't really been started that much yet. Abstraction of all the liveness stuff. You know, right now we have like a few specific live protocols. We don't really have that much of general infrastructure for generating live consensus protocols, but we'd like to abstract all of our liveness research so that we can have the most general infrastructure possible. We have to verify all of our liveness proofs, you know, both by hand and formally to the much bigger extent than we have already. And we want to talk about performance. You know, I mentioned earlier that like, we want to have the same network overhead as Nakamoto consensus. And you know, there's all sorts of other considerations for performance, like for example, the latency to finality, the latency to inclusion in the first block, which under normal execution is later finalized. You know, the number of like operations per second that you need to do like in terms of signature verification and like compute, as well as like the overhead, the message overhead, which is kind of what I was referring to and I'm thinking about the overhead of Nakamoto consensus. I wasn't thinking about mining. I was thinking about the clients and how they just have to download like one header per block or very little information. You know, we have, in CBC Casper, we have this requirement that the protocol, that the fault tolerance thresholds of the protocol are not in the consensus protocol, but they're client and validator side. And so we have to give strategies for clients or give at least some best practices for clients for choosing these thresholds, because not all thresholds are gonna be equally good or equally useful. So, you know, this is like just a whole bunch of stuff that needs to be done. There's probably more future work that isn't listed here. But if this is all done, then, and all the stuff that we already claimed is done so far is done, then actually we're pretty close to having a scalable distributed consensus protocol that has all of the security and overhead properties that we want. And also liveness, which is super important property that is shockingly difficult to provide. Basically you have to prove that if you exhaust, you basically have to prove that there is no way to execute the protocol that doesn't eventually lead to the decision, because you have to kind of exhaust every single possible state transition to the protocol until you're forced to make a decision. And that turns out to be quite a difficult thing to argue. So we have some announcements and resources to share. So we're collaborating with runtime verification to abstract and verify our protocols. It's a pretty exciting collaboration. And they're really amazing at this work. They have a paper that's being released right now. And here you can see the main contributors on the CVC, on the runtime verification on this research. And they basically did a proof and a cock of the safety and non-triviality properties of the abstract consensus protocol for the full node and the light node. And here is the paper. Give you a moment if you want to take a photo of that. There it is, this is the paper. This is cock proofs. It goes in detail about the formal verification of these light and full client protocols. These are abstract. They only have safety and non-triviality. They're not live at this level of specification. And you also look, check out the cock proofs here. This is like a GitHub link to the actual proofs if you're interested in that. Maria Nakamura, like I mentioned, has this formal verification of the decision detector. I didn't make a QR code for this, that's kind of dumb. I'm sorry. Go check them out on Twitter, look for this tweet, click on that link, maybe see him after and get it from him. Sorry about the lack of QR code, I don't know what happened. Casper Labs is implementing a CVC Casper blockchain for production, you know, quite different than a research roadmap. And they have like a GitHub that you can follow and is quite active. And they came up with this paper, which also released today, is gives this leader-based liveness strategy for partial synchronous networks. And it's basically, it gives I think both the liveness strategy and the finality criteria. And here is the QR code for that paper. The Ethereum Foundation continues to support our work. Sometimes I have to say this, people get confused. You know, we're still very much being supported by the Ethereum Foundation in our research, both directly and indirectly through grants. I have a paper which I was planning on releasing today, but which unfortunately I haven't been able to finish, but I broke my back trying and I'm gonna try to finish it super soon for all of you to see. And this is basically a abstract kind of, in a similar to the minimal consensus protocol paper style, but which also has liveness properties in a synchronous network. It's a really, really, it's quite a cool paper. It gives formal problem statements for the consensus problem and goes through the correct by construction process to show kind of how the protocol can be derived from the problem statements in a way that is guaranteed to be correct. And it kind of justifies a lot of the minimal CVC CASPER paper and this one with the liveness. So finally, right after this, I'm hoping we will, or some of us, anyone who's contributed to CVC CASPER research will hopefully meet us right out here and we'll have a little conversation about CVC CASPER research. If you have any questions that you want answered, please come and talk to us. Hopefully it won't be just me and the other researchers will come too. But, you know, it's up to them. We're gonna do an Ask Me Anything online soon. Also, I have t-shirts, limited edition t-shirts that I'm giving away, not to everyone. Please, first I have to give away to contributors. So I know there's some of you here. Give away to contributors first and then I'll do a first come first serve after. So the first come first serve will be tomorrow. But for now, if you're a contributor and you want a shirt, come get it. Thank you so much. I really appreciate it.