Popular Science | State transition in the Ethereum 2.0 beacon chain

The beacon chain is composed of blocks and a progressive state; blocks are produced, signed, spread throughout the network, and then used to update the state. The following diagram shows the main interrelationships:

-The solid line indicates the aggregation relationship, and the dotted line indicates the dependency relationship. That is, the part that emits the arrow is aggregated / dependent on what the arrow points to-

This picture is based on the 0.10.1 version detailed by Ethereum 2.0. Compared with the 0.11.0 version just released, the content described in the figure above is slightly different in the calculation of the Domain part, but the overall relationship is consistent with the previous version.

Create a new block

To create a block, start from the top of the current blockchain.

If there is currently a short fork chain (for example, a time slot is skipped because the block propagation speed is too slow, resulting in the difference between the latest blocks obtained by different validators), then the fork selection algorithm , To help you choose the "most suitable" (the greater the weight of the obtained verifier witness message, the more "suitable") the blockchain head.

In addition, even if some slots are skipped (no blocks are generated), the state will still advance (but do nothing).

BeaconBlockBody ("Beacon Block Block") will contain all the operations that need to be performed (margin deposit, witness message, verifier exit, etc.). These operations will be used to change the state and generate a new BeaconState ("beacon chain state").

The time slot, parent block root, and operation root hash (body root) will be added to the state as constituent elements of BeaconBlockHeader ("beacon chain block header"). It should be noted that the root of the state of one of the BeaconBlockHeader components is zero (0x000 …), because the state cannot recursively contain its own hash, otherwise an infinite loop will occur.

The root hash of the final state (the state with the value 0x000 … above) is calculated and added to the block, and then the block hash is obtained as the Block root ("block root") and put together with the domain of the chain. Spread in the network. The meaning of Domain is to prevent collisions between blocks being propagated to other mainnets or testnets.

Application state transition

After receiving the SignedBeaconBlock ("signed beacon chain block"), the node must perform some verifications, including: confirming the validity of the signature and whether there is a state corresponding to the parent block Root "pointed out).

By advancing the status time slot to the time slot where the block is located (which can be a skipped time slot), and then performing the operations included in BeaconBlockBody (such as depositing deposits, witness messages, verifier exits, etc.), we can update status.

It should be noted that when a skipped time slot occurs, a new internal state is also generated, and the current state is advanced to the next time slot, the difference is that there will be no other accompanying execution actions.

The resulting state should be the same as the state obtained by the block producer, so we can verify the root of the state recorded in the received block by calculating the new BeaconState (including 0x000 …) hash value.

* BeaconBlockHeader **

The beacon chain state contains three of the basic composition information of the four blocks-the time slot, the root hash of the parent block, and the root hash of BeaconBlockBody (that is, the operation to be performed).

When calculating the internal state, the latest block time slot should be different from the latest state time slot, because if a skipped time slot occurs, it will make the latest block time slot and the state time slot inconsistent. For example, if time slot 7 is skipped, we will still use time slot 6 as the latest block, and both the parent block root and block body root hash will still point to the time slot 6 block.

These elements are used as a cluster, using the same structure as BeaconBlockHeader, but the block root state used is always zero (0x000 …), because the state cannot recursively contain its own hash; it is represented as "BeaconBlockHeader" in the figure.

The advantage of this is that we can easily calculate the state of the block root-by calculating the root hash of the state, then create a copy of the block header and insert the correct root state, and finally calculate the hash of the entire block header (this value Will be the same as the hash value of the received block).

Linked blocks can increase trust

An important feature of the blockchain is that it replaces the original inter-individual trust (trading counterparty or third party) with systemic trust (the majority of processors reached through algorithms).

Systematic trust can be described by the following characteristics:

  • Large number of processors (for example, public chains)-the higher the degree of decentralization of these processors, the higher the degree of credibility.
  • Client diversity (for example, the development team)-if there are multiple clients for users to choose, the more they can avoid the algorithm being centralized.
  • Open source-not only allows the public to check the algorithm, but also can fork (if most people want to change the direction of the system).

Linking blocks together can also enhance system trust—because the earlier blocks are produced, the greater the weight they have. In a general distributed ledger / distributed database, because no systematic trust is needed, no such link is needed.

A 51% attack on the latest block may be successful, but if you want to change a block before 100 slots, the attacker must have an absolute majority of processors in these 100 slots (so very difficult).

For short-range bifurcation attacks, the entire network may be confused about "which chain is the main chain"-for example, two competing blocks propagate through the network at different speeds.

But the good news is that since the blocks are linked together, the true main chain will be confirmed sooner, and other fork chains will no longer have the opportunity to oppose the guest.

In this way, security can be guaranteed, and the system can easily allow verifiers to withdraw their funds without worrying about "nothing at stake" attacks.


Original link: https://sgryphon.wordpress.com/2020/03/17/eth-2-0-state-transition/ Author: Sly Gryphon translation & proofreading: IAN LIU & A sword