Casper FFG

Casper FFG operates on a series of checkpoint blocks, which are blocks at regular intervals (e.g., every 100 blocks). The protocol's primary job is not to choose every block, but to finalize these checkpoints. This abstraction separates block proposal (handled by the underlying chain, like Proof of Work) from finalization (handled by Casper).

• Checkpoints form a tree structure, with each checkpoint referencing a parent.
• Finalizing a checkpoint implicitly finalizes all blocks and checkpoints leading up to it.

Finality is achieved through a two-round voting protocol conducted by validators who have staked cryptocurrency. Each round requires a supermajority (typically 2/3) of the total staked value to agree.

• PREPARE Vote: Validators vote to attest a link between a source checkpoint (already justified) and a target checkpoint.
• COMMIT Vote: Once a checkpoint receives enough PREPARE votes, it becomes justified. Validators then vote to attest a direct link from this justified checkpoint to a genesis or previously finalized checkpoint. A checkpoint that receives a supermajority of COMMIT votes becomes finalized and irreversible.

To prevent validators from acting maliciously and compromising safety (e.g., finalizing two conflicting checkpoints), Casper FFG defines slashing conditions. If a validator's signature is found to violate these rules, their staked funds are partially or fully destroyed (slashed). The key conditions are:

• Double Voting: Signing two distinct votes for the same target height.
• Surround Voting: Signing a vote that "surrounds" a previous vote (e.g., voting for a newer source checkpoint and an older target checkpoint). These rules make it economically irrational for a validator to attempt to finalize conflicting histories.

Casper FFG is designed to be plausibly live. This means that regardless of what has happened in the past (e.g., validator failures, network partitions), it is always possible for new blocks to be finalized in the future, provided a sufficient subset of validators follows the protocol. This property prevents the network from stalling permanently. It is achieved because the slashing conditions only punish validators for creating contradictions; they do not punish validators for simply not voting. This allows the protocol to recover and continue finalizing new checkpoints after periods of inactivity.

In its original conception for Ethereum, Casper FFG was designed as a hybrid consensus layer. The underlying chain (e.g., Ethereum 1.0) used Proof of Work (Nakamoto Consensus) for block proposal and probabilistic consensus. Casper FFG was then overlaid on top, periodically taking snapshots (checkpoints) of the PoW chain and running its two-phase voting protocol to provide provable finality. This combined the censorship-resistance and permissionless entry of PoW with the strong, unambiguous settlement guarantees of Proof-of-Stake finality.

A core innovation of Casper FFG is accountable safety. If the protocol's safety property is ever violated—meaning two conflicting checkpoints are finalized—the protocol's cryptographic design allows the network to identify and slash at least 1/3 of the total staked value belonging to the validators who misbehaved. This is stronger than classic Byzantine Fault Tolerance (BFT), which only guarantees safety if less than 1/3 are faulty. Casper provides a cryptoeconomic guarantee: not only does safety hold if less than 1/3 are Byzantine, but if it breaks, the offenders are financially punished and identifiable.

Finality is the irreversible guarantee that a block and its transactions will never be reverted. Casper FFG was designed specifically to provide provable cryptographic finality, which is stronger than the probabilistic finality of Nakamoto Consensus.

• Checkpoint Finality: In FFG, epoch checkpoints become finalized after a two-phase vote.
• Safety vs. Liveness: Finality is a safety property, ensuring agreement on history. It contrasts with liveness, which ensures new blocks are produced.
• Enterprise Critical: Applications requiring absolute settlement (e.g., high-value transactions) depend on protocols with finality guarantees.

Byzantine Fault Tolerance (BFT) is the property of a distributed system to reach consensus despite arbitrary (Byzantine) failures of some components. Casper FFG is a BFT-inspired consensus mechanism.

• Fault Model: Tolerates validators that are malicious, faulty, or offline, up to a threshold (typically < 1/3 of staked weight).
• Voting Rounds: Its two-phase voting protocol is a classic BFT pattern for achieving agreement.
• Distinction: Unlike traditional BFT protocols (e.g., PBFT) that require known validators, Casper FFG is designed for a large, dynamic validator set common in public blockchains.

A validator is a network participant responsible for proposing and attesting to blocks in a Proof-of-Stake system. In Casper FFG, validators are the actors who participate in the checkpoint voting process.

• Staking Requirement: Validators must stake a significant amount of the native cryptocurrency as collateral.
• Duties: Propose blocks for the underlying chain (e.g., a PoW or PoS chain) and cast votes on checkpoints for the FFG overlay.
• Slashing: Validators can be slashed (lose part of their stake) for provable violations like equivocation (voting for two conflicting checkpoints).

Slashing is the punitive mechanism in Proof-of-Stake systems where a validator's staked funds are confiscated for provably malicious behavior. It is a core incentive alignment mechanism in Casper FFG.

• Slashing Conditions: Penalizes safety faults (e.g., voting for two conflicting checkpoints) and liveness faults (e.g., being offline).
• Economic Security: The threat of slashing disincentivizes attacks, as the cost outweighs potential gain.
• Implementation: Slashing rules are codified in the protocol's cryptoeconomic design, making Byzantine behavior financially irrational.

A checkpoint is a special block (typically the first block of an epoch) that is subject to Casper FFG's two-phase voting process. Checkpoints form the backbone of the finality mechanism.

• Epochs: The chain is divided into epochs (e.g., 32 blocks in Ethereum). The first block of each epoch is a checkpoint.
• Two-Phase Vote: Validators first vote to attest a checkpoint, then vote to justify it. A justified checkpoint that receives another round of votes becomes finalized.
• Graded Security: Blocks gain increasing security as they are included in justified and then finalized checkpoints.