Popular Science: The Genesis Process of the Beacon Chain

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: ethfans)

Ethereum enthusiasts (ID: ethfans)

, Author: Ben Edgington, translation & proofreading: Min Min & A Jian, reprinted with authorization by Odaily.

Large distributed multi-client blockchain launch events are uncommon. Yesterday (July 30) was the 5th anniversary of the birth of ETH 1.0: it can be seen that such a major birthday event is even rarer.

The ETH 2.0 genesis mechanism is a bit (what we call the blockchain bootstrapping process) complicated. I'm going to explain it in detail. For the actual technical specification, you can see my comments in "ETH 2.0 Specification Notes".

In the following, "genesis" refers to the moment when the beacon chain goes online and starts processing attestations and blocks, that is, the beginning of slot 0 of epoch 0.

(If you don't want to read the long article, you can jump directly to the "Scene" section and start reading.)

Validator deposit

Here is a little background first. Anyone can become an ETH 2.0 validator by sending a deposit of 32 ETH and some other data to the ETH 1.0 contract. For example, you can become a validator on the Medalla testnet through the Lanchpad portal. Note that on the Medalla testnet, we are using the Goerli testnet ETH! Do not try to send mainnet ETH to the contract. Of course, when the beacon chain is officially launched, we will use the real mainnet ETH.

Margin contracts will only react to valid deposits, i.e. single deposits of 32 ETH and above, multiple deposits of 32 ETH and above in total (additional data to be checked, e.g. cryptographic signatures). Any invalid or insufficient margin will be ignored.

first level title

In the pre-creation phase, only beacon chain nodes will participate in the ETH 2.0 network; once the creation is complete, validators can immediately participate in the consensus mechanism. Beacon chain nodes maintain system state and communicate with each other on a peer-to-peer network.

Therefore, before genesis, there will be some beacon chain nodes listening to ETH 1.0 and monitoring the effective deposit in the deposit contract. In fact, beacon chain nodes don't need to monitor ETH 1.0 all the time: blocks on ETH 1.0 are timestamped, so nodes can catch up anytime before genesis.

As we all know, the ETH 1.0 chain can be rolled back, and transactions that were already on the chain may also become invalid due to changes in the blockchain. This is why when you transfer ETH to an exchange, you need to wait 30 blocks to ensure that the transaction is confirmed. Rollbacks are usually small - just 1 or 2 blocks - but when the network is under attack, the rollbacks are much larger. In order to avoid a rollback of ETH 2.0, we are very careful to maintain a delay of 14*1024 seconds (about 4 hours) when synchronizing ETH 1.0. I call this the "follow distance" to ETH 1.0.

first level title

1. when? who?

2. For creation, the two most important questions are "when" and "who"? Specifically, "When will genesis happen?" and "Who will be the genesis validator?" These two questions determine the genesis state of the beacon chain, and other states are derived from the genesis state.

3. The general process is as follows:

Monitor margin inflows on ETH 1.0.

After waiting long enough, with enough margin, the creation state is created.

• Two days later, ETH 2.0 is launched by triggering the genesis event.

• Specifically, in step 2, we want to find the first ETH 1.0 block that satisfies the following two conditions: (a) enough margin is locked; (b) the timestamp in the block is not too old. Genesis state is determined by this block.

• The three main parameter settings that affect "when" and "who" are as follows:

MIN_GENESIS_ACTIVE_VALIDATOR_COUNT refers to the minimum number of valid deposits we need to lock in the ETH 1.0 margin contract before creating the genesis state. For Medalla (and the mainnet), a minimum of 16384 validators is required.

Scenes

Lesson learned from Medalla testnet launch: While we have time to organize the party, 44 hours is a bit of a stretch to ensure that the launch node is in good shape, that the updated client software contains all necessary information, and that it is easy for end users to use rush. We may increase the GENESIS_DELEY for mainnet.

1. first level title

2. Scenes

When this block is created, the number of validators must not be lower than 16384 (MIN_GENESIS_ACTIVE_VALIDATOR_COUNT).

The timestamp is not too early (not earlier than MIN_GENESIS_TIME - GENESIS_DELAY).

According to the order in which the above two conditions are satisfied, the genesis process can be completed in the following two ways:

secondary title

1. Meet the minimum margin requirement first

In this case, condition 1 is satisfied first. Before the earliest genesis time, we have obtained enough margin.

The ETH 1.0 block we used to trigger the genesis event had to be mined after this point in time. Assume that this block was mined at 9:00:05 pm on August 2, Beijing time (5 seconds after 9 o'clock).

If the margin contract has received at least 16384 effective margins (including all margin transactions in this block), then all margins received in the margin contract are also included in the genesis state. Therefore, there are over 16384 Genesis validators on the ETH 2.0 chain. (On the Altona testnet, we set MIN_GENESIS_ACTIVE_VALIDATOR_COUNT to 640, but the last genesis validators had 685.)

image description

Summarize

One thing to note is that considering the ETH 1.0 follow distance, we actually have to wait 4 hours before we get the genesis state. In other words, in the current scenario, we have to wait until 5:00 pm on August 2, Beijing time to obtain the creation status.

Summarize

The genesis event will trigger a few seconds after the earliest genesis time if the minimum deposit requirement is met first. Validators who registered 48 hours before the genesis event will be included in the genesis state.

secondary title

2. After the minimum margin requirement is met

In this case, the ETH 1.0 block we use to trigger the genesis event must contain the 16384th valid deposit. Suppose this block was mined at 8:34:56 pm on August 5th, Beijing time.

Now, the beacon chain state will contain 16384 validators and other valid deposits in this block. Therefore, if this block contains multiple deposits, the deposit included in the beacon chain state will be slightly higher than the minimum requirement.

image description

Summarize

Summarize

in conclusion

If the deposit inflow is slow, the genesis event will be triggered 48 hours after the mining of the ETH 1.0 block containing the 16384th effective deposit. The genesis state will contain at least 16834 validators, and possibly a slight increase due to the number of margin transactions included in this ETH1.0 block (bringing the total number of validators above 16834).

first level title

in conclusion

This article has introduced the basic content of the ETH 2.0 creation mechanism.