Popular Science: State Transitions in the Ethereum 2.0 Beacon Chain
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
, Author: Sly Gryphon, Translator & Proofreader: IAN LIU & A Jian, reproduced by Odaily with authorization.
The beacon chain consists of blocks and progressive state; blocks are produced, signed, propagated across the network, and then used to update the state. The following figure shows the main interrelationships:
image description
- A solid line indicates an aggregation relationship, and a dashed line indicates a dependency relationship. i.e. the part that emits the arrow is aggregated/dependent on what the arrow points to -
This diagram is based on version 0.10.1 of the Ethereum 2.0 specification. Compared with the newly released version 0.11.0, the content described in the above figure is slightly different in the part of calculating the Domain, 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 differences in the latest blocks obtained by different validators), the fork selection algorithm , to help you select the "most suitable" (the greater the weight of the obtained verifier's witness message, the more "suitable") the blockchain head.
Also, even if some slots are skipped (no blocks are produced), the state is still advanced (but does nothing).
The BeaconBlockBody ("beacon chain block body") will contain all operations that need to be performed (bond deposits, attestation messages, validator exits, 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's root hash (body root, block body root) will be added to the state as constituent elements of BeaconBlockHeader ("beacon chain block header"). It should be noted that the state root of one of BeaconBlockHeader's constituent elements 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 above 0x000... value) is calculated and added to the block, and then the block hash gets the Block root ("block root") and puts it together with the Domain of the chain. spread in the network. The meaning of Domain is to prevent the block from being propagated to other mainnets or testnets from collisions.
Execution state transition
After the node receives the SignedBeaconBlock ("signed beacon chain block"), it needs to perform some verifications, including: confirming the validity of the signature, and whether there is a state corresponding to the parent block (the parent block is determined by the parent root "parent block") root tubers” pointed out).
BeaconBlockHeader*
By advancing the state slot to the slot of the block (it can be the skipped slot), and then performing the operations contained in BeaconBlockBody (such as deposit deposit, witness message, validator exit, etc.), we can update state.
It should be noted that when a skipped time slot occurs, a new internal state will also be generated, and the current state will be advanced to the next time slot. The difference is that there will be no other incidental execution actions.
The resulting state should be the same as the state obtained by the block producer, so we can verify it with the state root recorded in the received block by calculating the hash value of the new BeaconState (containing 0x000...).
The beacon chain state contains three of the four basic components of the block - the time slot, the root hash of the parent block, and the root hash of the BeaconBlockBody (ie, the operation to be performed).
When calculating the internal state, the latest block time slot must be different from the latest state time slot, because if there is a skipped time slot, the latest block time slot and state time slot will be inconsistent. For example, if slot 7 is skipped, we will still have slot 6 as the latest block, and both the parent block root and block body root hash will still point to the block in slot 6.
These elements act 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; represented in the figure as "BeaconBlockHeader".
The advantage of this is that we can easily calculate the state of the block root - by computing the root hash of the state, then creating a copy of the block header and inserting the correct root state, and finally computing the hash of the entire block header (this value will be the same as the hash of the received block).
Linked blocks increase trust
An important feature of the blockchain is that it replaces the original trust between individuals (counterparties or third parties) with systematic trust (the majority of processors reached through algorithms).
Systematic trust can be described by the following characteristics:
A large number of processors (e.g. public chains) - the more decentralized these processors are, the more trustworthy they are.
Diversity of clients (e.g., development team) - If there are multiple clients to choose from, the more you can avoid centralized control of the algorithm.
Open source - allows both public inspection of the algorithm and forking (if the majority wants to change the direction of the system).
Linking blocks together also increases trust in the system - because the earlier a block is produced, the more weight it has. In general distributed ledgers/distributed databases, since no systematic trust is required, such links are not required.
A 51% attack on only the latest block might be successful, but if you want to change a block 100 slots ago, the attacker must have a processor controlling a supermajority during those 100 slots (so very difficulty).
