Ethereum 2.0: How to achieve finality?

Editor's Note: This article comes fromUnitimes（ID：Uni-times）Editor's Note: This article comes from

, Author: Bruno Škvorc, Compiler: Summer, reprinted by Odaily with authorization.

First, let's try to understand what finality is. [Remarks: There are also translations that translate finality into "certainty"]

You must have noticed that cryptocurrency platforms and Dapps (decentralized applications) usually wait for several blocks to be finalized before considering your transaction as "confirmed". This is a way of ensuring that a transaction has been "nearly" finalized, or that the transaction is "almost" irreversible, that is, the transaction has been "finalized".

Ethereum 2.0 can provide the guarantee of finality, which is an objective fact enshrined in the Ethereum blockchain, rather than a "near" state. This is very important because it enables faster on-chain communication, i.e. if a block has just been finalized, the block will not have to wait for multiple confirmations.

That said, Proof-of-Work-based blockchains (such as Bitcoin) never included features that make transactions truly final; whereas Ethereum 2.0 chains are designed to provide stronger finality guarantees than Proof-of-Work.

• Let's be more specific. First look at a few definitions:

• LMD GHOST is the fork selection rule used by Ethereum 2.0 (that is, the rule used to determine which chain is the "authoritative chain"). The full name is "Last Message Driven Greediest Heaviest Observed SubTree (GHOST driven by the latest news)"

• Casper FFG is the proof-of-stake (PoS) mechanism used by Ethereum 2.0, and its full name is "Casper the Friendly Finality Gadget (Casper the Friendly Finality Gadget)"

• In the Ethereum 2.0 chain, each generation of 64 blocks (about 6.4 minutes) is called an epoch;

• In the Ethereum 2.0 system, slot is the time required to generate a new block, that is, the time required for a new block to be proposed and proved correct. Each slot is set to 6 seconds, but not every new block will be generated during each slot. The last slot during each epoch is called checkpoint (checkpoint).

Based on the above information, we continue to discuss Justification (proof) and Finalization (finality).

Casper FFG

secondary title

Casper is a method for attesting and finalizing blocks (whether they are produced by the blockchain platform in general or during epochs in the Ethereum 2.0 chain). Casper is a general-purpose "gadget" that can be added to any blockchain that needs to achieve finality, but Casper is most useful in PoS blockchains.

Finality in Ethereum 2.0 is the concept that the system determines that there will not be two competing, finalized checkpoints, and that when this happens, at least one-third of active validators Violators will be slashed. We call it economic finality.

You may wonder, why is it that one-third of the validators will be slashed? We know that in the Ethereum 2.0 system, two-thirds of the verifiers must be honest verifiers to participate in verification (that is, to vote), so if there are two competing and finalized checkpoints in the system, then It means that two-thirds of the validators voted for one of the checkpoints, and at the same time, two-thirds of the validators voted for the other checkpoint, that is, at least one-third of the validators voted for this checkpoint. If both checkpoints have voted, these verifiers will be considered by the system as malicious verifiers and will be slashed accordingly.

For the verifier, the greatest benefit comes from correctly finalizing the beacon state, rather than performing improper malicious operations.

So what does "finalized" in "finalized checkpoint" mean? Before explaining this, we need to explain what "justification" is.

The proof is that validators decide which checkpoint is the top block of the beacon chain by voting on the checkpoint. If two-thirds of the verifiers (that is, the vast majority of verifiers) reach a consensus on two consecutive epochs, so that the two consecutive epochs are justified, and the previous epoch is considered finalized ( finalized).

NOTE: The above definitions are largely simplified for ease of understanding. A number of other factors are also involved, but this is beyond the scope of this article.

Thus, a "finalized" epoch is really a "proven" epoch, with one key difference - when something is "proven", you can still go back in time and reprove it ; but when you "seal" something, it becomes very difficult to rewrite history.

In other words, if something is "finalized", it must mean that it has been "proven", and that something has been "proven" does not necessarily mean that it has been "finalized".

Validators therefore attest/finalize epochs by voting, which is how validators vote on the latest known valid state of the Ethereum blockchain.

LMD GHOST

secondary title

This is where the fork choice rule comes into play.

GHOST is actually a very popular protocol on PoW (Proof of Work) and other blockchain platforms. The GHOST protocol follows the "heaviest" subtree, which is the longest chain.

In the Bitcoin blockchain, the "heaviest" branch is the chain that puts the most computing power into its blocks, which is also the longest chain. Obviously the longest chain is what we call the "canonical chain", but it is still possible for this chain to switch to another forked chain (although the possibility is very small), so the finality of the longest chain is a probability sexual.

LMD makes "messages" work, meaning that finality on the Ethereum 2.0 chain is "driven by the latest news." The message is the attestation, and what it all boils down to is that the forked chain with the most votes will be considered the "authoritative chain".

In the figure above, although the forked chain at the top is the longest chain, the chain of green blocks below is the "authoritative chain" because the green blocks contain the most proofs and are also That is, having the most validator votes.

Gasper

secondary title

Let's take a look at this slide from Ethereum researcher Justin Drake's talk about Eth2.0 at the EthCC conference.

image description

slide 1

In the figure above, the two dotted boxes show illegal situations in fork selection. The dotted box on the left above shows that if you vote for two different state roots at the same time, it is an illegal vote, that is, you cannot vote for two different content (state roots) at the same time The epoch.

The dashed box on the upper right shows that you cannot skip certain epochs and vote for later epochs. In other words, you cannot vote for future epochs before voting for the current candidate epoch.

Let's look at the second slide.

image description

According to the above, it is illegal to vote for two epochs with different content at the same time. In the case where the bottom half of slide 2 contains two forked chains, the two epochs (red dots) in the upper forked chain have been finalized (finalized), so it seems that the upper forked chain The chain is valid; but the forked chain below also contains two epochs that were finalized, but those two epochs were finalized later!

image description

slide 3

This means that the forked chain below is an invalid fork, because if voting follows the two finalized epochs below, it will mean that a newly voted epoch will follow one from the other fork The epoch of the chain. This is illegal because finalized checkpoints must be in chronological order. If this happened, the large number of validators would be severely penalized, since the majority of validators voted for an epoch on an "illegal chain". Therefore, these validators must be punished.

That's it! If you are a validator, make sure you only vote once per slot period, and make sure you are voting what everyone else is voting. To avoid being forfeited! (Don't worry, these will all be built into the Ethereum 2.0 client you use)