If you have encountered the terms of justification and finalization in the process of learning about Ethereum 2.0, but don't know what they mean, I hope this article can give you some inspiration.
First, we try to understand what finality is . [Note: There are also translations that translate finality into "certainty"]
- Vitalik Buterin said Ethereum did not roll back the deal after TheDAO incident and was criticized by netizens
- Under the double black swan, where is the coin circle?
- BTC short-term test for $9,800 resistance, the disk is not stable, should not chase
- Important Ethereum Capacity Expansion Solution: Optimistic Rollup Status Report (Part 2)
- Wind vane, senior US CFTC official: willing to approve a compliant Ethereum futures contract
- China and the United States upgrade each other, BTC welcomes golden moments
You must have noticed that the cryptocurrency platform and Dapps (decentralized applications) usually wait for several blocks to be finalized before treating your transaction as a "confirmed" status. This is a way to ensure that a transaction is "nearly" determined, or that the transaction is "almost" irreversible , that is, the transaction has been "finalized."
Ethereum 2.0 is able to provide a guarantee of finality, an objective fact that the Ethereum blockchain is sacred, not a “near” state. This is very important because it enables faster on-chain communication, ie if a block has just been finalized, the block will not have to wait for multiple acknowledgments.
That is to say, blockchains based on proof of work (such as bitcoin) never contain features that make the transaction truly final; the Ethereum 2.0 chain is designed to provide a more final guarantee than the proof of the workload.
Let us explain it more specifically. First look at a few definitions:
LMD GHOST The fork selection rule used by Ethereum 2.0 (the rule used to determine which chain is the “authoritative chain”), the full name is “Last Message Driven Greediest Heaviest Observed SubTree (GHOST by the latest news)”
Casper FFG is a Proof of Entitlement (PoS) mechanism used by Ethereum 2.0, the full name is “Casper the Friendly Finality Gadget” (Casper the Friendly Finality Gadget)
In the Ethereum 2.0 chain, each block is generated (about 6.4 minutes) is called an epoch;
In the Ethereum 2.0 system, slot is the time it takes to generate a new block, the time it takes for a new block to be proposed and proven correct. Each slot is set to 6 seconds, but not every new block will be generated during each Slot. The last slot in each epoch period is called the checkpoint.
The Committee is a set of verifiers randomly selected by the beacon chain during each slot (the number of target verifiers per committee is 128), and the first randomly selected verifier in each committee will have a chance. A new block is proposed during the slot, and other validators of the committee will attest the proposed block.
Based on the above information, we continue to explore Justification and Finalization.
Casper is a way to prove and finalize blocks (whether it's a normal blockchain platform or a block generated during an epoch in the Ethereum 2.0 chain). Casper is a generic "gadget" that can be added to any blockchain that needs to be finalized, but Casper is most useful in the PoS blockchain.
The finality in Ethereum 2.0 is the concept that the system determines that there will be no competing, finalized checkpoints , and when this happens, at least one-third of the active verifications The person will be slashed. We call it economic finality.
You may want to ask, why is one-third of the verifiers being fined? We know that in the Ethereum 2.0 system, it must be ensured that two-thirds of the verifiers are honest verifiers to participate in the verification (ie, voting) , so if there are two competing, finalized checkpoints in the system, then This means that two-thirds of the verifiers vote on one of the checkpoints, and two-thirds of the verifiers vote on the other checkpoint, that is, at least one-third of the verifiers Both checkpoints are voted, and this part of the verifier will be considered a malicious verifier by the system and will be penalized.
For the verifier, the biggest benefit comes from correctly correcting the beacon state, rather than performing improper malicious operations.
So what does “finalize” in “finalized checkpoints” mean? Before we explain this, we need to explain what is “justification”.
The proof is that the verifier decides 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) agree on two consecutive epochs, then the two consecutive epochs are justified, and the previous epoch is considered finalized ( Finalized) .
Note: The above definitions have been simplified to a large extent for the purpose of easy understanding. Some other factors will also be involved, but this is beyond the scope of this article.
Therefore, a “finalized” epoch is actually an epoch that has been “proven,” but there is a key difference – when something is “proven,” you can still revert the time back to re-certification. But when you "finalize" something, it becomes very difficult to rewrite history.
That is to say, something "finalized" must mean that the matter has been "proven", and that something is "proven" does not necessarily mean that the matter has been "finalized" .
It should be noted that when the verifier proves or pings the epoch, it does not mean that the verifier is voting on the epoch itself, but rather that the verifier is voting/verifying the "content" during the epoch period, this "content" Is the state root of the last slot (ie, checkpoint) during each epoch.
Therefore, the verifier is to prove/finalize the epoch by voting, which is how the verifier votes for the latest known valid status of the Ethereum blockchain .
This is where the fork selection rules come into play.
GHOST is actually a very popular protocol on PoW (workload proof) and other blockchain platforms. The GHOST protocol follows the "heaviest" subtree, the longest chain.
In the Bitcoin blockchain, the "heaviest" branch is the one that puts the most computational power into its block, which is the longest chain . Obviously the longest chain is what we call the "canonical chain", but it is still possible to switch to another forked chain (although the probability is small), so the finality of the longest chain is probability. Sexual .
LMD has made "messages" work, that is, the ultimate in the Ethereum 2.0 chain is "driven by the latest news." The message is attestation, all of which comes down to the fact that the forked chain with the most votes will be considered the “authoritative chain” .
The above picture shows the fork-selection rules driven by the latest news: the green block represents the block proved by the LMD GHOST fork selection rule, and the smiley symbol represents the latest attestations, in a block The total amount of proof (the total number of smiles) is the weight of the block, expressed as a number in the block.
In the above figure, although the bifurcated chain at the top is the longest chain, the chain consisting of green blocks below is the “authoritative chain” because the green block contains the most proof. It is the most certifier vote .
Let's take a look at this slide from Ethereum researcher Justin Drake at the EthCC conference about Eth 2.0.
The dotted box on the top right shows that you can't skip some epoch and vote on the next epoch . In other words, you can't cast a future epoch before voting for the current candidate epoch.
The lower part of the figure above shows the two forked chains that have been finalized. The first and second epochs, which are represented by red dots, are the "authoritative chains" that have been finalized, since the two epochs are followed by the third and fourth (indicated by red dots) epoch . However, the third and fourth epoch are present in two parallel bifurcation chains. Which of these two bifurcation chains belongs to the “authoritative chain”?
Let's take a look at the second slide.
That's it! If you are a certifier, make sure to vote only once during each slot and make sure that you are casting and that others are casting. To avoid being fined! (Don't worry, these will be built into the Ethereum 2.0 client you use)
I hope this article will give you a clearer understanding of justification and finalization. If you still have an unclear party, please let me know (Twitter @bitfalls)! Many thanks to Dustin Brody, Mamy Ratsimbazafy, Justin Drake, and Danny Ryan for their help in writing this article!
Author: Bruno Škvorc