CBC Casper and Serenity

Transcript

what's up everyone welcome thank you for all waking up so bright and early I'm so I'm Ben I'm gonna be introducing some of the like leather luxury love lovely speakers this morning before we do that I know that Pangaea has put an incredible amount of work and time and energy into this project so I think we should give her another round of applause seriously thank you in any case our first speaker probably needs no introduction in this room but he's going to be talking about the future of youth 2.0 and some research so let's please welcome to the stage Vitalik bittern good morning raise your hands if you have a good morning raise

your hands if you haven't this the side of the question always gets no answers for some reason it's strange so today I'm going to talk about one of the technical developments that's not going to become relevant to etherium 2.0 immediately it's a slightly later stage three things so possibly a face to shortly after face - I've been calling it part of phase 3 which is the introduction of a CBC Casper into the etherium 2.0 proof of stake blockchain so first thing I should start off by introducing what CBC Casper is right so CBC consensus is this a new school of a

safe under asynchrony visit e'en fault-tolerant consensus meaning the kind that works originally invented by Vlad's ampere and the main theme of CBC Casper is that you have basically approve of stake chains so you have validators and validators keep on making blocks and when they make blocks they make a block on top of the chain that they consider to be a the best chain ends they might pick this with what Vlad calls an estimator I call a fork choice rule and fork choice rules are pretty common so for example the longest chain rule in Bitcoin or in aetherium is a fork choice rule except here there is a twist which is that unlike the longest chain rule we are

nomads any given any particular chain there is always the possibility some longer chain exists here there exists this possibility of a kind of locking mechanism where once enough validators build on a particular chain for enough rounds then according to the rules of this fork surest rule it's that chain becomes locked in it's like not possible to switch to voting or building on another chain without a huge portion of alligators like basically committing provable violations which means they get their deposit slashed so in CBC Kaspar finality and the concept of when you know that a block is not going to be reverted is client-side so what this means is that you don't

need to choose hard thresholds in protocol like the number of 2/3 that you might see in bft protocols more more commonly does not appear in CBC right like you can choose for yourself a threshold of 2/3 but you can choose for yourself a threshold of 0.8 or 0.55 and every user personally has the ability to matures for themselves their own trade off between aliveness and safety so LMT ghost it's this fairly important built building block of at least the the version of a CBC casper that I'm going to be representing here right so what is lmg ghost so it stands for latest

message driven greedy heaviest observed subtree and so it's an adaptation of the ghost protocol created by Janet ensemble in skin if you have zohar back in 2013 to a proof of stake context and the way the ghost protocol for proof of work worked is basically that instead of looking at the longest chain you do this kind of block by block procedure where every time you reach a blocks that has two children you pick the child that has more blocks in total supporting it even if those blocks are not part of the same chain now in latest message driven ghost which is this adaptation to proof of stake we don't look at all of the blocks

that have been made because unlike in proof of work we're making ten times more blocks requires ten times more computing effort in proof of stakes you can sign as as much as you want so there's not much more points in counting and so we look only at the most recent messages of any node as evidence of the most recent opinion of what that particular validator is favoring right so now if we can look at this through a diagram so let's assume a kind of simple model where the only thing that happens is blocks you don't have ads of stations you don't have message you don't have any more complicated messages you just have blocks so you might imagine time being and if splut us split up into

epochs during each epoch every validator has a chance to create a block so here we're assuming five validators where each valid validator makes a block once over here on the left so ABCD and here the validators and then each validator makes a block on the right and so if from your point of view as a client your view so the blocks that you have seen and with this then you figure out what the latest met blocks are created by each validator in this case from a it's going to be this one from B it's gonna be this one from C it'll be this one from E will be this one and from D it's still this one because we haven't heard a block from D in this epoch right so this is so this is what latest message

driven means right so now what does ghost mean so the idea is that we're going to focus on these five latest messages and we're going to assign a score to each block where the score of the block basically is the total number of latest messages that are supporting that block so this block only has one block supporting it which is that block itself this block when we has a score of 1 this block has a score of 1 this block is supported by itself and this block so it has a score of two this block has a score of four cuz it's supported by this this this and this now it's not five because this block itself is not a waitest block and so it doesn't

count this is also four now here you have one and then this finally goes up to five now you might notice that scores go higher the older a block is so we're not going to just pick the block with the highest score right the idea here is that we're going to start with the with the Genesis block so start over here and then if there's one child we hop over to the child and then if you have a choice between two or more blocks then you pick the side that has a higher score so over here you pick bottom then you go to the right and then over here you pick middle cuz middle has a score of two and then you go forward and this ends up being your head now you might ask well why do we what do we need why do we care about

using LMG ghosts right so for example just a simple longest chain rule would also pick this block in this particular case that's the winner because this block is the unique block that has a chain of length 6 and so even on the longest chain rule it wins as well so why not just use the longest chain rule if it is simpler so the reason why we use LMZ ghost is that there's two parts to it one of them is a kind of common property of ghost in general which basically is that longest chain rules cannot take into account information from frequent parallel a meta stations so what does this mean right so what this means is that in the current

aetherium chain you have a block coming once every 14 seconds and an and so on average something like over 91% of all blocks make it as part of the main chain and so we can kind of not care about what those blocks that are not part of the main chain say because they don't really affect things that much but now imagine we wanted to have a chain that comes to consensus faster and so instead of one block every 14 seconds we had 14 blocks every one second now if you do something like that then almost all of those blocks are not going to end up being part of the same chain right just because of network latency if I publish a block by the time that block reaches

the entire network there will be a hundred other blocks that other people will have published and so the kind of depth of the chain the the length of the longest that part of it will be maybe one percent of the total number of blocks so the problem with this is that if you have an attacker then an attacker just running on their own server could more easily just create a chain which is much longer because they can perfectly coordinate with themselves they don't have any network latency so but in reality though even if you have an attacker that can make a longer chains but there's plenty of information that says that the chain the rest of the network is working on has more support right you can just look at a day you can

see that there's like a hundred times more people building on the real chain then there are people building on the attack chain and so the question is well how do we have a formally defines fork choice rule that actually takes this information into account and LMT ghost is the answer right if two blocks appear in parallel they still both count as support for whatever their common ancestor is another interesting property of lmg ghost and this is very importance to CBC finality specifically and specifically importance to ghost in a proof of state context is that the minority can never beat the majority regardless of how many messages the

minority sends so in this particular case here right we have five validators once again and you might notice that four of them are kind of peacefully happily coordinating on building up one chain I mean you see C and D make up make a little bit of a mistake but otherwise it's just going on fine and then you have B off in a corner possibly disconnected from the network possibly trying to attack it now imagine B makes 500 blocks if you use the longest chain rule B would win if you use proof-of-work style ghost B would also win if you use LMT ghost B would lose because all of those blocks come from

and we only count the latest message anyway so when you make a new message it over writes everything that you said before so from these a two property is what we get is a fortress rule which is both kind of very friendly to eath 2.0 is a goal of trying to coordinate on blocks very quickly and at the same time something that looks like it might actually kind of finalize in the same sense something like Casper FFG finalizes so let's um take a look at this a view that I showed you in the slide more closely right so let's assume the thing at the top is your global view so you are happily running an etherium

node and you're happy etherium node has received these blocks from the network so that's your global view from your global view you can infer things about the local views of each of the validators so for example one thing you might notice here is that a made-up made their most recent block over here and so if a made the most recent block over here that means that at that recent point in time a was building i'm a was aware of these four blocks and and at that particular point in time a consider these four blocks to be the latest messages if you look at sees view see build a block over here which means c was aware of these four which means you

know that see that see C is that these four these four latest messages are kind of pushing the fortress rule I'm in this direction um you know this is the same thing about these view and you know the same thing about about ease view right so each of the four validators except for b c is the chain and sees that everyone else is also building on the same chain so from this information we can make a claim right and the claim basically is that unless at least two validators make blocks that violate the protocol rules so make blocks that where you can just take that block put it together both a block the validator made

before and you get a proof that the validator violated the protocol then the chain will the basically unless at least two to validators break the rules no validator except B has the ability to make a block on to on top of the top chain and so the only thing that can keep growing is the bottom chain and so we say the bottom chain or specifically a is finalized with a quote safety margin of two right so how do we justify this well first of all it's a rule of CBC Gasper that for a block to be valid that block must be that must be the the

blocks parents must be the result of executing the fork surest rule given all of the messages that that chain knows about and so here well can Eve build a block over here right so first of all for a to do this then a would need to a would build a block over here but then no one else and buildable built a block yet and so well a would be clearly violating the rules because a moved from a chain that has more support to a chain that has a less support can see illegally moved to the top chain well no because C built a block on this chain that's supported by for our validators and this chain has one validator so C can't legally move over Kenzi legally we've over no can illegally move over no

and it turns out that you I that you need to eval any two of these validators to break the rules and illegally move over to the top chain for everyone else to be able to follow and for the top chain to win so this is why a is finalized with a safety margin of two now you might notice here that this concept of safety is completely subjective right all that we have here is validators fun following a fortress rule we just have validators following a version of ghosts that gets that's been adapted to approve of stake and that's been adapted to this context of a unbounded validator set and out of this you have this concept of finality even

though you do not have an explicit two-thirds threshold you do not have an explicit concept of preparing and committing you don't have any these and if explicit ideas that exist in either Casper FFG or more traditional visiting fault-tolerant consensus algorithms more generally right so this seems like what we've basically managed to do is we've managed to build this concept of finality which previously was a more kind of the domain of these BFC algorithms on top of a proof of stake algorithm that looks very chain based so it looks very similar to just some of the older proof of snake algorithms that people have been doing for the last five

years except by switching from longest chain to LMD ghost you just kind of unlocked the ability to get this finality property right so basically what this says is that a is finalized unless two validators on almost 40% of the validator said is willing to burn all of their money to cause the inside just to shift over so more generally in the context of LMZ ghost there exists a heuristic called the two round quick Oracle which says if there exists a 1/2 plus p.m. sized subset of validators that all support the same chain with two consecutive messages so two rounds of messaging from one half plus P then the

earliest of the blocks signed in those two rounds is finalized with safety margin P now if you want to solve for kind of maximizing safety and maximizing aliveness then you might want to set P to be 1/4 and so if 3/4 of the validators support the same chain with two rounds then you get a safety margin of 1/4 so the two round queeg Oracle is sufficient but it's not necessary for finality so there's also the three round quick Oracle there's the the end round quick Oracle there's potentially other kinds of Oracle's so there's this extremely large space of heuristics that you could potentially use to and if compute whether or not finality is

happening locally so cool things about CBC Casper right so why is this potentially interesting so first of all different clients can we choose different required safety margins at which they show a block is finalized and especially if a client believes that some subset of nodes are permanently offline it can privately use that information to verify finality so for example let's suppose that 70 and 2% of aetherium staking is done in Antarctica and let's suppose Antarctica suddenly gets blown up by a nuclear war oh no it's 72% offline what am I gonna

do so in a traditional BFT context right you just don't finalize anything you lose any any notion of finality at all but here if I as a as a validator privately but know that Antarctica has been blown up and 72% of the proofs take validators are gone then I can use that information and incorporate it into the fortress or into the finality gadget so I can say oh I am going to reduce my threshold from two thirds to two thirds times 28 percent and then to me privately the chain is going to keep giving me guarantees of safety that are conditional on my own information you

could potentially do even more advanced things so you could potentially have an opinion that some particular subset of alligators is more trustworthy in some way and so you you could just privately assign them more weight so there's this extremely large space of things that individual clients you can just personally do and the responsibility of figuring out what level of safety guarantees they have is sort of offloaded to the edges now there are simple heuristics you can use like for example the 1/2 plus p2 around click Oracle but if you have more information then you can use it so he gets another benefit is that you get some amount of

safety with just any amount on line over 1/2 right so if only half of Antarctica gets blown up and 36% of validators go offline in Casper FFG and in tandem and in these BFT algorithms then basically they're either gonna halter they're going to stop finalizing and you lose any guarantee in Casper CBC you you still get potentially depending on what your Oracle's are somewhere between eight to sixteen percent as safety margins so you still get kind of as much safety margin as you can get under more extreme circumstances in other benefit is that this can be kind of bolted onto

existing chain based proof of stake block chains very cleanly right so even just existing chains if you you know teak NXT peercoin like any of any of these if they are willing to switch to LMZ ghost then the N which actually is not that much of a switch because under quote normal conditions like LM D goes tends to just agree with whatever the Fortius rule before was saying then they could just have nodes privately run the safety Oracle as give this extra safety guarantee add these some swashing conditions and you have a Casper cbc system it's extremely flexible there's lots of different ways to kind of

implements it and bolt it on top of other things so why upgrade to CBC why isn't Casper FFG good enough right so honestly F of G is kind of ugly and the reason why is because it kind of grows together the FFG for choice rule which basically says highest justified epoch wins with some underlying fortress rule so in the original Casper FFG paper it would be gluing together the FFG for choice with proof-of-work c in the current Imperium Pikachu and implementation its gluing together FF g for choice with LMZ ghost and this has prior this kind of ugliness has practical consequences there's kind of bounce back and forth attacks between

two chains and there are ways to fix these attacks but they're definitely less clean than what you've just seen from a CBC a Casper right so that's one of the kind of bigger reasons just increasing kind of comp conceptual simplicity and just decreasing the conceptual attack surface of the design but also all of these other benefits of ICBC that I talked about so why is the one if you REM 2.0 phase zero not using CBC right why is it still using FFG so one of the big reasons why we were not able to do this earlier was some efficiency so

basically the problem with implementing CBC is that you have these two conditions that you need to enforce one of them is this validity condition I mentioned which is for a block to be valid under the Casper CBC rules the block needs to be the building on top of what the chain itself kind of thinks is the head of the chain maybe in some sense right so the block itself needs to contain evidence that shows that the person creating the block has the right to build that particular block at that time on top of that particular parent and this requires so basically executing the LMZ ghost fortress rule in protocol

as part of the validity condition of a block so in English this basically says in order for B to be that for a block B to be valid it must be the case that given all the evidence included in B or its predecessors B as the correct block to build swashing condition this is the only CBC swashing condition we're down to one if a validator creates two messages m1 and m2 we our m1 does not reference them to an empty does not reference m1 then the validators deposit can be slashed so every message that you make has to reference the previous message that you made and it had the chain that you're building on has to like basically include a superset of all of that

information so everything you say must reference the previous thing you said forming a single personal kind of message chain so the implication is that if you make a block that took into account some piece of evidence all future blocks must also take into account that evidence the problem is of course we have a beacon chain we have a huge number of validators that are making messages very quickly we make this practical now we make this practical in a Casper FFG context with kind of separating out blocks and anta stations so we have one block every six seconds potentially thousands of at the stations every six seconds and we use this cryptographic technique called BLS aggregation that

allows us to combine together a huge amount of signatures into one signature that into in terms of data complexity requires one bit per participant and in terms of one computational complexity requires one ec ad which is maybe one or a few microseconds to a per validator the problem is that BSL BLS aggregation requires many validators to be signing the same message but CBC Casper kind of goes against that right so CB TC Casper says every validators message must reference that validators previous message and so it sounds like we're requiring validators to be each signing different things which sounds like it

might make be a less aggregation efficiently impossible so here is a solution every block maintains a Merkel tree of the value of every validators most recent message and so the way that you make sure that each validator builds on their previous message is that each validator builds on a Merkel root which is the same Merkel root for every one containing everyone's previous messages so a slashing condition basically says if a validator signs a message of salaat C of a block or their most recent message was at some salat a before C and they signed another message it's a lot B that's between a and C then they get penalized so a problem so it challenges write computing LM z goes to takes a

huge amount of time there's this other version of ghost called bitwise LMG ghost where instead of going block by block you kind of make it even more finer grains and you go bit by bit in the ham in block hashes and it turns out that this has a relatively efficient time algorithm where you can store information inside of the chain about whether or not like basically the chain is valid so for every validator you can basically there's this this algorithm that you can use and you you can basically get verification of LMZ ghost and something close to kind of K times law some logarithm logarithmic time if there are

K validators that are being changed first what so this is actually not much more expensive than what's happening already where you have that many changes already happening to your Merkel tree so these things are definitely possible now what does this mean right so first of all casper cbc it can just be bolted on to existing systems including any form of proof of stake but also this means that casper CBC has this path to work on potential faster deployment in etherium anyway that actually changes surprisingly little of how aetherium itself kind of fundamentally works today right so cbc is definitely not something that's happening in phase zero phase one

but it's also there's no need for cbc Casper to be a kind of aetherium 3.0 territory it's something that we can start getting the benefits of more quickly thank you [Applause]