Justified Checkpoint

A justified checkpoint achieves probabilistic finality, meaning it is considered irreversible unless an attacker controls more than one-third of the total staked ETH. This is a stronger guarantee than the 'longest chain' rule used in Proof-of-Work. The security model ensures that once a checkpoint is justified and finalized, rolling it back would require a catastrophic slashing event affecting a large portion of the validator set.

The primary security mechanism protecting justified checkpoints is slashing. Validators that vote for conflicting checkpoints (a surround vote or double vote) have a portion of their stake burned and are forcibly exited from the network. This cryptoeconomic penalty makes coordinated attacks economically irrational, as the cost to attack the chain would far exceed any potential gain.

The security of the checkpoint system hinges on two key thresholds:

• One-third (≥33%) of stake: An attacker controlling this much can prevent the chain from finalizing new checkpoints, causing a liveness failure.
• Two-thirds (≥66%) of stake: Required to finalize a checkpoint. An attacker with this majority could finalize a conflicting chain, causing a safety failure and rewriting history. Acquiring this stake is considered prohibitively expensive.

If more than one-third of validators go offline, the chain cannot finalize new checkpoints. To recover, the protocol triggers an inactivity leak, which gradually burns the stake of inactive validators. This reduces their voting power until the remaining active validators once again constitute a two-thirds supermajority, allowing finality to resume. This mechanism ensures liveness can be restored even after a massive correlated failure.

New nodes or those syncing after a long downtime cannot trust the longest chain alone; they require a weak subjectivity checkpoint. This is a recent, socially-agreed-upon justified checkpoint (e.g., from a trusted source) that serves as a trusted root. Starting from this point protects nodes from long-range attacks, where an attacker with old validator keys could create an alternative finalized history.

Justified checkpoints provide a different security model than other consensus mechanisms:

• vs. Nakamoto Consensus (PoW): Offers explicit economic finality instead of probabilistic confirmation depth.
• vs. Traditional BFT (e.g., Tendermint): Achieves finality in a partially synchronous model with a dynamic validator set, rather than requiring a fixed, known committee. This makes it more adaptable for public, permissionless blockchains.

In Ethereum's consensus layer, a justified checkpoint is a block that has received attestations from at least two-thirds of the total staked ETH. This is the first step in the Casper FFG (Friendly Finality Gadget) finality process. A checkpoint becomes finalized when it is followed by another justified checkpoint, creating an irreversible chain of attestations. This mechanism provides economic finality, where reverting a finalized block would require slashing at least one-third of the total stake.

Node operators use checkpoint sync (also called weak subjectivity sync) to bootstrap a consensus client rapidly. Instead of verifying the entire chain from genesis, the client downloads a recent justified checkpoint state from a trusted source (like another node or a public endpoint). It then verifies the BLS signatures of the attestations for that checkpoint, ensuring its validity before syncing forward. This reduces sync time from days to minutes and is essential for maintaining network health after outages.

The Weak Subjectivity Period is the time window during which a new or offline node must connect to the network using a recent justified checkpoint as a trusted starting point. For Ethereum, this period is approximately two weeks. This concept is critical because, in a PoS system, a node starting from genesis could be tricked by a long-range attack. Relying on a community-verified checkpoint within this period ensures the node joins the canonical chain.

The LMD-GHOST fork choice rule, which determines the canonical chain head, uses the latest justified checkpoint as its anchor. All validators build and attest to blocks that descend from this justified checkpoint. This ensures network consensus remains aligned even during temporary forks. The rule prioritizes the chain with the greatest weight of attestations that are consistent with the most recent justified state.

A justified checkpoint is central to Ethereum's slashing conditions. Validators can be slashed (lose stake) for two types of surround votes and double votes that violate the consensus rules around checkpoint justification. For example, a surround vote occurs when a validator's attestation surrounds a previously justified checkpoint, attempting to revert finality. The protocol detects these by comparing attestation source and target checkpoints.

Justified Checkpoint finality differs from other models:

• Probabilistic Finality (PoW): In Bitcoin, finality is probabilistic and increases with confirmations. A justified checkpoint provides cryptoeconomic finality after one epoch.
• Instant Finality (BFT): Some chains (e.g., Tendermint) have instant, absolute finality after one round. Ethereum's checkpoint model provides single-slot finality after two epochs (~12.8 minutes), balancing speed and decentralization.
• Accountable Safety: If two conflicting checkpoints are finalized, the protocol can identify and slash the malicious validators.

A finalized checkpoint is a justified checkpoint that has been justified in a subsequent epoch. This creates a chain of justifications, making reversion economically infeasible and providing the strongest guarantee of state permanence. Finality is a key security property distinguishing proof-of-stake from proof-of-work.

• Economic Finality: Reversing a finalized block requires slashing at least one-third of the total staked ETH.
• Two-Step Process: Justification is the first vote; finalization is the confirming vote in the next epoch.

Casper FFG is the proof-of-stake finality mechanism used by Ethereum. It operates alongside a block proposal mechanism (LMD-GHOST), periodically establishing justified and finalized checkpoints.

• Hybrid Model: Provides finality on top of a chain built by another consensus rule.
• Epoch Boundaries: Checkpoints are created at the first block of each 32-slot epoch (every ~6.4 minutes).
• Voting: Validators cast votes (attestations) linking a current checkpoint to a previous one.

These are the two fundamental properties of a consensus protocol, which checkpoints help balance.

• Liveness: The chain continues to produce new blocks even if some validators are offline or malicious. A chain with only justified but not finalized blocks maintains liveness.
• Safety: Validators never finalize conflicting checkpoints. Finalization provides safety, ensuring the chain cannot fork at a finalized point without catastrophic slashing.

A justified checkpoint enhances safety while the protocol works towards finality.

Weak subjectivity is a security assumption required in proof-of-stake systems like Ethereum's. It refers to the need for new nodes or validators returning after a long offline period to obtain a recent, trusted checkpoint (a weak subjectivity checkpoint) to sync correctly.

• Checkpoint Sync: Clients can bootstrap by trusting a recent justified checkpoint instead of verifying from genesis.
• Boundary: The weak subjectivity period is the time window (e.g., ~2 weeks in Ethereum) beyond which a node must obtain an external checkpoint to ensure it follows the canonical chain.

An attestation is a vote cast by a validator to support a specific block and checkpoint. It is the fundamental action that leads to justification and finalization.

• Content: Contains votes for a head block (for fork choice) and for a source and target checkpoint (for Casper FFG).
• Supermajority: A checkpoint becomes justified when attestations representing at least two-thirds of the total staked ETH are collected.
• Aggregation: Attestations are aggregated by committees to reduce network load.

Slashing is the penalty for a validator violating protocol rules, which secures the justification process. Two key slashing conditions protect checkpoint finality:

• Surround Votes: A validator cannot attest to a checkpoint that "surrounds" a previous vote (violating monotonicity).
• Double Votes: A validator cannot publish two distinct attestations for the same target epoch.

These conditions make it cryptoeconomically impossible for two conflicting checkpoints to be finalized, as it would require at least one-third of stake to be slashed.