4. Beacon Casper chain by Vitalik Buterin and Justin Drake (Ethereum Foundation)

hello everyone welcome to the next day shorting status whatever this workshop is called hope it will be a you'll find it as happy as the previous days so I guess first of all so I guess first of all like is are there many people here who were not here the previous two days um just to make sure okay so about to I mean yeah so I guess sorry about the oppressing my new pressing the minority is a bit but I will kind of like did you assume somewhat that people some knowledge of how the I guess foreign shorting design works but maybe since today is kind of the development day will focus a bit more on details from the implementations from an implementation point of view so basically if if you're someone looking to develop a Casper in shorting client then from that standpoint it's like what will the protocol look what will developing the protocol be like what sort of and it demands will that end up putting on you so I guess some will start off with just kind of repeating a simple description of the Abeka of the beacon chain so there is a first of all there is the existing proof-of-work chain that we kind of I that we know and love and throughout the like basically the all but the last phase of the Chardon sharding roadmap the existing proof-of-work chain is going to continue to exist and it'll begin to endure continued it it to be a chain as long as the cryptic ets and the gambling IC o---- stay online it will continue having an uncle rate of about twenty to twenty-five percent unless some alex a's optimization work pays off really well but at the same time there is going to be this kind of new beacon chain that starts up right so first of all like in the current set up there is still going to be ace our contracts that lives on the main chain and on the main chain line basically they're being as part of the main chain State there will be this contract and into this contract users will be able to ascend we'll be able to send deposit transactions did that come out well thirty-two we've okay yeah so basically you'll be able to send your 32 eath into the deposit contract along with two other parameters right so the function is gonna have three parameter first of all the fog it's any transaction Cod that's depositing will have to actually contain 32 eath it will also have to specify a pub key and it will have to specify another thing realistic will have to specify a withdrawal address as well though the original spec right basically had this idea of a validation code where you can basically specify some arbitrary program as your pub key and you can specify some arbitrary address for the withdrawal but because especially because we want to do implement webassembly in all of this right we it's probably not a good idea to like bake that in right from the start because the MVM details might change so realistically there's a large chance of withdrawal addresses itself going to be another pub key right so this pub tia is the pub tia that you use for us taking and then you have another update that you use for with that you use for withdrawing right and you might I might have a short ID in here as well might not be specified but this is kind of roughly what it'll look like right so you specify some data and at the very least you have to pop keys and when you up deposit the transaction the transaction if everything is correct we'll end up creating a receipt and this receipt is so first of all any client of the products take beacon chain we'll needs to have at least enough access to the proof-of-work chain in order to be able to first of all know what the block hashes are but seconds know what the receipts are what the deposit receipts have been between any two checkpoints so for a previous take clients being a proof-of-work light client is actually totally sufficient so the beacon chain is going to also exist in parallel to all this it will have because of the address of the attestation mechanism it'll probably have an uncle rate much lower than 25 percent and so this is still kind of in progress but generally at least some proof of stake blocks will have these pointers that basically go back into the main go a point to the main chain and later blocks and the beacon channel points to later blocks in the proof-of-work chain and the idea basically is that if you have if you're processing this block and you see that first of all there is a hard consensus rule that says that the main chain reference of a child has to be either the same or a descendant of the MHz and reference of an of an ancestor so but then when you process this block it'll be part of the consensus rules that you also have to execute this this in this so you also have to execute these three and then into this basically the whoever deposited here would end up adding themselves into the and into the pending validator set that's stored over here right so inside of the beacon chain state you have some validator sets so in the current set in the current spec you have an active alligator set of a pending validator set and an exited validator set and obviously if you join if you deposit then you'll be basically a joint into the pending validator set over here right so then so as a a client's developer of the primitive stake chain line basically needs to have at least the lifeline of the proof-of-work chain you need to be able to process receipts and get a complete listing of receipts and you would need to be able to actually process these beacon chain blocks right so this is kind of fairly abstract structure this so far doesn't really depend that much on the kind of inner details of the beacon chain so I guess first of all any questions at this point is it could be could be implemented as the first stage and so what I was trying to understand that is there any minimal of a set of functionality that could be useful for making and be implemented in the piece or something even smaller can be done hmm okay um you answer first channels and agreeing you know what networking stack will use and implementations would be great right so if you want something to be useful and I think the a proof of stake chain that hooks onto the minimal derivative work chain basically as a minimal components because that's like first of all I do think that the sharding is somewhat more up in the air than the proof of stake side but the proof stake side even without charting will serve the useful purpose of providing a kind of linked finality gadget right so the idea basically is that if let's say inside of here and at some points like this block ends up being a of the beacon chain ends up getting finalized then because this contains this and according to a consensus rule that implement that that is aware of the beacon chain this being finalized is also going to end up finalizing this right so that's probably the smallest components that I would say is useful but like the Perot stake chain is a significant component by itself right this depends like to what extent that's actually possible to write a verifier for the beacon chain inside the proven work chain as like especially if we if in the earlier versions of the spec we're using a yeah like we're using cryptography that's more kind of like RSA or you ought to curve based then snart then Stark based then it should be like it could be designed to be implemented implemented oh what the freaking plows although if we go with the LS 12 381 then no because the main chain doesn't support BLS to all 3d one or we've definitely not efficiently unless you do some ugly hack where you would use BN 256 to make us gnarrk over the BLS well 3d one but that's like horribly ugly example of usefulness I think right yes so shards definitely will have a similar dependency relationship as the the beacon change in the main chain though like as we discussed yesterday we are considering this plan where a shard chain is basically only dependent on the last finalized walk over the beacon chain and the purpose of that is that basically increases the stability of the stability of the mechanism because like basically there is no chance of like the beacon chamber you're competing to Ocean Road chain reorganize I means there's a bunch of code you don't have to write [Music] medium and what Danny answer so much [Music] so [Music] the actor and I respect one of the benefit three kind of above the password contact time is that you have all the heavy lifting that a lanyard so you do now have all so there [Music] like hatches like actually not like using washes as randomness for like any of the test debts that's totally fine because like realistically if it's a test that we don't really have to worry much about attackers and actually if someone doesn't and doesn't like to do random it's been a POA show on the blog cache that would be great because we could see what the effects are the you know I like the other parts of the structure right the parts that have to do with like maintaining the the beacon change state and like producing blocks and so forth I think are definitely implement implementable and useful one other thing the black box by the way is the hash function like to use Blake for an elbow it's something that might end up getting swapped [Music] I am like at least I personally super to continue to be kind of like throw multiple implementations in the sense of like multiple actual implementations of code and I think the reason being that like first of all like we've seen other blockchain strike that have one implementation and even with like iOS right they have they have one implementation there is a bug a week after and like the entire thing just shut down until they get had a totally decentralized phone call and got it back together again so it's um like I don't basically I don't think that especially not for not in the short term we're not kind of slow moving enough to be able to take the Bitcoin the Bitcoin core approach which is like in basically in practice changing barrage it's changing very little and moving slowly so I mean if we want to preserve like a very high degree of network up the instability of which especially as we've seen from the Dass attacks is that like you you can also get a lot of the benefits of this by doing absolutely like basically I like separating the two parts of it out so basically you have a establish that the proof of State clients should basically only talk to the proof work chains through art by clients through our PC and then theoretically they can share a lot of libraries but like the goal would be that if you want to use the Python charting clients together with a gaff note or the other way around and you should be able to and then like if one implementation comes out far ahead of the other ISM you can just use that one implementation plus using whatever other know that these before from the main chain [Applause] sure so one correction is that we're not black boxing the beacon chain wear black boxing terrain or we're suggesting black boxing the random number generator so well I guess with my black box saying what we mean is just like replacing it with some temple some possibly horribly insecure component that still satisfies the same interface and the eye base so look for it and the idea would be that it can be kinda like swapped out with the real with a real component later without changing on any of the rest of the code so for the random number generator like obviously you know we're thinking of five design well okay not five designs two designs and it can be gone but until those designs are perfected you can use you can just use hashes for the hash function you know we've been doing research on like stark friendly hash functions always so you know like arithmetic hash function friendly hash functions generally recently but even before that like basically the like you can outside of the fancy new stuff like I think we both like alike wake to and Blake too is like fairly fast and there's a bunch of libraries for it and we can in it's substantially faster than shell 3 and we can like get rid of this stupid issue we're using a slightly different non-standard version of shell 3 because that's how it has to work we turned out I mean another thing so I guess we could go with the Brewers sub what about in terms of like what in the current plan as it exists a now beacon chain blocks and state are likely to contain now obvious weak details of this change but but it's always kind of enough to give you an idea so mmm yeah so this would be the we can look at the beacon chain state structure Oh quo and we can look at the beacon chain block structure so basically the block contains we'll start off with the block right so the block first of all what it needs to contain right is that it needs to first like first of all the block has a proposer and it means a signature from a signature from the proposer a second a block contains at the stations and you want a because we're using aggregate signatures you want an aggregate signature for the ax testers the block so now also the M this second signature is an aggregate signature which means that you also need a a bit field so you want a basically a a bit field of the testers and the bid field basically is just like a list of bits right so if you imagine you have say 5,000 and testers per block which could totally happen then you meet this midfielder basically just contain 5,000 bits so 600 us so 625 bytes right these signatures size is going to be either 64 96 bytes no matter how big it is and the one other thing that's worth pointing out is that it is theoretically possible to combine together the proposer and the attested signatures so there are like there's totally offered some opportunities for an optimization here so that's proposers and testers blaga testers another thing you probably one outside of this that you'd want is if it is a checkpoints block then first of all you need a a pointer to the parent so you need a pointer to the parent you might also need a a main chain reference so basically this is the pointer to the parents in the vegan chain this is a pointer to some parents in the main chain any other variables that I missed the height possibly Haider SWAT number possibly weakening potentially include both there [Music] yes well that's I mean technically I think that might be the whole thing what else do you need okay so the the the attestation signature in the big field also here's the a distinguisher in the alias station signature in the bid field for the F F G votes and we're hoping for the cross links as well yes yes so like things that we haven't fully finalized yet basically are probably transactions for slashing conditions you know and basically validator penalization and I mean as far as structure goes it might make sense to like include records of including here basically a list of records of what validators joined look technically that's redundant because the information is in the main chain but it would be a good convenience feature because then you would be able to actually fully validate a beacon chain without having the main chain if that's what you want to do so if you do that then that would basically look like you trusting the the validators and the beacon chain to say who the new validators are which is a not a perfect model but one that you could trust if you wanted to so in terms of the size of this right like the bulk of this as you have about a couple hundred bytes here couple maybe a couple hundred bytes altogether the bid field could go up to something like a kilobyte but so in the worst case right so the size of one value ders what is 32 ether and the maximum like for the maximum amount of ether that could exist I'm using as a simplification 132 million which is a two to the 27 and you know this is not a statement of the exact exact ether Hartke hard cap that I wants to impose on everyone with an iron fist it's like a number of something to think it's a like a number to use to kind of keep in your head and think and what that gives you as to the 22 validator slots which is about 4.2 million so with 4.2 million validator slots and then if we assume say a hundred and twenty eight blocks epochs then that goes down to a two to the 15 so a 32,000 validators get included inside of every block which is baten 32,000 bits basically means these block these walk headers are going to be is something like five kilobytes and this has five kilobytes that's coming in like every few seconds so like it is so the block the chain in this in this particular structure like it it definitely would be kind of like heavier as a good way heavier than the current aetherium header chain which is 500 bytes every 15 seconds though in practice it's not going to go up to 5,000 actually will be like 500 bytes every five seconds and a one area of research is also thinking about it like is there a possibility of designing the system so that a white clients can get by with some subset and I think the answer is maybe but it's not clear that that has to exist in the form of a chain like that could also exist in the form of a structure where say every checkpoint vlog has to point to the previous checkpoint block so you could download just the chain of checkpoint blocks and then you would basically use just the validators at the checkpoint height as a kind of proxy for all of them for all of the validators so like there are like these are like details that we're thinking about but not finalized yet [Music] pointer to the main chain there's no point well so remember the only case where the beacon chain contains pointers to shards is where you have a cross link and so like basically the idea is that these signatures are going to simultaneously be signatures of data where the data can be calculated but basically you can in the structure in Mike you might end topics you're wanting to explicitly include like a list of what checkpoint hashes hashes people are voting on right so basically you have this harriet signature you have the bid field and then you'll probably also want to have a list of checkpoint hashes and the checkpoint hashes ultimately do kind of go above and they attest to shard blocks then you can like basically like to sign the hash of 42 as a checkpoint hash and we can keep doing that until we're ready to have real short chains of all look there is the discussion of you know how big are the rewards gonna be and like will there okay it proved a stake requires a much lower rewards than proof of work so I think like the community should know like as I've said before think about like eventually going down to zero issuance and having a supply cap but even if it doesn't right that basically me even let's say worst-possible-case scenario park it requires six million either issued every year which it totally votes but that's the current issuance then the number one basically the activity or the amount of effort needed to process the beacon chain will only go up by six percent a year and that's not multiplicative thats not exponential it's linear so like it was the Moore's law totally be a gets it out basically the idea is that there is no possibility of general-purpose computation happening on the beacon chain right because the beacon chain is not a chain on which like the aggies activity happens in the sense of what people like and you know end-user activity happens so all you have on here as hash verification like right now be a less signature of verification and a random beacon verification eventually stark verification and that's it the one thing you can do is you can sign for a cross the link that like nobody else is signing for and so one thing that we haven't fully figured out here is like basically how do we need to and it's so kind of how to impose the limits on the load if lots of feel like pretty much everyone is voting for a different different cost link hash but that's only impossible and like the worst case and there are like one thing we could do is we could just to limit the number of carts across link hashes per block and so if you're really really part of the minority you just don't get it good [Music] when the main chain goes away they have to exist somewhere anyway first of all if we want super minimal then we don't even need penalties right because in the super minimal case like basically nobody can withdraw and technically you don't have to implement slashing until you allow people to start withdrawing you would know because like well in the design in the idea that I just suggested you would know because the vegan chain would contain records of what the of who the new depositing validators are every time the median reference changes but like you would have to trust that if you're not validating the main chain yourself okay [Music] right in this design there's no Tulpas hop upstairs just 32 wheat deposits [Music] and then in the block you would contain kind of like a reveal messages and like there could be R and L reveals it could be like PDF solutions and proofs you know so there would be a reveal message in here I guess some I'm not drawing now or drawing it now but you can leave it kind of like empty slot as you know like some white field and for now like it can be empty but right we do but well so I guess like the simplest black box random number generator that you can think of doesn't require any reveals at all right well I guess what you could do is you could just like have a salon for reveals and then what block producers will reveal whatever they want that's the other sort of that's the other stubble you can make it goes in the block it goes in the block and then you would have our sorry and G stayed there so you would have so RNG state is definitely part of the state of the beacon chain it could or could change every dynasty so I personally like to split the state up into kind of two parts that I call I mean in the spec I call it active and crystallize but it's basically a kind of quickly changing information and slowly changing information so the quickly changing information basically is so number one you have the RNG number number two you have basically Asia like various different bit fields so you would have a you would have a bid field of like basically who participated at what height and like you might also have bit fields of who participated at each cross link so basically and you might have a series of cross you'll have a series of cross link hashes that people are trying to submit the bit us so you'd have bit the bit field at different heights which also doubles as the cash graph of G bid field so this is all basically storing like who participated bid field over here then let's see what else would you have bid field at build fields of cross links I remember the active state being very Caribbean being very small right you know you would have you would have RNG data you would have right so data related to across records of cross links in progress that's not short term that's long term data yeah oh yes so then long term data's more interesting right so long term data you basically first of all you have validator sets so you have active validators you have and you have pending validators and then you have possibly exited validators so exited validators or just validators awaiting withdrawal so active alligators are valid is that Ark active right now pending validators or validator sort of logs on but they've or that have deposited but have not been inducted so you might have to equate one dynasty to get inducted and exit evaluators are valid leaders at which jurors that are waiting either withdrawing or getting slashed depending on how nice day war or possibly some combination of the two so for each of these right you have a basically you have a validator record and the validator record might contain but first of all it contains the pub key i'm your pub pious it contains your balance and real really might contain rng private state depending on what the depending on what the rng ends up being oh yeah looks terrible they really should write teach me writing in school more useful than cursive hmm what else do they have like basically it's like when I did the calculation all together it's something like a honey it's like a hundred bytes per validator so it's very little [Music] so from the point of view of the execution engine like the thing that matters is obviously first of all like what what information is a particular step a particular part of the system allowed to have an information about what so that basically is determined by the cross linked structure the I mean it would also get environment variables so like for environment variables you have in wash timestamp book for you you might want to allow up codes for random number state and all that so like basically just for that assume that there is like environment data that and the short is aware of the environment data from the beacon chain and from the last point of finality and then the short is obviously also aware of the area of the environment data of itself pretty much instantly there isn't sayin whatever the incentivization of the execution is like depending on I guess how fine-grained the incentivization ends up being it could either happen on the beacon chain so you want like penalties on to be a big penalties on the beacon chain or you could you incentivization inside of shards if you have like penalties that have to be applied to every one every block or rewards [Music] with what what date are you thinking oh yes well so proof of custody challenges would actually go here right they would go in the blog and like prove custody itself doesn't need to have a large state sighs mmm does it I mean I get that in in this part of the state in the validator state you probably want like a you probably want proof of custody seed commitment so we'll just like say I like commitments and then he OC [Music] yeah I don't expect stuff like that to be a source of massive bloat and also like keep in mind that the like the size of Leah crystal I stayed all together in the kind of like the worst case is gonna be something like 400 megabytes and it all expected to be possible to make enough challenges to get anywhere close to that the active state is somewhere in the okay the active state is mainly a bunch of bit fields so the active state might only go up to the hundreds kilobyte range so like basically from an implementation point of view like all of this would just be a big long thing in RAM and I don't know what she'll the active state into an l1 cache or whatever if you care about optimization the though I expect like basically in terms of like cost of computation and processing right you're gonna have a lot of bit field manipulation and a lot of hash checking so up to or and a lot of in a lot of BLS signature verification so just and a lot of like randomly fetching public key is from the crystallize State so just optimize for that right yeah now I mean that said you know we are considering designs where vdf like submissions only get submitted once every a Polock instead of once every block which would basically mean that sometimes you have negative EF blocks but it gets advertised yeah I will add though so if we're using even starks for the vdf that having the starks be big doesn't matter much if we're using like big constructions for the signature aggregation that is a bit that is a bit more of a problem I will look from a from a development point of view right like there's things that are easy to change on the fly and there's things that are difficult to change on the fly so adding parameters to header structure like especially if you just have one implementation you know care about consensus is fairly easy right so I don't know I figured eonni is already I capable that said at least some of the changes to the specs that I made since I since I wrote up that proof-of-concept code right so like in general like as far as basic structure goes I feel like like yes you know like some parts of the active state in some parts of the crystal I state are not finalized but that's not the sort of thing that it would take like a month delays if we end up rethinking it whereas if we end up rethinking you know the whole concept of the beacon chain and it's gray and its particular type of relationship wasn't maintained and now it's the sort of thing that would cause most like more than a month of delay so it gets like at this point I feel like the concepts are definitely more crystallized than the implementation details and that's in part because we realize that crystallizing the concept as it was probably what matters more in terms of providing kind of development stability than crystallizing the or like specifying exactly what what all the 32 byte hashes look like in what the alignments are this correct this said does not need to have a body now possibly right so it depends on the design so for example over here right you basically just include the if we're gonna do the optimization or we combine together the procore signature and the aggregate signature then you can't be revived the proposer without verifying everyone else and so then like basically you can't have a concept of header whereas like if we don't do that then you do have a concept of a header another thing worth so like that is one trade off and then the other question is like by having headers who are we trying to serve anyway right and like my answer is we're trying to serve like clients but there might be other ways to serve like clients such as for example on basically having a blog parent structure where you can verify a subset of the chain instead of value verifying the full chain if you want to [Music] I think that you need to standardize everything before it makes sense to start development right so like if for example your goal is to have like a toy that you can run as a proof of concept and show and like show people that your team is great and sharding is great then first of all you definitely don't have to worry about validator rotation you definitely don't have to worry about penalties you definitely don't have to worry about proof of custody challenges or even proof of custody at all you can just implement a structure that has some static or at least like static and only growing validator set and you can just like basically do whatever the minimal structure is for FFG messages and then implement that and that would you know it would work it would have a lot of the prot of the properties that we're looking for and then the other components can be sort of added on over time