Technical Guide | Ethereum 2.0 Phase 0 V0.8.0 Technical Specifications (1)

table of Contents

• Resource
• Overview
  • Bifurcation selection rule
  • Finality
  • Crosslink
  • Certifier responsibility
• data structure
  • note
  • Beacon chain operation

Resource

• Phase 0 Technical Specifications
  • Beacon chain state transition
  • Fork selection
  • Certifier guide
• Design philosophy
• Academic paper
  • Casper FFG
  • Papers on the use of LMD GHOST to formalize FFG on the PoS chain are collaborating and will be released soon

Overview

The Beacon chain is a chain at the heart of the Ethereum 2.0 system. This name is called because this chain acts as a beacon of randomness, but it can also be called "system chain" or "spine chain", and so on. This chain is also the chain of the certifier "where", that is, the certifier's responsibility will be assigned on this chain, the verifier will run the protocol layer random number generator in this consensus environment, the verifier is also This chain votes for the block at the top of the chain and forms a deterministic checkpoint ; this is where the verifier refers to the fragmentation chain, acts as the root of the fragmentation chains, and assists in cross-slicing communication. The beacon chain is not only the brain behind the system operation, but also the framework for the subsequent fragmentation system.

The state of the beacon chain (BeaconState) is the core object around the technical specification. BeaconState covers all relevant information: the verifier has those people, what state they are in, which chain belongs to the block tree, and a hash reference to the Eth1 chain.

Starting from the creation state, whenever a block can satisfy all the conditions set by the state transition function, the state after the block is processed is considered to be valid. In this way, the precondition of a block can be recursively defined as the effective postconditions of running the state transition function on the previous block (and its state), so that it goes back to the creation state.

Bifurcation selection rule

The meaning of the fork selection rule is that given a block tree, it is always possible to select a single chain (ie, canonical chain, main chain) and final state based on such rules and recent messages from the verifier. The fork selection rule accepts the block tree and the corresponding latest attestation from the set of verifiers, and then returns a block as the current chain top block. LMD GHOST (the latest message-driven GHOST algorithm), the fork selection rule used by Eth2.0, only considers the block pointed to by each verifier's latest attestation ("witness" or "certificate"). Calculate the total number of witnesses recursively attached to each block on the tree. That is, the "weight" of a node (ie, a "block") on the block tree is the sum of the number of all verifiers that point the latest witness to the block or the descendant block of the block. The GHOST algorithm starts at the bottom of the block tree and selects the heaviest of the sub-chains at each node until it reaches the leaf node (the block at the end of the block tree). The leaf is the top of the chain and recursively defines the entire backbone.

• QKL123 market analysis | Forex market smoke, bitcoin broke 12,000 US dollars? (0805)
• Zou Chuanwei: Economics and regulatory issues in blockchain
• Coindesk Senior Analyst: The dollar is coming to an end, bitcoin or become one of the global reserve currencies?

Specifically, in each of the designated slots in an epoch, the verifier has an opportunity to generate an attestation . Submitting attestation.data.beacon_block_root is a vote in the sense of a forked selection. When calculating the fork selection result, the algorithm takes all votes from recent active verifiers into account

Finality

The fork selection rule allows us to select a main beam in a block tree, and "Finality" gives us a guarantee that certain blocks will remain in the main chain. . The beacon chain uses a modified version of Casper FFG for determinism. Casper provides "auditable security", and certain blocks remain in the main chain until a certain percentage of the verifier burns their locked capital. This is the “security” in the sense of “cryptographic economics” that we believe is different from the traditional “security” definition in traditional consensus algorithms.

Specifically, in each of the designated slots in an epoch, the verifier has an opportunity to generate an attestation . Submitting attestation.data.source will serve as the source pair for the FFG, and submitting attestation.data.target will serve as the target pair for the FFG. The former has a more in-depth discussion at " Coming GHOST and Casper ".

Crosslink

Crosslink ("crosslinking") is a reference to the recent state/block of the slice chain that is stored on the beacon chain. These references are both the root of the slice chain when doing the fork selection and the tool for asynchronous communication between the slice chains. Under normal circumstances, each shard can be cross-linked to the beacon chain once per time (if the number of certifiers is small, sometimes every N time slots).

Although we will not join the slice chain before Phase 1, the system in Phase 0 will assign a slice to the cross-linking committee and try to generate a cross-link every time. In Pahse 0, the data root in the cross-link is simply stubmed to 0x00.

Certifier responsibility

For a more detailed discussion of the certifier responsibilities in Phase 0, see here .

The two main responsibilities of the verifier are: (1) witnessing the beacon chain every time period; (2) occasionally generating a beacon chain block when selected. At each time, the verifier is divided into different “cross-linking committees”. Each committee is assigned a time slot and a slice. In a given time slot, the verifier performs attestation for the top block of the beacon chain (and after the Phase 1 it also bears witness to the latest data of the slice chain). Each time slot selects a beacon chain block proposer from the committee that is scheduled to the time slot (via get_beacon_proposer_index).

As long as the beacon chain main chain and the fragment chain are witnessed on a regular basis, the verifier can be rewarded; on the contrary, if the responsibility cannot be completed, they will be punished. If a verifier violates the Casper FFG rules, or if they create two beacon chains in the same time period, they will be fined (more severely than punishment). More details on the conditions for fines and penalties can be found here .

data structure

note

The data street in the beacon chain and the hash of the data structure are encoded as Simple SerialiZe (SSZ) objects. One benefit of using the SSZ hash method is that the depth of the tree can be uneven when generating a Merkel tree for the underlying data. The result of this and the rest of SSZ's clever design is that an SSZ object has the same hash tree root value regardless of whether the child object of the object is fully represented or only partially Merkel root. of.

Beacon chain operation

The beacon chain operation is a data structure in which a block proposer can join a BeaconBlock, and is also a way of combining various messages related to system layer verification/construction. These operations are essentially beacon chain state machine transactions at the verifier level. Each operation has an upper limit in a block, defined by max operations per block as a constant.

ProposerSlashing

• If a beacon chain block proposer proposes two different beacon chain blocks in the same time period, the TA can be penalized.
• This data structure contains proof that a punishable incident has occurred.
• Hash_tree_root(block) == hash_tree_root(block_header) , so the signature is valid for all data structures. BeaconBlockHeader can therefore be used as a proof to reduce the size of a message.
• Field
  • Presenter_index – the ValidatorIndex of the verifier that is proposed to be punished
  • Header_1 – the first block header in the first block of the beacon chain
  • Header_2 – the second block header in the two punctured beacon chain blocks

AttesterSlashing

• If a beacon chain witness signs two conflicting witnesses (the conflict situation is defined by is_slashable_attestation_data , the latter applies Casper FFG's "double voting" and "surroud" voting conditions to check)
• Field
  • Attestation_1 – the first of the two attestation, note that the form of this field is also indexed
  • Attestation_2 – the second of the two attestations, note that the form of this field is also indexed

Attestation

• The most basic form of message that the verifier creates for the consensus process. Although only one verifier per time slot can create a beacon chain block, all certifiers in each time slot have an opportunity to create an attestation. Normally, all online verifiers can create an attestation every time period, and an attestation is included in the block.
• AttestationData is the main part of the certifier's signature.
• The external data structure contains the aggregated signature and the participant fields necessary to verify the signature.
• Field
  • Aggregation_bits stores a bit for members of the committee, and the committee assigns a value of 1 to each verifier participating in the aggregate signature. Note that this is arranged in the order of the committee.
  • Data is the AttestationData signed by the certifier or certifier committee.
  • Beacon_block_root – the block root of the beacon chain block at the top of the chain at the specified time slot
  • Source – the checkpoint that was recently determined in the BeaconState at the specified time slot.
  • Target – the checkpoint to try to finalize (current time period and epoch boundary block)
  • Crosslink – cross-linking attempted to build for a given slice
  • Custody_bitfield indicates the "proof of custody" bit for each committee member (or 0 if not participating). In the Phase 0 phase, this value must be 0. (Because the hosting certificate is to be implemented in Phase 1).
  • Signature is the BLS aggregate signature of the relevant data.
• AttestationDataAndCustodyBit is the actual message signed by the certifier. Given Attestation, there are two types of messages that a verifier might sign – AttestationDataAndCustodyBit with a custody bit of 0 or 1. According to custody_bitfield, we can recover the required signed message (custody_bit 0/1) from each participating certifier. In Phase 0, all custody bits are 0.

Deposit

• Represents the upcoming verifier deposit from the Eth1 chain's margin contract.
• Field
  • Proof – Merkel evidence for the current eth1_data.root in BeaconState. Note that the +1 of the vector length is because the SSZ length is mixed into the root.
  • Data — DepositData is submitted to the margin contract for verification purposes, using the proof of deposit root for verification.
  • Pubkey – the BLS12-381 public key used by the verifier to sign the message
  • Withdrawal_credentials – The hash value of the offline public key used to retrieve the pledged funds. This key is not actively used for authentication and can be saved in a cold wallet.
  • Amount —— the number of Gweis stored
  • Signature — Signature of the DepositData using the privkey corresponding to pubkey. This data is also used as a one-time "proof of custody" to ensure the safe use of the BLS key.

VoluntaryExit

• Message type, the certifier can actively release the certifier responsibility by sending such a message
• Field
  • Epoch – The minimum number of time periods required to exit the action chain. This field prevents this function from being used during chain reorganization/forking
  • Validator_index – the index from which the certifier exits the activity
  • Signature — The signature of the relevant certifier with the public key to VoluntaryExit (the certifier identity is defined by validator_index).

Transfer

• Allow the verifier to transfer the balance.
• Basically, in order to allow Eth2 to have currency liquidity in the Phase 0 and Phase 1 phases (before the slice chain bearer state).
• Balance transfers must be included in the exact slot specified to avoid replay attacks.
• The certifier who is taking responsibility cannot transfer the balance unless the balance of the TA is higher than MAX_EFFECTIVE_BALANCE
• MAX_TRANSFERS is expected to be set to 0 during the Phase 0 startup phase and will only increase after Phase 0 appears to be stable and available.
• Field
  • Sender – the index of the certifier that sent the funds
  • Recipient – the index of the certifier receiving the funds
  • Amount —— the number of Gweis sent
  • Fee —— the fee charged to the block proposer calculated in Gwei
  • Slot – The specific time slot in which this signed Transfer can be chained. Prevent replay attacks
  • Pubkey — the pubkey that the sender fetched. The hash of the public key must match the sender's withdraw_credentials.
  • Signature — the signature of the Transfer, from transfer.pubkey

(unfinished)

Original link: https://notes.ethereum.org/jDcuUp3-T8CeFTv0YpAsHw?view#Beacon-state Author: Danny Ryan Translation: A Sword

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

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