 Hey everyone. How's it going? They already started my clock, so I'm just gonna start too. So we got talked today about CBC Casper design philosophy. It's mostly really about design methodology. And I'm going to walk you through some of the stuff that goes on in CBC Casper land in terms of the methodology that we use to develop and define distributed systems protocols. I'm going to talk about it first is like what is craft by construction, and then I'm going to talk about domain theory, and then like this kind of defined in this stuff. It's gonna be kind of a trip. It's gonna be pretty cool, and then I'll talk and I'll give some examples of like actual CBC design in CBC Casper and some of the you know stuff that happens and to give you kind of a taste of the methodology and the you know like the the kind of approach that we have that kind of sets apart CBC Casper from you know other because it's a protocol research. And finally, you know the last bit of my talk, I'll just remind you all that where the resources are, show you some new resources and make some announcements. So let's talk about design methods in CBC Casper. The number one kind of like design methodology in CBC Casper is the correct by construction design a protocol design methodology. The idea with correct by construction is that like the process by which you decide what program you write should guarantee that that program has the properties that you want. Like the very process that you use to specify the protocol should guarantee that the protocol has the properties that you want. So somehow like the way you decide what like formats to use or what like the protocol is in terms of like the data and the behavior you know that happens somehow like definitions don't come out of nowhere and there's like a process by which stuff gets defined and it's called you know your process is called correct by construction if you know the process that you use to define the thing somehow or guarantees that the definition that comes out is correct. And this is kind of as opposed to the trial and error approach where you will like try something and then analyze it and then you might it might work it might not you'll maybe get lucky and maybe and if not they maybe learn something and just keep trying until Maybe you'll find something so this is a very different approach, right because instead of like we never really Have the trial and error we just have like a lot of time defining stuff and then like once the definition pops out It's like correct by construction and so there's no like error, but in some way like you know It takes us a lot longer to come out with a full definition But when it when it pops out, you know, we know it's correct by construction And we don't worry at all about Mistakes in the specification in the same way So there's two basically kinds of correct by construction software design that I'm kind of aware of one of them is you know you Use you define like a a proof Maybe a type system and some proofs over broad class of protocols or broad class of programs and then you in your design process choose your Protocol your protocol to be part of that set so that you know when you choose it that it's going to satisfy the theorem that You know is is is inhabited by this much broader set of protocols So if we have like a you know a family of protocols They all satisfy a theorem and we like pick protocols or construct them in a way to guarantee that it's part of the family then we can in a correct by construction way get a protocol that Has that property that you know the theorem shows for the family and the other kind of approaches that The protocols are specified in a way that actually generates a proof of their correctness So, you know the you generate that protocol and a proof like a new proof for every protocol And and I don't do any of that Sounds hard and I've heard people doing it and like programming languages and compilers, but it hasn't showed up for me yet So what I do here is basically we we use we define Large families of protocols and we prove things about them And then we and then we and then we choose specific protocols out of them Which will there by virtue of being in those families have these properties And so now we're gonna switch over to this very related topic But we're going off into the math deep-end So domain theory is a field of mathematics that studies You know it studies the semantics of programming languages but it really the reason why it's super interesting to me and To the to just rise really useful for understanding the correct by construction process is because it provides us a language for talking about Partial definitions, you know incomplete definitions partial protocol specifications and and and we can Understand what it means to have a process of defining something as opposed to just having something that's outright fully defined as You might have in the set theory So like you know you should think of domain theory as something that arose out of people's Feelings that set theory was inadequate for dealing with Programs and the semantics of programs, especially recursive programs and like a lazy evaluation But I'm not I'm not an expert in domain theory But there are some things that I've learned from domain theory that I find super useful for thinking about a Bunch of stuff including correct by construction protocol design. So there's a really really you know kind of core notation in In domain theory to use this like a and to define this thing called undefined So this bottom notation means undefined and it's like defined to be the most undefined thing It is the most undefined thing in this partial order of Definedness, it's like if I if I say nothing about my protocol then like I have left it completely undefined And then somehow that's like the most undefined that I could leave it as soon as I say stuff Because more defined And we could talk about and reason formally about this order of Definedness and this process of defining stuff and you know having at certain stages a partial definition And then getting in more and more more and more Defined protocols so if a is a definition that can be reached from a definition B by replacing an undefined term in B with something that's defined or something else Then a is gonna be is more defined than B So basically like if I have a definition it's got some undefined term in it And I can replace it to get some other definition then that other definition is more defined than this like initial definition So I'm gonna give some examples So here we go, you know bottom times bottom is more defined than bottom because you can replace bottom with bottom times bottom and therefore You know you can define something which is completely undefined bottom to be this thing bottom times bottom which is Still not totally defined, but it's more defined than just bottom You know bottom times empty set is more defined than bottom times bottom because you can replace bottom with Empty sets and get from bottom times bottom to bottom times empty set. What about empty set times bottom versus Bottom bottom. Well, you know you can place the first bottom with an empty set And so the thing on the left is more defined than the thing on the right But the next example is a little trickier because it's not more defined than the thing on the left sorry the empty set times bottom is not more defined than empty set times Bottom times empty set because you can't replace the bottom To get empty set times bottom because there's already an empty set in that position So, you know, basically what we're doing is replacing the bottoms on the right to see if we can get the thing on the left And if we can't Then it's not more defined then and if it if we can then it is more defined then so at the end of the day what we kind of get is this picture this partial order of the definiteness of These terms so like bottom is the most undefined bottom times bottom is a little more defined These two terms the left and right they're not more defined than each other even though they have a term that is in Common, I mean a term that in both of them can define That you know a term that inhabits both of these partial definitions And so kind of you know what we do in the correct by construction process is we move from less defined protocol specifications to more defined protocol specifications we have a Kind of process of we say something about the protocol that we prove things about the protocol So that later when we continue to define the protocol the things that we proved Continue to hold because all of the later definitions are just a they're just a refinement of the previous definition you know, so you know, so the kind of Theorums that we have for less defined versions of the protocol spec are going to hold for more defined versions of the spec And this kind of starts to make you feel why we have like this correct by construction protocol Design because at some point we're gonna have a partial spec and some proofs And then there's no way for us to define that spec more that will kill those proofs So Basically like our kind of strategy is to like deliberately give and prove or give Partial specifications and prove things about partial specifications so that we can have a lot of flexibility in our iteration and design because we can continue to define from that point in many different directions without having to worry and go back about you know verifying and changing proofs that You know because of the change in the protocol like a lot of the time when you have a protocol and you make a change You're gonna have to like change the proofs that you have about the protocol but if you instead had some Partial definition of the protocol that you had some proofs from which you could change and you can make your change to your protocol by just Continuing to define the protocol just like in a different way from before then you can you know not have this additional proof obligation because you just Have proven it for a much broader class of things Which are kind of the things that inhabit this less well specified definition of the protocol so let's So so you know I think we can get a lot of flexibility and design and Because we because of this because of this approach so here is some Actual like partial order of definiteness in like some definitions that we have in the casp CBC Casper world So we have this minimal CBC Casper family of protocols which is like the Specification that's like the easiest to understand the smallest the fewest fewest parts and we Defined terms in that specification to define like the binary consensus protocol the blockchain consensus protocol And other consensus protocols that you've seen if you've watched me present on CBC Casper over the years And so all of these protocols these three protocols the binary consensus protocol the integer and the friendly ghost they're all More defined than the minimal CBC Casper specification and they all satisfy the same proof as the minimal CBC Casper spec and These these all Therefore we kind of benefit from that proof and we don't need to look back much when we when we when we're defining forward From this minimal CBC Casper family We don't need to look back and ask about whether that proof will continue to be satisfied But you know this this this family of protocols actually has a Full node condition it requires that all the messages all the nodes processes all the justifications of all their messages And so that's actually not super useful for example for sharding and so we don't actually want to have defined sharding as a Further definition of this Specification because it's a full it requires its full node condition and so actually what we do instead is we have like this other Spec which is like this light client spec which you know where Clients don't need to have all of the just all of the resolve all the pointers and all their messages and so we and we define the Sharding blockchains as protocol spec as an instance of this like CV like client CBC family protocols Which all satisfy the same because that's a safety proof and actually there's like a more abstract Family of protocols, which is you know considerably harder to communicate than the minimal one but which is less defined than both the light client protocol and the minimal CBC Casper protocol and so like if we with with this kind of setup what we think what this does is it gives us a Like a little roadmap of like starting from where like what is defined and what properties do you have and if you go Downstream from there and continue to find stuff, you know What do you get to benefit from and so it can be really? you know, I think this kind of notion of a Order of definiteness and of progressively giving more and more defined protocol specifications is very very Very very much what we're doing in correct by construction protocol design Because we're engaged in the process of defining something and I we start at the start We don't have a full definition But we want to get to a point where we do have a definition that satisfies certain properties And we want to know that the process that which we follow will guarantee that we have those properties And so you know which we try to have it's kind of a disciplined approach for getting them One step at a time in a way where we don't really have to look back So But you know, it's not always a straightforward sometimes we have like alternative choices of what how exactly to define stuff And even to get the same goal, so it's you know, I painted a pretty simple picture But the reality is more complex for example for validator rotation the easy thing to do in terms of the protocol Specification and the proof obligations is to just launch lots of instances of these protocols that have new validator sets And that really can work in some cases But there are also cases where we want to define protocols that do validator rotation in a way that is outside of the minimal CBC Casper framework And whenever we do this kind of design that's outside of the of the framework We need to we create new proof obligations And so we sometimes have to have a choice between you know, do we do we design things in a way to take advantage of existing? Proofs or do we come up with a new system or a broader family that? That have other proofs and it's it's it's tricky because like on the one hand We want to benefit from all the proofs we already have and we don't make any new ones on the other hand When we have when we can generalize stuff sometimes we can generalize it like a bit and not as much as we'd like And so if I come up with a more general family of protocols for doing validator rotation for example Like I haven't come up with one that really does everything I want so there's there's there's definitely It definitely isn't as simple as like, you know define as you go and everything will be fine There's real choices that we need to make And like in the design process so one of the decisions we've made for example is that the Validator strategies are not part of the Certification I will like the core core like the you know the core partial spec is Only for clients. It's like not the spec for minors or for people who make messages people for people who receive them And the reason why we did this is because it's like kind of It separates out the the parts of the protocol in a way that allows us to tackle them separately and we can like Independent of when validators make messages or how validators make messages show consensus safety So we have this big part of this the protocol of like when do you know it's make messages? Which is not defined in the core spec which both seems weird because you'd expect that to be part of the consensus protocol but also is really nice because There's nothing that There's no way that that term could be defined in a way that disrupts the proofs in the for the like client protocol and so Validator strategies are not in the core the core partial protocol spec and I and that was like one of the decisions we made and Def I definitely don't regret it at all We have a bunch of design decisions that are motivated by economic thinking but also at the same time we leave incentives undefined until Very late in the game because the incentives have to respond to the actual states of the protocol and the actual and and the you know the Consensus protocol itself and so you can't actually define the incentives until the consensus protocols define And so although we do a lot of thinking economic thinking in front and we come up with a lot of distributed systems properties That we want based on the economic thinking the And the the definition is of the incentives is left for later so you know we have The the fault tolerance threshold is not specified in the protocol. It's like a decision we made and like very like you know like it was not an arbitrary decision and was like was motivated by like the design requirements that we have and We have and this is and this is like an area where It's not in the core reference spec But we have a proof for how nodes use would use it with different fault tolerance thresholds And so we can without changing the core spec very much Give proofs for a new kind of use of the protocol so, you know more kind of weird proof tactics around you know Using multiple instances of this like correct by construction core protocol partial spec You know we have Preventing DOS will require like you know that we bound the amount of work required to process a message and that people have throttling for the amount of messages that they Can receive and so that is that's good that requires a new constraint on consensus messages It requires a new strategies for the validators. None of this stuff is part of the core protocol spec None of it is part of the minimal You know core piece of the like, you know The of like the start of the correct by construction process and all of that is kind of very deliberate Because the idea is that we can define this stuff later, and it's more than fine Because we didn't screw it up by defining it earlier so so the the the the other kind of You know really cool thing about the correct by construction approach is the fact that you can iterate actually quite quickly Without having because you don't have to reason about much of the protocol when you make changes you because you Literally could not define it in a way that screws it up And so we I'm going to show you some of the progress we've made in the last little little few months on some of the sharding stuff So this is what came out of the ETH Berlin hackathon We came up with like a pair of shards one of which kind of follows the other one there. It's very it's very similar to the traditional CBC Casper consensus protocol in the sense that like it's you know, it's really implemented at completely as just a definition of the further definition that protocol by giving the consensus values and the estimators and the validators and their weights and the fault on a special so So we did this binary so we said we did this to two shard system and one thing that we've kind of been wanting to do for a while that finally kind of got to implementing is You know and just like a few months like a really short order is Shard rotation so like here what we see is two shards that are changing position One of them is the root at first and then it changes and the other than the other one is the root and then it changes again And the other one is the root so the purple blocks there are root blocks the yellow blocks are child blocks and the roles of these shards and the hierarchical consensus are changing and this does not require that We reason about consensus safety at all because the career the correct by construction process kind of guarantees that I with no thought because It's kind of upstream from our definition process And so relatively little work compared to normally working in consensus protocols We define this like actually relatively complex because this protocol that like this comes to consensus on you know the state of two shards with blocks that have like two different positions and have like a relatively complicated fork choice role And here's like and the kind of next kind of conclusion of that is like oh look when we have two Shards that can send messages. We can do routing If we can move shards around in two positions, we can move shards around it more and then we have this, you know Pretty cool sharding solution where we have messages being routed around Cross shards and with like the atomicity property that if your Route doesn't fully completed then the block that started that route will be orphaned so we have like You know the really kind of strong ability to iterate very quickly Because of the correct by construction approach because we don't need to look back at the previous guarantees We're not at risk of disrupting them And so, you know, I'm Walked through this again. So this so what's what's gonna happen here is first of the route shards was initially zero Now it's switching to one these messages are being routed from shards six to three and back Shards shard zero and one switched From zero one to like one zero and then and then back and then shard three Became a child of shard four even though it was previously a sibling and then messages start to get routed through shard four After that swap so it's really kind of quite complicated We have like a routing tables and they're updating and but we really didn't need to think about consensus protocols almost at all While us find this thing so, you know, we have Thank you so we have like methodology that lets us define consensus protocols we've defined a large number of consensus protocols or partially defined a large number of consensus protocols and You know and we iterate while creating minimal proof obligations and we are able to mix and match Kind of a lot and you know, so I recommend that you try out You know correct by construction and we Sorry, I'm looking at the wrong slide here. I got ahead of myself That was the next slide So we basically really rely on these partial specifications and you know the fact that it's not defined yet It's actually a huge asset for us the fact that we leave things undefined until you know, the latest possible moment means that we have As much flexibility as possible to iterate without disrupting our previous proofs so I already said all this yes, it's it's great try it correct by construction protocol design. It's awesome so now let's moving to the like Kind of announcement section of the talk So that was that was like all that was pretty much all of the all of the content so we have some a bunch of a bunch of announces of people like you know contributing to CBC Casper research. This is a Rob Hanbrock from true level built a generative testing for the CBC Casper protocols I'm gonna let's see if I can And then with this spoiler alert So with this what this kind of shows here is the the red the red Dots are members of a clique Which are validators who see each other agree in a way that they Are actually finalizing that block the blue one down there And this is something you know related to the way that finality works in in in Casper And and and here we see like multiple views of the protocol From point of view of four different validators until one of them finds a decision on this block Namely finalizing you know this this this blue block and the the green dots are the messages from the validator whose view We see and the red dots are the clique which is like a Group of validators who sees each other agree in a certain way that corresponds to a cassette signature that You know is like a decision So so that's pretty cool stuff, you know the I mentioned the charting proof of concept. We've been working on this with like a significant like Rotating group of people since the East Berlin hackathon actually before that at the theory might see three workshop We worked on the specification Especially want to give a shout out to Alex Skeetanoff who in the last like You know week and also during the East San Francisco hackathon put in like heroic efforts to get The routing working and the shard swapping. I mean he's the first he's the first person to prototype the Cross-shard message routing a bit jealous But you know you should check out this github repo and see if you like it and it's not there's still loads of bugs But there's you know, it's definitely interesting Aditya who is probably somewhere here has announced that he's implementing a sharding client With like, you know, they're in blocks and like, you know, very like a theorem sharding client And he has a github repo and a Twitter handle. You should follow him for his work We this is an exciting one We kind of released a draft or are going to release a draft I wrote these slides I thought we'd have it released by now, but we're gonna release a draft today of Oh wait, it is released my bad github.com slash cbc dash Casper And you can download a new specification of the minimal cbc Casper protocol states that is You know extremely rigorous and pedantic with extremely rigorous and pedantic proof of the consensus safety result and Example protocols including the friendly ghost the finality gadget Sharding with fixed hierarchy And I'd like to thank the code and my co-authors Nate rush Aditya and Georgios and they're all here You should you can probably recognize them from their faces. I Put a DS face was on the previous slide Um finally, you know, don't forget about the prototype in the wiki at there am slash cbc dash Casper Those are like good resources if you want to like dip your toes and check it out You know, we're totally looking for help of all kinds and we're getting better and better at Helping you help us as the like documentation and definitions and stuff have laid themselves out in a way where you can you know Come in and contribute in a way where it's really clear how it interfaces with everyone else's work and where you know You won't be wasting your time and you will be helping so you don't Reach out and thanks so much for listening. I have time for one question. It's okay You don't need to ask a question. I can just go Bye everyone. Oh wait, there's a question. Sorry. Sorry. Sorry. Do you have a microphone? So what's the deal? There's there's the microphones are at the front You have to come up come up to the front. We got like 30 seconds. You got to be quick 10 second question 20 second answer Yeah, can you hear me good? What's a good way of really understanding CBC? If you come from math background, yes, read this paper And anything anything more sort of high level just no the paper is really good. It's just it's set theory Okay, it's very accessible. I think okay