2 of 48

Hybrid Casper Overview

Running PoW and PoS at the same time with

Casper The Friendly Finality Gadget

3 of 48

Casper Validator 1,000 foot overview

Users deposit an amount of ETH to become a validator
Validators vote on the canonical chain, weighted by their deposit
Validators can withdraw deposits after a quiet period where they don’t validate
Validators make money for converging and building a single blockchain
Validators lose money for not converging, or forming two blockchains

4 of 48

Casper + PoW

Casper’s rollout will be incremental, and not immediately replace proof of work

PoS rewards slowly scaled up over time
PoW rewards slowly scaled down over time
Reduces complexity
Boil your frogs ;)

5 of 48

Finality

What is finality?

Why doesn’t proof of work have it?

6 of 48

Finality guarantees that history will never be changed.

7 of 48

Why do we want finality?

Fun finality fact:

Assurances that if I am paid, that record will not be erased
Reduced uncertainty for coordination

Proof of work provides no economic finality guarantees

8 of 48

Real world finality

UASF is a great example which demonstrates finality’s importance
If the user fork grows long enough, it could revert all transactions/blocks on the miner fork

Before

Miner

User

After

Reverted

chain

User & miner

Head

9 of 48

Checkpointing PoW

How we get finality in PoW by checkpointing with PoS

10 of 48

Hybrid Architecture Overview

The first rollout of Casper will *not* remove PoW
Instead it will provide finality “checkpoints” to specific blocks
A checkpoint is applied every 100 PoW blocks, called an epoch
A checkpoint cannot be reverted without at least ⅓ of validator’s deposits being slashed
These are Casper’s “safety” guarantees

11 of 48

Casper’s checkpointing

…98 blocks later ...

Validators

Miners

One

Epoch

12 of 48

Some fun attacks

What if miners censor all validator transactions?

Validators can collude to validate a chain with much less PoW that “honest” miners validate

What if validators collude with miners and censor a subset of validator transactions?

We will examine this later when we get into slashing conditions and censorship resistance

Validators are in charge.

13 of 48

Casper Messages

The two messages required for Casper validators to come to consensus: Prepare & Commit

14 of 48

PREPARE

Casper’s checkpointing

…98 blocks later ...

[“PREPARE”, 2, 0xaa…68a41, 1]

0xaa…68a41

0xbe…728cc

0x…..

15 of 48

PREPARE

Casper’s checkpointing

…98 blocks later ...

[“PREPARE”, 3, 0xbe...728cc, 1]

0xaa…68a41

0x…..

0xbe…728cc

0x…..

Prepares can reference any previous epoch

16 of 48

COMMIT

Casper’s checkpointing

…98 blocks later ...

[“COMMIT”, 2, 0xaa…68a41]

0xaa…68a41

0xbe…728cc

0x…..

⅔ COMMITs on a single [epoch, HASH] means a checkpoint has been

finalized

17 of 48

Providing Safety with Slashing Conditions

How we punish validators that validate our finality guarantees

18 of 48

Economic Finality means that for finality to be violated, at least ⅓ of the validators funds will be slashed (aka destroyed)

“

19 of 48

Four Slashing Conditions

Prepare REQ
Commit REQ
Prepare Commit Consistency
No Double Prepare

We will go over each of these individually.

For more information see: https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c

20 of 48

Prepare REQ

The epoch_source of each prepare must itself have at least ⅔ prepares

NOTE: Each box in this diagram is an EPOCH not a block

⅘ prepares

Valid prepare

⅓ prepares

Invalid prepare

21 of 48

Commit REQ

The HASH of each commit must have received at least ⅔ prepares

NOTE: Each box in this diagram is an EPOCH not a block

⅘ prepares

Valid commit

⅓ prepares

Invalid commit

22 of 48

Prepare Commit Consistency

You must never submit a prepare such that:

prepare_epoch_source < commit_epoch < prepare_epoch

NOTE: Each box in this diagram is an EPOCH not a block

My last commit

My Invalid prepare

epoch source

epoch

23 of 48

No Double Prepare

You must never submit two prepares for the same epoch

NOTE: Each box in this diagram is an EPOCH not a block

My second prepare for epoch X will get me slashed

My first prepare for epoch X is OK

24 of 48

Providing Availability: Negative Interest

How can we punish validators for not finalizing blocks

25 of 48

Overview of Availability concerns

If checkpoints do not finalize, validators should be punished
Finalizing every 20 minutes vs finalizing every day seriously harms usability
Validators should be paid in proportion to the utility they are providing to the blockchain
The protocol cannot differentiate between being offline and being censored

26 of 48

Cases in which we need to penalize

Validator Actions	< ⅔ Prepares	< ⅔ Commits	> ⅔ Commits
Nothing	The worst	The worst	Bad
Prepare	Not good	Bad	Not good
Commit			OK
Prepare & Commit		Not good	Good

These

When the network doesn’t finalize, everyone is punished
We can’t tell the difference between censorship & being offline. This is why we have to punish validators who both Prepare & Commit in the < ⅔ commits case

27 of 48

Summary

Users join and stake their ETH
Validators which break safety get slashed
Validators which prevent availability lose money
Proof of work will be slowly phased out
Validators make money if they form a single, unalterable blockchain!

28 of 48

Validator Rotation

How the validator set can change over time

29 of 48

1,000 foot overview for dynamic validator sets

Each validator set is called a ‘dynasty’
Validators change when there are 2 finalized epochs is a row

30 of 48

Putting it together with a fork choice rule

How clients and validators decide which chain is the “the longest”

31 of 48

Fork Choice

Iterate over all dynasties to find the most recent validator set
Iterate over all epochs looking for ones with more commits (deposit size of validators who committed)
Proof of work

Most recent dynasty change

30% commits

35% commits

50% commits

10% commits

5% commits

HEAD

PoW for

subsequent

blocks till

next epoch

32 of 48

Success!

That’s Casper!

33 of 48

So how does this thing work when it’s all

inside a smart contract?

“

34 of 48

Consensus in a Smart Contract

How you can use a smart contract in order to provide consensus

35 of 48

Important Concepts

Smart contract computes payouts
Smart contract records finalized hashes

Validator decides which fork to build on
Validators send normal Ethereum transactions

Smart Contract	Validator
Economic Incentives	Fork choice
Historical Data (Consensus Messages)	Transaction sending logic

36 of 48