Eth2 Beacon Chain: The First Things You Should Know

Editor's Note: This article is from:Ethereum enthusiasts (ID: ethfans)Editor's Note: This article is from:

Ethereum enthusiasts (ID: ethfans)

Ethereum enthusiasts (ID: ethfans)

, author: ethos.dev, translation: A Jian, reprinted by Odaily with authorization.

Do you still remember the joy when you sighed "so so" to the blockchain world for the first time?

Do you want to have such a thorough understanding of the Beacon Chain?

The beacon chain is the core of the entire Eth2 system; however, most of the content about the beacon chain is just a technical vocabulary, which is trivial and not deep enough.

Here, we will provide a thorough understanding of the elements and mechanisms of the Beacon Chain. We'll also provide examples and pinpoint key details so you can do more with less.

We assume that you already have a solid understanding of the Ethereum blockchain or the Bitcoin blockchain and are familiar with Proof of Stake.

Let’s first take a look at the panorama of shards, staking validators, attestations, committees, checkpoints, and finality.

Fragmentation: a lofty ideal

To understand the beacon chain, it helps to first understand the concept of sharding. The main difficulty currently faced by blockchains (including Ethereum) in improving scalability (scalability): every node must verify and execute all transactions.

From a computer science point of view, there are two main ways to scale throughput:

A. Vertical expansion: the general idea is to strengthen the node and make the node more and more powerful.

B. Horizontal expansion: to the effect, adding more nodes.

In order to decentralize, the blockchain system can only expand horizontally. One of the goals of Ethereum 2.0 (also called Eth2 or Serenity) is to make it possible to run nodes on common consumer-grade hardware. The original meaning of the term sharding is to perform horizontal partitioning on the database (horizontally partitioning).

Basically, a shard chain will be processed by a subset of nodes (i.e. a subset of the entire network). The virtual miners in the system, validators, will be assigned to different shards, and only process and verify transactions on their own shard chains.

In this system, the group of nodes that process a shard by block is constantly changing.

To shard a blockchain system, the main challenge is the security of sharding. Because validators are distributed across shards, it is less difficult for malicious validators to compromise a single shard.

The crux of the sharding solution is therefore: Randomly shuffle validators so that each shard block is processed by a committee of (pseudo)randomly chosen validators such that one controls less stake than all An attacker with a stake of 1/3 of the validator has a probability of success of 0 (mathematically improbable).

Fraud proofs, custody proofs, and data availability checks are also important security components, but they require dedicated articles to explain.

The current plan for Eth2 is to enable 64 shards. Although sharding and the beacon chain are conceptually separate from each other, we are going to talk about some key elements of the overall system.

• The concept of sharding reflects the functions and needs of the beacon chain; through the concept of sharding, we can understand why these additional parts need to be added to the traditional blockchain system. This new field also welcomes innovations from readers who have some insights.

• Stages of Ethereum 2.0

• Ethereum 2.0 will be deployed in three phases:

Phase 0: Beacon Chain

• Phase 1: Fragmentation

• Phase 2: Execution

• It can be compared to the three parts of the human body:

Phase 0: Heart

• Phase 1: Limbs

• Phase 2: Brain

• It can also be compared to a majestic orchestra:

Phase 1: Instruments

Phase 2: Musicians

Each stage is integrated into the system and serves a different role. Phase 1 will introduce features more quietly than other phases, while Phase 2 will be more about execution.

Slot and Epoch

The beacon chain is the heartbeat of Ethereum 2.0 and the main theme of the harmony and consensus of the entire system.

A slot (slodt) is 12 seconds and an epoch consists of 32 slots, thus 6.4 minutes.

image description

- 32 time slots of period 0. The genesis block is created at epoch 0 -

(The parameter data used in this article are all from Beacon Chain Technical Specification v0.10.1)

Slots are used to mark the opportunity to generate beacon chain blocks and shard blocks: on the beacon chain and each shard, each time slot has an opportunity to generate a new block. You can imagine that the beacon chain and the shard chains are carefully designed and tightly synchronized. Ideally, every 12 seconds, there will be 1 beacon chain block, and 64 shard blocks distributed on different shard chains. Validators do need to be synchronized in time.

Therefore, slots are like block times, except that slots may also have empty blocks. The genesis block of the beacon chain and shard chains is generated at time slot 0; however, the shard chains will not start running until the epoch 0 of the beacon chain the origin of the world block).

The PoW blockchain is maintained by miners, while the proof-of-stake system of Ethereum 2.0 relies on "virtual miners" - verifiers. Validators are active participants in the consensus process of the Ethereum 2.0 protocol. The economic incentives for TAs will be discussed later in the section "Rewards and Punishments for Beacon Chain Validators".

The proposer of a block refers to a validator who is randomly selected to produce a block.

Most of the time, validators are just witnesses, voting on beacon chain blocks and shard chain blocks. These votes will be recorded on the Beacon Chain, which will also determine the latest block of the Beacon Chain and the latest block of the Shard Chain.

image description

- At the 28th slot of a certain period, there is no corresponding block proposal (the validator assigned as the proposer did not propose a block for some reason) -

The so-called attestation is a vote initiated by a verifier, and its weight is determined by the verifier's balance. The attestation message will be appended to the block by the verifier and propagated along with the block.

Verifiers will also supervise each other, and can report other verifiers to make conflicting votes or propose multiple blocks of misbehavior, and if the report is true, they can be rewarded.

The main content of the beacon chain is a registry of validator addresses, the status of each validator, attestation messages, and information linking to shards. Validators need to be activated by the beacon chain before participating, and can also change their status, as described in the "Beacon Chain Validator Activation and Lifecycle" section below.

secondary title

Validators participating in staking: term meaning

On a proof-of-work blockchain, users become miners by controlling hardware to participate in consensus. In Ethereum 2.0, users can obtain validator qualifications by staking ETH, and participate in the network by controlling validators. Therefore, the verifier is virtual and is actively activated by the pledger.

It’s easier to understand when you relate stakers to stakes and validators to balances. The maximum balance of each validator is 32 ETH, although the pledger can pledge all of his ETH. Every time you deposit 32 ETH, you can get 1 validator qualification.

Validators operate by means of validator clients, which utilize beacon chain nodes to perform their normal functions. The beacon chain node has the function of following the operation of the beacon chain and reading the information of the beacon chain. A validator client can either run the functionality of a beacon chain node itself, or connect to someone else's beacon chain node.

Crosslink: let the shards take root on the beacon chain

The so-called cross-linking refers to the data placed in a beacon chain block and pointing to a certain shard block. The beacon chain is to track the shard chain (the latest block) through cross-linking. Since there are 64 shards, each beacon chain can contain up to 64 crosslinks. There may only be one crosslink in a beacon chain block if no validators propose blocks for the other 63 shards in that time slot. The cross-link function is planned to be introduced in Eth2 Phase 1, so that each shard chain can be rooted on the beacon chain, and let the beacon chain serve as the link for the selection of shard chain forks, the certainty of shard chains, and cross-shard communication. Base.

Committee Profile

A committee is a group of validators. For security reasons, every time slot, on the beacon chain and every shard chain, there will be a committee consisting of at least 128 validators. An attacker has less than one in a trillion chance of controlling 2/3 of the validators in a committee.

The name of the beacon chain comes from its function of publicly providing random numbers (ie, "randomness beacon"). The beacon chain will reach consensus on a pseudo-random process called "RANDAO".

image description

Validators are selected by RANDAO based on the validator's balance. It is possible for a validator to be both a proposer and a committee member in the same slot, but this is not the norm. The odds of this happening are 1 in 32, so we estimate we'll see it once every time period. The diagram above depicts the situation when the number of validators is less than 8192, otherwise there will be at least two committees in a slot.

This article focuses on the Beacon Chain Committee: the validators that serve the Beacon Chain. A Beacon Chain committee is randomly assigned to a shard to generate crosslinks on a Beacon Chain blockchain. Moreover, the members of the committee are not constant for a long time, and the committees responsible for generating crosslinks are replaced block by block.

The committee that produces blocks only for the shard chain is left for future interpretation. Shard chain validators may produce many beacon chain blocks without interacting with the beacon chain, but if a shard wants to communicate with other shards, it needs the beacon chain committee to crosslink the shard blocks to on a beacon chain block.

image description

- The protocol assumes that validators always vote for the block they consider to be the top of the blockchain -

The picture above synthesizes what happens in the three time slots. In slot 1, a validator proposes a block, and the block is witnessed by two validators; one validator in committee A goes offline. In time slot 2, someone proposed a block again, but a verifier in Committee B did not see it, so its witness message indicates that TA believes that the top of the beacon chain (the latest block) is still generated at time slot 1 blocks. Note that this verifier is not the same as the offline verifier in slot 1. The vote for the top block of the beacon chain is called "LMD GHOST vote". At time slot 3, all validators in committee C run the LMD GHOST fork choice rules and independently vote the same block to be the beacon chain top.

A validator will only participate in one committee at a time. In general, there will be more than 8192 validators in the system, so there will be more than one committee per slot. The committees are all the same size and have at least 128 validators. When there are fewer than 4096 validators in the system, security decreases because the committee size will be less than 128 validators.

Committee: key

In each epoch, validators are evenly divided into slots, which are then further divided into committees of equal size. All verifiers must issue a witness message in their time slot, indicating the top of the beacon chain. Each committee tries to crosslink to a specific shard in its own slot. The shuffling algorithm increases and decreases the number of committees to ensure that each committee has at least 128 validators.

As an example, assume there are 16384 validators. 512 of these validators are pseudo-randomly assigned to slot 1, another 512 to slot 2, and so on. The 512 validators in slot 1 are further split into 4 committees. All 512 validators are required to initiate an LMD GHOST vote at slot 1; 128 validators from one committee try to cross-link to shard 33; 128 validators from the other committee try to cross-link to shard 55; A committee tries to crosslink to shard 22 and shard 11.

In time slot 2, the process repeats itself. The same 512 validators are divided into 4 committees. Suppose they are assigned to shards 41, 20, 17, 15. All 512 validators vote for the top of the beacon chain at slot 2; these committees also try to propose crosslinks for shards 41, 20, 17, and 15.

However, in the above process, validator votes are based on slots, not periods. It's kind of like voting for local government instead of a national election. All validators have never voted for the same thing. The next section discusses checkpoints and finality, explaining the period-specific votes each validator needs to initiate in its slot. That is to say, in their time slot, they also vote for the checkpoint of the time slot.

Beacon Chain Checkpoints

A checkpoint is a block that occurs during the first slot of an epoch. If no block is generated in the first time slot of a certain period, the latest qualified block is identified as the checkpoint block. There will be one checkpoint block per epoch; a block may be checkpointed for multiple epochs at the same time.

image description

- Schematic diagram of checkpoints when a single period contains 64 time slots -

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

When initiating an LMD GHOST vote, the verifier also votes for the latest checkpoint, and the new checkpoint that the voter wants to establish is called the "target checkpoint". This kind of voting is called Casper FFG voting, and the voting will also include the last checkpoint identified by the voter, called "source checkpoint" (source). In the diagram above, a validator in epoch 1 voted for the genesis block as the source checkpoint, and then elected the block produced at slot 64 as the target checkpoint. At epoch 2, the same validator voted for the same checkpoint again.

Only the validators assigned to a slot need to vote for the block of that slot, however, all validators are required to issue FFG votes for the checkpoints of each slot.

A vote backed by 2/3 of the total balance of all active validators is the majority vote.

Certainty

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

first level title

At the end of an epoch, a checkpoint is justified if it is backed by 2/3 of the total balance (forming a majority).

If a checkpoint B has been rationalized and its checkpoint for the next period is also rationalized, then B is finalized. Typically, a checkpoint is finalized within two periods, which is about 12.8 minutes.

On average, a user's transaction is always packed in the middle of an epoch; then there is half an epoch until the next checkpoint, so a transaction goes through 2.5 epochs (16 minutes) to get finality. Ideally, more than 2/3 of the attestations will be packaged within the first 22 slots of a period. Therefore, the average time for a deal to finalize is 14 minutes (16 + 32 + 22 slots). Block confirmation is upgraded step by step from block witness message to rationalization and then to certainty. Users themselves can decide whether they want to wait until the transaction is confirmed, or whether a lower level of security is enough.

image description

- checkpoint at slot 64 rationalized while finalizing last block produced at slot 32 -

Top of the Beacon Chain

(Above) An epoch boundary block was produced at slot 96 and contained an attestation (vote) for the epoch 2 checkpoint. The number of attestations meets the 2/3 majority requirement. The period 2 checkpoint is then rationalized, and at the same time, the previous rationalized checkpoint, the period 1 checkpoint, is finalized. The block at slot 32 is finalized, making all previous blocks finalized. When finalizing a checkpoint, there is no limit to the number of blocks that can be finalized at the same time. Therefore, although the finality is only generated at the boundary of the period, the attestation message is accumulated block by block, and the "Journey from the Genesis Block to the Top of the Blockchain" section below provides another description.

All crosslinks contained in the beacon chain blocks from slot 1 to slot 32 also make the shard chain final. In other words, when a beacon chain block is finalized, the shard chain block corresponding to the crosslink contained in the block is also finalized. Cross-linking by itself is not enough to finalize a shard block, it is only helpful for the fork selection of the shard chain.

secondary title

In the same way, it is possible to observe a storyline starting from the genesis block. All proposers, from slot 1 to slot 36, have proposed a block one by one, and these blocks appear on the chain. For all blocks in epoch 1, its checkpoint (the block at slot 32) has cumulatively been witnessed by 55% of the validators. When the validator proposed the block at slot 64, it also included the attestation to the epoch 1 checkpoint. Now, 70% of the validators witnessed the epoch 1 checkpoint, so the epoch 1 checkpoint is justified. When epoch 2 is complete, the epoch 2 checkpoint (block at slot 64) has accumulated less than a 2/3 majority of attestations. When the block at time slot 96 was proposed, the witness message for the checkpoint of block 2 was also included, so at this time, the checkpoint of time slot 2 also reached the 2/3 majority requirement, which was rationalized. Rationalizing the period 2 checkpoint also finalizes the period 1 checkpoint and all previous blocks.

Sometimes, rationalizing a block finalizes a block two or more time periods ago. The Gasper paper discusses this situation, which is expected to only occur in extreme cases of high network latency, network isolation, and powerful attackers.

Determinism is a top priority for users of shards and Ethereum blocks, as determinism allows them to be sure that transactions are permanently written on-chain and cannot be changed. Determinism also reduces the complexity of communicating across shards. Without finality, rollbacks of transactions within and between shards can be disruptive and even negate the benefits of sharding.

In-depth understanding of testimonies

A witness message includes an LMD GHOST vote and an FFG vote. Ideally, all validators would issue an attestation message every epoch. There are 32 time slots for a witness message to be packaged on the chain. This means that a verifier may have two attestation messages packaged on the chain within a single period of time. The time when the testimonial message is packaged and uploaded also determines the amount of rewards that the verifier can get: the most rewards can be obtained by packaging and uploading the witness message in the time slot where it is located; will fall. In order to give validators enough time to prepare attestations, they will know in advance which committee they are on a period in advance. Block proposers are only allocated once at the beginning of the epoch. In addition, covert leader election research also works on mitigating attacks and bribery on block proposers.

The committee mechanism makes it possible to aggregate all witness signatures and turn them into a single aggregate signature for technical optimization. If all validators in the same committee have cast the same LMD GHOST and FFG votes, their signatures can be aggregated (become a single signature).

• first level title

• Beacon Chain Validator Incentives and Penalties

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

• Witness Reward

• Witness punishment

• Typical depreciation risk for stakers

Slashing and Whistleblower Rewards

Block Proposer Rewards

inactivity penalty

When the current witness message (including LMD GHOST vote and FFG vote) is consistent with the majority of other verifiers, the verifier can be rewarded. In Eth2 Phase 1, validators can also get rewards for sending crosslinks. When the block is finalized, the validator reward is also determined.

On the other hand, validators are also penalized if they fail to commit attestations, or vote for a block that cannot be finalized.

Slashing can range from 0.5 ETH to the full stake of a validator. If the attestation message submitted by a verifier violates the slashing conditions defined in the protocol, the TA will lose at least 1/32 of its own equity and be expelled from the verifier team. The penalty is as severe as if the validator was offline for 8192 epochs. The protocol also imposes an additional penalty based on the number of validators slashed within a similar time period. The calculation formula for this additional penalty is: validator balance × 3 × percentage of slashed validators. Then, if 1/3 of all validators violate the slashing condition, they will lose their entire balance. Correspondingly, validators who report these misconducts will be rewarded as whistleblowers.

The block proposer will also receive a proportional reward after the proposed block is finalized. A validator who is always online and does a good job proposing increases the total reward by about 1/8. When a slashing event occurs, the proposer will also receive a small reward for packaging the slashed evidence. In Eth2 Phase 0, all whistleblower rewards go 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 type of reward and punishment is the so-called "laziness penalty". Basically, if 4 epochs have elapsed since the last block was finalized (no new checkpoints finalized), all validators suffer a laziness penalty that increases quadratically until a new checkpoint is finalized . The laziness penalty ensures that even if 50% of the validators are offline, the system restarts finalizing blocks after 21 days.

secondary title

Forfeiture conditions

There are three main conditions for slashing, namely: double proposal, FFG double voting, and FFG surround voting. LMD GHOST votes will not incur penalties.

• Double proposal means that the block proposer proposes more than one block in the same slot.

• Double voting means that when the validator submits FFG votes, multiple votes point to the same target checkpoint, but the referenced source checkpoints are different.

Surrounding voting means that when the verifier submits FFG votes, the checkpoints pointed to by multiple votes are exactly in the shape of a circle. As an example, suppose a validator voted at epoch 5 with the block at slot 32 as the source checkpoint and the block at slot 128 as the target checkpoint:

If the validator's vote in epoch 6 checkpoints the block of slot 64 as the source and checkpoints the block of slot 96 as the target checkpoint, then the vote is surrounded (surrounded) by TA's own vote in epoch 5 Woke up.

If the validator's vote in epoch 6 uses the block of slot 0 as the source checkpoint and the block of slot 160 as the target checkpoint, then this vote surrounds TA's own vote in epoch 5.

If this validator votes again for block 128 in time slot 6, unless its source checkpoint is still block 32 in time slot, it will be a double vote and be slashed. The same FFG votes will not be confiscated.

Validators who report others need to include conflicting votes in the attestation message to prove that the other validator should be punished. It is also an algorithmic and data structure challenge to efficiently find conflicting votes from a long history. Therefore, the Open Engineering Challenge Slash Detector is also looking for contributors.

Well-controlled validators are generally immune to slashing: just remember which attestations they have signed. Honest verifiers will not be affected by the actions of other verifiers. As long as validators do not sign conflicting attestations and do not double propose, they will not be slashed.

In order to get a better operating experience, a more trustworthy source of information, and even better DoS protection, the validator client may use multiple beacon chain nodes at the same time. In this mode, including when using backup validator clients, care needs to be taken not to have validators signing conflicting messages.

first level title

Beacon chain validator activation and life cycle

Every user who wants to be a validator must first have 32 ETH to qualify as a validator. Users pledge 32 ETH to the margin contract on the Ethereum mainnet to obtain a validator qualification.

On the other hand, the beacon chain will also dissuade (deactivate) all verifiers whose balance has been reduced to 16ETH; pledge users can withdraw the remaining verifier balance, but this is not yet possible in Eth2 Phase 0.

For more technical details, see "Ethereum 2.0 Phase 0 Validator Life Cycle". The image below is also from this source:

Summarize

In order to avoid large-scale changes in the set of verifiers in a short period of time, there is a mechanism to limit the number of verifiers that can be activated and withdrawn within a single period of time. This makes attacks that activate many validators and quickly attack the system much more difficult to launch.

• The beacon chain also uses a concept called "effective balance", which avoids changes in the validator's balance, making technical optimization possible.

• Summarize

• In each epoch, validators are evenly distributed into different slots and further divided into committees of the same size. Validators have only 1 called slot and will only exist in 1 committee. therefore:

All verifiers in a period try to finalize a certain checkpoint through collective decision-making; the method is FFG voting;

All verifiers 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 vote collectively to attempt to crosslink a shard to the beacon chain.

The behavior that best conforms to the protocol gets the most reward.