# LMD GHOST and Casper FFG

### Understanding the Difference Between Consensus and Finality

In [previous article](https://hackmd.io/@ayoola/ryDFwqXzZe), we separated **sybil resistance mechanisms** from **consensus protocols**. With Ethereum’s proof-of-stake design, there is another important split inside the consensus layer itself: Consensus and Finality.

* **LMD GHOST** decides *which block is currently the head of the chain*. - Consensus
* **Casper FFG** decides *which part of the chain is irreversible*. - Finality

Together, these two protocols form **Gasper**, the consensus mechanism that secures Ethereum’s beacon chain: [Vitalik Buterin, Diego Hernandez etal](https://arxiv.org/abs/2003.03052).

If we treat them as one monolithic “PoS consensus”, we miss why the protocol is structured this way, how liveness and safety are balanced, and why some blocks can be reorganized while others are effectively set in stone.

---

## Head vs Finalized: Two Different Questions

A running blockchain answers two related but distinct questions at any point in time.

1. **What is the current head of the chain?**
This is the block new transactions should build on. It may still change if the network sees a better branch.

2. **Which part of history is finalized?**
These are blocks that the protocol promises will never be reverted, unless a large fraction of validators are slashed.

LMD GHOST is responsible for the first question. Casper FFG is responsible for the second. Ethereum’s specs describe them explicitly as two separate consensus protocols that are composed: LMD GHOST “essentially provides liveness”, Casper FFG “provides finality”: [eth2book.info](https://eth2book.info/latest/part2/consensus/lmd_ghost/).

Once we keep this distinction in mind, the rest of the design becomes easier to follow.

---

## LMD GHOST: Picking the Head with Weighted Votes

### Intuition: Walking the Heaviest Subtree

LMD GHOST stands for **Latest Message Driven – Greediest Heaviest Observed SubTree**. It is a **fork-choice rule** that, given a block tree and a set of validator votes (attestations/ or message as M in the name), it chooses a single block as the head: [Binance](https://www.binance.com/en/square/post/3626459485250).

The mental model looks like this:

* We start from a **justified** or **finalized** block as a root.
* At each step, we look at the children of the current block.
* For each child, we compute a score: how much validator voting weight supports that child and its descendants, considering only each validator’s latest attestation (that is the “latest message driven” part).
* We move to the child with the highest score.
* We repeat this process down the tree until there is no heavier child to follow. The block where we stop is the **head**.

### What LMD GHOST Guarantees

Since Ethereum prioritized liveness, LMD GHOST gives the chain **liveness** in the presence of forks:

* As long as honest validators keep voting for a common view of the chain, the heaviest subtree they support will eventually dominate.
* Nodes that follow the same fork-choice rule and see the same set of attestations will converge on the same head.

However, GHOST alone does **not** give a strong notion of irreversibility. If a different branch later accumulates more total voting weight (for example, because many validators reorganize their votes), GHOST will happily switch to that branch. That is fine for a live head, but not enough for “this transaction will never be reverted”.

This is where Casper FFG comes in.

---

## Casper FFG: Checkpoint Finality on Top of the Chain

### What a Finality Gadget Is

Casper FFG (“Friendly Finality Gadget”) is designed as a **finality overlay** that can sit on top of an underlying block proposal mechanism. The [original paper](https://arxiv.org/abs/1710.09437) describes it as a partial consensus mechanism that can “overlay an existing proof-of-work blockchain” and mark some blocks as finalized.

In Ethereum’s PoS design, Casper FFG is wired directly into the beacon chain, but its conceptual role is the same:

* It does not decide which block is proposed next.
* It does not scan every individual block.
* Instead, it works with **checkpoints** and validator votes between them to provide a strong finality guarantee.

### Checkpoints, Justification and Finalization

Time in the beacon chain is grouped into **slots** and **epochs**. Each epoch has a checkpoint (the block at the start of the epoch). Validators periodically vote on links between checkpoints.

Thus:

* A vote has a **source** checkpoint and a **target** checkpoint.
* Votes are weighted by validator stake.
* When at least two-thirds of the total stake votes for the same source→target pair, we say there is a **supermajority link**.

Casper FFG uses these supermajority links to evolve the chain of checkpoints:

* A checkpoint becomes **justified** when there is a supermajority link pointing to it from a previously justified checkpoint.
* A justified checkpoint becomes **finalized** when there is a supermajority link from it to a later checkpoint: [eth2book.info](https://eth2book.info/latest/part2/consensus/casper_ffg/).

Once a checkpoint is finalized, reverting it would require some validators to violate slashing conditions (for example by double-voting in incompatible ways). In practice, this means reverting finality would burn at least one-third of the total stake, which is an extremely expensive attack.

Finality, thus, is an **economic guarantee**: we accept that enough stake would be destroyed that it is irrational for honest participants to follow such a chain.

### Casper FFG Without GHOST?

If we ran Casper FFG alone, we would have a sequence of finalized checkpoints and justified checkpoints in between, but we would still need a rule for choosing the “best” non-finalized head between checkpoints. Casper does not define that rule; it assumes some underlying chain growth mechanism.

This is exactly why Gasper combines it with LMD GHOST.

---

## Gasper: Composition of Head Selection and Finality

The Gasper protocol, formalised in the “Combining GHOST and Casper” paper [Buterin, Vitalik ; Hernandez, Diego](https://arxiv.org/abs/2003.03052), explicitly composes these two ideas: LMD GHOST for fork choice, Casper FFG as a finality gadget.

We can picture it like this:

* **Block production and head selection**
Validators propose blocks and attest to them. LMD GHOST uses these attestations to walk the block tree and pick a head. This gives us a live, responsive chain tip that can incorporate new blocks quickly.

* **Checkpointing and finality**
Every epoch, checkpoints are identified. Validators’ attestations also double as Casper votes between checkpoints. When the Casper rules detect that enough stake has consistently voted for a certain sequence of checkpoints, earlier ones become finalized.

On any given beacon node, there are therefore two important pointers:

* the **GHOST head**: where new blocks are proposed and transactions first land;
* the latest **finalized checkpoint**: the boundary beyond which the chain is extremely unlikely to be reverted without catastrophic slashing.

We can think of GHOST as answering “What does the chain look like *right now*, given the freshest information we have?” and Casper FFG as answering “Which part of that chain has enough economic backing that we are willing to treat it as permanent?”

---

## How Consensus and Finality Interact in Practice

To picture this perfectly, lets look at a simple scenario.

Let's assume we have:

* Validators actively attesting, following LMD GHOST.
* Checkpoints every N slots.
* Casper FFG advancing justification and finality when enough attestations have accumulated.

A new transaction is included in a block near the head. For a while, that block is only **GHOST-canonical**: another branch with more attestations could still cause a reorg that drops it. As more blocks are built on top and more attestations come in, it becomes increasingly unlikely that this will happen, but it is not impossible.

Later, when enough epochs have passed and validators have voted consistently for the checkpoints containing this block, Casper FFG will finalize a checkpoint that is an ancestor of the block. At that moment, we have **finality**: reverting the block would require burning a large fraction of validators’ stake.

From an application’s point of view:

* For quick and low-value actions, we might treat “GHOST head plus a couple of confirmations” as good enough.
* For high-value actions, centralized exchanges or bridges usually wait until the transaction is safely before the latest finalized checkpoint.

---