Ethereum Consensus

For public chains, durable settlement is the core promise. If history can be cheaply rewritten, the system cannot secure real value.

Decentralized constraint

That promise must be achieved under decentralization. There is no central sequencer or final authority: many independent nodes must verify the same history and reach the same conclusion. This distributed, adversarial setting is exactly why public chains can resist tampering—but it also makes agreement harder.

Time cost

Because agreement is harder, durable settlement costs time. The network is distributed, messages propagate with delay, and validators need time to observe, vote, and converge. Strong finality is therefore intentionally slower than raw block production.

At the same time, products cannot run on “wait 10+ minutes” UX. Wallet status, swap feedback, and exchange interaction all need a fast signal in seconds.

In other words, public chains need to answer two questions continuously: what happened most recently, and what part of history should now be treated as durable.

Ethereum’s proof-of-stake design solves this by separating the fast answer from the durable answer. The rest of this page explains how.

Split and cadence

Now we can name the two protocol tracks precisely:

  • fast track: update the best head quickly for live interaction,
  • durable track: finalize history with stronger settlement guarantees.

Ethereum runs both tracks on one shared clock:

  • epoch = 32 slots (~6.4 min)
  • checkpoint = epoch boundary anchor

So the latest chain view can update at slot cadence, while finality advances at epoch cadence. We will call that latest view “head” in the next section.

slotepoch

Fork and vote

In a distributed network, messages arrive at different times. In that gap, different nodes can briefly see different latest blocks, creating temporary forks.

Voting is the convergence mechanism:

  • validators publish attestations for what they observed,
  • fork choice uses stake-weighted votes to select the best live branch,
  • finality uses accumulated supermajority votes to lock history.
forkheadaltvote

So forks are a normal effect of asynchronous propagation, and voting is how the protocol converges to one canonical history.

That convergence signal is exactly the input used for head selection.

Head selection

Head selection means choosing the chain tip to follow right now.

At each fork, follow the branch supported by the strongest latest validator weight.

This is handled by LMD-GHOST.

Formal weight for a child subtree c:

w(c)=∑v∈Vbal(v)⋅1[latest(v)∈subtree(c)]w(c)=\sum_{v\in V}\text{bal}(v)\cdot\mathbf{1}[\text{latest}(v)\in\text{subtree}(c)]

Minimal shape:

head = root
while has_children(head):
    head = argmax(children(head), key=weight)

What this means operationally:

  • only each validator’s latest vote counts,
  • weight is stake-weighted,
  • brief head disagreement during propagation is normal.
LMD-GHOST weight
eff(A)=latest(A)+boost(A), eff(B)=latest(B), head=argmax(eff).

Finality mechanism

Head logic answers “what to follow now.”

Finality logic answers “what is durable enough to settle on.”

That second track is Casper FFG.

Instead of reasoning over every block, it reasons over checkpoint links.

A link s -> t is supermajority when:

voteWeight(s→t)≥23W\text{voteWeight}(s\to t)\ge\frac{2}{3}W

Transition sketch:

if justified(s) and supermajority(s, t):
    justified(t) = True
 
if justified(s) and justified(t) and epoch(t) == epoch(s) + 1:
    finalized(s) = True

Readable interpretation: justify child, then finalize parent.

FFG votes
n+1: justified
n+2: justified
n: finalized

Safety enforcement

Once finality is defined, the next question is enforcement: what stops validators from voting inconsistently across branches?

Answer: conflicting voting behavior is slashable.

Two slashable patterns:

  • double vote
  • surround vote
double-vote: t1=t2 ∧ vote1≠vote2\text{double-vote: } t_1=t_2\ \land\ vote_1\neq vote_2 surround-vote: s1<s2<t2<t1 ∨ s2<s1<t1<t2\text{surround-vote: } s_1<s_2<t_2<t_1\ \lor\ s_2<s_1<t_1<t_2
Slashing rules
double: same target + distinct vote2; surround: one interval strictly contains the other.

So safety is backed by stake at risk, not only social agreement.

Liveness recovery

Safety alone is not enough; a live chain must also recover when participation drops.

If participation falls, finality can pause temporarily.

Inactivity leak then reduces effective non-participating stake over time, allowing active honest validators to regain supermajority and resume finality.

Product mapping

From here, protocol states map directly to product risk tiers:

  • head: fastest, highest reorg risk
  • safe: stronger than head
  • finalized: strongest settlement confidence

Use finalized for high-value irreversible transitions.

One-line model

LMD-GHOST picks the present best head; Casper FFG locks history over time.

That is Ethereum consensus in practical terms.

Spec anchors

References