1 of 35

Caspar explains Gasper

07/09/2024 - Kiln Rendez-Vous EthCC

Caspar Schwarz-Schilling

Robust Incentives Group @ Ethereum Foundation

2 of 35

Robust Incentives Group

EF research team focused on everything with strategic flavour.

Strategic in the sense:

Stakeholders make decisions to optimise their payoffs
Their payoffs are affected by decisions of other stakeholders

You can find of our work on https://rig.ethereum.org/

3 of 35

Consensus

4 of 35

Protocol layers

The execution layer interprets and “runs” the data.

Users pay for block space (execution) with the fee market (EIP 1559).

The consensus layer coordinates everyone on a shared view of the data.� Consensus is open and incentivised: anyone can join, earn rewards� Consensus is secure: hard/expensive to create alternate histories

Execution layer: what is the meaning of the data?
Consensus layer: which is the correct data?

5 of 35

Coming to consensus

Execution layer: What is the meaning of the data?
Consensus layer: Which is the correct data?

6 of 35

Consensus mechanisms

Goal: Achieve consensus under open and dynamic participation

Open: Anyone can start participating in consensus formation
Dynamic: Set of consensus-forming players may change over time

Consensus mechanism�Leader selection + Consensus algorithm + Incentives + Cryptography

7 of 35

Leader selection mechanism

Who has the right to propose a new block?�No identifiable players per se! We need Sybil-resistant mechanisms

Proof-of-Work: Whoever solves cryptographic puzzle based on parent block� Miners turn on their machines, crunch numbers until they find a solution
Proof-of-Stake: Leader selected from a set of bonded parties� Validators deposit some stake into the system

Examples

PoW Bitcoin: Puzzle difficulty tuned dynamically such that blocks are found� following Poisson process with average rate = 10 minutes
PoS Ethereum: New validator pseudo-randomly selected from bonded set,� every 12 seconds

8 of 35

Consensus algorithm / Fork choice rule

Typically assume consensus happens over partially synchronous network

Think: Over the Internet
Messages sent are eventually received, but unknown bound for delay� => can’t tell whether message is late, or never sent

Consensus algorithm� Given a tree of blocks, which chain is canonical?

Example: Longest-chain rule (Bitcoin)

B

C

D

E

A

9 of 35

Proof-of-Work (PoW) intuition

PoW → One CPU = one vote, try to solve the PoW puzzle by hashing

What do you vote on? The continuation of the chain� Spend energy to maybe get the right to add a new block

Costly to vote wrong: You have to spend energy on a stale branch

G

B

C

D

10 of 35

Proof-of-Stake (PoS) intuition

PoS → One coin = one vote

What do you vote on? The continuation of the chain� One coin is chosen at random to create the next block

Costly to vote wrong? Coin exists on both branches... Nothing-at-stake!

G

B

C

D

11 of 35

Slashing

Validators sign their votes cryptographically, broadcast them

We can find out if a validator does a slashable offence

Minimal set of attributable + detectable deviations,� trying to build and finalise alternate histories

B

C

C’

A

12 of 35

Why slash?

The slashable offences are really bad attempts to make the chain unsafe

Safety: Two checkpoints on different branches cannot both be finalised

Slashing guarantee: Two conflicting checkpoints cannot be finalised … � … unless at least 1/3rd of the stake did slashable offences

B

C

C’

A

13 of 35

Defence scenario

Collusion of stakers (> 33%) attacks the chain� Gets two conflicting checkpoints finalised…

Community can decide to restart the chain from C or C’� + slash malicious stakers on their chain

Repeating the attack is very expensive! vs reaching 51% in PoW…

B

C

C’

A

14 of 35

Economic finality in Proof-of-Stake

Accountable finality: Two conflicting blocks cannot both be finalised (>⅔ quorum)� UNLESS at least ⅓ of the stake produced conflicting votes!

In particular, we can slash validators who equivocate (remove stake from deposit)� + coordinate off-band on which side of the fork to restart on

In PoW, no such mechanism, longest chain prevails, probabilistic finality…

B

C

C’

A

15 of 35

Finality

In distributed systems, we want to know data will not be changed later

Consensus => Arrive at a shared view of the system

PoW offers probabilistic finality

Always a chance that a fork would overtake current chain

With PoS, we can checkpoint the chain

Validators know that other validators know the checkpoint

B

C

D

E

A

Finalised

Pending

Stale

16 of 35

Ethereum Proof-of-Stake 101

Consensus mechanism with staked (bonded) validators

User locks up 32 ETH in a deposit contract (execution chain)
Deposit is activated on the beacon chain (consensus chain)
User becomes validator of the Gasper consensus

Expected to produce blocks and vote on their view of the chain
Rewarded for acting well, helping consensus form
Penalised for doing bad job, i.e. being offline
Very penalised (slashed) for doing malicious job, i.e. sign conflicting messages!

Economic incentives are central to security of the consensus!

17 of 35

Consensus

algorithm

18 of 35

Security = Safety + Liveness

Consensus protocols are typically evaluated based on their ability to maintain liveness and safety.

Liveness - regular addition of new transactions to the output ledger in a timely manner

Safety - security of confirmed transactions remaining in their positions within the ledger

A consensus protocol that is safe and live is considered secure.

19 of 35

PBFT consensus algorithm

Typical PBFT consensus algorithm (ideal path):

Leader proposes a value x
Players send prepare message,� “x should be consensus”
If players observe ⅔ prepare messages, send pre-commit message,� “I have seen ⅔ wanting x to be consensus”
If players observe ⅔ pre-commit messages, commit value locally,� “⅔ agree that ⅔ agree”

Why ⅔? ⅓+ε adversary votes for both forks A and B, splits honest stake ⅓-⅓ � => 2 distinct values are committed => Safety fault!� Adversary smaller than ⅓ can’t delay finalisation => Liveness guarantee!

20 of 35

Economic finality in Proof-of-Stake

Accountable finality: Two conflicting blocks cannot both be finalised (>⅔ quorum)� UNLESS at least ⅓ of the stake produced conflicting votes!

In particular, we can slash validators who equivocate (remove stake from deposit)� + coordinate off-band on which side of the fork to restart on

In PoW, no such mechanism, longest chain prevails, probabilistic finality…

B

C

C’

A

21 of 35

GASPER

22 of 35

Ethereum consensus algorithm

GASPER = LMD GHOST + Casper FFG

(Available Chain) (Finality Gadget)

23 of 35

GASPER: LMD GHOST + Casper FFG

24 of 35

LMD GHOST

25 of 35

Time in Ethereum

26 of 35

Progression of a slot

27 of 35

LMD GHOST: Happy path

28 of 35

LMD GHOST: Unhappy path

29 of 35

Casper FFG

30 of 35

GASPER: LMD GHOST + Casper FFG

Justification: epoch boundary block receives >⅔ target votes

Finalization: epoch boundary block is justified +

receives >⅔ source votes (B32, B64)

31 of 35

PBFT consensus algorithm

Typical PBFT consensus algorithm (ideal path):

Leader proposes a value x
Players send prepare message,� “x should be consensus”
If players observe ⅔ prepare messages, send pre-commit message,� “I have seen ⅔ wanting x to be consensus”
If players observe ⅔ pre-commit messages, commit value locally,� “⅔ agree that ⅔ agree”

Why ⅔? ⅓+ε adversary votes for both forks A and B, splits honest stake ⅓-⅓ � => 2 distinct values are committed => Safety fault!� Adversary smaller than ⅓ can’t delay finalisation => Liveness guarantee!

32 of 35

Dynamic availability

Maintain liveness as participants enter/leave at will

→ Available chain keeps growing with <⅔ stake participation

→ If chain stops finalizing for prolonged period,

→“inactivity leak” kicks in

→ offline participants lose stake until exited out of protocol

and online participants control >⅔ of stake again.

→ The chain is then able to finalize again.

33 of 35

tldr

Security: liveness + safety

Accountable safety → Finality

Dynamic Availability

34 of 35

Thank you!

Email: caspar@ethereum.org

Twitter & Telegram: @casparschwa

https://rig.ethereum.org/

35 of 35

Bonus: CAP Theorem

CAP: Consistency, Availability, Partition tolerance

Cap Theorem: no protocol with both dynamically availability & finality

(no safety under asynchrony, e.g. partition)

→ nested chains (available chain + finality gadget)

→ accountable finalized chain: not live under small participation (but inactivity leak!)

→ available chain: not safe under asynchrony

→ not secure… → Ethereum consensus mechanism → SSF