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

Author: ethos.dev

Translation: A Jian

Source: Ethereum enthusiasts

Do you remember when you first sighed "Oh!" To the blockchain world?

• What Bitcoin will look like in 10 years, Satoshi Nakamoto says | Bitcoin Secret History
• Vicious competition causes frequent DDos attacks on exchanges. What is the cost of the attack?
• Organizational form from the future: DAO

Do you have such a thorough understanding of Beacon Chain?

The beacon chain is the core of the entire Eth2 system; however, most of the content on the beacon chain is just playing with technical terms, which is trivial and not deep enough.

Here we provide a thorough understanding of the elements and mechanisms of the beacon chain. We will also provide examples to properly identify key details so that you can do more with less.

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

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

Sharding: Great Ideal

To understand the beacon chain, it is helpful to understand the concept of sharding. The main problem that blockchain (including Ethereum) currently faces in improving scalability is that each node must verify and execute all transactions.

From a computer science perspective, there are two main ways to scale throughput:

A. Vertical expansion: The idea is to strengthen the nodes and make them more and more powerful.

B. Horizontal expansion: The idea is to add more nodes.

For decentralization, the blockchain system can only be expanded horizontally. One of the goals of Ethereum 2.0 (also known as Eth2 or Serenity) is to allow ordinary consumer hardware to run nodes. The original meaning of the term sharding is horizontally partitioning the database.

Basically, a shard chain will be processed by a part of nodes (that is, a subset of nodes in 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 chain.

In this system, the node group that processes a shard by block is constantly replaced.

To shard a blockchain system, the main challenge is the security of the shard. Because the verifiers are scattered across the shards, it will be less difficult for a malicious verifier to compromise a single shard.

Therefore, the key to the sharding solution is to randomly shuffle the verifiers and let each shard block be processed by a committee of (pseudo) randomly selected validators, so that one controlled interest is less than the entire The probability of success of the attacker with 1/3 of the validator's equity is 0 (mathematically improbable).

Fraud proofs, custody proofs, and data availability checks are also important security components, but they need to be written to explain them clearly.

Eth2's current plan is to enable 64 shards. Although the sharding and the beacon chain are conceptually independent, we are still going to talk about some key elements of the entire system.

The concept of sharding reflects the functions and needs of the beacon chain; through the concept of sharding, we can understand why it is necessary to add these additional parts to the traditional blockchain system. This brand new field also welcomes readers who have a sense of inspiration to propose innovations.

Ethereum 2.0 stages

Ethereum 2.0 will be deployed in three phases:

• Phase 0: Beacon Chain
• Phase 1: Sharding
• Phase 2: Execution

It can be likened to the three parts of the human body:

• Phase 0: Heart
• Phase 1: limbs
• Phase 2: the brain

It can also be likened to a magnificent orchestra:

• Phase 0: conductor
• Phase 1: musical instrument
• Phase 2: Musician

Each phase is integrated into the system, each playing a different role. Compared to other stages, the features introduced by Phase 1 will be more unpredictable, and Phase 2 will be more about execution.

Slot and Epoch

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

A time slot (slodt) is 12 seconds, and a time slot (epoch) consists of 32 time slots, so it is 6.4 minutes.

-32 time slots for period 0. Genesis block is generated at period 0-

(The parameter data used in this article are from the beacon chain technical specification v0.10.1)

Time 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 a chance to generate new blocks. You can imagine that the beacon chain and the shard chains are carefully designed and tightly synchronized. Ideally, every 12 seconds, 1 beacon chain block will be generated, and 64 shard blocks distributed on different shard chains. Validators do need to be synchronized in time.

Therefore, a time slot is like a block time, except that it is also possible for a time slot to be empty. The genesis block of the beacon chain and the shard chain was generated at time slot 0; however, each shard chain will start to run after the period 0 of the beacon chain is completed, and each of them has its own time period 0 (generating the The beginning of the world block).

Validators, witness messages, and beacon chains

The PoW blockchain is maintained by miners, and the Ethereum 2.0 proof-of-stake system is based on "virtual miners"-validators. The validator is the active participant in the consensus process of the Ethereum 2.0 protocol. The economic incentives of the TAs will be discussed later in the "Beacon Chain Verifier Reward and Punishment Measures" section.

A block proposer refers to a validator that is randomly selected to generate a block.

Most of the time, validators only act as witnesses, only voting on beacon chain blocks and shard chain blocks. These votes will be recorded on the beacon chain, and the latest block of the beacon chain and the latest block of the shard chain will be determined accordingly.

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

During a period, a validator is pseudo-randomly assigned to a time slot and a slice. The validator will participate in the consensus process of the assigned shard to vote to select the latest block of the shard. The verifier will also link the latest block to the beacon chain block within a time slot.

The so-called attestation is a vote initiated by a validator whose weight is determined by the balance of the validator. The witness message will be appended to the block by the verifier, and will spread with the block.

Validators will also monitor each other and can report other validators to make conflicting votes or propose wrongdoing of multiple blocks. If the report is true, they can be rewarded.

The main content of the beacon chain is a register of verifier addresses, the status of each verifier, witness messages, and information linked to the shard. Validators need to be activated by the beacon chain before participating, or they can change their state, as described in the "Beacon chain validator activation and life cycle" section below.

Participating Validators: Meaning of Terms

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

It will be easier to understand the association of stakers with stakes, validators and balances. The maximum balance of each validator is 32 ETH, although the pledger can pledge all of his ETH into it. For every 32 ETH deposits, you can get 1 validator qualification.

The verifier runs on the verifier client, which uses the beacon chain node to perform 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. The verifier client can either run the function of the beacon chain node itself or connect to other people's beacon chain nodes.

Crosslink: Let the shards take root on the beacon chain

The so-called cross-linking is data that is placed in a beacon chain block and points to a certain fragment block. The beacon chain is to track the shard chain (the latest block) through cross-linking. Because there are 64 fragments, each beacon chain can contain up to 64 cross-links. There may be only one cross-link in a beacon chain block. If no validator proposes blocks for the other 63 fragments in this time slot. The cross-linking function is planned to be introduced in Eth2 Phase 1, so that each shard chain can be rooted on the beacon chain, and the beacon chain can be used as the shard chain fork selection, shard chain determinism, and cross-shard communication basis.

All shard chains track the beacon chain throughout.

Committee profile

A committee is a group of validators. For security reasons, every time slot, on the beacon chain and each fragment chain, there will be a committee composed of at least 128 validators. Attackers have less than a trillionth chance and can control two-thirds of validators on a committee.

The name of the beacon chain comes from its ability to provide random numbers publicly (that is, "random beacons"). The beacon chain will reach a consensus on a pseudo-random process called "RANDAO".

-In each period, the pseudo-random process RANDAO will select all time slot proposers, and shuffle the validators to different committees-

The verifier is selected by RANDAO based on the balance of the verifier. A validator may be both a proposer and a committee member in a time slot, but this is not abnormal. The probability of this happening is 1/32, so we estimate we will see it once per period. The above diagram depicts the situation when the number of validators is less than 8,192, otherwise there will be at least two committees in a time slot.

This article focuses on the beacon chain committee: the verifier serving the beacon chain. A beacon chain committee will be randomly assigned to a shard to generate cross-links on a beacon chain blockchain. Moreover, the members of the committee are not permanent, and the committees responsible for cross-linking are replaced block by block.

The committee that only generates blocks for the shard chain is left to explain in the future. The shard chain verifier may generate 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 cross-link the shard blocks to On a beacon chain block.

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

The picture above synthesizes the situation generated in three time slots. At time slot 1, a validator proposed a block, and the block was witnessed by two validators; one validator in committee A went offline. In time slot 2, someone proposed a block, but a validator 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. Block. Note that this verifier is not the same as the offline verifier at time slot 1. Voting on the top block of the beacon chain is called "LMD GHOST voting". At time slot 3, all validators in Committee C run the LMD GHOST fork selection rule and independently vote for the same block as the top of the beacon chain.

A validator will only participate in one committee at a time. Generally, there are more than 8192 validators in the system, so there will be more than one committee per time slot. The committees are all the same size, with at least 128 validators. When there are fewer than 4096 validators in the system, security is reduced because the size of the committee will be less than 128 validators.

Committee: Key

At each time period, validators are evenly distributed into time slots and then further allocated to committees of equal size. All validators must send out a witness message at their own time slot, indicating the top of the beacon chain. Each committee will try to cross-link to a specific shard in its own time slot. The shuffle algorithm increases or decreases the number of committees to ensure that each committee has at least 128 validators.

For example, suppose there are 16,384 validators. Of these, 512 validators were pseudo-randomly assigned to slot 1, another 512 were assigned to slot 2, and so on. The 512 validators in slot 1 are further divided into 4 committees. All 512 validators are required to initiate LMD GHOST voting at slot 1; 128 validators from one committee attempt to cross-link to slice 33; 128 validators from another committee attempt to cross-link to allocation 55; the other two Each committee attempts to cross-link to slice 22 and slice 11.

This process is repeated at time slot 2. The 512 validators are also divided into 4 committees. Suppose they are assigned to shards 41, 20, 17, 15. All 512 validators will vote for the top of the beacon chain at slot 2; these committees will also try to propose cross-links for slices 41, 20, 17, 15

This process is also repeated one by one in the remaining time slots of the period. Each validator will have a time slot in which TA can speak, present a witness message, and generate a cross-link. By the end of the period, all 16,384 validators have had the opportunity to initiate voting and cross-linking.

However, in the above process, the verifier's votes are based on time slots, not time periods. It's a bit like voting for a local government, not a national election. All validators have never voted for the same thing. The following section discusses checkpoints and certainty, and explains the period-specific voting that each verifier needs to initiate in the time slot in which it is located. In other words, during their time period, they also have to vote for checkpoints in the time period.

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