[Paper Review] Combining GHOST and Casper

Vitalik Buterin, Diego Ortega Hernandez+7 more|arXiv (Cornell University)|Mar 6, 2020

Distributed systems and fault tolerance15 references67 citations

TL;DR

Gasper is a proof-of-stake protocol that combines Casper FFG with LMD GHOST to achieve safety and (plausible and probabilistic) liveness for Ethereum 2.0 beacon chain proposals, under various assumptions.

ABSTRACT

We present "Gasper," a proof-of-stake-based consensus protocol, which is an idealized version of the proposed Ethereum 2.0 beacon chain. The protocol combines Casper FFG, a finality tool, with LMD GHOST, a fork-choice rule. We prove safety, plausible liveness, and probabilistic liveness under different sets of assumptions.

Motivation & Objective

• Define and study a proof-of-stake consensus protocol suitable for Ethereum 2.0 beacon chain design.
• Combine Casper FFG finality gadget with LMD GHOST fork-choice to create Gasper.
• Prove safety, plausible liveness, and probabilistic liveness under different synchrony and fault assumptions.
• Address practical considerations such as sharding, view implementation, and dynamic validator sets.

Proposed method

• Present Gasper as an idealized abstraction of Ethereum’s beacon chain.
• Formalize primitives: validators, views, attestations, and slashing conditions.
• Define epoch boundary blocks/pairs and committees to coordinate attestations.
• Integrate Casper FFG concepts of justification and finalization with LMD GHOST fork-choice.
• Prove Accountable Safety and Pfob? plausible liveness and probabilistic liveness under specified models.
• Discuss practical implementation aspects and differences from Ethereum’s actual design.

Experimental results

Research questions

• RQ1 Can Gasper achieve safety with finalized blocks on conflicting branches under Byzantine faults?
• RQ2 Under what synchrony and fault assumptions can Gasper guarantee plausible liveness and probabilistic liveness?
• RQ3 How do epoch boundaries, committees, and attestations interact to yield finalization in a PoS setting?
• RQ4 What are the practical implications for sharding, view construction, and dynamic validator sets in Gasper?

Key findings

• Gasper achieves accountable safety: two finalized checkpoints on different branches cannot both be finalized unless a slashed set of validators breaches protocol rules.
• Plausible liveness holds: new checkpoints can become finalized provided new blocks can be created by the underlying blockchain.
• Probabilistic liveness is established under certain probabilistic network assumptions and attack models.
• The paper discusses how delays in attestation inclusion and finalization affect safety and liveness in practice.
• A four-case finalization rule and considerations for dynamic validator sets are explored to bridge theory and practice.