# The CBC Casper Roadmap by Vlad Zamfir (Devcon5)

- Speakers: [Vlad Zamfir](https://streameth.org/speakers/vlad-zamfir)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2020-10-09
- Duration: 30:36
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-oLlBVJwDhdA
- YouTube: https://www.youtube.com/watch?v=oLlBVJwDhdA

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/5/the-cbc-casper-roadmap

The CBC Casper roadmap is a plan to implement Proof-of-Stake and Sharding for Ethereum using “correct-by-construction” (CBC) software design methodology. This talk will share new CBC Casper research, including specifications for light clients, liveness and sharding. It will include updates on formal verification and engineering efforts, and a roadmap for (eventual) release.

Speaker(s): Vlad Zamfir
Skill level: Intermediate
Track: Consensus layer
Keywords: vlad, casper, CBC, technical

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

So today we're going to talk about the CBC Casper roadmap, and it's going to be a little less eventful than a typical Devcon talk. Here is my short plan. I 'll talk about the roadmap as a research roadmap, not as an implementation roadmap or, um, a developer roadmap. I will talk about the connection between my roadmap and Ethereum roadmaps. I will talk about our past and future work, because in a way, the roadmap is made up of everything we have done and everything we are going to do or plan to do. And then I'll talk about some resources and announcements. So the CBC Casper roadmap CBC Casper roadmap is, as I said, a research and architecture roadmap. The results of this roadmap are research and specifications. You know, we don't like that the goal of the roadmap is to create an architecture, to create, you know, research in the form of distributed systems computer science, um, theoretical computer science, you know? And also creating specifications that serve as abstract descriptions of protocols, which if you can implement something that conforms to the specifications, you get all the benefits of the architecture benefits of the architecture . So in a way, the CB PC Casper roadmap creates the architecture and research, and then engineers have to implement the architecture the way they work, and they work, and any way of implementing the architecture will inherit the properties of the architecture. So, you know, if we prove that this architecture has a property, then property, then any of the many ways to implement it will benefit from that property. And so you know that the CBC And so you know that the CBC research map does not create complete protocol specifications. It creates architecture-level specifications that guarantee that any implementation that conforms to the architecture will benefit from the functions or features of these protocols. Hmm, they are protocols. Hmm, they are , um, but, you know, we're going to, um, so we're somewhat independent of the engineering effort. We graduate with architecture, and then we go into engineering. Hmm, but that does n't mean we don't provide support to software developers and help them interpret the architecture, or, you know, we're going to provide support even if it's not a roadmap for implementing it. The roadmap is to develop architectures and conduct research conduct research . Hmm, this is a research roadmap. It all comes down to proper construction through consensus protocols. We use proper engineering design to design your systems in such a way that the design process ensures their correctness. It's not about correctness, it's about the process used to develop these protocols. So we really formally formulate design requirements and abstractly formulate protocol statements. Hmm, and then we refined them to derive from the problem statements a solution to the problem that is guaranteed by the way it was derived. Um, and so, you know, we formulate design requirements and then find a solution that satisfies them directly from the design requirements that are expressed in abstract protocol specifications. So, in particular, we are not interested in just any consensus protocols. We want scalable Proof-of-Stake consensus protocols that have the same network overhead as Nakamoto consensus. We want to be able to have blockchains that work at internet work at internet scale but don't have the, ahem, crazy overhead of a traditional consensus protocol. And actually have the same overhead as Nakamoto consensus, or comparable to the overhead of current Ethereum. So, essentially, we want to be able to meet all the usual requirements, all the traditional requirements of a consensus protocol, such as security, non-triviality, and viability; and a number of other requirements, such as the ability to make this ideal, ahem, theoretically optimal overhead trade- off. And we're also interested in scalability, um, you know, through sharding you know, through sharding , and essentially, um, what we fully understand within the consensus protocol, um, where, you know, if you, if you were at the sharding seminar yesterday, um, that's what it's all about . So I'm not going to touch on that right now. Um, we have a very formalistic approach to developing protocols. We are formal from the very beginning. We never engage in trial and error, as is usually the case in development. We don't implement something until we are sure it's right. We do a lot of mathematical calculations before writing a single line of code. There are a bunch of mathematical calculations for a single line of code. Um, it's a very formalistic process, and it takes quite a while to create a specification this way , especially if you mean a full specification, but it's guaranteed to be correct because of the process by which it was derived. This, you know, is the correct construction process. And it's also guaranteed to have a certain aesthetic appeal that's typical of mathematics, where you make only the minimal, most natural choices and nothing more. And everything is so natural and elegant, and everything is symmetrical, and, you know, it has this nice feeling of mathematics about mathematics that comes from looking at any, well, any good branch of mathematics. Uh, and, and that's, like, one of the biggest appeals, I think, of the roadmap is that the aesthetic appeal is very, very high, because everything, like, is derived from mathematical objects in a very careful way, and it doesn't involve any weird arbitrary choices, except for the bare minimum . Um, that's the basic, basic idea of ​​what it is. This is a research roadmap. That doesn't tell you much. But before I get to the roadmap elements, let's talk about the connection between the CDC Casper roadmap and the Ethereum roadmaps. So in a sense, we are completely independent of Ethereum roadmaps. You know, we are a research roadmap. Ethereum roadmaps Ethereum roadmaps are roadmaps for deployment on the Ethereum mainnet. But, you know, in some cases, CBC Casper research has made it into Ethereum 2.0. Um, um, and maybe it will make it into Ethereum 3.0. Because it is not yet entirely clear what Ethereum 3.0 is. Um, one of the most famous things that came out of CBC Casper's research is the message-driven final selection rule that is introduced in the beacon chain. Um, one more thing, Vitalik suggested adding the CBC Casper finality mechanism to the beacon chain. Um, so somehow the CBC Casper research flow from the research roadmap is at least a little bit flowing into Ethereum 2.0 research. Um, in a sense, uh, you know, so in a sense, actually, the Ethereum roadmaps are not really independent of the CBC Casper roadmap, at least as long as we keep building the things that they want to implement. And, you know, um, that's our goal: we want to create protocols create protocols that people will actually want to implement because of their simplicity, elegance, useful features, etc. Hmm, yes, we did, but Ethereum roadmaps are in no way blocked by CBC Casper roadmaps. You know, no one is waiting for us to complete our research on implementing protocols. Hmm, so they really...they really are very independent of us in a way. Perfectly. So now I'll talk about the CBC Casper roadmap in terms of what we've actually done so far, and what we're going to do in the future. Before I start, I'll just mention that CBC Casper research began before the split between CBC Casper and Casper FFG. Casper research started as research into Proof of Stake, economically secure Proof of Stake, where we can have, like, an equilibrium to follow a protocol that's really secure, where we... where we use staking to make, uh, the equilibrium as secure as possible, so that we can have penalties... can have penalties... to make the equilibrium not just an epsilon equilibrium, but epsilon equilibrium, but , like, a very secure equilibrium. And then, essentially, what happens is this: at some point after doing the stimulation study, you realize that you need to have something specific that you want to stimulate, like a certain protocol. And so the CBC Casper roadmap actually represents research into distributed systems that will be incentivized in Proof of Stake. It does not represent Proof of Stake research. It simply represents the research of a consensus protocol, such as the research of distributed systems. Although absolutely the product requirements in CBC Casper are completely driven and defined by the Proof of Stake research that preceded it. So, we're doing research on Proof-of-Stake and then research on distributed systems, where Vitalik and I split into different protocols. Casper FFG vs. Casper CBC. Hmm, and this will be about distributed systems. This will be the roadmap for distributed systems. You won't see anything here about Bruce's incentives. Not because it's not some other roadmap . Simply put, CBC Casper . Simply put, CBC Casper is a roadmap for distributed systems. So, what is a roadmap ? Well, any roadmap is essentially everything you've done so far and everything you plan to do in the future. Hmm, it's kind of like a map over time, like you know what you need to accomplish to reach your goals. Hmm, and so I'm going to talk about all the past work we've done. These will be important milestones. There are many difficulties behind the scenes that are not listed here. A lot, just a lot of work that's not here, because, you know, not all work leads to a certain milestone, especially in research, that can be properly presented. So the first thing that really gave impetus to the research into CBC Casper, which went far beyond simply getting to know the design of the CBC protocol and studying the issue, was the type of CBC Casper message. This is something Greg Meredith and I came up with in August 2016 when we were trying to create a preliminary infrastructure for formulating the CBC consensus problem. In August, just a month later, I first came up with this secure and non-trivial binary consensus protocol, which I presented at DevCon in Shanghai. He used the idea of ​​the ideal adversary to argue about security, which we replaced with the idea of ​​the security oracle. And, but, but this was, you know, a real milestone you know, a real milestone , a secure non-trivial consensus protocol – consensus protocol – this is a real milestone. In June 2017, a few months later, L&D Ghost was first identified. This happened when Carl, who was just speaking, asked me how we were going to move from binary consensus to blockchain consensus. He was disappointed and worried. Carl and I were working together on the Binary Extended Protocol at the time, and I thought, "I just tried it and somehow...sorry, I'm looking at the next slide." So in fact, the "be until...until... fork" selection rule appeared, Yoshi conducted a formal security audit of the binary consensus protocol in March 2017. And then in June, the latest message-driven protocol first appeared as a specification... you know specification... you know , when Carl asked me this question, and he and I adapted the binary consensus protocol to the latest message-driven protocol with very, very minor changes. Then in July 2017, at the IC3 Ethereum bootcamp, erm, LMD Ghost was first implemented. I worked with John Levy on its implementation. I did most of the work, but he was definitely there and contributing. In November 2017, we proposed our first proposal for an atomic cross-shard cross-shard fork, which ensures that, you know, communications between shards are atomic. This is an extremely important property. And that was the first solution to sharding that ever happened. CBC Casper research CBC Casper research is an atomic solution for cross- sharding with merge blocks that exist simultaneously on two chains and are in the chains of both of them. So they must synchronize at this height. And then later, quite a lot later, we came up with a messaging model between shards that has the ability to send messages not immediately, but after some time, and that's much more convenient for preventing orphaned blocks. This is a much more realistic model of communication between shards, and we still have dominitarianism, albeit a slightly different concept. This is more like atomicity in the final state than atomicity simply in the fork selection rule. The thing about a merge blocking rule, a merge blocking rule, a thing in any fork selection rule at any point in time any point in time , you have this property of automaticity. In this case, there is a point where you feel like something has been sent but not yet received, where atomicity is not actually there, but in the final state it is guaranteed to be there. For example, you can never complete sending without completing receiving. You can never, well, you know, have a complete non-sending and a complete receiving. That would simply be a violation of protocol violation of protocol . That is, the protocol guarantees that this will not happen. So, if you follow the protocol, it's simply impossible. In August 2018, we developed the first correct and complete security oracle solution detector . And this was at the Ethereum Stanford Math Olympiad seminar. I don't know what it's called, I don't remember what it's called. Uh, it was invented by Greg Price, who's not part of the community, but he, you know, he comes to these, uh, hackathons, kind of like your math hacking events, uh hacking events, uh . And we had a long history of struggling for a very long time before this, this, this one specification for security discovery, uh, especially because, especially in cases of all the ambiguities, you know, like who sees which ambiguities, because it gets complicated when different validators see different ambiguities, and when you have to reason about the proof while they're ambiguous. So it turned out that this was a really complicated thing, and we had a real professional mathematician, a kind of math Olympian, who solved it. Uh, in September 2018, we first implemented the Crossard messaging system, uh, and here's this gift that we have . It's a really great system, and basically what happens underneath is that blocks are orphaned to guarantee the automatic atomicity of these communications between two shards. Um, in October 2018, we did our first specification, um, sorry, first implementation. I don't know when the specification of, uh , a multi-level shard hierarchy with message routing and shard balancing was made shard balancing was made . So it's like taking it to the next level, right? Instead of just having two shards that interact a little bit with each other, we want to have many shards that do the routing, and we don't want to have a fixed hierarchy of shards. We want to be able to change shards. This is an example of a two-shard system where the root shard and child shard swap positions. In a sense, there is no longer such a thing as a root shard and a child shard. There are only root blocks and child blocks. At each moment of the fork selection rule, perhaps one of them is the root, but perhaps at some moments both are the root. As you can see, when they, when they, when they, like this, sideways, it's like at that moment of choosing a branch, when the father says: " the father says: " Look, I'm not the root anymore." And then the child still didn't understand it. So they are both children of the root. In fact, there is no root at this point . But then when the child eventually gets that message, what it has to do because of the nature of the branching selection rule, uh, you know, the child becomes the parent. And then, and with such atomic message transitions, you can implement routing that guarantees with the same animacy property that we can transition from one shard to another through any number of shards. This uses a routing protocol that is typically similar to a routing table system, and the tables are updated when shards change positions. Because, I mean, if the shards had a fixed position, you would have static routing tables; You just need to perform routing from the source, calculate from the source exactly what the route will be. But since shards move, and shards here may not be aware of changes in the shape of a shard there, we need a dynamic routing table system in this, in this. solution, um, in November 2018 at, uh, last Devcon I I, I published this, uh, minimal paper about the CBC Casper protocol, which abstractly described the family of consensus protocols in a very, very formal way. Um, and it was kind of a very general abstraction of what we were doing before, like with the binary consensus protocol or the consistent blockchain protocol, or we had a whole bunch of others like the integer consensus protocol. Um, and and then it really abstracted them and formalized them in a way and wrote, when we wrote down the proofs in incredibly detail, just too much detail. Um, and then, uh detail. Um, and then, uh , the next month we had the first official specification for the CBC Casper thin client, which would n't actually see the light of day until today. Um, and that's pretty cool because originally the CBC Casper specification had message nesting instead of message chaining, and so messages get really big. And that's not very practical. People don't like to see this, even though from a semantics perspective in mathematics it's still a non-trivial safe because it's a protocol. Um, we have a client specification as of November 20, 2018, issue number February 20, 2019, another one of those, um...Um, in May 2019, researchers on the Casper Labs team developed the first two lead-based live activity strategies for CBC Casper. Um, actually, it was Daniel Kane, who works with them under contract, and Andreas Fackler. Um, both were developed almost simultaneously, about a week apart . This is similar to a leader-based CBC catheterization strategy, where the leader synchronizes everyone and ensures they go through the same states to make decisions. Um, also in the same month, but closer to the end, um, the first error rejection-based alignment strategy was developed for CBC Casper, which is a completely different strategy. It involves validators detecting validators detecting whether each other is faulty and using the fault information to develop an alignment strategy. Um, then at the IC3 Ethereum bootcamp in 2019 we came up with and did...Oh, I forgot! I just remembered, sorry remembered, sorry . I should mention that the sharding specification for cross- cross- shard messages was at the 2018 IC3 Ethereum bootcamp. And that's when DTA joined the CBC Casper team and, like, started writing proofs right away , and he really helped with the sharding; has been helping with this ever since. So the implementation obviously happened after the specification, and it was, I think, around June 2018 or something like that. So, in June 2019, we developed efficient algorithms for updating LMD ghosts updating LMD ghosts , security detector, and other things related to Casper. In July 2019, um, Sebastian Zani proposed the first asynchronous probabilistic live coin strategy for CBC Casper. Um, which is, um, you know, probabilistic, and it uses a common coin model, where basically everyone flips a coin, and then eventually everyone flips the same coin, and it ends up coming up alive. Um, um, um, the first partial synchronization, um, partial, the first synchronization specification for CBC Casper, um, I came up with in July 2019, um, and, and it was, um, it's also based on error detection. But now, instead of errors being perfectly reliably detectable, as in synchronicity, they aren't, and so it's much more complicated. And then, um, oh, we got the first official test of, um, the security and non-triviality of full and thin clients, abstract. Um, this is done through runtime validation , including, um, a bunch of people you'll see later. So, I don't want to, I just want to save some time. Um, we also had the first official performance test, um, detection of the security oracle from Ruri Nakamura, who is also here. Uh, and also, that same month we had, um, the first partially synchronous specifications for leadership protocols, uh, which Daniel Kane actually pioneered. And that's probably all the major roadmaps, maybe milestones on the roadmap, maybe if not all of them, then almost all of them to date. But we have a lot of future work, um. We need to continue many of the things we have been doing, many of the things we have already done. You may have noticed that I haven't posted, you know, you haven't seen it yet. Um, so we need to, you know, some things need to be formalized, abstracted, verified. You know, it's not entirely clear whether all of this, um, you know, how we haven't yet done the kinds of verification that we like, when we like, when , for example, you're paranoid, absolutely certain under all circumstances under all circumstances that everything is correct. We also have to, you know also have to, you know , abstract it; and in this way, we can have the results that we have in the most general possible features, so that they are as useful as possible in providing the most general architecture, which essentially guarantees the greatest number of possible implementations. Um, and we also need to do a lot of documentation and peer review of past work, um, you know, which, you know, I claim we've done, but you guys can't really say for sure at this point; actually, not that much. Um, here's some more past work, you know: validator rotation, load balancing, sharding, client strategies. These are things that, um, aren't being done, but which are necessary for a scalable Proof-of-Stake or a scalable distributed system distributed system , um. You know, also, and, um, you know, I would say that we have, we have, I mean we have solutions to some extent, but they're not completely, you know, at the level of formality, completeness, etc. that we're used to and that we expect. Hmm, we also have future work that hasn't started yet. Abstraction of everything related to live performance. We now have several specific live performance protocols. We don't really have that kind of common infrastructure for building live performance consensus protocols, but we would like to abstract all of our live performance research live performance research to have as common an infrastructure as possible. We need to test all our evidence of live performance, both manually and formally, to a much greater extent than we already have. And we want to talk about productivity. I mentioned earlier that we want to have the same network overhead as Nakamoto consensus. And, you know, there are all sorts of other performance considerations, like: latency to completion, latency to inclusion in the first block, which under normal execution would finish later. Um, you know, the number of operations per second that need to be done, for example, in terms of signature verification and computation, and also the overhead, the message overhead, that's what I was talking about when I was thinking about the overhead of Nakamoto consensus. I wasn't thinking about mining; I'm just thinking about clients and how they need to load, like one header per block or very little information. Um, you know, CBC Casper has this requirement that the protocol crash tolerance thresholds are not part of the consensus protocol, but they are on the client and validator side. So we need to provide strategies for clients or at least some best practices for clients on how to choose these thresholds, because not all thresholds are going to be equally good or equally useful. Um, you know, it's just a whole bunch of things that need to be done. There's probably a lot of future work that's not listed here, but if all of this is done, and everything we've already claimed to have been done so far is done, then we're actually pretty close to creating a scalable distributed, uh, consensus protocol that has, uh protocol that has, uh , all the security and overhead properties that we want, and also, uh, which is an extremely important property that is, uh, amazingly difficult to provide. Essentially, you need to prove that if you exhaust all possibilities, then you need to prove that there is no way to execute the protocol that does not eventually lead to a decision, which means you need to exhaust every possible state transition to the protocol until you are forced to make a decision. And this turns out to be a rather complicated topic to debate. So we have some announcements, announcements, and resources to share. So we partner with Runtime Verification to abstract and verify our protocols. Uh, it's a pretty exciting collaboration, and you know they're really great at this job. Uh, they have an article that's currently being published. Hmm, and here you can see that the core participants of CBC, uh, and verification while doing this research, and they essentially did a full validation of the security properties and non-triviality of the abstract consensus protocol for full and light nodes. And here is the article. Give me a minute if you want to take a picture of this. Hmm take a picture of this. Hmm , here she is. This is an article. Hmm, this is complete confirmation. It details the formal verification of these lightweight and complete client protocols. They are abstract. They only have security and non-triviality. They are not available at this level of specification. And you can also see the full confirmations here. This is sort of a GitHub link to their actual evidence, if you're interested. Uh if you're interested. Uh , Ruya Nakamura, as I mentioned, had this formal verification of the decision detector. Uh, I-I didn't make a QR code for this. This is a bit silly. Sorry. Visit him on Twitter. Look for this tweet. Click on this link. Maybe you'll see him later and get it from him. Sorry for the lack of a QR code for the lack of a QR code . I don't know what happened . I don't know what happened . Uh, Casper Labs is implementing CBC, the Casper blockchain, uh, for production. You know, this is not at all like a research roadmap. Uh, they have something like a GitHub that you can follow, and it's pretty active, and they came up with this paper that was also published today, uh, it proposes a leader-based viability strategy for partially synchronous networks. Uh, and uh, you know, it basically gives, I think, both a leveling strategy and finality criteria. Uh, here's the QR code for this article. Uh, the Ethereum Foundation continues to support our work. Sometimes, I have to say this, people get confused. You know, the Ethereum Foundation is still very supportive of our research both directly and indirectly through grants. Um, I have an article that I was planning on announcing today, but unfortunately I couldn't finish it, but I broke my back trying, and I'll try to finish it very soon so you can all see it. And this is, um, essentially an abstract article, similar to the article on the minimal consensus protocol, but which also has the properties of survivability in a synchronous network. This is really, um, this is a pretty cool article. It contains formal problem statements for the consensus problem and goes through a process of correct construction to show how a protocol can be derived from the problem statements in a way that is guaranteed to be correct. And this to some extent justifies a lot of, for example, Kasper's article on the minimal consensus protocol and this one on survivability properties. Um, so finally, you know, right after this, I hope we or any of us, you know anyone who contributed to the CBC Casper study, will meet with us here, and we'll talk a little bit about the CBC Casper study, if you have any questions that you want answered. Um, please come and talk to us. I hope it will not only be me, but also other researchers. Um, but you know, it's up to them. Um, we're going to ask me anything online soon. I also have T-shirts, limited edition T-shirts that I don't give out to everyone. Please, I have to distribute it to the participants first. So, I know there are the participants first. So, I know there are some of you here. First, distribute to the participants, then I, and then I will arrange the order of actions in the queue. Um, so the order of business will be tomorrow. In the meantime will be tomorrow. In the meantime , if you are a participant and want a t-shirt, come and get it. Thank you very much. I really appreciate it.