Epoch 00–31
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Epoch 132–63
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Slot 30360s
Choose a head now. Finalize history as votes accumulate.
Two blocks can both pass execution checks 
and still disagree about transaction order. Which one should a node follow? And when can it stop expecting that choice to change?
Ethereum uses LMD-GHOST to select the current head, and Casper FFG to finalize older history. Together they form Gasper. They use votes from the same validators, but answer different questions.
One clock, two timescales
A slot is a 12-second opportunity to propose a block. One proposer is selected for each slot; a missed proposal leaves an empty slot. Time advances anyway.
An epoch contains 32 slots: 384 seconds, or 6.4 minutes. A checkpoint pairs an epoch number with the block root at its boundary. If that slot is empty, it references the most recent preceding block.
Slots & Epochs
Block production follows slots. Justification and finalization are processed at epoch boundaries. A slot passing does not guarantee a new block; an epoch passing does not guarantee finality.
What validators vote for
A validator’s attestation combines three references:
| Reference | Meaning |
|---|---|
| Head | The block it currently sees as the best chain tip |
| Source | A checkpoint it already considers justified |
| Target | The checkpoint for the epoch it is attesting to |
The head reference helps fork choice. The source → target link helps finality. Voting weight comes from effective staked balance, not the number of machines or received messages. Relaying one vote through ten peers does not create ten votes. See the attestation structure.
Messages take time to travel. One node may know about a block or vote that another has not received. A late block can also arrive after a proposer has already built on an older head. Nodes can therefore temporarily see different branches without either accepting invalid execution.
Choose the head: follow subtree weight
Start at the justified checkpoint and consider the branches compatible with the node’s checkpoint rules. At each fork, count the latest eligible vote from each validator. A vote for a descendant supports the whole branch leading to it.
Choose the heavier child, then repeat until there are no more children. This is the core of Latest Message Driven Greediest Heaviest Observed SubTree, or LMD-GHOST.
Fork Choice
Subtree stake
In the initial example, B1 has 40 stake directly behind it. A1 has 35 and A2 has 25. But A’s whole subtree has 60, so the walk enters A first, then chooses A1. Counting only votes on individual tips would miss that first decision.
“Latest” also matters: when a newer eligible message replaces an older one, the validator’s weight moves instead of accumulating. The interactive example shows that accounting, not a recommendation to change signed votes arbitrarily.
The full fork-choice specification also includes timing checks, checkpoint filtering, deterministic tie-breaking and proposer boost. The example isolates subtree weight. Selecting a head does not require a two-thirds vote.
Finalize history: vote between checkpoints
Finality uses a different threshold: a source → target link needs at least two-thirds of the total active effective balance, not merely two-thirds of whichever validators happened to vote.
A checkpoint is justified when it receives the required support from an already justified source. On the normal consecutive-epoch path, a supermajority link from a justified checkpoint to the next epoch justifies the target and finalizes the source.
Finality
Epoch 0
C0
Justified
Epoch 1
C1
Pending
Epoch 2
C2
Pending
C0 → C164 / 96 stake
⅔ · 64
Follow one checkpoint, C1: the link C0 → C1 justifies it; the later link C1 → C2 finalizes it. C0 was already justified at the start, so it can become finalized on the first link shown. “Two steps” describes C1’s progression, not two extra links required after a checkpoint is already justified.
Finalizing a checkpoint also finalizes its ancestors. Newer blocks can remain part of the chosen chain while still being unfinalized. Under normal participation, finality takes roughly two epochs; inclusion time and vote processing affect an individual transaction’s wait. It is not a fixed countdown.
This is the normal path. The epoch-processing rules also handle delayed justification patterns.
Why conflicting finality is costly
Validators put stake behind their votes. Two attester behaviors can prove a slashable offense:
- Double vote: two different attestations with the same target epoch.
- Surround vote: one source–target interval strictly contains another.
Slashing
Under Casper’s safety assumptions, finalizing conflicting checkpoints requires at least one-third of stake to have violated slashing rules. This gives finality an economic basis. It does not mean a client normally reorganizes finalized history after someone pays a fee; conflicting finality is a protocol failure requiring recovery outside ordinary fork choice. See the Casper FFG paper.
Blocks can continue while finality stalls
Imagine only 60 of 100 stake units participate. Those validators may still propose blocks and select a head. They cannot supply the roughly 66.7 units needed for a supermajority link.
After an extended period without finality, the inactivity leak increases penalties for validators missing target votes. Their declining balances can eventually let participating validators regain a two-thirds share. This recovery takes time; it is not an immediate fallback vote. The Altair rules define inactivity scores and penalties.
What an application sees
Execution APIs expose different points along this history:
| Block tag | What it tells an application |
|---|---|
latest | The node’s current execution head. Recent inclusion can be reorganized. |
safe | The execution block marked safe by the consensus client; stronger confidence, still not finalized. |
finalized | The execution block covered by the finalized consensus history. |
These are positions reported by a node, not three timers running on each transaction. The Engine API passes them as distinct fork-choice state fields.
A receipt answers whether a transaction was included and whether its execution succeeded. Settlement requires checking whether its block is still canonical and has reached the confidence level the application needs. For example, an interface can show inclusion immediately while an irreversible withdrawal waits for finality.
The two articles meet here: execution checks the computation; consensus selects and finalizes the history containing it.
References
- Gasper overview — how fork choice and finality cooperate.
- Mainnet configuration and phase0 preset — slot duration and epoch size.
- Gasper paper — protocol analysis.