Popular Science | Eth2 Beacon Chain: What You Should Know First (2)

Author: ethos.dev

Translation: A Jian

Source: Ethereum enthusiasts

Beacon chain checkpoint

• Why does Babbitt's weekly quotation suddenly disappear? Can the Bitcoin halving effect be fulfilled again?
• UAV plant protection, multispectral imaging, blockchain technology, farmer's uncle's farming "black technology"
• The overall adoption of cryptocurrencies has grown exponentially, with 3.1 billion transactions on the chain over the past decade

A checkpoint is a block generated in the first time slot of a period. If no block is generated in the first time slot of a certain period, the most recent block meeting the requirements is determined as a checkpoint block. Each period will have a checkpoint block; a block may be a checkpoint for multiple periods at the same time.

-A checkpoint diagram when a single period contains 64 time slots-

Note that there are empty blocks between time slot 65 and time slot 128. The checkpoint for period 2 should have been a block generated at slot 128, but because the slot was skipped, the checkpoint for period 2 is still a block generated at slot 64. Time period 3 is similar, time slot 192 is skipped, so the block generated at time slot 180 is considered as the checkpoint of time period 3.

The epoch boundary block is a term used in some literature (such as the Gasper paper and the source of the above diagram), and can be considered as a synonym for checkpoint.

When an LMD GHOST vote is initiated, the verifier will also vote for checkpoints in the most recent period. The new checkpoint that the voter wishes to establish is called a "target". This vote is called a Casper FFG vote, and the vote also contains the last checkpoint identified by the voter, called a "source checkpoint" (source). In the figure above, a validator's vote in period 1 takes the genesis block as the source checkpoint, and then recommends the block generated at time slot 64 as the target checkpoint. During period 2, the same verifier voted again for the same checkpoint.

Only validators assigned to a certain time slot need to vote for blocks in that time slot, but all validators must initiate FFG voting for checkpoints in each time slot.

most

The majority of votes are supported by 2/3 of the total balance of all active validators.

Let's take a simple example to illustrate. Suppose there are 3 active validators, two with a balance of 8 ETH, and the other with a balance of 32 ETH. Then, only the vote that contains the largest validator can be a majority vote; although the other two validators may have voted for another checkpoint, their total balance only accounts for 50%, which does not form a majority.

Certainty

At the end of a period, if its checkpoint is supported by 2/3 of the total balance (a majority vote is formed), then the checkpoint is justified.

If a checkpoint B has been rationalized and its checkpoints for the next period have been rationalized, then B is finalized. Generally, a checkpoint is finalized in two periods, which is about 12.8 minutes.

From an average perspective, user transactions are always packaged in the middle of a period (in a block); then there is still half a period of time before the next checkpoint, so a transaction passes 2.5 periods (16 minutes) to get the finality. Ideally, more than two-thirds of the witness messages will be packaged within the first 22 time slots of a period. Therefore, the average time for transaction finalization is 14 minutes (16 + 32 + 22 time slots). Block confirmations are gradually upgraded from block witness messages to rationalization to determinism. Users themselves can feel that if they wait for the transaction to be confirmed, a lower level of security is sufficient.

-The checkpoint at time slot 64 is rationalized and the previous block generated at time slot 32 is finalized-

To simplify the description, it is assumed that the balances of all validators are the same.

Top of beacon chain

(Above) A time slot boundary block is generated at time slot 96, and it contains the witness message (vote) for the time point 2 checkpoint. The number of witness messages reached a majority requirement of 2/3. Then the checkpoint of period 2 is rationalized, and at the same time, the last rationalized checkpoint, that is, the checkpoint of period 1, is finalized. The certainty of the block at time slot 32 will make all previous blocks deterministic. When finalizing checkpoints, there is no limit on the number of blocks that can be finalized at the same time. Therefore, although certainty is only generated at the time boundary, witness messages are accumulated one by one, block by block. The following section, "The journey from the genesis block to the top of the block chain," provides another description.

All the cross-links contained in the beacon chain blocks from time slot 1 to time slot 32 will also make the fragment chain deterministic. In other words, when a beacon chain block is deterministic, the shard chain block corresponding to the cross-link contained in the block is also finalized. Cross-linking itself is not enough to make a shard block finalize, it is only helpful for the fork selection of the shard chain.

The journey from the genesis block to the top of the beacon chain

In the same way, you can observe a story line from the genesis block. All the proposers, from time slot 1 to time slot 36, proposed a block one by one, and these blocks appeared on the chain. For all blocks in period 1, the checkpoints (blocks in slot 32) have cumulatively witnessed 55% of the validators. When the validator proposed the block at time slot 64, it also included a witness message for the checkpoint for period 1. Now, 70% of the validators have witnessed the checkpoint for period 1, so the checkpoint for period 1 is rationalized. At the completion of period 2, the witness messages accumulated at the checkpoint (block at time slot 64) in period 2 still do not meet most of the requirements of 2/3. When the block at time slot 96 was proposed, it also included the witness message for the checkpoint at block 2. Therefore, at this time, the checkpoint at time slot 2 also met most of the requirements of 2/3, which was rationalized. The checkpoint in the rationalization period 2 also knocks the checkpoint in period 1 and all previous blocks.

Sometimes, rationalizing a block will finalize two or more blocks before the time period. This situation is discussed in the Gasper paper, which is expected to occur only in extreme cases of high network latency, network isolation, and encountering powerful attackers.

Determinism is a top priority for users of shards and Ethereum blocks, because certainty enables them to be sure that transactions are always written on the chain and cannot be changed. Determinism also reduces the complexity of cross-shard communication. Without certainty, the rollback of transactions within and between shards can be destructive, and even the benefits of shards are lost.

Understand witness messages

A witness message includes an LMD GHOST vote and an FFG vote. Ideally, all validators will send a witness message every time period. A witness message has a 32-slot opportunity to be packed onto the chain. This means that a validator may have two witness messages packaged on the chain in a single period. The time when the witness message is packaged and chained also determines the reward range available to the verifier: if the packet is packaged and chained in the time slot in which it is located, the maximum reward can be obtained; Will fall. In order to give validators enough time to prepare witness messages, they will know their committee in advance before a certain period of time. Block proposers are allocated only once at the beginning of the period. In addition, covert leader election research is also working to mitigate attacks and bribes on block proposers.

The committee mechanism makes it possible to technically optimize all witness signatures and turn them into a single aggregate signature. If all validators in the same committee voted for the same LMD GHOST and FFG, their signatures could be aggregated (become a single signature).

Reward and punishment measures for beacon chain verifiers

To avoid going too deep, we only discuss 6 measures related to validator incentives:

1. Witness reward
2. Witness punishment
3. Typical depreciation risk for pledgers
4. Slashing and whistleblower rewards
5. Block proposer reward
6. Inactivity penalty

When the current witness message (including LMD GHOST vote and FFG vote) is consistent with most other validators, the validators can be rewarded. In Eth2 Phase 1, validators can also be rewarded for sending crosslinks. When the block is hit, the validator reward is determined.

On the other hand, if the validator fails to submit a witness message, or if they vote for a block that cannot be finalized, they will also be punished.

Before listing the less common penalties and rewards, you may also want to know what the risk of depreciation is when you become a pledger. The answer is that the ETH you may lose is exactly symmetrical to the amount of ETH you can earn. If a validator's reward rate for a year is 10%, the malicious validator may lose 10% in the worst case. For example, if a validator is always offline, or always votes for those blocks that cannot be finalized, the amount of ETH lost is exactly the same as a person who always submits a witness message in time, and the total number of supported blocks is Is the reward obtained by the finalized verifier, the amount is equal.

Slashing down to 0.5 ETH, up to the full equity of a validator. If the witness message submitted by a verifier violates the penalty conditions defined in the agreement, the TA will lose at least 1/32 of its own rights and be expelled from the verifier team. The penalty is as if the validator had been offline for 8192 time periods. The agreement will impose an additional penalty based on the number of verifiers confiscated in a similar period of time. The calculation formula for such additional punishment is: balance of verifier × 3 × proportion of verifiers confiscated. Then, if one-third of all validators have violated the penalty condition, they will lose the entire balance. Accordingly, the verifier who reports these wrongdoings will be rewarded by the reporter.

The block proposer will also receive a proportional reward after the proposed block is finalized. Validators who are always online and suggest that they do a good job can increase their total reward by about 1/8. In the event of forfeiture, the proponent will also receive a small reward for packing the evidence of forfeiture. In Eth2 Phase 0, all whistleblower rewards are given to block proposers.

There are many mechanisms in the Ethereum 2.0 system, and the evaluation of these mechanisms should start from the overall effect of all mechanisms. The last reward and punishment measure is the so-called "laziness punishment". Basically, if 4 periods have elapsed since the last time the block was finalized (no new checkpoints have been finalized), all validators will be penalized for laziness, and the penalties will increase by a square level until the new checkpoint is finalized . The laziness penalty guarantees that even if 50% of the validators are offline, the system will restart to finalize the block after 21 days.

Penalty condition

There are three main fine conditions, namely: double proposal, FFG double voting, and FFG round voting. LMD GHOST voting does not incur penalty.

Double proposal means that the block proposer has proposed more than one block in the time slot.

Double voting means that when a validator submits an FFG vote, multiple votes point to the same target checkpoint, but the source checkpoint cited is different.

Orbital voting means that when a validator submits an FFG vote, the checkpoints pointed to by multiple votes are exactly orbiting. As an example, suppose a validator uses the block at time slot 32 as the source checkpoint and the block at time slot 128 as the target checkpoint when voting in period 5:

• If the verifier's vote in time slot 6 uses the block in time slot 64 as the source checkpoint, and the block in time slot 96 as the target checkpoint, then the ticket is surrounded (rounded) by the TA's own vote in time slot 5 Woke up.
• If the verifier's vote in time slot 6 uses the block in time slot 0 as the source checkpoint and the block in time slot 160 as the target checkpoint, the vote encloses the TA's own vote in time slot 5.

If the verifier voted for the block of time slot 128 in time slot 6, unless the source checkpoint is still the block of time slot 32, it will be a double vote and will be fined. The same FFG vote will not be confiscated.

FFG voting with checkpoints from the same source will not incur fines. This is an important condition for maintaining network activity. For example, if both fork chains have 50% validator balance support each, the protocol should encourage validators to switch between forks by voting for the same source checkpoint and different target checkpoints (rather than punishing them for switching Forking, which causes the network to continue to split). Being able to safely switch between forks allows validators to break the deadlock and try to form a two-thirds majority.

A verifier who reports others needs to include conflicting votes in the witness message to prove that another verifier should be punished. Efficiently finding conflicting votes from a long history is also a challenge in algorithm and data structure. Therefore, the Open Engineering Challenge / Confiscator is also looking for contributors.

Well-controlled verifiers can generally avoid being confiscated: just remember which witness messages you have signed. Honest verifiers are not affected by the actions of other verifiers. As long as the verifier does not sign conflicting witness messages and does not make a double proposal, he will not be confiscated.

In order to obtain a better operating experience, a more trusted source of information, and even better DoS protection, the verifier client may use multiple beacon chain nodes at the same time.

In this mode, including when using a backup validator client, care needs to be taken not to allow the validator to sign conflicting messages.

Beacon chain validator activation and life cycle

Every user who wants to become a validator must have 32 ETH before they can qualify as a validator. Users pledged 32 ETH into the margin contract on the Ethereum mainnet to get a validator qualification.

On the other hand, the beacon chain will also discourage (deactivate) all validators whose balances have been reduced to 16 ETH; pledged users can take out the remaining validator balances, but this is not possible at Eth2 Phase 0.

The validator can also actively log out after serving 2048 periods (about 9 days). When exiting, it is necessary to complete 4 periods before the pledged user can withdraw his rights. During these 4 periods, the balance of the validator can still be fined. Therefore, the balance of honest verifiers can be withdrawn in about 27 hours. However, if the verifier is confiscated at this time, he can only withdraw the remaining amount after waiting for another 8192 periods (about 36 days).

For more technical details, see "Ethereum 2.0 Phase 0 Validator Life Cycle". The following figure also comes from this information:

To avoid large-scale changes in the set of validators in a short period of time, there is a mechanism limit on the number of validators that can be activated and withdrawn in a single period. This can make it harder to launch an attack that activates many validators and quickly attacks the system.

The beacon chain also uses a concept called "effective balance". This effective balance avoids the change in the balance of the verifier, making technical optimization possible.

to sum up

In each period, validators are evenly allocated to different time slots, and are further divided into committees of the same size. The validator has only one call slot, and it only exists in one committee. therefore:

• All validators in a period try to finalize a checkpoint through collective decision-making; the method is FFG voting;
• All validators in each time slot try to select the top block of the beacon chain through collective decision-making: the method is LMD GHOST voting;
• All validators in a committee try to cross-link a shard to the beacon chain through a collective vote.

The behavior that best meets the agreement can get the most reward.

The start of the beacon chain (genesis block) requires at least 16,484 validators. The number of validators will decrease due to confiscation and withdrawal of resources, and will also increase due to the increased investment of pledged users. Moreover, with the upgrade of Eth2 Pahse 1 and subsequent stages, more validators are expected to participate. The beacon chain needs at least 262,144 validators (more than 8 million ETH pledged) to enable a single beacon chain block to contain 64 crosslinks.

We have never had a scalable platform for decentralized systems and applications. If you want to dig deeper into Ethereum 2.0, the definitive reference source is Ethereum 2.0 Specifications. This technical specification contains the technical specifications of the beacon chain, it also provides other key information sources, and you can get bonuses by submitting issues. At present, the most urgent engineering need is the networking function of the point-to-point network.

Do it yourself, or refer a friend to a challenge, participate in the ethresear.ch forum or the Ethereum Magician forum, and make history!

We will continue to update Blocking; if you have any questions or suggestions, please contact us!