An article to understand the creation of the beacon chain

Author |Ben Edgington

Author |

As for Ethereum 2.0,Medalla TestnetMedalla Testnet

Already launched on August 4th, this is likely to be our only official rehearsal before the release of Ethereum 2.0 in the second half of this year.Eth2 annotated specThe creation mechanism of Eth2 is a bit complicated. Creation is a process in which a blockchain system injects life into itself. I will explain it as accurately as possible in plain language. As for a really technical explanation, the reader can find the

See my notes above.

In the following, "genesis event" refers to the exact time when the beacon chain starts up and starts processing proofs and blocks. It is also the time when slot 0 epoch 0 starts.

(If readers want to see a quick overview, they can skip directly to the "Two Cases of Creation" section below)

validator depositLaunchpadFirst of all, a bit of background knowledge that readers need to know is that validators need to deposit deposits into contracts on the Eth1 blockchain before joining Eth2. For each Eth2 validator, they need to send 32 ETH and some other data to the contract. For example, readers can access the

The website sends deposits and data to the Medalla testnet. Remember that Medalla is now using ETH from the Goerli testnet! Do not send mainnet ETH to the contract. Of course, when the real beacon chain is released, we will use the ETH of the main network.

Next, we only care about valid deposits: a single deposit of no less than 32 ETH, or multiple deposits belonging to the same validator totaling no less than 32 ETH, for which additional data verification (cryptographic signature ). Any invalid or insufficient deposits will be ignored in Genesis

beacon node

Before creation, only beacon nodes were active on the Eth2 chain; after creation, verifiers will become active immediately. Beacon nodes maintain the state of the system and communicate with each other in a peer-to-peer network.

Therefore, before the creation of the world, there were a large number of beacon nodes watching the Ethereum 1.0 blockchain and paying attention to the valid deposits on the deposit contract. They don't need to keep an eye on it 24 hours a day, because Eth1 blocks are time-stamped, so nodes can keep up-to-date at any time before genesis.14 * 1024Now, everyone knows that Eth1 blocks can be rolled back and change their minds about which transactions are valid. This is why you need to wait 30 blocks when transferring ETH on the exchange. The scope of the rollback is usually very small - about one or two blocks; but in the event of a network attack, the scope of the rollback can become very large. In order to avoid this situation on Eth2 as much as possible, we are very careful to keep

Seconds of delay, about 4 hours. I call this the synchronization distance of Eth1 (Eth1 follow distance)

when? who?

Two questions about genesis "when?" and "who?": when will it start, and who will be in the genesis block validator army. The answers to these two questions define the genesis state of the beacon chain, from which all other states are derived.

1. The general process is as follows:

2. Follow deposits on the Eth1 blockchain

3. When enough time has elapsed and the deposit reaches a certain amount, the genesis state is created

Two days later, start the blockchain at genesis time

1. In step 2, we need to pay special attention to two points when looking for the first block on Eth1:

2. whether there are sufficient deposits;

Is it too early.

The first block that meets these two conditions will be set to the genesis state.

1. MIN_GENESIS_TIMETime and role are affected by the following three key parameter settings.1596546000Unix time——UTC time 13:00:00 on August 4, 2020, adopting the RFC2822 specification.

2. GENESIS_DELAYyes172800yes

3. MIN_GENESIS_ACTIVE_VALIDATOR_COUNTseconds, exactly 48 hours. This is the time interval between the creation of the genesis state and the initiation of the blockchain and genesis events. This delay is to allow client teams to write the genesis state into their beacon nodes so that they no longer need to follow the Eth1 blockchain even if they are not running validator nodes. This also leaves time for hosting general genesis event streams and meetup events.16384is the minimum number of active validators we need in the Eth1 deposit contract before creating the genesis state. On the Medalla testnet (and mainnet), this parameter is

verifiers.

The Two Situations of Creation

The genesis state is based on the first Eth1 block that meets the following two conditions:

1. The first Eth1 block on which the genesis state is based needs to meet the following two conditions:

2. At least 16384 (MIN_GENESIS_ACTIVE_VALIDATOR_COUNT) validators have registered on this or previous blocks; and

Its timestamp will not be too early (not earlier than MIN_GENESIS_TIME – GENESIS_DELAY).

According to the order in which these two requirements are met, the creation process will proceed in the following two cases:

The number of deposits is met first

In this case, condition 1 is satisfied first. Sufficient deposits we received before the earliest genesis time.

The Medalla testnet time point between MIN_GENESIS_TIME – GENESIS_DELAY is Sunday, August 2, UTC 1300.

Our start block is the first block on Eth1 mined after this time, that is, mined at 13:00:05 (5 seconds after 1pm).

If the valid deposits received by the deposit contract for this block reach or exceed 16,384, all deposits received so far will be included in the genesis state. Therefore, the number of validators could be much higher than 16384 (on the Altona testnet we set MIN_GENESIS_ACTIVE_VALIDATOR_COUNT to 640, but it turned out to have 685 genesis validators)

This Eth1 block starts the calculation of the creation state, and the creation event of Medalla will start exactly 48 hours after the block timestamp. In this example, it would be 13:00:05 on Tuesday, August 4th.

Note that we don't really know the genesis state until 4 hours later due to the Eth sync distance. That is, in this case, we know the genesis state of the Medalla on Sunday, August 2nd at UTC1700.

Summarize

Summarize

The genesis event will start a few seconds after the earliest genesis time if the deposit amount meets the requirement first. The genesis state includes all registered validators 48 hours before this point in time.

2. The timestamp meets the conditions earlier than the deposit number

This happens when condition 2 is met first. The number of deposits increased slowly and did not reach the minimum effective amount within the predetermined time.

In this case, the Eth1 block packing the 16384th deposit becomes the start block. We assume that this block was mined on Wednesday, August 5 at 12:34:56 UTC.

Now, the block state will contain 16384 validators and any other valid deposits in that block. Therefore, if that block contains multiple deposits, more validators than the minimum deposit will be included.

The genesis time will be the block's timestamp plus 48 hours. In this example, Friday, August 7 at 12:34:56 UTC.

Also, due to the Eth1 sync distance, we do not know the genesis state or genesis time until 4 hours after this Eth1 block was mined.

Summarize

If the deposit growth is slow, the genesis event will start 48 hours after the Eth1 block containing the 16384th deposit is mined. The genesis state contains 16834 validators, plus some other validators in the same Eth 1 block.

in conclusion

in conclusion

The article is written here, have you already understood the basic situation of the creation of the beacon chain?

Looking forward to seeing you all at Medalla!

Disclaimer: ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprints must indicate the source of the original text and ethereum.cn. For long-term reprints, please contact ethereumcn@gmail.com Authorize.