Introduction: Implementation of Casper FFG in ETH2.0
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
Ethereum enthusiasts (ID: ethfans)
, author: Aditya Asgaonkar, translation & proofreading: Min Min & A Jian, reprinted by Odaily with authorization.
My last article covered the basics of Casper FFG. The first part of this article will give a brief description of the Casper FFG implementation used in the Eth2.0 beacon chain. The second part will discuss the fork selection rules of the beacon chain and other factors related to the liveness of the blockchain.
This article directly explains some concepts in the ETH 2.0 specification, and attaches links to relevant parameters and functions in the specification as much as possible. These links are for informational purposes only and it is not necessary to read the content of the links to understand this article.
Part 1 - Casper FFG Mechanism
Slot, Epoch and Attestation
Slot (time slot): The time on the blockchain is divided according to slots, and a new block can be proposed during each slot. Currently, the duration of a slot is SECONDS_PER_SLOT = 12, which is 12 seconds. The system will assign a validator to each slot to create new blocks.
Epoch (period): The Casper FFG mechanism does not apply to the complete block tree, but only considers the votes of blocks at certain slots. In this way, the mechanism does not need to verify too many source block-target block pairs when checking the certainty according to the voting situation, thus saving costs. Since the intervals between these slots are long enough, the vast majority of validator newly submitted votes will be seen every time the FFG finality check runs. Each epoch is composed of a certain number of slots. The current parameter is SLOTS_PER_EPOCH = 32, that is, 1 epoch = 32 slots = 6.4 minutes. The FFG mechanism only considers blocks at these epoch boundaries ("checkpoints" or "epoch boundary blocks" (EBB)).
- Slot and epoch case when SLOTS_PER_EPOCH = 3 and blocks A, D and G are checkpoints -
Attestation (witness message): attestation is the Casper FFG vote, which contains information such as the source block and target block, the slot number when the attestation was generated, and the identifier of the validator. The attestation is broadcast to the peer-to-peer network by the verifier, and finally selected and packaged into the block by the block proposer.
Casper FFG Mechanism Changes
There is one change to the definition of Finalization I mentioned in the previous article:
Deterministic achievement: As long as block B satisfies the following conditions, determinism can be obtained
The rationalized block B_0 satisfies the following conditions:
There is a sequence of checkpoints on a chain of [B_0, B_1, ... , B_n] (n >= 1) increasing by slot number, all of which are rationalized, and
- Yellow blocks are justified, red blocks are finalized -
The changed definition still retains the outline of the Casper FFG security proof described in the previous post. See the "Security" section of this article for a full description of security proofs.
secondary title
Deterministic detection with Casper FFG
The on-chain FFG mechanism of the Beacon Chain is designed to detect certainty by processing blocks and attestation. At each epoch boundary, the mechanism processes new attestations and updates blocks that have been rationalized and finalized.
The on-chain FFG mechanism only deals with the attestation of a specific source block-target block pair, rather than all possible source block-target block pair attestations, thereby reducing costs. Specifically, the mechanism only deals with attestations in the current and previous epoch (plus some other conditions!). Therefore, the on-chain FFG mechanism cannot detect all deterministic instances! In short, this on-chain mechanism is solid, but not perfect.
The specification of the FFG mechanism on the chain is very simple:
The first step is to check the plausibility of the block, that is, use the attestation from the latest two epochs to verify the plausibility of the latest two epoch boundary blocks.
The next step is to check the finality of the block, that is, check the finality of the last two epoch boundary blocks. Deterministic checks will only use 4 source block-destination block pairs (to improve performance and simplify specification) The backtracking distance is also limited).
image description
- Checkpoint status in deterministic checks (yellow blocks are justified, red blocks are finalized) -
Although the Casper FFG mechanism outlines the rules for ensuring block certainty, it does not mention how the mechanism ensures network liveness (Note: This article does not attempt to prove the liveness of the network, but outlines the process that is expected to achieve liveness. Think For a more rigorous analysis, see this article). This section mainly introduces two major considerations about liveness:
The fork selection rule used by validators to determine which block is the top of the chain
The block and attestation generation scheme followed by validators
secondary title
HLMD GHOST Fork Selection Rules
A validator proposing a block must first determine the (locally observed) tip of the blockchain. To do this, they need to use the Hybrid Latest Message Driven (HMLD) GHOST fork selection rule.
The specification for this fork selection is as follows:
Blocks that do not use the rationalized block identified in step 1 as the latest rationalized block are all excluded
Use the normal LMD GHOST rules to walk down the block tree until a leaf block is found.
For more information on fork selection, see the "Hybrid LMD GHOST" section of this post.
secondary title
Validator Program
Proposal Schedule: The system will assign a validator to each slot in each epoch to act as a block proposer. The verifier will find the top of the chain on the block tree of the local view according to the fork selection rule, and then generate a new sub-block. The verifier can package the attestation it sees into the block to get rewards. These attestations are fed into the on-chain FFG mechanism for computation when certainty checks are run.
Witness Plan (Attestation Schedule): In each epoch, each validator must (at a specific slot) generate an attestation. In fact, on each epoch, the entire validator set will be randomly divided into SLOTS_PER_EPOCH committees of equal size, and each committee will be assigned to a specific slot in the current epoch to generate attestation. When generating an attestation, the verifier will take the latest finalized block as the source checkpoint according to its local view, and use the checkpoint closest to the top of the chain as the target checkpoint (initiating FFG voting).
https://github.com/ethereum/eth2.0-specs/tree/dev/specs/phase0
