EthCC 2: Justin Drake

okay can you hear me is that working hello testing hello ok it's working ok so my name is Justin and I'll be talking about phase zero specifically Shh the spec of phase zero and even more specifically I'm going to try and and give you a deep deep dive into the the objects that we are building that are part of the beacon change so what is phase zero phase zero is the the beacon chain is this kind of hub in a hub-and-spoke model it's the the system chain for a film 2.0 it has no user transactions and you can kind of think of it as a voting machine so it's a place where we organize the voters that we call validators and we process the votes which are called attestation and we do this in an incentive compatible way with rewards and penalties and then phases one and two which I won't talk about today is the shot so phase one is the data layer for the shots and then phase two is why you add a notion of state and the notion of execution so today is the focus is on phase zero which is the the one piece of it people know where the spec is relatively mature so in the film 2.0 we have this notion of discrete time which we call slots and slots are six seconds so time progresses from left to right and in each slot we can have you know one block so there's one well-defined block proposer who is invited to make one block and usually there will only be one block because if if a block proposal makes two blocks then they get slashed and then some slots you know they can be empty but that's fine you know the beacon changes keeps on going and then eventually you kind of start building this block and you know for every block we have the state that advances so here you know there's nothing nothing in you here the beacon chain is a block chain and then we have this straight state transition which is basically what the specs describe so 95 percent of the spec is telling you how does this state transition work the last little bit the five percent is going to be the so called fork choice rule so the state transition tells you how the blockchain advances in time and the folk to Israel tells you if you have multiple Forks how do you collapse them to one canonical chain so you know this is the object of study in the context of the the abstract spec we have a pre state and a block and then from these two things we want to compute a post state and the both of the states the triangles and the blocks are well-defined objects with a well-defined type and a lot of what I will be spending my time on today is describing what are in these things concretely but before I dive into these two key objects the state object and the block object I kind of want to give you a little bit of background on objects in general like what do we mean by objects how do we define them how do we mark lies them sterilizing etc okay so let's let's go into the background on objects so the way we build objects is that we start with so-called basic types so we only have three basic types it's a very clean very simple we just have UN 64 where we do all the arithmetic it's unsigned we serialize it using a little endian sir ization eight bytes then we have bytes we use this for example for for hashes or blobs of data we also use it for pub keys and signatures you know which are just kind of raw bytes and then we have the boolean which we just use for four flags and then from these three basic types we will start building more complex types with so called composite types and there's also three here very simple so we have the notion of a container which is a bit like an odd like a javascript object where you have key key value pairs and the values don't have to be homogeneous so you can kind of if you have an object for example a block object well you can put all sorts of different things in there and that would be a container it's it has a well-defined size and we use the the the curly braces notation we have two poles which is basically an array fixed size already the elements need to be homogeneous and then we have lists which is the same thing as a tuple but the size could be a variable size so if you want to build an object at the very bottom you have these basic types and then you can build for example lists of U and 64th and you can do the lists of lists and etc so semantically we we use a lot of U n 64 so we have slots epochs shard indexed amount time we always try to use UN 64 everywhere we do we arithmetic and that that's very nice because it is very simple now one thing to mention here maybe is that the the amount that we denominated that we denominator are in a way so that's a one billionth of an ephah and 64 bits is enough to basically represent any balance and the timestamp is is basically seconds so we use a unique timestamp so the notion of epic I haven't talked about that it's basically 64 slots and the index I mean validator index so in the registry of validators every validator will have a well-defined index and then in when we look at bytes we have you know hashes and and and roots so roots will be kind of merkel roots we have pop key signatures bit filled and flags and that's that's the bulk of like the basic objects we'll be working with and then we'll be building even more complex objects with these basic things okay so now let's talk about merkel ization you have an object how do you merkel eyes it so Merkel eyes it means building getting a root sorry okay yes so why do we want to merkel eyes objects so one reason to merkel eyes objects is to get a unique identifier for every every object and the other reason why merkel vocalizing is a kind of a nice data structure is that you can prove an inclusion of a specific field so you have a huge object you know it could be like a close to gigabyte and you want to prove that one specific element is part of your object and you build this merkel path from the from the field to the route and then you know it has all these nice properties about updating the the object so if you change one field element we don't have to rehash everything you just you just have to update the map path anyway so for mac realization we need the basic cryptographic primitives that we need is the hash function we have for example sha-256 we were kind of constrained with two choices and in phase zero either fat 56 or catch AK 256 and the reason is that if theorem 1 does the only two hashes that are well supported natively right now you know we'll see which one we'll pick in the end okay so if I talk about object Mike realization let me talk about the mechanization of just bytes like chunks of bytes so a chunk is let's say 32 bytes and if I have these chunks of bytes if I want and I want to merkel eyes i just add a little bit of padding until I get a power of 2 so 4 is a power of 2 and then I can start vocalizing and I get a root so nothing new here ok so now let's talk about basic object packing so I have these these events for example and I have 5 of them what I do that each event is is 8 bytes so I'm going to pack them as much as possible in a single and in chunks and you know you there might be this overflow so the fifth one kind of is overflowing the chunk that's not a problem I add a little bit of padding to the last chunk and that's that's my packing function that's just a helper to explain how the Americanization works and then the final helper that we have is the kind of mix in length so let's say that we have a list of variable of variable length and we want we have we've done an initial merkel ization but we want to include the length in the merkel root well that's not a problem we just take the the the root we take the length and then we we do one extra layer of hashing and we get the new it and the reason why we want to include the length of lists in when we see realize is that one we want to be able to if we if we don't know the number of elements we want to be able to distinguish kind of padding from zero elements so that the padding just looks like zero bytes and want to make sure that the padding is is not you know interpreted as element and we also want to know how how deep the the Merkel branches should be so we don't want to confuse for example an intermediate node in a in a Merkle tree as an element's we only want to consider the the leaves as we learned okay and then this is how we do a mechanization so there's basically four different options if you have a basic object or a basic tuple or basic list so something that build out of these these basic types then all you do is that you pack and you merkel eyes so you pack into chunks and you micro that's what you do it's very simple and if you and if you have one of these more composite objects what you do is that you recursively merkel eyes the elements you get these roots and then each root can be interpreted as a chunk because it's 32 byte and then you america rise again so very very simple object mechanization and the the final thing is that if you have a list which is the variable size thing then you want to mix in the length and and that is that is all you need to do okay so that's a smirk realization it's very simple very nice and it's part of the what we call a simple serialized spec so when you that's kind of the standard that is used for the various clients to communicate with each other and then the final thing I want to mention in this kind of background on objects is how we do signatures so if we have a a container which need to be signed and we have the notion of a self-signed container a self-signed container has its own signature in the object now a signature cannot sign over itself that would be kind of a recursive thing so what we do is that we remove the signature as step number one if you want to verify the signature too we compute the route without the signature and three we check that the signature matches against the root it's very simple and kind of as a convention that we use in the phase zero spec but you don't necessarily have to use everywhere is to have the signature be the last field so for example the object that's being signed here is a block header and that will be one of the objects that is signed by the block proposer and I will have to be verified okay any any questions so far before moving into the state object so you know this was just background on objects and and you know the state object is where the fun really starts and we can really concrete as to what what the what's in this bag okay so let's look at the state object okay so this is the full state object you know it might look a bit scary at first it it has 29 fields so about 30 fields and you can kind of do this semantic batching of the fields you have seven categories no versioning routes etc and so what would I what I'd like to do is kind of go through every every field and and tell you about it and hopefully give you a bit of of intuition as what's going on and this kind of this this hand-holding will hopefully help you to read the spec if you're not already familiar with it okay so versioning so we have a three different fields here the first one is the Genesis time so we the way that the the beacon chain is is created is that we have the e theorem one chain which allows for deposits of ether into the affirm to chain and the way that it works here is that you you send ether into this burner contract which creates the deposit receipt which can be consumed by the new film to chain and once you have enough of these receipts and specifically once you have two million ether then you can you can start the staking process so if the firm - - chain will both will started its life once we have two million Eva and the Genesis time is kind of scheduled to be at midnight UTC and it's it's scheduled to have at least one one day of security margin after we've reached the two ether and the reason is that we don't have multiple Genesis events we want to have a single clean the Genesis event for film - and so we wait for lots of confirmations on if one to make sure that we have a single one one like kind of interesting quirk here is that the timestamp is you next time so sorry that's for the next day okay slots so if slots is you know this discrete notion of time six seconds it progresses we also have the notion of epoch which is 64 slots so if you want the epoch number what you do is just take slot and divided by 64 one interesting thing about slots here is that it's in a unix time which means that it has leap seconds so technically okay let's measure much better for the sound thank you technically you you can have slots which are five seconds or seven seconds depending on the on the leap seconds and then we have the the notion of a fork so here this is kind of a version name at the social layer in terms of doing hard Forks so we have kind of this this- mechanism which is very nice nice if you want to do a fork and what the folk specifies is number one the the previous version of the fork and the current version and one of the things that we do is that we do signature so we have this domain isolation with the signature so when you when you sign a message that's going to be relative to a fork and so that gives us native replay protection against possible events on the film 2.0 okay let's look at the roots so here there's nothing you know nothing groundbreaking we have the the beacon chain keeps track of its own block roots positive reason there is that it wants to expose them in in the shards because the shot will probably want to use them and it also exposes the state roots you know one question you might ask is isn't you know the block roots sufficient well the answer is that blocks only come you know when they come and we want kind of full granularity of the states so we we put state roots that at every single slot and then we have this this kind of really cool data structure which is the historical roots which is very simple and basically it allows you to to prove that some has some stay true to some block root was a given value at some point in the past so so you see this this kind of separation between the recent stuff we quick with keeping the the latest 8,000 block and state rules and then there's a historical stuff and the way that we build the historical roots is that we we take the the block and the state root and every 8,000 blocks we utilize them and we include one root and the history the the root of that in the historical roots and so basically this this data structure only grows by thirty two bikes one hash every eight thousand slots and so it's it grows extremely slowly and then the latest the other relevant thing in the roots is the latest blog header so we one of the things that we want is when when the block arrives on the on the we want to check that it's previous block root matches the actual previous block roots unfortunately the the previous the previous block root is as part of the header which itself has the state route and so because the state can't refer to this own State Route that would be kind of a circular dependency what we do is that we we actually remove the state route we kind of we blank it out but that's fine because on the on the on the next lot you can kind of recompute the the previous blog header compute the the block route for for that and then check that the the previous block route kind of points the right thing okay so this is a bit technical technicality doesn't really matter okay if one so you know as I mentioned we're using if one to do the economic bootstrapping of if two and we use these deposit from f1 to be two and so at the very least the favor to chain needs to be aware of the film one chain and what we do here is that we have the notion of f1 data so if one data is going to be a block hash that is pointing to and basically a recent block hash in the film one land and it's also going to have a deposit root so the deposit root is going to be the Merkle tree of all the deposits that have been made up to that point in in the in the deposit contract and so the way that we have the film to chain be aware of the film one chain is using a so called you know if one voting committee so we have a thousand block proposes that are invited to vote on what they think is the tip of the if one and if sufficiently many of these proposals agree on what the tip is and that is what we dictate is is the tip and this this is handled by the votes so basically every time a new block comes in that's that casting a new vote for what the e theorem data is and if you reached the the fresh hold which is in this case one half then you basically update the latest f1 data and having this as I said as I mentioned having this the if m2 chain a world if m1 chain is going to be required to process the deposit and we also saw the latest deposit index and the reason why we have that is because we want to process the deposit in order and we also want to force the the validators to actually process deposit if there are deposits to be to be processed okay so this is kind of the heart probably of the beacon chain this is the validator registry so as I mentioned the beacon chain is this voting machine and we have this registry effectively of voters which the other valid and let's have a look at what it means to be a validator so should be a validator you you it means so we have these seven fields for validators and you know validators are such an important object that I'm gonna do a deep dive into those specifically okay so in a validator the first two fields are going to be the pub key and the withdrawal credentials so in a way here we have two separate pub keys two identities per validator we have the the pub key which is going to be your your day to day signing key so if you want to assign a vote in attestation or sign a block or sign a transfer or whatever you will use actually not another transfer block water station you will use your pop key and then anytime you want to withdraw money out of the system we have a separate key and which we call kind of the the withdraw key that is hidden in the withdraw Prudential there we've broken two installs being the hash of this of this withdraw key and the reason we have it is because the pub key as a validator you will it will be a hot key so you need to be online and you need to be signing the messages online and we don't in a few computers hacked as a validator we won't don't want you to lose all your money so we have a separate key which you can keep in in cold storage and you only use it for withdrawal events and these two fields are basically specified in the the deposit transaction that you make on a film one two the deposit contract so once you made the deposit you eventually become rekted once this if one process works and then if your balance is greater than or equal to 31 32 if you get activated and what does it mean to get activated it only it basically means that your your activation epoch is less than or equal to the current epoch and then you have the ability to exit the system so if you know voting on the film 2.0 is not your thing and you want to leave then you can exit and you can issue a so-called voluntary exit message but there's there's actually two other ways that you can exit which are non voluntary which are forced one is through an injection so if your balance gets too low and kind of gets dangerously low then we'll just kick you out automatically and if you do something which is kind of provably bad in the voting process and I'll talk about the various lashing conditions there's only three of them and then that will also force an exit on you and so we have this notion of active validators so the set of active validators are those that are kind of active at the present moment and the way that you check the set of active validators is you just go through the whole registry and you check that the current Airpark is between the activation network and the exit network and then once you've exited you have to wait a little bit and then your withdraw bowl and you can you can send your money out of the beacon change and then we have these two flags just help it flags number one is basically specified if you if you've made a voluntary exit or not and two specifies whether you're busy slash or not the reason why we have the voluntary exit is because if you do a voluntary exit we kind of want to q.

q the voluntary exit so that people don't leave the beacon change too fast and that's helpful for for like clients and kind of weak subjectivity so we want the the set of valid the active validators to remain roughly constant over time over let's say a period of four months and so we have this disc Ewing mechanism so that not everyone can leave at the same time we have the slashed flag because if you've been slashed and we want you to to receive the the slashing penalty which is going to depend on on other people being slashed I'll talk about that later okay so we have the the registry and then another important aspect of the registry which for technical reasons is kept separate is all the balances so we have one balance per validator and the reason why we've separated the registry from the balance is merely an optimization so the registry almost never changes so you know the pub key never changes they were broke gradual never change and the the activation network is kind of a one-time thing similar for the exit app work so this the registry doesn't change that much on the other hand the balances they change at every single epoch because every single validator will get like a micro incentivization like a micro reward or micro penalty and so this this balances structure is going to change a lot that's gonna be a lot of churn and we're gonna have to rehash it and so to have less hashing overhead we separate out the two it's just a technicality we also have we also keep track of the validator registry update epoch so when was the registry last updated mostly technicality here because the reason why we have it is that we have this exponential back-off mechanism which is a security mechanism if if finality doesn't happen often anyway let's just skip that and then we have the active index root so for the purposes of like clients as a light client okay so let's briefly talk about like now how do they work so a lack client is a client that is aware of the state of the beacon chain without having to run all the transactions and the way that it works is that you have a a trusted set of active validators at time T and then you want to know what the set of active validators is at t plus let's say nine days and the way we we do that is that we ask the active validated set from nine days ago to vote on what they think is the the active validator set today and so you can do these big jumps from checkpoint nine days separated separated nine days from each other and in this active indexed routes is basically the the validator registry filtered to just the active validators and that that's what's useful for for lifelines okay shuffling so now that we have this validator it's a very important for security purposes that we shuffle the validator set and so this is the what we have in the state to support that the most important of these field is the first one the the latest random mixes it basically keeps track of the last eight thousand random X's we also have the the the the shuffling seeds so basically I'll talk about the sorry I'll talk about the random mixes later on because it's quite important we we also keep track of the the the seed which is basically going to be the specific random mix that we use to shuffle okay so let me talk let me talk about the shuffling function so we have this seed which is going to be a random mix which I'll explain later and we have the set of validators and we to shuffle them okay so what what kind of properties do we want from the the shuffle function number one we want it to be a pseudo-random permutation so permutation here is quite important it means that every validator gets assigned to two one one unique place and locally computer computable means that if you if you take a specific validator you want in you want to be able to compute where it's been assigned to you without having to compute the the permutation on the whole valid data set and we have this this really nice shuffling function which is called swap or not and I'll just briefly show you how it works because it's actually super simple so let's say you have this the set of validators active validates as one through n these are the ID indices and you want to shuffle them what do you do number one you pick a random pivot so that's going to be a random number between 1 and n based on your seed and then you're going to build these pairs around the pivot and then for each pair you're gonna pick a random bit there's gonna be 0 or 1 and you can this this random bit can be locally computable because what you do is you just take the position of the bit and then you hash it with the seed and you can get this one bit kind of for for position that's that's somewhere somewhere in between without having to compute everything and then when the bit is 1 you will swap the the two elements and if the bit is 0 you don't swap so it's called swap or not because either you swap or you don't swap and then you just repeat this process 90 times so cryptographers have proven that this is a pseudo-random permutation meaning that the permutation that you get after doing this looks like a random permutation so this is what we want it's it's a permutation in the first place because if you want to compute the the reverse you just do the the 90 rounds in Reverse they're like the the reverse operation of the swap is itself and if you didn't do any swap then you know that's already its own inverse and the reason why it's locally computable is because each bit here is locally computable anyway so once we have the active value data set and we have the seed from R and L and we have the shuffling function we can take take the shuffled active validators and we can kind of slice it up so what we do here is that we do slicing vertically in in slots in the 64 slot that's kind of to spread the load over time the validates that could be enormous you know we can have a million validators and so we want to spread the load a little bit over time and we do slicing horizontally basically in such a way that we have exactly 1,024 committees and the reason why we want with 1,024 committees is that we want one committee per shot and the reason why we want one committee per shot is that we wanted to take this this committee and assign them some tasks in a shot and this is this is how we get scaling by the way so this is how sharding works the basic idea of sharding is that we move away from the model where every validator does all the work that has to be done you know for example in an f1 every note does all the computations instead we take the the pool of validators we slice it and dice it and then we as in these very small committees to two specific shots to do some work and each validator will kind of get one single vote per epoch okay and and here's the the the explanation as to why the the idea of having committees works basically we have this honesty assumption so in in the pool the very similar to Bitcoin Bitcoin you know we assume let's say a 51% of the miners are honest well in the film 3.0 we have a slightly stronger assumption we assume that two-thirds of the validators are honest and we have this massive pool which could be for example million validators and we with the sampling mechanism there's this shuffling and dicing we get much smaller committees you know on the order of let's say a thousand validators and if we have this two-thirds honesty assumption then with extremely high probability will have at least one half of the committee which is honest and you can use this basic fact to basically have a voting process where if at least half of the the validators agree on something then this thing must be true because at least one honest person who's voting on that okay so the seed that the epoch in the start all that kind of three things that are required to determine this slicing and dicing of the committee's the star chart is kind of a technicality it has two purposes number one it's to to the add a little offset to the star chart so that you know within a network you you kind of move around the okay that's my technicality and we we store these triples seed Epoque star chart for both the current epoch and the previous epoch because we want to be able to recompute the set of active validators relative to two different from the recent past okay whoo finality so finally is this really nice gadget which we which we have any film 2.0 and it's it's it gives us the notion of economic finality which means that if if something goes really wrong you have to cross links so to finalize checkpoints which are inconsistent with each other then you have a guarantee that a lot of money will be burned specifically one third of the active validators will get slashed and finality is done using these these attestations which are the votes and the one of the important things here for at the stations is the notion of aggregation so we we have these signatures called BLS signatures with very friendly to aggregation and specifically if everyone is voting for the same thing so everyone is signing for the same message then you can just take the sum of these signatures and verify them as if they were one single signature as opposed to being you know a thousand signature then and here you basically get a 1,000 fold increase in scalability so one of the reasons we have so many shards is thanks to this this trick of BLS signatures anyway the attestation data is the important thing which I'll dive in because it is just so important so the attestation is the vote right I mentioned that the beacon chain is this voting machine we have the voters that are the validators and this is what they're voting for and it turns out that the the attestation which is this metal vote is extremely powerful because it contains three different types of sub boats inside it so the first vote is going to be a vote for a single block root in your beacon chain and that is important for the the fourth choice rule so the focus rod has basically assigns weights to every single blocks and very similar to the somewhat similar to the the current focus rule in the film one and in Bitcoin and the reason why we include these this information on chain is because we want to do incentivization of the core of the correct vote so if people have indeed voted for the right block route by right I mean from the perspective from the perspective of a chain then then you get a reward if you if you voted for block route which is different than the current chain that you're currently looking at then you get a penalty we have FFG votes which is for finality and then you have these cross link boats which is used for sharding so cross links are basically the communication mechanism between between the shots the beacon chain is is aware of every shot as a light client and the cross links are basically shard checkpoints that get included in the beacon chain and to become a cross link you need to have the committee assigned to a shot agree on the cross linked data route okay so I'll try to move faster because I don't have that much time there's basically four things that need to be chosen when you vote and each thing basically isn't is as a micro incentivization so if you vote to the right thing you get a reward and if you've wrote it for the wrong thing you lose a lot of money that gets burnt okay so we have justification which is basically the this this mechanism to to [Music] where the whole set of validators tries to to vote on what they think is the the tip of the of the beacon chain and they do so with this with these arrows from source to to target and basically they try different things and if they don't reach the two-third threshold which is kind of this and shrine to first threshold in the in the protocol then the the arrow is dashed and once you do reach the threshold then you get a full arrow anyway this is the the justification process I'll skip over this and then you have the finalization process which is basically pattern matching on on the justification so one when you have two red dots in a row which is to justified epic boundaries then the first one is going to be deemed to be finalized and we you know I can skip over this but basically we have a generalized version of the finality gadget where we actually have two finality patterns and this is the other one and then we have the cross links which is as I mentioned you have every shot is assigned this very small committee small relative to the total validator pool they make these individualized stations these at the stations if they're if that the same they get aggregated and then if you reach the two threshold then you become a cross-linked okay and this is the very last field in the state object thank God latest slash balances so the idea here is called partial slashing so you know what one of the things that we want to to encourage is to become a validator and if there's some sort of software bug in an individual client we you know we don't want that that that poor guy to get completely slashed and lose their 30 to leave so we have this mechanism called partial slashing which says that if there's some sort of isolated incident where you know a few validators it's something bad but the rest of the validator set didn't do anything bad at all then it's actually fine because security is not compromised in any way so we have a very small penalty if on the other hand a very large portion of validators that something slash a ball then we consider this to be a real threat and hence a real attack and so will slash very heavily and the latest slash balance is this we keep track of how many of these slashing events have happened so that you can do the slashing proportional to the recent past okay I only have a few minutes so and I wanna take a few questions so I'll just roughly heard that the block object so this is the block object considerably simpler than the state object and you have the header and the body and within the body you have these two mandatory fields one is used for randomness the random reveal one is used for this voting on f1 and then you have these optional transactions or operations as they some people call them and basically we'll just quickly go through them all so actually in the header here there's nothing kind of magical here so we have the the slot number which is the versioning over time we have the previous block route that allows us to build a blockchain a chain of blocks you have the state route which is the post state route so every block computes us a corresponding state hash merkel eise's it and includes the route in the in the in the header we have the body which is what's below and the signature which is the signature in the context of a self-signed container that i explained at the beginning okay so let's look at the the body so in the body we have the Randall mix this is really important so the way that it works is that it's it's a signature it's a BLS signature and the reason so we used to have it we used to have a hash chain based Randall but now we've used to BLS signatures everywhere and this is really really cool because it makes the the phase zero spec 100% MPC friendly so MPC means a multi-party computation but specifically we want to be friendly to staking pools so if you can't afford 32 Eve and you still want to be a validator while you can put down let's say 10 if with you know 3 3 other people when you get you get your 32 Eve and you can have a to of 3 multisig mechanism and by removing the the secrets from the the commit reveal previous design now now we have these signatures and one of the cool things of pls signatures is that they have the support for you know end of them multisig out-of-the-box so if you have the this the random reveal is going to be the signature of the current epoch which is something that is unpredictable to everyone except the designer so it's kind of local entropy that each signer is kind of sharing to the world is revealing to the world and what we do is that we have to reveal and then we XOR it with the the current so called random acts this is just one line of code which is very nice and just the graphical version is that in one air park you have these 64 block proposals each one of them has the option to either Evie or not reveal their local entropy and then you just XOR everything and so long as you have one single reveal which was not previously revealed then this whole thing is unpredictable which is what we want okay so you then you know we have this if one voting process as I mentioned you have a committee of a thousand proposes and they vote on what they think is the tip of f1 and then if you get this one half threshold then that becomes the the the route that if two considers canonical okay transactions I think I'll just talk about them on this single side because I don't have much time so we have two types of slashings proposal slashing at Tessa stashing proposal session is super simple is just says as a proposer I'm not allowed to make two proposals at the same slot and that's kind of to minimize forking so normally in every single slot you should have just one single block I test the slashing is basically the the the the two stashing conditions in Casper FFG one is called no double vote and the one is called no surround and I'll share this lie so you can look at it but one of the cool things is that with these two static conditions you have safety what the safety mean it means that if there's a fork see here there's a fork and you have to finalize checkpoints like this one and this one because they satisfy the finality pattern well because of the no double vote you can't have a the the target be any of these two crossed out checkpoints and because of the no surrounds you cannot have this surrounding thing because that would surround the the finality pattern on top and so the there's no way that you can kind of connect the dots and so you have at least one third of the validators that get slashed at the stations basically you know these are the votes that need to get included on chain so that they can be processed you have the deposits nothing really interesting here I'll just skip over this voluntary exits basically saying I want to stop being a validator so I leave the validator pool and then transfers this transfer is kind of interesting because for phase zero we you know we have this one-way deposit from f13 to and there's no way to bring the if to back unless you sell it on on the exchange and and this is precisely what transfers allows so it allows for taking your balance as a validator and sending it to another validator and that other validate so it could be like an exchange and that that will basically make if to liquid on the beacon chain before we have the shot where you will then be able to send your balance to okay I think I think that that's basically mostly it one last slide is that the good news is that in this in this kind of 50 minutes or whatever I've covered 37 percent of the spec and the reason is that so I a few days ago I posted this this challenge to try and ride the whole spec in go in 1024 lines of code and Pro soul and I took the talent and basically wrote the whole thing in like three or four days which is extremely impressive I think this will be made public very soon it's extremely readable probably more readable than the spec itself and this is going to be like the this the second or one of two executable specs so we have now the go executable spec which is this one and we have the Python executable spec which Vitalik just basically did yesterday and so we can kind of get these two and compare them and try and find back so this is this is really exciting thank you I'll take a few questions if I have time yeah I will tweet this light so the question is where can I find the slides with with all of this the schemas yes so you you can go on the phase zero spec just search for if your phase zero spec and you'll find that it's on github and you have a question yes here I was wondering how are constants like the two million eath decided how do we decide on having to two million if to start the process yes like how are those constants yeah so these are constant that we can change can have two million if it's kind of something we felt was with large large enough to have a secure system you know it would it would be very unfortunate if we had you know only half a million or whatever because it would mean that the beacon chain would be relatively easily overtake a ball so the main assumption that we have is that you know no more than one-third of the validators are dishonest so if you have only have that say you know half a million if then it only takes a few hundred thousand if to take over the beacon chain so you know Joe Lubin or whatever I could just go ahead and do it any other question okay thank you [Applause] hello everyone sorry just before everyone leaves we have any announcements for you we have we are organizing a city of competition during sorry yeah so we are organizing a city of competition during the HCC it starts today and it's organized by teams like telogen stray lab it's Claro's and also Leger and so you can check the asset twitter to get information about where we