The Genesis of a Beacon Chain

--- tags: explainers description: Exploring the Eth2 beacon chain genesis process image: https://benjaminion.xyz/f/favicon-96x96.png --- # The Genesis of a Beacon Chain ![My avatar](https://benjaminion.xyz/f/ms-icon-144x144.png =32x32) Ben Edgington ([PegaSys](https://pegasys.tech/), [ConsenSys](https://consensys.net/) — but views expressed are all my own) _31 July 2020_ You don't get to kick-off huge, distributed, multiclient blockchains very often. Yesterday was five years since the genesis of the Ethereum 1.0 chain: truly significant genesis events are few and far between. As for Ethereum 2.0, the [Medalla testnet](https://github.com/goerli/medalla) is due to go live on August the 4th, and it is probably our one and only dress rehearsal before the real thing later this year. There's a little bit of complexity involved in the Eth2 genesis mechanism, which is what we call the process of a blockchain bootstrapping itself into life. I'm going to try to walk through it precisely, but gently. For the actual technical specification you can see my comments in the [Eth2 annotated spec](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/#genesis). In the below, "genesis event" means the exact time at which the beacon chain starts up and begins processing attestations and blocks. It is the beginning of slot zero of epoch zero. (Skip down to [Scenarios](#Scenarios) if you want the tl;dr.) :::info Update: the Medalla beacon chain Genesis occurred at 13:00:08 UTC on the 4th of August, with 20084 genesis validators. This is "Scenario 1" below - deposits came in quickly! ::: ## Validator deposits The first bit of background is that validators get onboarded into Eth2 by making deposits into a contract on the Eth1 chain. For each Eth2 validator, 32 Eth needs to be sent to the contract along with some other data. You can do this for the Medalla testnet via the [Lanchpad](https://medalla.launchpad.ethereum.org/overview) portal, for example. Please note that for Medalla we are using Goerli testnet Ether! Do not try to send mainnet Eth to the contract. Of course, for the full beacon chain launch we will be using proper mainnet Eth. In what follows, we are only interested in _valid_ deposits: single deposits of 32 Ether or more, or multiple deposits for the same validator that add up to 32 Ether or more, for which the extra data checks out (such as the cryptographic signature). Any invalid or too small deposits are just ignored for genesis. ## Beacon nodes Pre-genesis, the only active players on the Eth2 side are the beacon nodes; the validators spring into action immediately _after_ the genesis event. The beacon nodes maintain the state of the system, and talk to each other in a peer-to-peer network. So, before genesis, there are a bunch of beacon nodes listening to the Ethereum 1.0 chain, watching the deposit contract for valid deposits. They don't actually need to be watching the whole time: Eth1 blocks are time-stamped, so nodes can catch up with the action at any time before the genesis event. Now, it is known that the Eth1 chain can revert, and change its mind about which transactions are valid. This is why exchanges make you wait for 30 blocks or so when transferring Eth in. Reversions are usually very small - one or two blocks' worth - but in the case of an attack on the network could be much bigger. We avoid having to deal with this in Eth2 by following the Eth1 chain with a very cautious delay of [14](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/#seconds_per_eth1_block) * [1024](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/#eth1_follow_distance) seconds, which is roughly 4 hours. I'll call this the Eth1 follow distance. ## When and Who The two big questions for genesis are "When?" and "Who?": when will it occur, and who will be in the cohort of genesis validators. Together, these define the genesis state of the beacon chain, from which all other states will be derived forever. The rough process looks like this: 1. Watch the Eth1 chain for deposits coming in. 2. When enough time has passed and enough deposits are in, create the genesis state. 3. Exactly two days later, start the chain with a genesis event. Specifically, in step 2, we are looking for the first Eth1 block that has both (a) enough deposits, and (b) is not too early. The first block that meets both conditions is the one that sets the genesis state. There are three key parameter settings that affect the when and who outcomes. - [`MIN_GENESIS_TIME`](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/#min_genesis_time). This is the earliest time that the genesis event can occur. For Medalla, it is [1596546000](https://github.com/goerli/medalla/blob/master/medalla/chain.yaml#L8) in Unix time, which is Tuesday, 04-Aug-20 13:00:00 UTC in RFC2822 time. - [`GENESIS_DELAY`](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/#genesis_delay) is [172800](https://github.com/goerli/medalla/blob/master/medalla/chain.yaml#L25) seconds, which is exactly 48 hours. This is the interval of time that will elapse between the creation of the genesis state and the chain starting with the genesis event. This delay is basically to allow client teams to bake the genesis state into their beacon nodes so that they no longer need to watch the Eth1 chain if they are not running validators. It also allows time to organise genesis event livestreams and parties in general :smile: - [`MIN_GENESIS_ACTIVE_VALIDATOR_COUNT`](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/#min_genesis_active_validator_count) is the minimum number of valid deposits we need in the Eth1 deposit contract before we will create the genesis state. For Medalla (and the mainnet) this is [16384](https://github.com/goerli/medalla/blob/master/medalla/chain.yaml#L7) validators. :::info A lesson learned from the Medalla launch: while we got [the party](https://www.youtube.com/watch?v=PvQdZ74i7Xw) organised in time, 44 hours was a bit tight for making sure the bootnodes were good, and updating client software with all the necessary info to make it easy for end users. We may increase `GENESIS_DELAY` for the mainnet launch. ::: ## Scenarios The genesis state is based on the first Eth1 block that satisfies both of the following conditions: 1. at least 16384 (`MIN_GENESIS_ACTIVE_VALIDATOR_COUNT`) validators must have been registered by this or previous blocks; and 2. its timestamp is not too early (not earlier `MIN_GENESIS_TIME - GENESIS_DELAY`). Depending on the order in which these two requirements are satisfied, we end up with two ways that the genesis process can play out. ### 1. Deposits come in quickly In this scenario, condition 1 is met first. We have enough deposits sufficiently in advance of the minimum genesis time. Consider the point in time `MIN_GENESIS_TIME - GENESIS_DELAY`, which for Medalla is 1300 UTC on Sunday the 2nd of August. Our trigger block is the first Eth1 block that is mined after this time. Let's say it is mined at 13:00:05 (five seconds past 1pm). If the deposit contract has received at least 16384 good deposits up to and including any in this block, then _all_ of the deposits so far received will be included in the genesis state. Thus, there could be many more than 16384 genesis validators. (On the Altona testnet, we set `MIN_GENESIS_ACTIVE_VALIDATOR_COUNT` to 640, but ended up with 685 genesis validators.) This Eth1 block triggers the computation of the genesis state, and the Medalla genesis event will occur at exactly 48 hours after the block's timestamp. That is, at 13:00:05 on Tuesday the 4th in this example. <img width="529" height="236" alt="Deposits come quickly" src="https://benjaminion.xyz/images/200802_genesis_0.png"> The red block is the first Eth1 block that satisfies both requirements. (Not to scale.) Note that, because of the Eth1 follow distance, we won't actually know the genesis state until about four hours later. That is, in this scenario, we will know the genesis state for Medalla around 1700 UTC on Sunday the 2nd of August. #### Summary If deposits come in quickly, the genesis event occurs a few seconds after the minimum genesis time. The genesis state includes all validators registered earlier than 48 hours before this time. ### 2. Deposits come in slowly This scenario occurs when condition 2 is met first. Deposits have come in slowly, and have not achieved the minimum number by the appointed time. In this case, our trigger block is the Eth1 block that contains the 16384th valid deposit. Let's say that it is mined at 12:34:56 UTC on Wednesday the 5th of August. Now the beacon state will contain 16384 validators plus any other valid deposits in that block. So there could still be a few more than the minimum if that block contains multiple deposits. The genesis time will be the timestamp of that block plus 48 hours. That is, 12:34:56 UTC on Friday the 7th of August in this example. <img width="529" height="236" alt="Deposits come slowly" src="https://benjaminion.xyz/images/200802_genesis_1.png"> The red block is the first Eth1 block that satisfies both requirements. (Not to scale.) Again, due to the Eth1 follow distance, we won't know the genesis state or genesis time until around 4 hours after this Eth1 block was mined. #### Summary If deposits come in slowly, the genesis event occurs 48 hours after the Eth1 block containing the 16384th deposit. The genesis state includes 16834 validators, plus maybe a few more that were in the same Eth1 block. ## Conclusion That pretty much covers the bases :slightly_smiling_face: Bottom-line: if you want to be sure of being in the genesis cohort of validators for the Medalla testnet, get your deposits done by 1300 UTC on Sunday the 2nd of August! If you don't make it before the genesis state is decided, your validators will be put in a queue based on deposit time, and will slowly be inducted into the validator set after genesis. Getting through the queue could take a few hours or days. Looking forward to seeing you on Medalla! :rocket: