Ethereum 2.0 Phase 0 Deep Dive: Beacon Chain Consensus

[00:00:03]thank you all for coming myself shall we chat chang-dong could justin and metallic who is apparently on this floor will today give you a deep dive into the phase zero specification that is the beacon chain of Ethier and 2.0 protocol today we will get a sec nickel as we can with the time permitting and at the same time point you to portions of the spec so you can dive in deeper and hopefully just get you more acquainted with what's going on so that you can better technically understand the problems at hand and the solutions and kindig and contribute all that so we're building this thing as it theorem - it's a chartered protocol there are many shards connected to a central beacon chain it also is has loose coupling to the existing ethereum chain which at the beginning just supports deposits coming into the beacon chain today phase zero is just this pure proof of stake chain connected to the etherium one protocol so that is what we'll talk about today I believe at the same time will at least show you the scaffolding upon which shard chains will be connected but will you'll not dive deep into this portion of the protocol the beginning what we're gonna start off with today is we're gonna look at the kind of the some of the core building blocks of consensus that's the cast for FFG protocol the LNG ghost fork choice randomness and BLS signatures after that we'll take a short break maybe take some questions and then we'll dive into the actual some of the mechanics and in stage concrete instantiation of the protocol with the actual state transition and things and validators and things built on top of some of these components so f of G applied to proof of stake so there was a paper written probably bout a year and a half ago now by Vitalik and Virgil Griffith Casper effigy consensus protocol generally built to be layered upon a block proposal mechanism the original being a proof-of-work mechanism but there's some modifications to bring this protocol to be on top of a previous take protocol and more importantly some modifications that get us to where we need to go for his protocol so I'm gonna go over some of some of some of those modifications how we think about slots checkpoints epochs slashing finality that kind of stuff I will give you an intuition for the safety proof but will not have time to dig deep into that and we have a yeah I'll talk I'll talk like that now I can hear myself we will we have a modification of the FFG protocol in a paper it is a draft I really wish it was gonna be done by today it's in last round of edits and will be released on archive very soon so hopefully this will help you read that paper when it comes out so traditionally when we think about blockchain protocols we think about blocks and block Heights and every block you build on top of another block moves us into another block height the original FFG protocol considered considered block Heights and actions that validators could take with respect to block Heights these Heights were divided into epochs and units of work would be done per Epoque so essentially a round of voting by all validators can happen per a PUC what you can do and not do to the protocol is also kind of defined within these epochs we have a slight modification to how we think about a chain being built still we have blocks linked to each other block by block building a block chain but we have this notion of of time called a slot also embedded into this kind of overlaid on this structure and so what we can what can or cannot be done by a by a validator in any given time it was with respect to a slot so my duty to propose or to a test or do any type of these messages it's with respect to a slot and so a block someone someone shows up and they propose this at slot 0 this is slot 1 no one showed up at slot 2 or maybe it didn't get propagated the network and so the proposer at slot 3 built upon slot 2 but the the state-transition the internal mechanics of the consensus protocol and other portions of the protocol are aware of this skip and so instead of things being divided and to strictly block heights because this would just be a block height of 3 although much more has transpired with respect to the the duties and positions of the protocol so instead a pox are divided into slots slots epochs in actuality or on the order of like 64 slots this is just illustrative so this consensus protocol needs to be modified FFG needs to be modified to work on top of this new kind of slot and epoch mechanism checkpoints so in Kasparov oh gee we checkpoint we attempt to finalize checkpoints checkpoints are blocks at per units of time here checkpoint might be this block whereas there may be might that but importantly because we have this notion of skipped slots we have to define what actually a block being at a checkpoint is and means and so we call it in the in this paper coming out it's called an epoch boundary block EB B so in this Fork of the chain we have the epoch boundary block which is the 0th block in that epoch is actually B but in this Fork of the chain where a slot at slot 66 was built on top of a the epoch boundary block is actually it's the block at the zeroth slot or the most immediate block prior so it's actually it's actually a so in this version of the chain this fork of the chain if votes happening and blocks are justified if something was was check pointed or finalized it would actually be a at this slot because a can be transitioned through empty slots up until B exists you're actually check pointing and ultimately finalizing this tuple of a at the start of this slot to illustrate that a little bit more what I was implying is we have this notion of paired justification impaired finality in the optimal case we're always just say justifying the 0th in the optimal case we're always justifying and final exams exists at all slots then we can just always justify the 0th one here but instead because we we can have drop slots and skip slots we have to have a notion of what we're actually at a given a PUC what we're actually finalizing and it turns out that we're we're finalizing this notion of a paired justification of a block at an epoch so just to illustrate that a little bit more we have a block at epoch one the zeroth slot at 64 but then a nothing happens like some everyone goes offline or some massive forking happens and the proposer the next proposer actually in epoch - it's la 129 builds on top of this 64 and so and we go on in this epoch to to actually justify this epoch boundary which ended up being a block from a prior epoch but at this slot and so then we can go on to do further justifications and actually finalize this and so what that does is finality in this mechanism ends up being not only will this block say this block is at this epoch is finalized not only will this block never revert but blocks that are lower than this epoch boundary slot can also but built upon this can also are also not valid so for example if someone built a block right here it's lost 65 cc6 but this was finalized those are those are considered invalid and I don't consider them a part of my fork choice so we have this this notion of coupling blocks with an epoch in finality [Music] so justification rules similarly to Caspar FFG the original protocol the genesis block at epoch zero is justified and subsequently we have justified and again we have these pairs these block epoch pairs any justification pair from a source of a prior justification pair is justified and when votes are cast we're always specifying a source and a target so here in this link that was created this prior justification was the source and this new one is the target so we create a justified link I think it's called a supermajority link to create these just this chain of justified blocks and a subset of them depending on the rules can be finalized so finality rules I know this isn't actually super meaningful this is taken from the paper the finality rules in the original cast ref of G paper were essentially you had to have to epochs that were sequentially justified where the the lower of those two becomes finalized here we actually extend the finality rules to be a little bit include a little bit more cases where we generalize it the original case that I just described is called the K equals one case where we are sequentially justifying but we can we can generalize this and add cases to the K equals n such that the rule becomes if we have a justification link and or here's our justification link but all epochs contained within that justification link are also justified then we can finalize the source of this link so here we jump to but we justify the center so we can finalize here here we jump over over three but we had justifications in the center and so we can finalize the base and the intuition here is that here our justification and finality here is we can't double vote to try to finalize something exactly and if we wanted to essentially like skirt the double vote and and jump over then we we we can't there's an and I'll get to that in a moment we can't surround this vote to essentially jump over and here we've like plug to the holes so we have a similar mechanism and we've plugged the hole and then now we just need to prevent surrounds to avoid that finality issue in the actual e theorem to protocol we only consider the K up to K equals 2 case because and the reason that we need this is because we allow at two stations to be included during the epoch that they're created on chain up through the next epoch and so you have a few if things are not performing super optimally and at a stations aren't being included on each epoch every time and they're included a little bit delayed the the state of the chain and what is actually justified in the view on chain can be delayed and so we have these cases where if we open up here's our K equals 1 cases case 2 in case for those are nice but here we have these other K equals 2 cases where by extending the finality rules we actually can capture finality in a few more cases I think Justin will probably get into this a little bit later but in the beacon state we do have these are the portions of the state that are related to finality we track the last for just a epochs whether we justified them and a few things about the checkpoints and with that data we can track these cases and no finality on the case of on chain here's this massive nasty function that processes justifications and also processes finality based upon those mechanisms I was kind of alluding to these and I probably should have these earlier in the slides but we the things that keep this protocol safe is we prevent making double attestation so voting for the same target in the end within one epoch and we as I eluded said earlier we want to prevent given any source target link here here here we to to prevent essentially getting around the node double vote we prevent a no surround so I can't come from something earlier jump over and then begin finalizing here's the actual code we can probably get into this little bit later where we take attestation data can't have the same target epoch can surround that's that for now sorry that was so fast we have a lot to cover today and that's like one of the more detailed components metallic all right so I am going to be talking about as you can guess the LMG goes for choice rule so I guess so to start off kind of what is LMG ghost it's an adaptation of ghost aka a greedy heaviest observed subtree which is a alternative proof-of-work fortress rule that some academics humans ensemble in ski anivia so hard developed in 2014 and it basically takes the same principles as original ghosts and try stone have modified them slightly and fit them into a proof of stake context so to start just a kind of quick intro of what ghost itself is basically the idea here is that if you imagine a network where there is a lot of network latency or there is normal network latency network latency but blocks are very fast so say network latency is one second you have a block coming every three seconds then maybe like something like a quarter of all the blocks are not going to be here kind of conveniently in the same chain right because you might just have a block get produced to end before that block gets broadcasted another block gets created at the same time and the reason why like this is bad and so in Bitcoin they call this orphans or sales and aetherium we call it uncles the reason why it's bad is because if you imagine there is an attacker and the attacker is trying to do a 51% attack so make an attack chain that's longer than the honest chain after at some point then the attacker has an advantage right because the fork choice is tries to look for the longest chain so the honest chain one of every four blocks is not lengthening the chain it's kind of a sister of some other block but on the attack chain it's just the attacker and so everything works perfectly so instead of needing to have 51% of the hash power the attacker might only need to have 43% of the hash power and if network latency goes higher than the percentage drops more or announced Network latency approaches infinity of the attacker can through a 51% attack with basically nothing so ghost fixes this and the kind of philosophy behind this right is that if you imagine a chain here where let's say block D was built on top of block PE but then this chain was block C and then block he ended up winning if you look at block D like block G ultimately is still a vote for B right it may not be a part of correctly on the same chain but D is still voting for B who ever voted for overbuilt D still thought that B is a good block to build a chain on and so really you should be taking into account both D and E as of blocks that's that support B's rightful position as as part of the chain so the way that ghost works is basically instead of looking at the longest chain you have the you run this kind of iterative process where you start from the root if some block only has one child you walk over to the child if you if a block has multiple children then you select the child whose tree of descendants is larger right so over here this block has no descendants so total of 1 including itself over here this block has 1 2 3 4 5 6 descendants and so we go over here then you walk over here then you have another fork then this is the kind of heaviest subtree again and so E is the head now in this particular case right like the the Wong is chain rule and ghost agree but there are going to be points like many theoretical cases especially when there is an active attack being attempted when these extra blocks that really do matter and they can save you from an attack now the way that ghost applies this to a proof of state context is basically to start off it's very similar except instead of looking at all blocks it only looks at the block that is the most recent message submitted by that validator so for example in this case imagine you have a proof of stake chain you have 5 validators we'll call them like la Alice Bob Charlie David and Evan and if you look at Alice now has created two blocks over here and then one over here and a Bob over here created this and this Charlie created these two David created this one but then David might have dropped off line so he's got nothing over here so this is his most recent one and Evan created two blocks and that's his more recent one so what we do first is we only look at the most recent blocks from each individual validator would you basically means this this does this and we run through the exact same process but only using those five blocks two counts toward the weight right so over here you start from the root one child go over here then over here this side you have a score of one on this idea of a score of 1 2 3 4 you go over here then you go here and then score of 1 score of 1 score of two go here and here and that's the head now for now we're assuming a simple kind of model where what I call blocks and what I call messages are the same thing right ends basically so in this case blocks are serving a kind of dual purpose one of them is that blocks are kind of entries in this graph structure and like your fork choices walking along the blocks but the other rule that blocks have is watch they're voting now in LMZ ghosts as we use it blog sent messages will be split and I will get into this and why we do this later so as in ghost start from the Genesis walk up the tree at each branch choose the child that has more latest message latest messages supporting it and keep going until you find the head so why LM D ghost right the so this here were interred bringing back kind of LM t ghost as more like it actually exists in aetherium 2.0 and what we have here is he have blocks and votes on a key a attestations as kind of three separate concepts right so you have a block and then you have five votes you have a blocking or like in reality this might be could be anywhere up to about 50,000 votes then you have a block you have a huge pile of votes a blog a huge pile of votes now over here you might have two different competing blocks and this could because one of the blocks just got delayed and the other boy and then the next proposed who created the block and this block appeared this could be because a proposer was malicious and created two competing blocks we don't know so now everyone who's voting chooses either this side or this side and if they choose this side then this block wins and then you keep on going right so the ghost fork choice rule is going to be counting these the antis Nations and specifically it counts latest data stations so if this like if this is all inside of one epoch then there's no difference because everyone only votes once per you park but if you imagine that say this and this are two separate epochs then maybe this at the station and this at the station come from the same validator in which case you don't count this one but you count this one now in general if a chain is progressing then the if you vote once over here then the next vote that you make is going to be a descendant of this block right so most of the time validators aren't changing their opinion they're extending their opinion so if you made a an attestation supporting this block then you're saying my opinion is this block is the best if you then later make an attestation over here saying my opinion this block is the best then like you're not disagreeing with your opinion before right you're an opinion though this block is the best is also an NPN you know this plug is the best and of this block is the best and then this block is the best but before you did not have an opinion on these guys and now you do have an opinion on these guys but maybe you made an attestation here then you make this at the station then you realize this chain wins and so at some point late at some point later you do change your mind so like both these things are possible now the reason why we do this is because this allows basically parallel confirmations right so in a kind of probabilistic for curious role there is this general concept of confirmations like basically how many kind of units of information in favor of a block are there and how many gee wants to wait for to achieve a certain degree of safety in Bitcoin you would wait for six and that means waiting for six in etherium like you would wait for 12 so you'd wait for 12 blocks but here you basically get tens of thousands of at the station's happening in parallel and so you get a very high assurance that a block is overwhelmingly likely to be included in the chain pretty much like in the average case after one single SWAT so the goal here basically is to give the same level of security after ten seconds that a traditional proof-of-work chain would only give after minutes or hours and because you have messages happening in parallel there's no way that all of them are like you can even possibly make all of them form a chain if you try and so a longest chain rule was not even sensible and LMD go strength is the obvious approach for how to have taken to account the information from all of these validators so why LMD ghost right so one reason is that the longest longest chain rules cannot take into account information from parallel testers and ghost based rules that do another interesting property that LMG ghost has is it has a property that the minority can never beat the majority regardless of how many messages they sign right so for example suppose that you have like a structure that looks like this and then base so you have these four validators that are all on this chain and these four validators have all agreed that this chain is best and you have this one kind of a lone attacker now let's suppose that a CD and E just get knocked off line they disappear then if you use traditional ghost right eventually be could just make blocks we could make blocks B could make blocks and eventually be what B's chain will be longer and B would win but in LMT ghost if all four of these guys get knocked off line then you could keep on making blocks and B could keep on making vlogs for a long time but this chain is still going to continue to be the winning chain because it's not about the quantity of messages it's about the quantity of distinct supporters of one chain versus the other and if these four Val don't make any new messages than the system assumes that they're just supporting these four things forever so this kind of insight this idea that unlike longest chain rules lmg ghost has this mechanism where if it gets into this configuration but you just can't move over to this chin pretty much like no matter how long beach rise this is actually the basis of ICBC casper which is something that we're interested in switching to for the longer term but so this is one reason why and a second reason why LMG ghost is interesting now let's look at some edge cases of LMG ghosts and specifically LMG ghosts interaction with the with the finality gadget right so safety message attacks are one one a kind of example of an edge case first right so basically here look that here's the intuition behind a safety message attack so a validator is allowed to make a maximum of one attestation in each epoch and the way you enforce that is that every attestation has to come with a tag that says this is the epoch I come from and if you send two distinct at the stations with the same epoch tag then you can get slashed for it now a thing that you can do is you can say well I'm gonna just drop off line for any box and now I have in historical tags that I've unused and then within one epoch I can just like send all of those messages with all of those tags all at once so a worst-case traditional ghost like it's not very it's not very good at handling this kind of situation LMT ghost is better because at least those n votes do not stack on top of each other but lmd ghost is still imperfect because with this kind of mechanism well you have the ability to and if influenced to basically make the fork choice go back and forth right you can say I vote for you now I vote for you now I vote for you and now I vote for you and you can repeat this a bunch of times in a single epoch and this could be used for some attack still alive nacinda lay finality so a proposed solution here is FMD ghost which basically says clients only look at messages and have tagged with the current or previous epoch and this prevents kind of saving saving up more than one more than two epochs from being a being useful for any kind of attack [Music] interaction between oMG ghost and FFG so we use both LMG ghost and the FFG in this kind of combined way basically lmd ghost provides block by block consensus and FFG provides finality and like you do have to kind of glue these algorithms together right so our actual a fork surest rule basically says first select the last finalized block you were aware of and at the beginning this is the genisis eventually you become aware of new finalized blocks second you selects the highest highest epoch the most recent justified block that's a descendent of the last finalized walk and then third starting from the last justified block you run LMG goes to find the head so it's basically running FFG first to figure out the last justified block and then writing lmg lmg goes from there to find what the head is now this does open room for certain kinds of like bounced attacks so basically the issue here is that you might have a situation where you have one block on one side and you have a block that's winning the fork choice rule but then you have some block over here with 65% of the votes and then the attacker has a few votes so then the attacker waits until some block here gets a 65% and then the attacker releases a few votes here this block becomes justified and so suddenly the fork sure is the rule kind of flips over from here to here and then people build over here and then when this block starts getting close to over to 65% then this blocks at 65% the attacker releases another 5% now this is justified now this halts everyone moves over here and so he can kind of bounce the chain around right and there's some a couple of solutions that are intended to mitigate this kind of attack one of them has to basically they all have to do with kind of delaying when you justified epochs have an effect right so one of them would say in most like in most cases delay until always switching until when epoch boundary so either finalization happens a coast of the start of an epoch or it happens much late or or you wait until the end or and I another idea is that a checkpoint can only be used can only be used to as part of the fork choice until like basically the height since the last justified epoch multiplies by three year and this ensures that there's kind of periods of three epochs eventually within which the fork choice is not going to change and you have the opportunity to finalize something so then like LMT go stick is not really more complicated more complicated than this right it basically is you have a block and if that block has multiple children to figure out whether you go to one child or the other a child you choose the child that has the most validators that you might have most recently supported that block and you can use that by itself as a as a fork choice rule and you have a bunch of validators that are making these messages in parallel and each of those messages contributes to the fork choice rule allowing the chain to kind of soft converge very quickly and after those messages are also simultaneously votes in FFG and so after about one epoch the blog gets justified and then which kind of entrenches it in the fork choice further and then after one more epoch he gets it gets finalized hey I'm dicot Feist and I'm going to talk about randomness in Ethier two point oh okay so basically I quickly want to summarize why randomness is such an important problem in if in any kind of proof of stake protocol and if 2.0 I'm going to talk about run now which is our first and like routine routine airy source of randomness quickly like also going to the the issues that this has and why like in the final protocol in a few years we're going to use a verifiable delay functions to improve this source of randomness so why is it so important to have a good source of randomness and proof of stake well so we need to do several things randomly and we don't have this kind of proof of work randomness that we have in proof work chains anymore so we need to select proposes we need to select committees and we need also like as an extension like some contracts on chain want to use randomness and we need to provide randomness for these as well and so for each of these like like good roundness required for proposes because we need to be fair like we distribute rewards to them and also we we want to protect against denial of service attacks but it's especially important for the for the committee is that it has to the short chains because if like if the committees are not honest like the the beacon chain cannot cannot check the state transitions of all the charge changed because that's the whole point of shouting that you don't have this huge load on the beacon chain but that means we can have to trust these committees to be honest and we can remedy against an incorrect vote by a commenter using for proofs but we don't want to have too many of these and finally we also want that smart contacts can use randomness and yes some applications like lotteries or so might attach a huge value to random numbers and like if you can somehow attack them that might degrade the randomness in the whole system right and then a bit further on their committees why it is so important this is like a very central issue they're like if the the problem is that we want to minimize the probability for having a dishonest committee and like a bad committee could potentially create a link to an invalid or non-existent block and a fraud proof would mean that you have to revert the state of the beacon chain until like when that happened so like the probability if you have a committee size of 128 then it's quite small five times 10 to the minus 15 but this kind of kind of cost completely changed as soon as someone can bias the randomness that we're using right so the idea behind run now is let's say like we have n people who want to generate a random number everyone goes into a room everyone contributes one random value X I you compute the X off all these values right so that sounds like it could get generate good randomness but the problem with that is the last player can just change their value after they have seen everyone else's value and then they change their choice and like get whatever they want okay so let's improve this so with commits reveal we can start the same they all go into a room and they each commit to their value ex I by telling everyone the hash and then they reveal their value we compute the XOR of those values again okay so in this case this cannot be manipulated because we force everyone to reveal their value because they were all in the same room but in the real world the problem is anyone can stop this process by not not actually revealing their preimage and then we can't compute this XOR right so run now basically builds on this idea so we make every everyone who's a validator has already committed to something in our case is actually their signature because we have a deterministic signature scheme BLS we can just use a signature as a reveal everyone can check that this was a correct signature so you sign the epoch this is denoted by E here and that's that's the reveals and then what can of course happen is that someone does not produce a block and so they they haven't revered the randomness and then we cannot include them in this XOR yeah okay so that is the basic process of run now and and this is used as a first instance to generate randomness eath 2.0 it only has one problem basically that whoever is last in an epoch can just choose to not produce a block so basically what does what this means is if I don't like the result of whatever this reveal that I'm going to contribute this like I can compute whatever the mix would be then I just don't contribute and it's as if I would get another roll of dice essentially and like you can that can be worse if if you control several validators in a row course than more bias as possible so like there was one nice analysis by vitalic on his research where he showed that if you just have a longest chain fork choice rule then with just 36 percent of the stake you can actually completely take over a chain that's bait that choose the step blocks based on run down that block producers right so what ran now is sort of our first source of randomness in the beginning it's obviously as I've shown not perfect but at the moment we don't have anything better so like in the future what we're going to build is honestly like so-called verifiable delay function the idea is that you have a function f of X that produce the results Y and prove PI and such that the computing this function takes a long serial time right so you can't speed it up by having many processors it's like you have to run and see really on one processor and then checking the result that the reason why is correct using the proof pi is fast and so one example which is actually the one that will we are very likely going to end up using is this squaring modular and RSA modulus so power taking many squares of X modulo M where m is P times Q is like one way to construct such a verifiable di function and by using the vdf output on run now VD f sorry the vdf on run now so using the ran Arad as input for the PDF the last revealer loses the advantage and the way that works can be Illustrated here so basically what happens is you have this last block of an epoch that starts the vdf computation and so later the vdf computation will have an output and that will be used as randomness on chain but by that time they will already be many more blocks so it the there the last reveal I wouldn't have a chance to know what how they could have influenced by not not revealing their reveal yeah that's it thank you so a stock is a POS signature aggregation so the goal is to provide a minimal set of knowledge that that make developers life easier so the goal is to introduce the signature scheme on a top but that it is built on the pairing operations and curved horns groups and they all built under of field operations button so yeah so a takeaway here is that when we say BOS we might talk about two things the one is the BOS signature aggregation scheme and the other is the curve parameter that of chosen by z cache is called BOS 12 3:81 curve there are different authors so first I'll give a primary how a queue operation works so you have a feel number like fill 13 that means it is operator operator on the prime prime number 13 and then you can define addition subtraction multiplication and division with this number and note that the outputs are always between 0 and Q minus 1 so you have a no matter how complex commutation you if none on @q you always get the same data size and you can use the py ECC library to to try try on different of primer fields and here's another primer on elliptic curves you when we say elliptic curves it's a it's an equation in this form is it's a Y Square and X cubic and when you define it on a real number when X Y is a real number you see a curved shape but if you defined on a finite field it looks like scattered and so a point on the curve is has a x and y coordinates and usually you need to send the points over the network so you can compress it by only specify X and only one pitch to him for which Y you are talking about because given X the Y is symmetric it's it's only two points on our graph so and you can you can add a point to another point so you can define additions of the points on the curve and it is usually on line when you want to add P to Q you draw a straight line and intersect the curve on another point and then mirrored it down to find a peep ask you so when we have the addition of the point you can define multiplication for a point you can multiply a point like by ten times like adding your 10 times and this is this is a hard math problem that you can given you have P and Q and you cannot find 10 easy it's really hard so you can hide bodies in here it's actually a secret key yeah and so here let's talk about the PRS 12 381 specifications it has a small small point called g1 and a big point called g2 if we remember the first pyramid is they have different finite prime fields on a button the smoke smoke small point has 48 bytes and a larger one has 96 bytes and they have different elliptic curve defined and note that so the fq2 is like a complex numbers it's a double the size of the small curve and there's a image in imaginary number I there and the G 1 and G 2 is that generator points that has a specific x and y coordinates specified for the for the curve and so I'm colored whole days then so it don't don't get lost with G 1 and G 2 so a pairing function pairing function is a function that takes a g1 group and G to group and the magic of the pairing function is that when you like multiplier constant a or b to group elements and you can tag the IV to the shoulders and that means that you can take that AV into the first one in a second one and that's rule number one and rule number two is that when you are adding points now you are adding points in g1 adding points in g2 you can like distribute them and spread them out so with this construction we can introduce how we can how the signature scheme is built and this type of construction and if you look at the pairing function there are some monies over there because it's expensive to run so it's a it's a computational heavily functions so we try to minimize the times you try to run pairings so here here is the POS a signature scheme private key is an integer thinking like 1 2 3 4 5 and you get a public key you just multiply the private key with G 1 point and to sign a message you need to hatch the message to a group of point and that's the when you her people saying the POS standardization effort they are standardized the way we hash the message to two points and then you multiply your primary key to a message and you get a signature here and to verify the signature and a public key and message you are used to pairing functions and the proof is really simple it's like you write a G 1 and s on the left-hand side and then that you can move the K from the right to the left and you get the expression of the right hand side and so the most powerful thing about be our signature seen is it can aggregate signatures and public keys so this just a curve point additions which before and this is you can aggregate three signatures and you can agree get as many signatures as you want and then verify using two pairing functions to verify so yeah so the proof lived as a exercise but what we are looking so what you are looking at here you are looking at a scalability so this this this is how you can aggregate many validators messages so here I present and it samples that kind of power on the chain saves simple C or istick on so it is an attestation message and it has signatures it looks like this and then I hide data part and you will see an aggregation page looks like this and this is actually a record SS or varied 805 is your signature included in this bunch of aggregation and then a kind used that information to look up public keys and to verify these signatures so yeah this how tos signatures works hopefully hopefully that helps you thank you very much thank you metallic dr. Chang next up was a break but we don't have time for that because we're definitely definitely running late already we might have some time for questions at the end but we're just gonna keep driving next up shall we gonna talk about we're moving into these are the kind of some of the building blocks to help you understand some of the underlying concepts that we use to construct these things and now we're gonna move into the more concrete and San Shi ation of the protocol shall we so hello everyone I'm sorry I'm pretty sick right now and konichiwa so my topic is the life of the serum the concern validator so this is the outline of this topic so we were talking about two main factors to define the editor state and then we will talk about the entry and exit cues and then the life cycle of this so the current spec defined list for status there are activation eligibility which is the preparing stage before it actually be activated and then the second one is to it the state that later is alive active and is helped to validate the state the blockchain and then when the editor they can choose to accede then after a while they were getting to to exceed status and finally the beacon chamber later we're getting to to withdraw Ball State so here we need to know is that in the big engine phase zero we only have with drawable state there's the actually withdrawn state will be introduced in the Phase two where we have yeast execution environments then that Square the litter can actually withdraw their deposit to the e to distractions okay so here is the validate Hearst data structure found the beacon train state so the validator is has these informations we need to know it's inside the content state so here I highlight is the status a parks so we can see this four different state of each park are defined here and initially the the state epoch is set into the unsigned integer of 64 bits which is the maximum number of here so the reason is that we can we haven't defined this status we haven't defined when this status will be happened so we said a rebel own wave long epoch okay so Stanley explained it that we defined the slot and epoch so each epoch consists of 64 slots and each slot is 6 seconds so we can use this epoch number as the timestamp here so as we define that we can see the epoch of hyaline and if the data has been set to with activation eligibility epoch 100 and also the activation impact 200 then when the time actually between two of this to ePub for example 150 the violator is not activate yet and when after 200 parks the data will be actually at it activate and so we introduced the state epochs no there's another flat oh it's another factor that in fact uh the peak enchants the data state which is called dashed which I think Danny will talk about how the idea to actually be slashed in the later session so in here you only need to know is that a flashed the later will be forced to exceed it which is very reasonable because they might be something that we have misbehaved so they were big thoughts it to be yeah I'm going to talk about the red limiting cues before that want to introduce the quick subjectivity this is a feature of the proof of stake duction and so if if you are new by daters we got it online and you you can only join you can only trust the your peers around you and also if you get offline and then be back again you can doing the same situations that you can only trust your neighborhood so then how long you can be with the offline its introduced it depends on how long the it takes for the attacker to withdraw their stake then then that's why the state I mean the exit rate is important here and also the tie line the the tie period we set for and but yet her from the time it initiates exceed my operation - it's actually be excited that triggers is also important so in the potential we have to choose which is twice the entry queue and another wise exceed cubed so let's two queues are the reason why we use queue is that we need to network also the you know that network and also the data set to be as stable as it can be so we we won't allow that enough short short period a lot of the data that they initiate exceeds then the data state will be like you can't select enough weather enough and the since say it from the ladies estate and also it ensure that the penalty guarantees is still remained between the two chains as well as the later locks on of often enough so we will see that how the queue is happen so so this is the channel rate functions we you can see that the for each epoch the maximal number of a later can't join or to exceed 85 it's based on the current active very data count so you can see that it the number is set us this and the tron red curtain is set to like 65 thousands so as you can see the number we can estimate that how many later can be is it at the same time and the lifecycle so at the beginning beginning the relator they will make a deposit on the east one trend and it's one change is the end point get to get let you get from the east one chain to its the world so when the later they make a deposit of the 32 either to discuss deposit contract you also watch the past encounter status from the be control so so this is a diagram here and we were show the four that were later so at the beginning the deposit data is here and we will check online and on the pension logic that is has enough balance and ready to activate and after full epochs and also it's a first influence of our queue we defined that the tron rate earlier like in that function so only the small amount of data can join the various said this is the entry to here okay and then leave now let's take a look the button diagram so from the window the validator is activated and there's two possible in this road is maybe the radiators and he got penalized and times my times and the the radiative balance is insufficient so then in that time the ladies will be objected and a knowledge option is that but nobody that can volunteer wellin Harry exceed here's the second road so both roads we'll get into will push Terminator in exceed cue here so it's also it has to wait for at its four epochs and also it has to be enough room Foley's theater to exceed and then we call that this valley it is in the state of it's our - but is exceeded okay so and then after 27 hours it will be with durable the reason why we remain we set a delayed high between the excited and we Straubel 3 most reasons why is that the very literally after the it's exceeded it's still possible that it will cut slashed which is this route and also maybe the very still have chance to get some a small amount of free world before it actually exit and also it will provide proof of custody challenges high to be made during this period I'm sorry the poor velocity things to face one thing that we will prepare this and then let's take a look the top diagram so the activated my later my got slashed and after it got stashed you will wear the short delay until a we can can initiate withdraw operation then you got into that the / and exceeded status and after at least 36 days it will be with durable so it's very you can see that the stash theater has to wait for more time it's got punished because the there either is locked into the kitchen that's the full picture that you can see how the little B switch between those data's okay okay okay so I'm going to talk about the state transition function of the of the beacon chain and I encourage you to just you know read the specs it's actually not too bad it's only roughly a thousand lines of code quite readable and the link up there is quite long so I've also shortened it okay just to give a bit of context you know you all know this we have the beacon chain which is kind of the the system chain of the whole system the spine all the shards kind of connect to it via cross links the shots come later and I'm going to focus on the beacon chain okay so we have slots we know this we have blocks and we can chain and we also have state and basically state advances for every block and so what I'd like to focus on today is you know what is a block what is state and what is the state transition so this is the state transition function and you know it takes a state which returned the post state or an error so we can just say okay this this block is just invalid and I'm gonna abort there and if it's valid I'll give you the next version of the state and in addition to slots we have a box so 64 slots for a park which is six point four minutes and epochs are kind of important from the point of view of the state transition function because this is where some of the kind of accounting happens at the epoch boundaries so you have these state transition functions on the Block basis and then you have also state transition functions that happen on a Airpark basis okay so this is a kind of a high-level overview of the various components of of the beacon chain and you can kind of think of it as an organism with various organs that connect to each other so you might have a little Long's the heart whatever all these things and here they each provide kind of vital functions so for example randomness you have the registry which keeps track of the validators you have finality down there you need deposits of course if you want proof of stake and yeah everything is kind of flat so it's not like a layered system but we do have like the beacon chain and the shard data and the short state but within the beacon chain is actually quite flat and and horizontal and each of these things you know we can be swapped out it's very modular and so you know one of the goal the roles of a designer is kind of to pick the best ingredients there and try and put them together in a in a harmonious system and in terms of color coding I'm gonna use blue for the state and and green for the blocks okay so what is the state let's try and actually read the code chunk by chunk trying to understand what is in there so we have these three properties which are basically related to two versioning in space and time so the the the Genesis time tells you when when the state was was created slot kind of gives you a more granular notion of how much time has processed and then the four core kind of be versioning in in space as it was as opposed to versioning in time so every time we do a hard fork we're going to update this and one of the the impacts that has is on the the way that signatures are verified okay so that's all all basic stuff more kind of basic infrastructure is you know the notion of of roots so we have state roots and block roots which is the equivalent to what what is traditionally called a block hash or an estate roots and this is just a way of cryptographically keeping track of the various objects that we're working with and representing them in a way which is friendly to to work with so the reason why we're working with roots as opposed to two hashes is because the objects that we're working with are structured and we have this notion of a tree of hashes and so if you're interested in a very specific property of an object then you can access it via a americorps path for just a specific object as opposed to having to need the whole object and then we have kind of the the economic link to 'if one so we need deposit in to leave to the deposits come from if one and so the if two needs to be aware of if one and and this is the state that is going to help us be aware of if one and then we have the register this is going to be like probably the most important part of the state so it's just the data structure that keeps track of all the validators and it's by far the largest part of the state so you know this might be hundreds of hundreds of megabytes let's say and the rest might be tiny just a few megabytes we have some state related to shuffling and and randomness we have state related to slashings we have state related to attestations so at the stations is basically what the validators need to do that's the work that they have to do it helps advance the system and make it move forward and this is what the the validators get get paid for we have the cross links which is the link to the to the various shards and then finally we have the finality mechanism and in terms of concretely what are the the modules that we've chosen here are some of the key words so we have F F G for finality we have BLS signatures for the attestation x' goes for the focus rule we have Rand out for randomness swap or not for the shuffling we have surety 56 as a hash function and we have tree hashing as the way that we we Merck realize the the objects okay so it all fits in this slide this is this is the the state okay so let's try and understand what's in a block so in the block we kind of have the header this is the header with things you'd expect like the slot which is the equivalent of the height and other systems the parent route which the the parent hash in a novice system state route the signature which is going to be the BLS signature and then the body which is going to be like the more important part of the block okay so let's let's look at the body what's in there so you know we have fields that are relevant to two of these systems one is the randomness system making progress ran down and then the other one is related to the link to f1 so trying to make that progress through voting and then we have a graffiti which is just any any data so this is kind of encouraging people to to innovate with putting data on the beacon chain and then we have the equivalents of a transaction so normally in a block you'd put transactions here it's a bit different because the transactions are not user transactions they're system-level transactions so we call them operations and we have these five different operations two are related to to slashing one is the attestations which is where like the real work should happen and then you have transactions which are related to people coming in of the system leaving the system or moving funds within within the system so these are just registry operations the attestation is probably the most important so block contains at the stations and that's what moves the system forward okay so I want to try and give you like the really high level of the state transition function and I'm gonna cheat a little bit and I'm going to only present what I call the honest state transition function and by honest I mean that I'm going to assume that the block has been honestly constructed so it's a valid block and and what this means in practice is that I'm going to try and tell you what are the mutations that the block will make on the state but what I'm not going to tell you about is all the various ways that you that the state transition function can can throw an error so all the various assertions and it turns out that the bulk of the complexity is actually here but here is really boring stuff is like Oh verified that the signatures valid verify that if you're transferring funds you have enough funds I think most of the insight actually you know comes here like you know just to try understand how the state evolves and this is where it all happens ok and so I've kind of subdivided the modules into into three columns so you have the the scaffolding which is development pretty much for all block chains time routes and randomness and then you have the the registry which is which is the one unique part to proof of stake so you know you have things like deposits and exits and then you have a final bit which is you know technically you know optional but it's still extremely powerful related to to finalization and cross links if you want sharding and and also ghost 3d attestations okay so let's go through these components one by one so blue is the state green is the the blocks so what happens at every every every slot the slot the slot number will increment so you you you read the slot value and you just increment it nothing nothing complicated here and the Genesis time and the fork don't change I mean the fork will change kind of at the social consensus layer but it doesn't change within the state transition function then you have kind of the the header part of the block in green which gets saved into into a data structure and also gets America lies into into block routes so the the beacon chain is kind of aware of its of its block routes and in the past the recent block routes and also recent state routes and it will basically come build from these so called historical routes so this is a historical accumulator which allows you to go back in time arbitrarily far and provide a witness to any part of the state or any part of a block and one of the cool properties of this accumulator is that the witnesses don't change over time so if you have you know a statement saying I know that you know its lot 1,000 the the balance of this validator was this amount well whatever proof you had the miracle path will remain valid forever and then you have the randomness which was explained by dank hat and these is the basic this is the basic scaffolding and the way that the the randomness moves forward is that in every every block the green part you XOR in the reveal into the Randall mix so the random makes just keep keeps on mixing in entropy and and this entropy is kept in the state and it is it sampled every epoch to do shuffling okay then we have the the registry with the validators and one of the things that we've done here as an optimization is we've decoupled the the Val the balances from from the rest of the of the the validated fields and the reason is that the validator fields will change very infrequently whereas the balances will change very frequently so there's a high overhead to constantly be mark realizing what what change is fast and so we want to segregate in one place everything that changes fast and this was covered by Yahweh so in the let's have a quick deep dive as to what was inside these validators so the validators is a list of valid data objects this is what the validator object looks like it has the the public key as you'd expect this is kind of interesting it's the hash of another public key so this other public key is meant to be your with withdraw key that you keep in cold storage so you as a validator you have two keys you kind of have a hot one that you use on the on a day to day basis to sign your attestation and then you have a cold one which you use for withdrawals and transfers and so if you validate a node which is online gets hacked then the hacker cannot steal your funds so that's why it's a nice level of protection for you okay all of this was covered by bi shall we okay so which parts of the systems interact with the registry well we have the deposits so every block in the beacon chain will contain a list of deposits here and these deposits will get processed and then that will create validator entries in the registry but then the beacon chain is to know what is a valid deposit and for that it needs to be aware of the f1 chain so how does that work so in every block we the the block proposal will have f1 data saying you know this this is what I think is the block hash of of f1 around which we need to come to consensus and so this data gets stored in in the state as votes and then at the at a certain epoch boundary these votes are counted and if there is a majority of votes for a specific f1 data this specific f1 data is updated in the state as the the latest snapshot of f1 and the idea here basic basically is on this majority sampling so we have we have the large number of validators that's a million validators we have this honesty assumption that at least 2/3 of the active validators are honest we're going to sample a thousand of them and and the way that this the sampling works is over a thousand sequential slots and if we if this randomness is good enough then we know if high probability that least one half of the f1 voting committee will be honest the voting committee being these 1000 block proposes and and so that means that if we have at least half of the votes here vote for a given piece of data then that piece of data will be representative of reality representative of f1 and and by the way this on this majority idea is reused for cross Nexus as well okay so now I guess comes the the more interesting stuff so the the attestation this is the work that the validators have to do so what is inside an attestation so this is kind of the header of the attestation it has a signature and here it's important that we have the BLS because we have different validators all part of the same committee that will be signing the same attestation and the way that the aggregation works is that we're going to specify in in the aggregation bits here which validators have participated in a specific aggregation so we have a committee let's say of a thousand validators they're ordered and this bit list is going to be a thousand bits each 0 1 1 indicating that the a validator was included in the aggregate signature here for this attestation and then we have the data which is going to be the body of the attestation which is more interesting and it basically has three parts the attestation that when you make an attestation as a validator you're making three votes all in one go and this is part of the reason why this is part of what I mean by harmoniously connecting the various elements this is one one place where we've done it so when you when you make an attestation you you're voting for a a past beacon block and that's going to count towards the focus rule LMD ghost but at the same time you're making a finality vote and FFG vote and so you're going to be vote you're going to be voting for a source target pair and so that's going to lead to justifications and finality and in addition you're voting for a cross link so as a you assigned to a specific shot you meant to download the piece a chunk of the short run it validate it and if it's good then make a cross link so vote vote for that specific chunk of shot so I mean this was covered by Danny basically the the the in the what is a checkpoint here in the FFG vote is nothing more than a pair of an epic and an hash and what is a cross link well the cross link is a small segment of a shot so how do you represent that well you need the shot number you're going to need the start of the end the end Apoc of this chunk of shot that you're cross-linking and you're gonna need the the data roots which is going to represent this can be the merkel is a ssin of the chunk that your cross linking okay so in green we have the attestation in the blocks and then on a slot by slot basis they get stored into the states and they can either get stored in the as previous époque or current epoch attestation so if your attestation is stale it's very old it's older than the previous app book then we don't even bother saving it in state we only record the current and previous epoch at the stations and then and then here we have the the beginnings of the finality mechanism so the financing mechanism works on an epic by epic basis hence the the blue arrow and what it does is that it is going to look at the the cache of recent data stations and then count count the votes and if we if we get to this two-third threshold is go and we're going to record that we have met the two first fresh hold by modifying the justification bit and also by potentially advancing the the last and the previous justified at Bach and then if we have this so-called finality patterns of which we have four as explained by Danny then we're also going to advance the the finalize checkpoints so the the beacon chain is going to be aware of its its last finalized checkpoint and as part as part of this you know as part of the the safety of this this mechanism is the idea of slashing the testers that that make bad votes so how does this work well we have fraud proofs we have proofs that our testers have been doing a bad job these are included in in blocks in green and they're going to have an immediate effect a green arrow on on the registry so if someone has has done / herbal behavior they will be marked as slashed immediately on in the registry and in addition to that would we keep track of the total amount of of 'if that that that was slashed and the reason we do that is because we want to the the we we want to have a mechanism whereby if only a few a testers do bad stuff for example then we they're not really jeopardizing the system so we don't want to penalize them to too strongly but if lots of people are doing bad stuff then the system is at risk and so we want to penalize everyone - to a large extent and so this this variable here in the state in blue is is keeping track of how much bad behavior has happened in the recent past and then we have the cross links and this this works pretty much exactly the well very similar to mmm yeah to to to to this so no doesn't work the same oh no this is different sorry so this is basically is as a mapping from from shard to to to cross link and it records the either the the previous cross links all the current cross links and basically on on an every every epoch hence the blue arrow we would we save the current cross links in the in the previous cross links and that basically allows for the for the beacon chain to be aware of of recent cross links across all the shards and hence for every shot to be aware through the beacon chain of the cross links on on every other shot and yeah this is this is pretty much it so we have the full kind of honest state transition function at a high level again like made out of these modules which are replaceable which talk to each other and at the end of the day there isn't that much happening there's basic scaffolding there's you know maintenance of the registry which is kind of obvious stuff and then there's finality which is a very important gadget and then we have this cross linking gadget for shouting okay great so that's what we're looking to launch in phase 0 but what what comes afterwards we we have transfers which are slated to come likely in in phase 1 which will basically allow for efj on the beacon chain to be and that will create a market for this if now we also have a bunch of security upgrades that we're looking to do and each of these security upgrades are optional but they're very nice to have and you know one of the reasons why we're not putting them up front is because they all have you know fancy constructions and fancy cryptography so one one of them is Cassidy proofs which we're looking to do in phase one we have the idea of secret proposes where instead of knowing upfront who then who the next proposals will be we can have a system whereby we don't know which proposes will be invited to create beacon blocks and that is a way to protect ourselves against in our service attacks because if you know who the next proposals will be then you can target them I didn't add the networking layer we have vdf randomness upgrade which you know my comment phase to my Combinator and then we have data availability proofs and I mean one thing I didn't mention here actually is like clients in infrastructure so we want to make it very easy for for to have a beacon chain like clients and and this infrastructure will come in phase one and we also have [Music] CBC Ghost which is e CBC Casper which I haven't listed here and then kind of to two other ways in which we we may upgrade the beacon chain is to have multi hashing so instead of having one single hash function sha-256 we might add native support for another hash function one which could be friendly to stocks and to stocks and you know later down the line we're also looking to change the various cryptographic primitives which are not quantum secure and change them over to quantum secure equivalents and so this includes BLS 12 381 which is not quite and secure and also the RSA based vdf which is not quantum secure so I guess that will keep us busy for a few years and yeah that's it Thanks [Applause] Thank You Justin I'm gonna close it out talking about the validator duties in or as age says duties I'm talking about the validator duties in phase zero some of this if you actually look at the phase zero state transition spec the validity conditions that Justin didn't go into kind of imply what a validator should be doing but to make that explicit we have the separate dock and when I was compiling my slides I thought that was a good idea so I made a QR code and a tiny URL so this document which I'll go over some of the the core components of it explain what and when a validator should be doing with respect to the beacon chain the initial part of this document talks about creating public keys initiating deposits and a lot of that was kind of covered in sha ways and just will be out of scope for this portion so you the tooth the two main things that you do in phase zero is you propose blocks and you attest to blocks in subsequent phases you would do similar activity but also on chart chains so we have some stuff going on pretty much at any given slot you can say am i the proposer and if you are make a block this can be this is independent of your at the station committee your cross-linked committee assignment and it's Noble within the epoch of of assignment you you don't have a look ahead in a prior epoch which is also different from the committee assignments and the action of proposing a block is is at the the initial start of a slot so slot ten starts I make my block I give it to the world and this is this is your proposal is publicly publicly known and so as Justin talked about secretly to election of something that we're looking at you computing the proposer index is essentially taking all the validators shuffling them and using some some of the recent randomness along with their effective balance to sample them great so you the the chance of you being selected is also proportional to your balance most most validators and normal operating conditions would have an effective balance as we call which is capped out at the max which is capped out of 32 so most in many situations that be an equal equivalent chance of being selected for proposal so Justin are you talked about these data structures the beacon block pikna block body what I do is I reveal my R and L which is a signature upon the epoch I go and find my eighth one data which I'll show you about in a second I signed some graffiti maybe I'll vote on some proposal or I'll say things about Who I am and I fill in any of these operations most importantly I'm gathering up at two stations because that's how I make my block proposal worth it and profitable by including high value add two stations which are add two stations that have not yet been included a decisions that are highly aggregated so it has a lot of participants in them and add two stations that are a more recent by optimizing those things I can optimize my reward I think you get one-eighth of the reward that was given to at a stations for added stations you receive yourself so in general by proposing by being a good proposer over time you're increasing your award by about 1/8 deposits deposits we come to consensus upon the eath one data which is some past eath block and the deposit contract deposit route and this deposit route allows us to process deposits in order of making a proof against that route a merkel proof and this number max deposits is I have to I have to buy the rules of the protocol include deposits any unprocessed deposits up into that max deposit so I think that's the number 16 so if there were 32 deposits that are unprocessed I have to include 16 if there were 2 I include the 2 and then no more if there's zero zero I also voluntary exits might be flying around on the network I can pick those up put them in I'm kind of naturally incentivized to put those in because the fewer validators that exist I'm the functions a little bit dynamic but I get a little bit less overhead and and it's nice proposer slashings and a tester slashings I might also choose to be I might be policing the network looking for nefarious activity and if I find these things submit proof proof of them I get a portion of the I I get a small reward a small amount of what was slashed so we can look into a little bit more into this eath 1 data essentially what this function does is like what I call a pile-on vote like once I see we divide the voting period the youth 1 voting period into a number of epochs and if I see good votes for each one data I just picked that vote and and I and I vote on it some of the some of the mechanism in here is to prevent me piling on to votes that were that were a little bit stale so early on in the period if that's less than the integer square root of the slots per Earth one data period I am will not pile on my vote if it looks like someone was putting in some stale information but otherwise I just vote on what the majority is and is valid if there's no votes [Music] the default I go get my oneth one data and what what we do in this this initial release is that we follow the eighth one chain by like a thousand blocks to be safe this is not the eighth one the beacon chain cannot handle if there were a reorg past that and the eath one chain knows nothing about the beacon chain so this is an assumed safe distance to follow the chain and so you do have like an induced latency on handling deposits because of that I'm not certain what the most deep reorg has ever been in eath one but it's not even on the order of like 100 so assumed to be safe unless there was an attack if there was an attack maybe we should revert the eath one chain instead of the beacon chain because it was attacked but that's mostly cool slash ability to block proposals it's really cheap to sign things so we have to make it but it's as opposed to improve work it's it's very expensive to make blocks that look valid because you have to exert the computational power so if I've been chosen to make a block I need to the protocol needs to make that expensive so that I can't make a ton of them so essentially we have a very simple slashing addition that is making sure that I'm not making too the same block in the epoch actually in a soon-to-be-released version that's changed to me not making the same block in the same slot but essentially it's like a no double vote no double proposal mechanism committees so I don't know if we've explicitly talked too much about committees we talked about like how we shuffle those people into committees but essentially within a given epoch every validator is assigned to exactly one slot to attest to it to create an attestation that they destructor that has all the things votes on the head for the fork choice votes on a cast for every vote votes on a cross link it does all sorts of stuff so I can use this function - essentially query which slot I'm assigned to what shard I'm assigned to and I can do my duty I get a look ahead of at least one epoch so during the current epoch I know my assignment in the next epoch this allows me to sync whatever shard I need to and kind of like get ready for my duty this is actually tunable in Mincey look ahead if we for some reason needed a longer look ahead because the overhead of syncing a chart or something was long we could tune that constant it's a trade-off between a kind of the longer you have you know the committee is the easier it is to potentially dose or bribe or whatever so I make an attestation yeah I had the cursor highlighted so that's why it's green so I make this out to station I do it at the slot might the slot I'm assigned to that time plus half of a slot duration so the ideas and optimal conditions a proposer has created a block at the start of a slot and by halfway through the slot I've gotten that block I see that as the state of the world I vote on it in certain non optimal conditions I might vote on some prior block but I can still kind of add weight as Vitalik showed an in fork choice and I can still manage to we can still keep the chain moving forward and finalize things around my fork choice and I get I see where the head of the chain is the state relative to that head of the chain at the slot that I'm assigned to is also going to give me this information so I can actually just go into the state and say hey what was the checkpoint what are we voting on right now and just pull that information and construct this data this is actually just stubbed in phase zero but this is relative to me running the fork choice on the sharp chain um that's not super important that's actually what I'm gonna put into the crosslink which Justin pretty much covered the fun part is that because it's a zero and there's no short chains so just a zero Hashim because he bit so this is I just want to show you this data structure because even though it phase zero we don't have a notion of sure we don't have any chart chains so we don't have this notion of custody games and having custody of shard data but there is this notion of like a bit in a custody bit which is tied to my personal a personal secret that I have and the attestation the cus of the cross link that I'm cross linking and so I'm not actually signing just the attestation data I sign the attestation data with my bit zero or one and so for any given Committee in phase one we'd have two versions of this aggregate able signature the one with the zero bit and the ones with the one bit in phase zero this is stubbed as a zero bit right but in this outer data structure with the custody bits so we remember we remember who participated with the aggregation bits and we remember which custody bit they participated with so that we can reconstruct the mess the proper message to validate the signature in the future in phase zero when I'm constructing my antis a Shinto broadcast I flipped my bit my position in the shuffling of the committee I flipped that bit and for the custody of its that's all 0 and I broadcast that to the network at the halfway point of the slide let's see there are some micro called micro incentives related to the creation of an attestation it's pretty much the various components of what I'm doing is the head correct correct being defined by what ends up being the canonical chain was the target of the F of G vote correct was the source of the FG FG vote correct the crosslink so pretty much any of these things that end up canonical if I got the vote right I get a good reward and I also get rewarded for fast inclusion this is so the sooner the opposition gets included on chain the more reward and this portion of the world were word degrades very quickly and this is so that I don't I'm not incentivized to like wait a little bit longer see what everyone else is doing before I actually cast my vote I want to move very quickly get my vote in and get maximum reward this is handled in processed rewards and penalties this is maybe not so surprisingly after our Interop session this is where we found the most consensus bugs on our initial networks obviously the calculations that deal with everyone's balances was where we had bugs but then reading writing some new tests and enhancing that getting ready slash ability about his stations this these correspond to the two slashing conditions found in Casper FFG pretty much if it's not the same vote it can't I mean if it's not the same boat it can't be the same the same epoch essentially if you double signed in an epoch you're slashed and you can't do this surround vote so if we have this add to station' that has a source and target we can't have a kind of a surrounding attestation that just like jumps over it that's it cool yeah thank you that was a long session appreciate you all being here [Music] you you