In Casper FFG, a checkpoint takes two voting sessions to be finalized.
Say checkpoint c. First, c needs to be voted to be justified (supermajority link c'->c). Then, c needs to be voted again to be finalized (c->c''). Why is the finalized phase necessary? If c already received >2/3 votes in the first round, why can't we be sure that it should be included in the canonical chain?
Although if a checkpoint has already received >2/3 votes in the first round and is justified, we can't be sure that it would be included in the canonical chain because although reorganization is unlikely at this phase, it's still possible, and all that takes is either a large network delay or attack on the network.
Because of this, a finalized phase is necessary because the probability that a finalized block to be reorganized is extremely unlikely, as it requires >2/3 of validators to finalize a competing chain. Reorganizing a finalized block also requires at least 1/3 of the total staked ether to be slashed, which is always expected to cost the attacker millions of ETH.
So a finalized epoch is a really really justified epoch, in essence, with one key difference - when things are justified, you can still rewind time to go to that point. When you finalize, it becomes incredibly difficult to rewrite history.
See:
https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer
https://our.status.im/two-point-oh-justification-and-finalization/
A great explanation can be found in the eth2book: https://eth2book.info/capella/part2/consensus/casper_ffg/#justification-and-finalisation
The idea is that the justification and the finalization represent the two rounds in the block validation process.
Why do we need a two-round process?
Round 1: I broadcast my view of the current epoch's checkpoint to the rest of the network, and I hear from the rest of the network what their view is. If a supermajority tells me that they also support the same view, that allows me to justify it. Justification is local to my network view. But I don't yet know that the rest of the network has come to the same conclusion.
Every node (validator) has its own view of the state based on many different obstacles like network conditions, bugs, performance issues, etc. So in case I use a problematic node for JSON_RPC provider it may tell me that a consensus is achieved on this epoch, but it only shows its own point of view which may be wrong.
That's why we need a second round.
Round 2: I broadcast the fact that I've heard from a supermajority of validators that they support the given state (in other words I share the justification) and I hear from the rest of the network whether they believe that a supermajority of validators supports X (that is, that they have justified the state). If I hear that a supermajority of validators agree with me that this state is justified, then I will finalize that state.
Now I as validator (node) know that the other validators have also received valid confirmations and they've updated their state the same way I've made it so when you ask my JSON_RPC about this block I can times more confidently say that this state is finalized.
Not only I've accepted the state with the received attestations from the other validators, but I know that the other validators also accepted the state based on the attestations they received from the other validators.
I can share more information about the risks of reorganization for justified and finalized blocks and why they are like that, but you can find this information in the eth2book (link above) so better keep the answer shorter.
