Checkpoints in the Beacon Chain

One critical question in PoS is what the correct chain is. Blockchains can fork (intentionally or unintentionally), and it is crucial that the network eventually agrees on one head of the blockchain. With PoS, this is not trivial, as there is the fundamental problem of “nothing at stake”. To help participants to decide what the correct fork is and to accelerate finality, Ethereum 2.0 uses checkpoints. A checkpoint tells the network that all blocks before this checkpoint cannot be forked anymore. Or in other words, all forks that appear before the checkpoint are considered invalid and being ignored.

In Ethereum 2.0, a checkpoint is the first slot in an epoch. If this slot doesn’t contain a block, the preceding most recent block becomes the checkpoint. Each epoch has a checkpoint. And a block can be a checkpoint for multiple epochs.

Attestors vote for the checkpoint of the current epoch. This checkpoint is called the target. This vote also includes an earlier checkpoint called the source.

Votes are submitted in every block of an epoch.

All validators of an epoch can cast votes for checkpoints. If checkpoint C at the end of an epoch gained 2/3 of all votes (supermajority) it becomes justified. If checkpoint D in the following epoch becomes justified, checkpoint C becomes finalized. And with checkpoint C finalized, all preceding blocks become finalized too.

So, in order to become finalized a checkpoint takes two epochs.

The supermajority is calculated according to the balances of all validators. If all validators have the same balance of 32 ETH, we would need 2/3 of all validators to gain the necessary supermajority.

But it is possible that a single staker staked more than 32 ETH, and hence controlling more than one validator.

A block can be justified within its epoch, but finalization always needs at least one more epoch.