[1710.09437 Casper the Friendly Finality Gadget](https://arxiv.org/abs/1710.09437) # Abstract [[Casper FFG]] is a proof of stake finality system that overlays an existing PoW or PoS chain Paper will introduce it, prove desirable features, and show defenses against long range revisions and crashes # Introduction Two major schools of thought in PoS design 1. chain-basd PoS mimics PoW mechanics wiut ha chain of blocks and randomly assigns the right to create new blocks to stakeholders 2. BFT-based PoS is based on classic BFT research like [[PBFT]] 1. Casper follows this BFT tradition 2. First introduced by Tendermint ## Our Work Casper FFG is an overlay atop a proposal mechanism - a mechanism that processes blocks Casper finalizes these blocks - selecting a unique chain that represents the canonical transactions of the ledger It provides *safety*, but liveness depends on the proposal mechanism If attackers control proposal mech, Casper protects against finalizing two conflicting checkpoints, but attackers could prevent casper from finalizing any future checkpoints [[Casper]] introduces several new features: - Accountability: if a violater breaks a rule, we can detect and know who did it - Dynamic validators, with a validator set that can change over time - Defenses:long range revision and when more than 1/3 of validators go offline (tradeoff is weak synchrony assumption) - Modular overlay # The Casper Protocol *Start with simple version and build up* Assume a fixed set of validators and a familiar proposal mechanism Most of the time the PM will produce one block after another in a linked list If network latency or attack, there may be multiple children of same parent Casper's job is to choose a single child from each parent, thus choosing one canonical chain Casper deals with checkpoints and only looks at subtree of checkpoints Height of a checkpoint c is the number of elements in the checkpoint chain stretching from c (non-inclusive) to the root along the parent links Each validator has a deposit Validators broadcast votes with the following information: 1. s - the hash of any justified checkpoint 2. t - any checkpoint has that is a descendant of s 3. h(s) - height of s in checkpoint tree 4. h(t) height of checkpoint t in checkpoint tree 5. S - signature Terms: - **Supermajority link** - Ordered pair of checkpoints (a,b) such that at least 2/3 of validators have published votes with source a and target b. - They can skip checkpoints - Two checkpoints are called **conflicting** iff they are nodes in distinct branches, so neither is a descendant of the other - A checkpoint c is **justified** if it is the root OR there exists a supermajority link (c',c) where c' is justified - A checkpoint c is **finalized** if it's the root OR it is justified and there is a supermajority link (c,c') where c' is a *direct child* of c. - Equivalently, c is finalized iff: - c is justified - there exists a supermajority link (c,c') - checkpoints c and c' are not conflicting - h(c') = h(c) + 1 ### Casper Commandments An individual validator must not publish two distinct votes such that either: I. Has the same target height II. A validator must not vote within the span of its other votes, $h(s_{1}) < h(s_{2}) < h(t_{2}) < h(t_{1})$ v2 shouldn't start before v1 starts and after v1 ends ## Proving Safety and Plausible Liveness Casper has two fundamental properties: accountable safety (two conflicting checkpoints cannot be finalized unless over 1/3 of validators violate a slashing condition) and plausible liveness (regardless of any previous events, if geq 2/3 of validators follow the protocol then its always possible to finalize a new checkpoint without any validator violating a slashing condition) **Theorem (plausible liveness):** Supermajority links can always be added to produce new finalized checkpoints, provided there exist children extending the finalized chain. *Proof:* Let a be the justified checkpoint with the greatest height, and b be the target checkpoint with the greatest height for which any validator has made a vote. Any checkpoint a' whic his a descendant of a wit hheight h(a') = h(b) + 1 can be justified without violating commandments, and then a' can be finalized by adding asupermajority link from a' to a direct child of a' ## Casper's Fork Choice Rule Follow the chain containing the justified checkpoint of the greatest height Follows the theorem which states its always possible to finalize a new checkpoint on top of the justified checkpoint with the greatest height # Enabling Dynamic Validator Sets To accomplish, we define the following: **Dynasty** **of block b** is the number of finalized checkpoints in the chain from root to the parent of block b When a would-be validator's deposit message is included in a block with dynasty d, then the validator v will join the validator set at first block with dynasty d+2 d+2 becomes the validator's *start dynasty* To withdraw, a validator sends withdraw message at d and is out by d+2, the *end dynasty* Once a validator leaves, their pubkey can never join again **Forward validator set** and **rear validator set** defined as ![[Pasted image 20230910103131.png]] To support dynamic validator sets, we redefine supermajority link and finalized checkpoint so that they're more stitched together with requirements from both forward and rear # Stopping Attacks ## Long Range Revisions Withdrawal delay after a validator's end dynasty introduces a synch assumption between validators and clients If validators with over 2/3 at some point in the past have withdrawn, they can use their historical supermajority to finalize conflicting checkpoints without fear of getting slashed The **long-range revision attack** Prevented by a fork choice rule to never revert a finalized block ## Catastrophic Crashes Suppose over 1/3 of validators crash-fail at the same time No supermajority links can be created and no future checkpoints can be finalized Recover by instituting an inactivity leak that drains the deposit of any validator that does not vote for checkpoints until its deposit size decreases low enough that the validators who are voting are a supermajority Introduces the possibility of two conflicting checkpoints being finalized without any validator getting slashed, with validators losing money on only one of the two checkpoints # Conclusions Yay Casper!