Source-linked AI summary
Casper the Friendly Finality Gadget
Vitalik Buterin, Virgil Griffith
TL;DR
Casper addresses the need for stronger finality protections on proof-of-work blockchains by overlaying a proof-of-stake mechanism derived from Byzantine fault tolerance. It finalizes blocks and proves accountable safety and plausible liveness, while adding dynamic-validator support and defenses against long-range revisions. The system remains limited when the proposal mechanism is wholly compromised, and some attack recovery remains an open problem.
Problem
Proof-of-work chains need additional protection against block reversions, while proof-of-stake systems require mechanisms for finality, validator changes, and attacks such as long-range revisions.
Method
Casper overlays a proof-of-stake finality system on a block proposal mechanism, using BFT-derived rules, validator deposits, dynamic validator sets, and attack defenses.
Results
Casper provides accountable safety and plausible liveness, protects against conflicting finalized checkpoints, and adds defenses against long-range revisions and catastrophic crashes.
Takeaways & Limitations
Casper can provide almost any proof-of-work chain with additional protections against block reversions through a modular finality overlay.
Takeaways & Limitations
Casper cannot finalize new blocks when the proposal mechanism is wholly compromised, and exact recovery from some attacks remains an open problem.
Abstract
from arXiv · showhide
We introduce Casper, a proof of stake-based finality system which overlays an existing proof of work blockchain. Casper is a partial consensus mechanism combining proof of stake algorithm research and Byzantine fault tolerant consensus theory. We introduce our system, prove some desirable features, and show defenses against long range revisions and catastrophic crashes. The Casper overlay provides almost any proof of work chain with additional protections against block reversions.
1. Introduction
Casper is a proof-of-stake finality overlay for existing block proposal mechanisms, combining BFT-derived consensus with accountability, dynamic validators, and attack defenses. Its modular design supports upgrades to proof-of-work chains.
- Consensus foundation: Casper follows Byzantine fault-tolerant proof-of-stake research, whose protocols can mathematically prevent conflicting finalizations when more than 2/3 of participants act honestly.The paper modifies this tradition for a proof-of-stake finality overlay.
- System design: Casper overlays a block proposal mechanism to finalize blocks and select a unique canonical transaction chain.Its safety protects against conflicting finalized checkpoints, while liveness depends on the proposal mechanism.
- System features: Accountability detects rule violations and can penalize malfeasant validators by destroying their entire deposits, addressing the nothing-at-stake problem.The paper argues that security based on deposit penalties can provide stronger incentives than proof-of-work mining rewards.
- System features: Casper introduces a safe mechanism for changing the validator set over time.This dynamic-validator feature is added progressively after the simple protocol version.
- Defenses and deployment: Casper adds defenses against long-range revision attacks and attacks causing more than 1/3 of validators to go offline, with a weak tradeoff synchronicity assumption.The overlay structure also makes Casper easier to implement as an upgrade to an existing proof-of-work chain.
- Defenses and deployment: The modular overlay can initially use an existing proof-of-work chain as its proposal mechanism, enabling a hybrid PoW/PoS deployment.The paper describes Casper in stages, progressively adding validator-set changes and attack defenses.
2. The Casper Protocol
Casper overlays a proof-of-stake finality protocol on a block proposal mechanism, using checkpoints, validator votes, and supermajority links to select and finalize a canonical chain. It provides accountable safety and plausible liveness, while adding dynamic-validator support, attack defenses, and a fork-choice rule based on the highest justified checkpoint.
- Protocol model: Casper initially uses proof of work to propose blocks while its proof-of-stake overlay finalizes checkpoints.Future versions may replace the proposal mechanism with a more efficient proof-of-stake scheme.
- Checkpoint structure: Casper selects a single canonical chain from a potentially branching block tree by operating on a checkpoint subtree.Checkpoints include the genesis block and blocks at exact multiples of 100; checkpoint spacing is chosen as 99 blocks as a middle ground.
- Voting and finality: A supermajority link requires votes from at least 2/3 of validators by deposit, and a checkpoint is finalized through a justified link to a direct child.Validators broadcast signed votes naming source and target checkpoints and their heights.
- Accountable safety: Two conflicting checkpoints cannot both be finalized unless at least 1/3 of validators violate a slashing condition.The protocol makes violations detectable and removes the validator’s entire deposit when evidence is included on-chain.
- Fork choice: Users, validators, and block proposers should follow the chain containing the justified checkpoint of greatest height.Following the standard longest-chain rule can leave Casper unable to justify or finalize blocks without validators sacrificing deposits.
3. Enabling Dynamic Validator Sets
Casper enables validator sets to change over time while preserving the evidence and overlap needed for safe finalization. Its stitching mechanism prevents safety failures when adjacent validator sets differ substantially.
- Validator-set transitions: Validators join two dynasties after their deposit message is included, and leave two dynasties after a withdraw message is included.A withdrawn validator cannot rejoin under the same public key, and its deposit remains locked during the withdrawal delay.
- Validator-set transitions: Casper defines forward and rear validator sets from each validator’s start and end dynasties.The sets are Vf(d) = {ν : DS(ν) ≤ d < DE(ν)} and Vr(d) = {ν : DS(ν) < d ≤ DE(ν)}.
- Validator-set transitions: The forward validator set of dynasty d equals the rear validator set of dynasty d + 1, creating overlap across validator-set transitions.This relationship supports redefining supermajority links and finalized checkpoints for dynamic sets.
- Dynamic-set finalization: A dynamic-set supermajority link requires at least 2/3 support from both the forward and rear validator sets of the target dynasty.The two support requirements bind votes across the changing validator sets.
- Dynamic-set finalization: Finalization additionally requires the votes justifying the checkpoint and its outgoing link to appear before the child of the target checkpoint.The inclusion condition is measured before block number h(c′) ∗100 + 1.
- Dynamic-set finalization: When validator sets substantially differ, stitching prevents safety failure caused by evidence appearing in one chain but not another.Without stitching, disjoint validator sets could finalize conflicting checkpoints without slashing anyone.
4. Stopping Attacks
Casper addresses long-range revisions and catastrophic crashes through checkpoint non-reversion, periodic client synchronization, withdrawal timing, and inactivity leaks. These defenses retain explicit assumptions and leave some recovery procedures and economic choices unresolved.
- 4.1. Long Range Revisions: Long-range attacks exploit withdrawn validators’ historical supermajority to finalize conflicting checkpoints without risking their deposits.Clients counter this by refusing to revert finalized blocks and periodically obtaining a complete, current chain view.
- 4.1. Long Range Revisions: If the withdrawal delay satisfies ω > 4δ, malfeasant validators are guaranteed to lose their deposits in every chain accepted by a client.Here ω is the withdrawal delay and δ bounds communication delay.
- 4.1. Long Range Revisions: Network delays can make clients disagree about whether slashing evidence arrived on time, causing a liveness failure but not a safety failure.The paper attributes the remaining finality risk to a corrupted proposal mechanism that can prevent evidence inclusion.
- 4.1. Long Range Revisions: A client that regularly gains complete knowledge of the justified chain is not susceptible to a long-range attack.The figure describes periodic synchronization as the relevant protection against revisions of older finalized history.
- 4.2. Catastrophic Crashes: When more than 1/3 of validators crash or disconnect, no supermajority links can be created and future checkpoints cannot be finalized.An inactivity leak gradually reduces offline validators’ deposits until voting validators regain a supermajority.
- 4.2. Catastrophic Crashes: The inactivity leak’s exact formula and treatment of drained ether are outside the paper’s Byzantine-fault-tolerance scope.The unresolved choices are framed as questions of economic incentives.
- 4.2. Catastrophic Crashes: An inactivity leak can finalize conflicting checkpoints without explicit slashing, while each validator subset loses deposits on one chain.Validators are instructed to favor the finalized checkpoint they saw first in this scenario.
- 4.2. Catastrophic Crashes: The exact recovery algorithm remains open, with the paper provisionally assuming manual minority soft forks against obviously malfeasant behavior.The minority fork is treated as a competing blockchain whose acceptance depends on market preference.
5. Conclusions
Casper is presented as a proof-of-stake system derived from Byzantine fault tolerance, with mechanisms for validator accountability, dynamic validator sets, and attack defenses. The system remains imperfect and leaves several security and design issues for future work.
- Casper combines two slashing conditions, a fork-choice rule, dynamic validator sets, and defenses against finalized-checkpoint reversions and inactivity attacks.These components are presented as the system’s principal mechanisms and extensions.
- Casper remains imperfect because a wholly compromised block proposal mechanism can prevent it from finalizing new blocks.The proposal mechanism constrains liveness even though Casper is intended as a security improvement for proof-of-work chains.
- The current system still relies on a proof-of-work block proposal mechanism, which the authors plan to replace with proof of stake.The proposed transition is part of the paper’s future work.
- Future work includes proving accountable safety and plausible liveness under changing validator weights and formally specifying a fork-choice rule for proof-of-stake attacks.These goals address validator-set changes and attack-aware chain selection.