Incentives in Ethereum's Hybrid Casper Protocol

Vitalik Buterin; Daniel Reijsbergen; Stefanos Leonardos and; Georgios Piliouras

arXiv:1903.04205·cs.CR·July 20, 2021

Incentives in Ethereum's Hybrid Casper Protocol

Vitalik Buterin, Daniel Reijsbergen, Stefanos Leonardos and, Georgios Piliouras

PDF

TL;DR

This paper presents an overview of Ethereum's hybrid Casper protocol, highlighting its incentive mechanisms, safety and liveness guarantees, and discussing implementation challenges and limitations.

Contribution

It provides a comprehensive overview of Casper FFG's design, incentives, and properties, including safety, liveness, and practical implementation considerations.

Findings

01

Incentive mechanisms ensure protocol liveness.

02

Safety guarantees improve over standard PoW.

03

Implementation details reveal potential limitations.

Abstract

We present an overview of hybrid Casper the Friendly Finality Gadget (FFG): a Proof-of-Stake checkpointing protocol overlaid onto Ethereum's Proof-of-Work blockchain. We describe its core functionalities and reward scheme, and explore its properties. Our findings indicate that Casper's implemented incentives mechanism ensures liveness, while providing safety guarantees that improve over standard Proof-of-Work protocols. Based on a minimal-impact implementation of the protocol as a smart contract on the blockchain, we discuss additional issues related to parametrisation, funding, throughput and network overhead and detect potential limitations.

Tables6

Table 1. TABLE I: Summary of vote function arguments.

Notation	Description
$ν$	validator index
t	hash of the ‘target’ checkpoint
h(t)	height of the target checkpoint in the checkpoint tree
h(s)	height of the source checkpoint in the checkpoint tree
$𝒮$	signature of $(ν, t, h (t), h (s))$ by the validator’s private key

Table 2. TABLE II: Updates in validators deposits.

E̱poch Finalization	V̱alidator $ν$ ’s vote	V̱alidator $ν$ ’s new deposit	P̱arameters
ESF ${}_{i}> 2$	$𝟏_{ν, i} = 1$	$D_{ν, i + 1} = D_{ν, i}$	$ρ_{i} = γ \cdot D_{i}^{- p} + β ({ESF}_{i} - 2)$
	$𝟏_{ν, i} = 0$	$D_{ν, i + 1} = \frac{1}{1 + ρ_{i}} D_{ν, i}$
ESF ${}_{i}= 2$	$𝟏_{ν, i} = 1$	$D_{ν, i + 1} = (1 + m_{i} ρ_{i} / 2) D_{ν, i}$	$ρ_{i} = γ \cdot D_{i}^{- p}, m_{i} \in [2 / 3, 1]$
	$𝟏_{ν, i} = 0$	$D_{ν, i + 1} = \frac{1 + m_{i} ρ_{i} / 2}{1 + ρ_{i}} D_{ν, i}$

Table 3. TABLE III: List of symbols.

Notation		Description
$l$		length (in terms of blocks) of a Casper FFG epoch
$V$		current active validator set
$D_{ν, i}$		deposit of validator $ν \in ℕ$ at the beginning of epoch $i$
$D_{i}$		total deposit at the beginning of epoch $i$
$m_{i} \in [0, 1]$		weighted fraction of correct votes in epoch $i$
$ρ_{i} \geq 0$		individual reward factor in epoch $i$
$C_{i} \geq 0$		collective reward factor in epoch $i$
$γ > 0$		base interest factor $> 0$
$β > 0$		base penalty factor
$p > 0$		total deposit dependence factor (typically in $(0, 1]$ )
$α \in (0, 1]$		stake fraction of supporting validators
$μ \in (0, 1]$		stake fraction of supporting block proposers

Table 4. TABLE IV: Losses to all groups of validators if ν ν \upnu abstains from voting.

	Ḻosses
J̱ustification	$ν$	Voters	Non-voters
Always	$\frac{ρ}{1 + ρ} (1 + \frac{1}{2} (μ ρ + α))$	$\frac{1}{2} α ρ$	$\frac{ρ}{1 + ρ} \cdot (\frac{1}{2} α)$
Never	$\frac{ρ}{1 + ρ}$	0	0
$ν$ is swing voter	$\frac{ρ}{1 + ρ} (1 + \frac{1}{2} (μ ρ + α))$	$\frac{1}{2} μ ρ$	$\frac{ρ}{1 + ρ} \cdot (\frac{1}{2} μ)$

Table 5. TABLE V: PLRs and GFs if ν ν \upnu abstains from voting.

	P̱roportional Loss Ratio (PLR)		G̱riefing Factor (GF)
J̱ustification	Voters	Non-voters	Voters	Non-voters
Always	$\frac{\frac{1}{2} α (1 + ρ)}{1 + \frac{1}{2} (μ ρ + α)}$	$\frac{\frac{1}{2} α}{1 + \frac{1}{2} (μ ρ + α)}$	$\frac{\frac{1}{2} (μ - α) (1 + ρ)}{1 + \frac{1}{2} (μ ρ + α)}$	$\frac{\frac{1}{2} (1 - μ)}{1 + \frac{1}{2} (μ ρ + α)}$
Never	0	0	0	0
$ν$ is swing voter	$\frac{\frac{1}{2} μ (1 + ρ)}{1 + \frac{1}{2} μ (1 + ρ)}$	$\frac{\frac{1}{2} μ}{1 + \frac{1}{2} μ (1 + ρ)}$	$\frac{\frac{1}{2} μ (μ - α) (1 + ρ)}{α (1 + \frac{1}{2} μ (1 + ρ))}$	$\frac{\frac{1}{2} μ (1 - μ)}{α (1 + \frac{1}{2} μ (1 + ρ))}$

Table 6. TABLE VI: Gas costs for the six core functions of the Casper contract as estimated by the Vyper compiler.

Function	Estimated gas cost
initialize_epoch	742 393
deposit	831 687
logout	131 308
withdraw	224 155
vote	532 031
slash	280 864

Equations61

B_{n}^{t} := {

B_{n}^{t} := {

B_{n}^{t} \subseteq B_{n}^{s}, for any s, t > 0 with s > t .

B_{n}^{t} \subseteq B_{n}^{s}, for any s, t > 0 with s > t .

ρ_{i} := {γ \cdot D_{i}^{- p} + β \cdot (ESF_{i} - 2), 0, if D_{i} > 0 otherwise

ρ_{i} := {γ \cdot D_{i}^{- p} + β \cdot (ESF_{i} - 2), 0, if D_{i} > 0 otherwise

1_{\upnu, i} = {10 if \upnu voted successfully during epoch i, otherwise.

1_{\upnu, i} = {10 if \upnu voted successfully during epoch i, otherwise.

C_{i} := {\frac{1}{2} m_{i} ρ_{i}, 0, if ESF_{i} = 2, otherwise.

C_{i} := {\frac{1}{2} m_{i} ρ_{i}, 0, if ESF_{i} = 2, otherwise.

D_{\upnu, i + 1} := (1 + C_{i}) \frac{1 + 1 _{\upnu, i} ρ _{i}}{1 + ρ _{i}} D_{\upnu, i} .

D_{\upnu, i + 1} := (1 + C_{i}) \frac{1 + 1 _{\upnu, i} ρ _{i}}{1 + ρ _{i}} D_{\upnu, i} .

D_{\upnu, i + 1} = \frac{1 + 1 _{\upnu, i} ρ _{i}}{1 + ρ _{i}} D_{\upnu, i} .

D_{\upnu, i + 1} = \frac{1 + 1 _{\upnu, i} ρ _{i}}{1 + ρ _{i}} D_{\upnu, i} .

D_{\upnu, i + 1} \approx D_{\upnu, i} + \frac{1}{2} ρ_{i} D_{\upnu, i}

D_{\upnu, i + 1} \approx D_{\upnu, i} + \frac{1}{2} ρ_{i} D_{\upnu, i}

D_{\upnu, i + 1} = \frac{1 + C _{i}}{1 + ρ _{i}} D_{\upnu, i} = \frac{1 + m _{i} ρ _{i} /2}{1 + ρ _{i}} D_{\upnu, i} .

D_{\upnu, i + 1} = \frac{1 + C _{i}}{1 + ρ _{i}} D_{\upnu, i} = \frac{1 + m _{i} ρ _{i} /2}{1 + ρ _{i}} D_{\upnu, i} .

⟨ \upnu, t_{1}, h(t \textsubscript 1), h(s \textsubscript 1), S_{1} ⟩ and ⟨ \upnu, t_{2}, h(t \textsubscript 2), h(s \textsubscript 2), S_{2} ⟩,

⟨ \upnu, t_{1}, h(t \textsubscript 1), h(s \textsubscript 1), S_{1} ⟩ and ⟨ \upnu, t_{2}, h(t \textsubscript 2), h(s \textsubscript 2), S_{2} ⟩,

D_{\upnu, i} = (1 + 0) \frac{1 + 1 \cdot ρ _{i - 1}}{1 + ρ _{i - 1}} D_{\upnu, i - 1} = D_{\upnu, i - 1},

D_{\upnu, i} = (1 + 0) \frac{1 + 1 \cdot ρ _{i - 1}}{1 + ρ _{i - 1}} D_{\upnu, i - 1} = D_{\upnu, i - 1},

ρ_{i} = γ D_{i}^{- p} + β (ESF_{i} - 2) = γ D_{i}^{- p} + β i .

ρ_{i} = γ D_{i}^{- p} + β (ESF_{i} - 2) = γ D_{i}^{- p} + β i .

max

max

α_{i} + δ_{i} (1 - α_{i}) \leq 2/3

δ_{i} \geq 0.

δ_{i} = \frac{2/3 - α _{i}}{1 - α _{i}} .

δ_{i} = \frac{2/3 - α _{i}}{1 - α _{i}} .

D_{\upnu, i + 1}

D_{\upnu, i + 1}

D_{\tilde{\upnu}, i + 1}

α_{i + 1}

α_{i + 1}

\geq (*) \frac{D _{\upnu, 0}}{D _{\upnu, 0} + \frac{D _{\tilde{\upnu}, 0}}{1 - α _{i}} [ \frac{2}{3} - α _{i} + \frac{1}{3} ( 1 + ρ _{i} ) ^{- 1} ]} = \frac{1}{1 + \frac{1 - α _{0}}{1 - α _{i}} [ \frac{2}{3} - α _{i} + \frac{1}{3} ( 1 + ρ _{i} ) ^{- 1} ]},

α \geq \frac{1 - α}{1 - α + ( 1 - α _{0} ) ( \frac{2}{3} - α )} .

α \geq \frac{1 - α}{1 - α + ( 1 - α _{0} ) ( \frac{2}{3} - α )} .

α \geq \frac{1 - α}{1 - α + 0} = 1

α \geq \frac{1 - α}{1 - α + 0} = 1

\frac{3}{2} α D_{0} \geq α D_{0} + (1 - α) D_{0} \prod_{i = 0}^{k - 1} (1 + ρ_{i})^{- 1},

\frac{3}{2} α D_{0} \geq α D_{0} + (1 - α) D_{0} \prod_{i = 0}^{k - 1} (1 + ρ_{i})^{- 1},

k_{α} := min {k \in N : \prod_{i = 0}^{k - 1} (1 + ρ_{i}) \geq 2 (1 - α) / α} .

k_{α} := min {k \in N : \prod_{i = 0}^{k - 1} (1 + ρ_{i}) \geq 2 (1 - α) / α} .

M := ar g max {h (B) : B \in C (B_{2}) \cap C (B_{2}^{'})}

M := ar g max {h (B) : B \in C (B_{2}) \cap C (B_{2}^{'})}

C (B_{2})

C (B_{2})

C (B_{2}^{'})

B \in (B_{2}, B_{1}, P (B_{1}), \dots, P^{n} (B_{1})) and B^{'} \in (B_{2}^{'}, B_{1}^{'}, P (B_{1}^{'}), \dots, P^{m} (B_{1}^{'}))

B \in (B_{2}, B_{1}, P (B_{1}), \dots, P^{n} (B_{1})) and B^{'} \in (B_{2}^{'}, B_{1}^{'}, P (B_{1}^{'}), \dots, P^{m} (B_{1}^{'}))

h (B_{1}^{'}) < h (B_{2}^{'}) < h (B_{1}) < h (B_{2}) .

h (B_{1}^{'}) < h (B_{2}^{'}) < h (B_{1}) < h (B_{2}) .

h (P^{k} (B_{1})) < h (B_{1}^{'}) < h (B_{2}^{'}) < h (P^{k - 1} (B_{1}))

h (P^{k} (B_{1})) < h (B_{1}^{'}) < h (B_{2}^{'}) < h (P^{k - 1} (B_{1}))

P (X > Y)

P (X > Y)

P (X < Y) = F_{B} (μ), with B \sim Beta (n_{1} = 3, n_{2} = 3733)

P (X < Y) = F_{B} (μ), with B \sim Beta (n_{1} = 3, n_{2} = 3733)

\frac{μ}{1 - μ} < \frac{3}{3733} ⟹ μ < 8.036 \times 1 0^{- 4}

Peer Reviews

No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.

Videos

No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.

Full text

Incentives in Ethereum’s Hybrid Casper Protocol††thanks: This work was supported in part by the National Research Foundation (NRF), Prime Minister’s Office, Singapore, under its National Cybersecurity R&D Programme (Award No. NRF2016NCR-NCR002-028) and administered by the National Cybersecurity R&D Directorate. Georgios Piliouras acknowledges SUTD grant SRG ESD 2015 097, MOE AcRF Tier 2 Grant 2016-T2-1-170 and NRF 2018 Fellowship NRF-NRFF2018-07.

Vitalik Buterin1, Daniël Reijsbergen2, Stefanos Leonardos2, Georgios Piliouras2

1Ethereum Foundation

2Singapore University of Technology and Design

Abstract

We present an overview of hybrid Casper the Friendly Finality Gadget (FFG): a Proof-of-Stake checkpointing protocol overlaid onto Ethereum’s Proof-of-Work blockchain. We describe its core functionalities and reward scheme, and explore its properties. Our findings indicate that Casper’s implemented incentives mechanism ensures liveness, while providing safety guarantees that improve over standard Proof-of-Work protocols. Based on a minimal-impact implementation of the protocol as a smart contract on the blockchain, we discuss additional issues related to parametrisation, funding, throughput and network overhead and detect potential limitations.

Index Terms:

Proof of Stake, Ethereum, Consensus

I Introduction

In 2008, the seminal Bitcoin paper by Satoshi Nakamoto [50] introduced the blockchain as a means for an open network to extend and reach consensus about a distributed ledger of digital token transfers. The main innovation of Ethereum [16] was to use the blockchain to maintain a history of code creation and execution. As such, Ethereum functions as a global computer that executes code uploaded by users in the form of smart contracts. Like Bitcoin [31, 32], Ethereum’s block proposal mechanism is based on the concept of Proof-of-Work (PoW). In PoW, network participants utilise computational power to win the right to add blocks to the blockchain. However, the alarming global energy consumption of PoW-based blockchains has made the concept increasingly controversial [65, 22, 45]. One of the main alternatives to PoW is virtual mining or Proof-of-Stake (PoS) [5, 1, 55, 46]. In PoS, the right to propose a block is earned by locking – or depositing – tokens on the blockchain, which has no inherent energy cost.

As part of its long-term goal to switch from PoW to PoS, Ethereum is designing a full PoS protocol called Casper [58, 57, 15]. To ensure a smooth transition with minimal impact on its users and the Ether price (Ethereum’s native cryptocurrency [41]), Ethereum deployed and tested a hybrid version, Casper the Friendly Finality Gadget or Casper FFG, as a smart contract on a dedicated testnet [26, 53, 54]. Essentially, Casper FFG is a simplified version of a Byzantine fault tolerant protocol [18], with “votes” for checkpoints taking the place of prepares and commits. In contrast to protocols that treat every block as a checkpoint (e.g., Tendermint [43] and Algorand [19]), Casper FFG periodically checkpoints blocks on an underlying chain. As such, the tried and tested PoW chain can be preserved during a transitional phase, whilst the extra load on the network is mitigated. This addresses two of the classical challenges that affect PoS protocols [47, 6]: the nothing-at-stake problem through the slashing mechanism that penalises misbehaving violators [17], and long-range attacks through a modified fork-choice rule that prioritises (and never automatically reverts) finalised checkpoints over PoW [61].

The high-level idea and fundamental properties of the hybrid Casper FFG have been outlined in [17]. In the present paper we extend [17] to include a full description of the implemented incentives (reward–penalty) scheme. We show that the scheme is incentive-compatible in the sense that participants are incentivised to follow the protocol, and we investigate its impact on the basic properties of liveness and safety. Based on the minimal-impact implementation of Casper FFG as a smart contract on the PoW chain, the present paper also covers the parameter choice, confirmation times, and network overhead, and a discussion of potential limitations. Along with the lessons learned, we present some directions, ideas, and design concepts for future development of Ethereum’s consensus mechanism and blockchains in general.

The contributions of this paper are as follows. We first provide an overview of the Casper FFG protocol and describe its core functionalities. To reason about liveness and safety, we develop a mathematical framework for the incentives scheme, slashing conditions, and the fork-choice rule. Our first theoretical result is that with the implemented reward scheme, Casper’s checkpointing scheme is $\alpha$ -live, for any $\alpha\in\left(0,1\right]$ , i.e., online validators controlling any fraction $\alpha\in\left(0,1\right]$ of the stake will be eventually able to finalise checkpoints. Concerning safety, we first show that the property proved in [17] carries over to the updated incentives scheme, namely that two or more “conflicting” checkpoints can only exist if validators controlling at least $1/3$ of the stake misbehave conspicuously and hence, can be slashed (i.e., punished). We then extend the safety analysis to the case of a protracted network partition. It is clear from the CAP theorem [35] that during a network partition, a distributed ledger can satisfy liveness or safety, but not both. We indeed find that the liveness guarantee has implications for safety, as it eventually allows for conflicting checkpoints to be finalised. However, using both numerical and analytical tools, we derive that the minimum duration of such a network partition is very large (i.e., at least three weeks). As such, Casper’s checkpointing protocol prioritises safety in the short term, but liveness in the long term, and hence strikes a balance between protocols that either always prioritise liveness (e.g., the underlying PoW chain) or safety (e.g., Tendermint). Next, we study the incentive compatibility of the protocol by investigating whether it is profitable for nodes to follow the protocol. Finally, we turn to the implementation of Casper FFG as a PoW chain contract. In this approach, the stakeholders’ deposits are stored as variables in the contract, and their actions appear on the blockchain as contract calls. In Section IV, we evaluate the effect on transaction throughput and computational cost (or load) as measured via gas, discuss the impact of different parametrisations, and identify potential limitations.

To remain compatible with Ethereum’s evolution towards a sharded and hence more scalable design [58, 13, 27], the specifications of Casper FFG are constantly updated [11, 15]. Yet, the key takeaways and the main findings from testing Casper FFG as a smart contract in a hybrid setting carry over to the currently developed design of a main PoS chain, called the Beacon Chain [15, 10], that will coordinate consensus among several side chains or shards. In particular, the main components, i.e., the incentives mechanism, functionality, and design philosophy remain basic components of Casper FFG even in the sharded construct (i.e., multi-chain) setting [10, 25, 15]. Although we focus on combining Casper FFG with Ethereum’s PoW chain, the protocol can be overlaid on top of any chain-based blockchain – PoW or PoS [61] – and may therefore be of wider interest to the blockchain community.

Outline

In Section II, we provide an abstract overview of Casper FFG and its operations in a formal mathematical model. Section III contains our main theoretical results on liveness, safety, and incentive compatibility. In Section IV, we present our findings on Casper’s implementation and discuss related issues. We summarise our results in Section V.

II The Hybrid Casper FFG Protocol

II-A The PoW Chain

Ethereum functions as a global computer whose operations are replicated across a peer-to-peer network. Participants in the network are called nodes – they typically interact with the rest of the network via a software application called a client. The client interacts with the Ethereum blockchain via transactions. There are three main types of transactions:

Token transfers

provide the same core functionality as Bitcoin by allowing nodes to exchange digital tokens.

Contract creations

upload pieces of code, called (smart) contracts, to the blockchain. Contracts are executed using a runtime environment called the Ethereum Virtual Machine (EVM).111The eWASM framework [21] may replace the EVM in the future. Two notable high-level languages that compile into the EVM are Solidity and Vyper which are based on the JavaScript and Python languages, respectively. Vyper is particularly relevant for this paper as it is used for the Casper contract. A typical contract will include one or more functions which can be called by the nodes.

Contract calls

handle interactions with the functions of an existing contract222For more details on these notions see Section IV-B..

In PoW, the ordering of these transactions in the blockchain is determined by a special class of nodes called miners. Miners collect and sort transactions, after which they execute these transactions in the EVM. Upon completion, information about the state of the complete global computer (account balances, contract variables, etc.) is then combined with the transactions and various other data into a data structure called a block. Miners compete to find a block that satisfies a condition that requires considerable computational effort. The winning miner receives a fixed amount of Ether (ETH) – Ethereum’s native currency – in the form of a mining reward. Additionally, all of the three transaction types listed above require gas, which is also paid to the winning miner as a reward for the computational effort. In particular, more computationally expensive operations in the EVM require more gas (see [67] for a complete specification of the gas cost for the different types of operations) – as such, gas cost is a good measure for the computational ‘cost’ of a transaction. In Section IV we will investigate the gas cost of the different functions in the Casper contract.

Formal Framework

To reason about the evolution of the PoW chain in the context of network latency and partitions, we require a formal framework. Let $N$ denote the full set of nodes as identified by an integer denoting their index in the network, i.e., $N\subseteq\mathbb{N}$ . At each time $t\geq 0$ , each node $n\in N$ is aware of a set of blocks $B$ which we denote by $\mathcal{B}_{n}^{t}$ , i.e.,

[TABLE]

The genesis block $g$ is the only block that all nodes are aware of at time [math], i.e., $\mathcal{B}^{0}_{n}=\{g\}$ for all $n\in N$ . Each block $B$ can be represented uniquely as an integer, e.g., via the hash of its header, although this means that the range of possible blocks is “restricted to” $\{0,\ldots,2^{256}-1\}$ . Due to network latency, eclipse attacks, or other reasons, it may be the case that different nodes are aware of different sets of blocks, i.e., there may exist $t>0$ and nodes $n,m\in N$ such that $\mathcal{B}^{t}_{n}\neq\mathcal{B}^{t}_{m}$ . We assume that nodes cannot forget about blocks, i.e.,

[TABLE]

Each block $B$ points to a previous block $P\left(B\right)$ via a function $P:\mathbb{N}\rightarrow\mathbb{N}$ , cf. [6], with

•

$P^{0}\left(B\right):=B$ for any block $B$ ,

•

$P^{2}\left(B\right)=P\left(P\left(B\right)\right),P^{3}\left(B\right)=P\left(P\left(P\left(B\right)\right)\right)$ etc.

•

$P^{k}\left(g\right):=\emptyset$ for all $k\geq 1$ , where $g$ is the genesis block,

•

$P^{k}\left(B\right)\neq B$ for any $B$ and $k\in\{1,2,\ldots\}$ , i.e., there are no cycles.333An attacker could theoretically construct a cycle, but the probability of succeeding is negligible: i.e., after picking a previous hash, the next block would need to have that exact hash, which occurs with probability $<10^{-70}$ .

Based on this relationship, we define the chain $C\left(B\right)$ of a block $B$ as the path from $B$ leading back to $g$ , i.e., $C\left(B\right):=\left(B,P\left(B\right),\dots,P^{k-1}\left(B\right),g\right)$ . If $B^{\prime}\neq B$ is a block such that $B^{\prime}\in C\left(B\right)$ then $B^{\prime}$ is called an ancestor of $B$ and $B$ is called a child of $B^{\prime}$ . If $B^{\prime}=P\left(B\right)$ , then $B$ is called a direct child of $B^{\prime}$ . The length $k$ of $C\left(B\right)$ determines the block height $h\left(B\right)$ of block $B$ , i.e., $h\left(B\right)=k$ if $P^{k}\left(B\right)=g$ . The height of the genesis block is [math], i.e., $h\left(g\right)=0$ . The state of the blockchain in block $B$ is obtained by executing all transactions in $C\left(B\right)$ starting from the genesis block $g$ , see also [33].

A fork occurs whenever two different blocks $A$ and $B$ exist such that $P(A)=P(B)$ . At any time $t$ , each miner $n$ needs to decide which block in $\mathcal{B}^{t}_{n}$ to extend. This is done using a fork-choice rule, which in its simplest form is a function $f$ that maps a set $\mathcal{B}$ to a single block $B$ . The block chosen is called the head. In PoW, the fork-choice rule is to select the block $B$ with the highest accumulated proof-of-work, and in case of ties to prefer the block seen first. In the absence of serious attacks or network partitions [29, 63, 56], a naive measure of a chain’s PoW is the height $h\left(B\right)$ of a block. Hybrid Casper FFG’s fork-choice rule is discussed in the next section.

II-B Execution of Hybrid Casper FFG

Validators

In hybrid Casper FFG, some nodes assume the role of validators. Nodes can become validators by locking/staking tokens on the PoW chain, thus creating a deposit. In the Casper contract, this is done by calling the deposit and withdraw functions. Additionally, the logout function removes a validator from the active validator set and needs to be called before withdrawing. Validators need to wait a long period after depositing before being allowed to withdraw. In the benchmark setting [61], this is 15000 epochs, i.e., around 120 days.

Checkpoints

The central role of the validators is to vote for checkpoints[60]. A checkpoint is any block with block number $i\cdot l$ , where $i\in\{0,1,\ldots\}$ and $l\in\mathbb{N}$ denotes the epoch length: an epoch is defined as the contiguous sequence of blocks between two checkpoints, including the first but not the latter. Block [math] (which is also a checkpoint) denotes the genesis block. We will assume $l=50$ throughout this paper [61]. The epoch of a block is the index of the epoch containing that hash, e.g., the epoch of blocks 200 and 249 is 4. Because validators’ deposits change between epochs due to the rewards and penalties we denote by $D_{\upnu,i}$ the deposit of validator $\upnu\in V$ at the beginning of epoch $i\in\mathbb{N}$ , where $V$ denotes the set of active validators at epoch. Deposits also change between blocks but since withdrawals and deposits only occur at the end of epochs, it is sufficient to track the deposits at those points. In practice, the validator set is dynamic and changes over time too. For the present analysis it suffices to assume a fixed validator set. We denote by $D_{i}:=\sum_{\upnu\in V}D_{\upnu,i}$ the total stake (deposited value) at epoch $i$ .

Votes in Casper

In the Casper contract, voting is done by calling the vote function with the arguments $\langle\upnu,\textnormal{t},h(\textnormal{t})$ , $h(\textnormal{s}),\mathcal{S}\rangle$ , where the entries are explained in Table I.

We will say that a validator $\upnu$ who generates a vote transaction to the Casper address votes correctly or casts a valid vote if $\upnu$ includes the expected source and target epochs (checkpoints) returned to $\upnu$ by a Casper contract call and a valid signature created by $\upnu$ ’s private key [60, 61]. In particular, the only valid target epoch is the current epoch (in the contract) and the only valid target for a vote that appears in block $B$ is the checkpoint block with the correct height on the chain $C\left(B\right)$ . Hence, the correctness of a vote message depends on the chain that a node is voting on.444We address this case in more detail in Section III.

II-C Finalisation

A checkpoint t is justified if at least $2/3$ of the validators – in terms of stake – publish a vote of the form $\langle\upnu,\textnormal{t},\text{h({t}), h({s})},\mathcal{S}\rangle$ for some checkpoint s, such that s is an ancestor of t and is itself justified. A checkpoint s is finalised on a chain if it is justified and the checkpoint t that immediately follows s on that chain is also justified – i.e., if $\textnormal{t}=P^{l}\left(\textnormal{s}\right)$ and $\textnormal{s},\textnormal{t}$ are both justified, then s is finalised. We consider $g$ to be both justified and finalised, to serve as the base case for the recursive definition. Two finalised checkpoints $\textnormal{s},\textnormal{t}$ are conflicting if neither is an ancestor of the other. When handling vote transactions, the Casper contract only processes (i.e., includes) correct votes as defined above. Votes for the wrong targets and target epochs are considered invalid and ignored. A typical execution of the Casper protocol is illustrated in Figure 1.

The notion of finality is a central primitive in the design of Casper and before proceeding with the rest of the definitions, we elaborate on its relationship with the typical notions of finality in PoW blockchains.

Finality in Proof of Work

Technically, a PoW blockchain never allows a transaction to truly be “finalised”: for any given block $B$ with chain $C\left(B\right)$ , there is always a positive probability that a miner will create a longer chain that starts from an earlier block $B^{\prime}$ , i.e., $B^{\prime}\in C\left(B\right)$ with $B^{\prime}\neq B$ , and which does not include $B$ . However, although the probability is positive, it decreases exponentially in the distance $k$ between $B$ and $B^{\prime}$ , i.e., as expressed via $B^{\prime}=P^{k}\left(B\right)$ [31]. This argument was first made in the Bitcoin white paper based on the solution to the Gambler’s Ruin problem [51]. In particular, the chain of an attacker who controls less than a fraction $\alpha$ of the network hash power (mining power), for any $\alpha\in(0,0.5)$ , can be shown to have a probability of at most $\left(\alpha/\left(1-\alpha\right)\right)^{k}$ to overtake the original chain if the original chain is $k$ blocks longer when the attacker launches the attack. By choosing a sufficiently high $k$ , the probability of reverting a block can be reduced to practically theoretical levels [64], cf. Figure 2.

Hence, a strong notion of finality can be argued to exist even on PoW blockchains [64]. However, this argument assumes that more than half of the nodes behave honestly, and that they are coordinated on the same chain. There are a multitude of scenarios in which this assumption is invalid, e.g., due to high network latency, eclipse attacks [37], or the sudden influx of (possibly malicious) mining power [4, 3]. The latter scenario is a particularly big concern for smaller PoW blockchains, which can be overwhelmed by mining power that is normally used on bigger blockchain platforms. One recent example is the attack on Ethereum Classic that occurred in January 2019 – according to engineers at Coinbase, a prominent cryptocurrency exchange, one block with as many as 122 confirmations was overturned [52]. We can therefore conclude that even though PoW’s probabilisitic finality provides strong guarantees under normal conditions, such conditions cannot always be guaranteed in practice.

Finality in Casper FFG

The Casper protocol is intended to offer stronger finality guarantees than PoW in both the hybrid PoW/PoS and ultimately in the pure PoS settings. The key insight is that in PoS, nodes must make a deposit to become validators, and their messages that appear on the blockchain can therefore be linked to those deposits. If the users engage in clear misbehaviour, e.g., by voting for conflicting checkpoints, then they can be punished by slashing their deposits. The equivalent notion in PoW would be that the mining hardware of adversarial miners is destroyed. In our setting, the worst case of misbehaviour is to vote for conflicting checkpoints. If $2/3$ of validators are placing their stakes behind their votes for a checkpoint, then if another $2/3$ of validators place their stakes behind a contradictory checkpoint, then that necessarily implies that the intersection, i.e. at least $1/3$ of validators, have been backing both of the conflicting checkpoints. We still cannot guarantee absolute finality – if conflicting checkpoints are finalised due to validator misbehaviour, then either the chain permanently forks or some off-chain governance mechanism is used to decide in favour of one branch, at the expense of the other. However, we have an economic form of finality that guarantees that a finalised block is never overturned under the condition that no group of validators is willing to suffer a financial loss of at least $1/3$ of the total value of the staked deposits. In PoW, it is impossible to put concrete bounds on the required financial cost to overturn a finalised block, although estimates can be made based on the cost to rent mining power [3].

As we will see in Section III, there is one other scenario in which finality in Casper FFG can theoretically be compromised, namely due to liveness recovery in more than one branch during a serious, protracted network partition. However, we will show that the minimum required time duration of such a partition is extremely long, namely over three weeks. In reality, such a partition would require that a significant fraction of validators is not able to connect to the rest of the network, even via satellite, for several weeks, yet that they are able to communicate amongst themselves to vote on each other’s blocks. Even in such an unprecedented case, it may be possible to retroactively compensate deposit holders on the losing branch through a hard fork coordinated by an off-chain governance mechanism (e.g., as in the case of the DAO hard fork). Hence, we do not consider this scenario to be a realistic threat to block finality.

Fork-Choice Rule

The Hybrid Casper FFG fork-choice rule extends the PoW fork-choice rule of Section II-A. In particular, to select a block as the head of the chain, a client queries the contract to find the block(s) with the highest justified epoch, prioritising the block with the highest mining PoW only in a case of tie. Clients only consider epochs in which the total deposit exceeds a given minimum threshold and never revert a known finalised checkpoint. If a chain has no justified checkpoints beyond $g$ , the fork-choice rule essentially reverts to pure PoW [61].

II-D Rewards and Penalties Mechanism

According to Casper’s payments scheme, validators who vote correctly during an epoch are rewarded, and validators who do not are penalised. This is achieved by adjusting the validators’ deposits depending on their own voting behaviour, i.e., on whether they are voting or not, and on the performance of the protocol as a whole, i.e., on what total fraction of validators vote correctly and whether that is enough to justify and finalise checkpoints. Specifically,

Correct voting:

If checkpoints are being finalised, i.e., if at least $2/3$ of validators are voting correctly, then deposits of correctly voting validators increase by a positive interest rate. If checkpoints are not being finalised, deposits of correct voting validators remain the same. The interest rate depends on the total deposit and how many other validators are voting.

Non-voting:

Regardless of finalisation, non-voting validators are penalised and their deposits shrink. The penalties are increasing in the proportion of non-voting validators. If epochs fail to be finalised during sustained time periods, then the penalties gradually become more severe.

Conflicting/incorrect voting:

Incorrect votes are ignored and validators who cast them are considered as non-voters and are not rewarded. If evidence is provided that validators cast conflicting votes, then their deposits are partially or entirely removed (slashed) depending on the severity of the violation and the overall protocol performance (i.e., the proportion of “correct” voters and whether epochs are being finalised or not).

Incorrect or missing votes are not punished as harshly as conflicting votes, as there are several faulty behaviours that can cause a validator $\upnu$ to fail to produce a valid vote, as we discuss below.

A valid vote by $\upnu$ for the target epoch either never makes it onto the blockchain, or only outside the target epoch. This could be because

(a)

$\upnu$ never cast the vote, or was too late when doing so, 2. (b)

a majority of the other validators are censoring $\upnu$ , 3. (c)

a significant portion of the nodes decided not to propagate $\upnu$ ’s vote, or 4. (d)

the network latency was too severe. 2. 2.

A vote by $\upnu$ does make it onto a block inside the target epoch, but it is otherwise invalid. This could be because

(a)

the signature is invalid, 2. (b)

the source epoch does not use the last justified epoch, or 3. (c)

the target hash is invalid.

In case 1a, the fault clearly lies with $\upnu$ . However, in cases 1b and 1c the fault lies with (a coalition of) malicious validators or other nodes respectively. In case 1d, the fault does not even necessarily lie with participants in the blockchain. In case 2a, this could have been due to a fault by $\upnu$ , or by one or more malicious or malfunctioning nodes tampering with $\upnu$ ’s message before propagating. In case 2b, this is either the result of a mistake by $\upnu$ , a safety fault (in which a previously finalised epoch is overturned), or because $\upnu$ had an incomplete view of the network. In case 2c, the blockchain must have been forked when $\upnu$ voted — again, this could have been caused by the network, a mistake by $\upnu$ , misbehaving nodes (who blocked $\upnu$ ’s view of the network), misbehaving miners (who were withholding blocks from $\upnu$ ), or a misbehaving coalition of validators (who finalised a chain that was different from the one preferred by the network).

The difficulty with fault attribution in the case of missing/incorrect votes (which in general suffers from the problem of speaker/listener fault equivalence [9]) creates a tension between preventing harm and fairness, i.e., between sufficiently penalising malicious validators and adequately incentivising honest validators to participate. In Casper’s implementation, these adjustments are achieved via a scheme of reward factors, cf. (1) and (2) that properly update validator’s deposits, cf. (3). This payment scheme is designed to make the protocol incentive-compatible, i.e., to encourage validators to vote correctly and as often as possible, and enforces the protocol’s purposes of liveness and safety, as we discuss in more detail in Section III.

The Scheme

In detail, the Casper contract adjusts validators’ deposits via the individual and the collective reward factors, $\rho_{i}$ and $C_{i}$ respectively, that depend on each validator’s voting behaviour and on the aggregate protocol functionality, i.e., on whether epochs are finalised or not, for every epoch $i\in\mathbb{N}$ . Specifically, let ESFi denote the Epochs Since Finalisation during epoch $i$ , defined as $i$ minus the height of the last finalised epoch. Since $g$ is finalised, ESF ${}_{0}=0$ and ESF ${}_{1}=1$ . For $i\geq 2$ , ESFi always equals $2$ in the ideal situation where everyone always votes (it requires two consecutive epochs to be justified for the first of them to be finalised), otherwise it is higher. Based on the total stake $D_{i}$ in epoch $i\in\mathbb{N}$ , the individual reward factor $\rho_{i}$ , is then defined as follows

[TABLE]

where $\gamma,p,\beta>0$ denote the base interest, total deposit dependence and base penalty factors, respectively. In the benchmark specification[61], the parameters were set as $\gamma=7\cdot 10^{-3}$ , $\beta=2\cdot 10^{-7}$ , and $p=1/2$ . Here, $p$ was chosen to strike a balance between $p=0$ (i.e., constant interest rate per validator) and $p=1$ (i.e., constant total amount of interest paid out by the protocol). In particular, given $p=1/2$ , $\gamma$ and $\beta$ were derived by reverse-engineering the constants from two desired outcomes: assuming that 10M ETH has been deposited, i) validators earn $\approx$ 5% annual interest if everyone (nearly) always votes, and ii) if 50% of the validators go offline, they lose 50% of their deposits in 21 days555The parameter choice will be discussed further in Section IV and Section IV-A for more details on their values and choice..

To define the collective reward factor, let

[TABLE]

At the end of epoch $i$ , let $m_{i}$ denote the weighted fraction of correctly voting validators in epoch $i$ , defined as $m_{i}:=\frac{1}{D_{i}}\textstyle\sum_{\upnu\in V}{\bf 1}_{\upnu,i}D_{\upnu,i}$ . The collective reward factor, $C_{i}$ , at the beginning of epoch $i$ is defined as

[TABLE]

Validators’ deposits are then updated via the scheme

[TABLE]

The intuition behind the updates in validators’ deposits $D_{\upnu,i}$ in (3) and the factors (1) and (2) that are used is the following.

Case 1: ESF ${}_{i}>2$ .

In this case, epochs are not being finalised properly, i.e., there exists a fraction of more than $1/3$ of validators that are not voting as expected. Accordingly, $C_{i}=0$ and hence

[TABLE]

Obviously, the actual value of $D_{\upnu,i+1}$ now depends on the value of $\mathbf{1}_{\upnu,i}$ , i.e., on whether validator $\upnu$ voted successfully during epoch $i$ or not.

Case 1a: $\mathbf{1}_{\upnu,i}=1$ .

In this case, validator $\upnu$ voted successfully and $D_{\upnu,i+1}=D_{\upnu,i}$ , i.e., validator $\upnu$ ’s deposit remains the same. In other words, if checkpoints are not finalised but a validator keeps voting successfully, then their deposits remain unharmed.

Case 1b: $\mathbf{1}_{\upnu,i}=0$ .

In this case, validator $\upnu$ did not vote successfully which means that they essentially contribute with their faulty behavior in checkpoints not being finalised. According to (3), $D_{\upnu,i+1}=\frac{1}{1+\rho_{i}}D_{\upnu,i}$ , and hence, since $\rho_{i}>0$ , cf. (1), the non-voting validator $\upnu$ ’s deposit will shrink. However, the exact intensity depends on the value of $\rho_{i}$ and the selection of parameters $\gamma,p$ and in particular, by the base penalty factor, $\beta$ . Specifically, since ESF ${}_{i}>2$ , a larger $\beta$ “penalises” the non-voting validator $\upnu$ by increasing $\rho_{i}$ . Additionally, the penalties further increase as ESFi increases, i.e., as the abnormal network conditions (non-finalization of checkpoints) persist.

Case 2: ESF ${}_{i}=2$ .

In this case, checkpoints are finalised as expected and possibly only a minority of validators – less than $1/3$ in terms of their stake – are not voting as expected. This implies that $\rho_{i}=\gamma\cdot D_{i}^{-p}$ , i.e., that the individual reward factor for validator $\upnu$ depends now only on the base interest $\gamma$ , the total dependence $p$ and the total staked deposit at epoch $i$ , $D_{i}$ . Again, the exact effect on validator $\upnu$ ’s deposit depends on whether $\upnu$ voted successfully during epoch $i$ or not.

Case 2a: $\mathbf{1}_{\upnu,i}=1$ .

In this case, $D_{\upnu,i+1}=\left(1+C_{i}\right)D_{\upnu,i}=\left(1+\frac{1}{2}m_{i}\rho_{i}\right)D_{\upnu,i}$ , i.e., validator $\upnu$ ’s deposit increases by the collective reward factor. Since, $m_{i}>2/3$ , and possibly even $m_{i}\approx 1$ under default conditions, we obtain the approximation

[TABLE]

In other words, a voting validator $\upnu$ ’s deposit increases by (approximately) half the individual reward factor which in turn is decreasing in the total staked deposit (more validators means each validator earns less).

Case 2b: $\mathbf{1}_{\upnu,i}=0$ .

In this case,

[TABLE]

Since more than $2/3$ of validators are voting successfully (epochs are being finalised), we have that $m_{i}\rho_{i}/2\in[\rho_{i}/3,\rho_{i}/2]$ . Hence, validator $\upnu$ ’s deposit decreases. The intensity of the decrease depends on the order of magnitude of $\rho_{i}$ which is typically quite small.

The above analysis is summarised in Table II.

In the Casper contract, the reward factors are updated by calling the function initialize_epoch once per epoch (the contract processes only the first call in each epoch).

Slashing Conditions

Finally, to account for conflicting votes, Casper introduces the following commandments or slashing conditions, [17]: a validator $\upnu$ who publishes two distinct votes

[TABLE]

violates Casper’s slashing conditions, if

I.

h(t1) $=$ h(t2): i.e., they are for same target height, 2. II.

h(s1) $<$ h(s2) $<$ h(t2) $<$ h(t1): i.e., one vote is within the span of the second vote.

Any validator is able to call the slash function with the data for two potentially offending vote messages as its arguments. If the slash call is found to be valid, then the offending validator’s deposit is partially or entirely taken away (slashed) and the sender receives 4% of the validator’s deposit as a ‘finder’s fee’. Invalid calls to slash are ignored in the same manner as invalid votes. Calls to slash can be valid on any chain, even those chains that do not include one or more of the offending vote calls in any of its blocks, because the function arguments and signatures by themselves are sufficient evidence for misbehaviour. In the Casper contract, the degree to which the validator’s deposit is shrunk depends to the total amount slashed ‘recently’ across the protocol – the reasoning is to punish more harshly when there is a higher risk that two conflicting checkpoints with the same height will be finalised.

III Analysis

In this section we investigate how Casper’s incentive mechanism affects the fundamental properties of the overall consensus protocol, i.e., on the underlying block proposal mechanism combined with Casper FFG’s checkpointing scheme. Before we begin the analysis, we discuss our threat and execution model in Section III-A. We proceed by analysing the fundamental properties of liveness and safety in Section III-B and III-C, respectively. We focus on the following types of liveness and safety faults for checkpointing protocols.666See also [34, 2, 40] and [66] for varying definitions of these concepts.

Liveness faults:

checkpoints not getting finalised during one or more consecutive epochs.

Safety faults:

two or more conflicting checkpoints being finalised in the same or different epochs. (After all, this would either lead to a permanent fork, or to at least one node having to overturn a finalised checkpoint through a manual reset.)

Finally, we study incentive compatibility (i.e., whether validators are incentivised to follow the protocol) in Section III-D.

III-A Execution Model

Node Types

We assume that the protocol consists of two main types of nodes: block proposers, who propose blocks on the underlying chain, and validators who vote for checkpoint blocks. We use the term $\alpha$ -strong for groups of nodes who control at least a fraction $\alpha\in(0,1]$ of the resources necessary for their role in the protocol (e.g., stake for validators, or mining power for PoW block proposers). When we state that a certain group of nodes is $\alpha$ -strong during a certain period, e.g., until finalisation resumes, then we assume that their strength at any point in time is at least greater than $\alpha$ even if it varies across the period. For example, if the group of online nodes is $60\%$ -strong at the start of a period, but $20\%$ go offline in the middle of the same period, then we say that the online nodes are at most $40\%$ -strong throughout the period. Since the Casper contract does not add new validators to the active validator set when checkpoints are not being finalised, and most of the proofs in this section consider periods without finalisation, changes to the strength of validator groups are in practice limited to network partitions, latency, validators going online/offline, and the effects on their deposits of rewards and penalties.

The theorems in Sections III-B and III-C reason about the liveness and safety of the network as seen from the perspective of a single user, and only hold if the fraction of the consensus nodes who support that user’s branch is strong enough. In particular, the supporting nodes are those that are honest (i.e., protocol-following), online (i.e., non-faulty, and not being censored or eclipsed), and aware of the same input as the user (i.e., on the same branch during a network partition). We denote by $\alpha$ the strength of the validators who support the chain seen by the user. Similarly, we denote by $\mu$ the strength of the block proposers who support the chain of the user.

Network Synchrony

In principle, we assume that the network is partially synchronous [24], which means that there is a finite upper bound on the time before a message from any node $A$ reaches any other node $B$ , but that we do not know the exact value of this bound. This has consequences for our failure model: e.g., we do not require that a vote message always reaches a block proposer before the end of the epoch, which would lead to a validator suffering a liveness penalty. However, when we say that the supporting validators are $\alpha$ -strong, we do require that the proportion of the nodes whose messages make into the blockchain in time does not go below $\alpha$ . In other words, the fraction $1-\alpha$ of non-supporting validators during an epoch includes those whose messages did not make it onto the blockchain before the end of the epoch due to network latency.

In the benchmark parameter setting, the duration of an epoch is $700$ (or $50$ times $14$ ) seconds. Each validator can individually decide when to cast a vote - this is a trade-off between 1) voting too early and therefore risking that her view of the blockchain is out-of-date 2) voting too late and therefore risking that her vote does not appear on the blockchain in time. For example, a validator who casts her vote after a quarter of the epoch has 175 seconds since the start of the epoch to decide on a block and 525 to get the message on the blockchain. In practice, we assume that these periods are long enough to avoid network latency having a significant impact on the strength of the supporting nodes.

During a network partitions, some nodes will not be able to reach every other node within a bounded time (that is, before the partition is resolved). This case is treated separately in the proofs in this section – as mentioned before, nodes that cannot communicate with a user are not counted as supporting that user’s chain.

Interactions Between Block Proposers and Validators

In “hybrid” Casper FFG, there is some interdependence between the validators and the block proposers in the sense that the protocol messages sent by the former need to be included in blocks proposed by the latter. For example, malicious block proposers could 1) refuse to include vote messages of blacklisted validators in their blocks, 2) refuse to extend blocks that include those messages, or 3) attempt to intimidate other block proposers into enforcing the blacklist through feather forking [49]. However, the probability of successfully performing the former two attacks is low if the strength of the malicious block proposers is noticeably below $0.5$ , and if the vote messages are sent early within the epoch. For example, for attack 1 it holds that if the malicious nodes are $(1-\mu)$ -strong, and if virtually all block proposers have seen a validator’s vote after the $k$ th block within an epoch, then the probability that not a single block includes the message before the end of the epoch equals $(1-\mu)^{l-k}$ . For $1-\mu=\frac{1}{3}$ and $k=20$ , this probability is approximately equal to $4.9\cdot 10^{-15}$ . For attack 2 to succeed, the malicious nodes need to build a chain of length $l-k$ before the honest nodes do, so that they can override the honest nodes’ chain (which may include the blacklisted validator’s vote) at the end of the epoch. This probability is similarly low.777It can be expressed in terms of the probability of reaching some set of absorbing states in a discrete-time Markov chain. Numerical algorithms exist to compute such probabilities, e.g., those implemented in the model checking tool PRISM [42], but a discussion of this would be outside the scope of this paper. Feather forking is theoretically feasible even when the malicious nodes are less strong, but requires that the honest nodes comply despite invariably hurting the confidence that users have in the platform by doing so, and therefore reducing their own profits. Finally, a malicious coalition of block proposers could try to censor slash messages. Since these messages are not epoch-dependent, the censorship would need to be maintained indefinitely, which is impossible in practice if the malicious nodes are not at least $0.5$ -strong.

The role of potentially malicious block proposers in the liveness proof will be discussed more detail in Section III-B4, and we will make our assumptions regarding the fraction of supporting block proposers explicit for Theorem 8. We note that in the future, Ethereum intends to adopt a fully PoS setting, in which case the supporting block proposer and validator groups always have equal strength.

As a final note, we would like to emphasise that a coalition of validators can also overrule a majority of the block proposers by voting for checkpoints that are different from those prescribed by the longest-chain rule. If the validators are $\frac{2}{3}$ -strong, then they have complete freedom to justify and finalise their preferred checkpoints. This would enable a supermajority of activist validators to act against attacks by a majority of block proposers (e.g., long-term censorship of slash messages). Furthermore, any other group of validators has the potential to fork away from the main chain, and to eventually become $\frac{2}{3}$ -strong on their own chain through the liveness recovery mechanism. This procedure is called a minority fork, but detailed analysis of this mechanism is considered out of scope for this paper.

III-B Liveness

In this section, we focus on checkpoint liveness as defined below.

Definition 1 (Checkpoint liveness).

We say that a checkpointing protocol $\Pi$ is $\alpha$ -live for some $\alpha\in\left(0,1\right]$ , if any $\alpha$ -strong group of validators who support a chain are able to finalise checkpoints on that chain after a finite number of epochs with probability $1$ .

During any period $E\subset\mathbb{N}$ of consecutive epochs in which more than $1/3$ of the validators (in terms of stake) are not voting correctly, checkpoints cannot be finalised. In the reward mechanism, this translates to an increase in the epochs since finalisation, ESFi which in turn affects both the individual $\rho_{i}$ (1) and the collective $C_{i}$ (2) reward factors, for $i\in E$ . This is captured by Lemma 2. Without loss of generality, we assume that a fault involving ( $1-\alpha$ )-strong validators not following the protocol is initiated at epoch [math]. All relevant notation is summarised in Table III.

III-B1 Delaying Finalisation: Liveness Recovery from Offline Users

We begin with a discussion of the scenario where checkpoints are not being finalised due to a sufficiently large number of nodes having gone permanently offline. For ease of notation, we consider the case where a single validator $\upnu$ represents the supporting nodes, and another validator $\tilde{\upnu}$ the non-supporting nodes.

Lemma 2.

Let $D_{0}$ denote the initial stake in epoch [math] and let $\upnu,\tilde{\upnu}$ be $\alpha$ and $\left(1-\alpha\right)$ -strong validators, respectively, with $\alpha\in\left(0,2/3\right)$ . Assume that from epoch [math] onwards, only the $\alpha$ -strong validator $\upnu$ continues to vote correctly. Then, for the consecutive epochs $i\geq 1$ that are not being finalised

(i)

the total deposits $D_{i}$ are decreasing in $i$ , 2. (ii)

$D_{i}$ * is given by $\textstyle D_{i}=\alpha D_{0}+\left(1-\alpha\right)D_{0}\prod_{j=0}^{i-1}\left(1+\rho_{j}\right)^{-1}$ ,* 3. (iii)

the individual reward factors $\rho_{i}$ are unboundedly increasing in $i$ .

Proof.

By definition (2), as long as epochs $i\geq 1$ are not being finalised, $C_{i}=0$ . Hence, by (3)

[TABLE]

and similarly $D_{\tilde{\upnu},i}=\left(1+\rho_{i-1}\right)^{-1}D_{\tilde{\upnu},i-1}<D_{\tilde{\upnu},i-1}$ . The last inequality holds because $\rho_{i}>0$ for all $i\geq 1$ by definition. Since $D_{i}=D_{\upnu,i}+D_{\tilde{\upnu},i}$ for all $i\geq 1$ , this implies $D_{i}=D_{\upnu,i}+\left(1+\rho_{i-1}\right)^{-1}D_{\tilde{\upnu},i-1}<D_{i-1}$ , which shows (i). The expression in (ii) is obtained by repeated application of the previous recursive equalities, $D_{\upnu,i}=D_{\upnu,i-1}$ and $D_{\tilde{\upnu},i}=\left(1+\rho_{i-1}\right)D_{\tilde{\upnu},i-1}$ , and the assumption $D_{\upnu,0}=\alpha D_{0}$ . Finally, to prove (iii), observe that ESF ${}_{i}-2=i$ , since the last finalised epoch is “ $-2$ ” and hence888Since we assumed that the attack started in epoch [math] to avoid unnecessary notation, $-2$ should be interpreted acccordingly, i.e. it is a convention to denote the last finalised epoch, $2$ epochs prior to the start of the attack., by (1)

[TABLE]

Since $D_{i}$ is decreasing by (i) and $p>0$ , $\rho_{i}$ is increasing to $\infty$ which concludes the proof. ∎

Intuitively, Lemma 2 states that as epochs are not getting finalised, Casper’s implemented incentives mechanism retains the deposits of correctly and consistently voting validators constant – i.e., validators who vote in each epoch without violating any slashing conditions – and decreases the deposits of non-voting validators. Thus, the voting validators’ stake as a share of the total deposited stake increases. As the ESF increases, this process continues until the voting validators will account for more than $2/3$ of the total stake on the chain that they are voting on. After that, the ESF resets to $2$ and the updates are much less aggressive. However, the overall period that is required for this to happen depends on the initial proportion of their stake and the voting behavior of the adversary (or the accidentally off-line nodes). This is the subject of Section III-B2.

III-B2 Delaying Finalisation: Liveness in the Worst-Case Scenario

The assumption in Lemma 2 that the $\left(1-\alpha\right)$ -strong nodes never vote again (after the initiation of the attack), does not correspond to the worst-case scenario for the protocol. If the “non-voting” validators vote irregularly, then this slows down the reduction process of their deposits. In particular, if all $\left(1-\alpha\right)$ -strong malicious validators can coordinate to reach a total vote of just below $2/3$ – the finalisation threshold – in each epoch, then they thwart finalisation while minimizing the amount of penalised deposits (and equivalently maximize the time that the protocol is unable to finalise checkpoints). This case is treated in Theorem 3 in which we account for the following types of validators:

(i)

Consistently supporting validators. Let $\alpha_{i},i\geq 0$ denote the deposit of the of $\alpha$ -strong validators who vote consistently during all consecutive epochs $i\geq 0$ for which finalisation does not happen. The size of the deposits of these validators in the initial period equals $\alpha_{0}\in\left(0,2/3\right)$ . 2. (ii)

Irregularly voting validators. To account for the worst-case scenario, we assume that the remaining $1-\alpha_{0}$ validators (in terms of their initial stake in epoch [math]), can coordinate under a single entity and decide their behavior in order to delay finalisation as much as possible. To model this situation, we assume that in each epoch $i\geq 0$ , a fraction $\delta_{i}$ of these validators are voting, where $\delta_{i}$ is the maximum possible number in $\left(0,1\right]$ – if any – so that $\alpha_{i}+\delta_{i}\left(1-\alpha_{i}\right)\leq 2/3$ , i.e., so that finalisation is marginally not possible. This policy maximizes the “life” of the adversarial stake while preventing finalisation of checkpoints.

Our goal is to prove that the sequence of periods for which such a $\delta_{i}\in\left(0,1\right]$ exists is bounded, i.e., that for any initial honest stake $\alpha_{0}\in\left(0,2/3\right)$ finalisation of checkpoints will ultimately resume (for $\alpha>2/3$ , the claim is trivial). This is achieved in Theorem 3. To model the worst-case scenario, we assume that all validators not belonging to the group of $\alpha_{0}$ -strong validators are malicious. In reality, some of them may only accidentally go off-line for some period and resume proper voting after that or vote irregularly during the period of non-finalisation. Also, note that during periods of non-finalisation, new validators cannot enter the protocol, i.e., deposits of new stake are not processed and reflected in the active validator set. This is critical to ensure safety of checkpoints in the PoS environment.

Theorem 3.

Let $D_{\upnu,0},D_{\tilde{\upnu},0}$ denote the initial stake in epoch [math] of the $\alpha_{0}$ and $\left(1-\alpha_{0}\right)$ -strong validators $\upnu$ and $\tilde{\upnu}$ , respectively, with $\alpha_{0}\in\left(0,2/3\right]$ . Assume that from epoch [math] onwards, only the $\alpha$ -strong validator $\upnu$ continues to vote consistently and correctly. Also assume that in each epoch $i>0$ , a fraction $\delta_{i}\in(0,1]$ of the $\left(1-\alpha\right)$ -strong validators is also voting correctly, so that for each epoch $i\geq 0$ , $\delta_{i}$ is the solution to the optimization problem

[TABLE]

Then, the number $T\geq 1$ of consecutive epochs that are not being finalised is finite.

Proof.

Since, any feasible solution of (WC) (where WC stands for the worst-case policy) must satisfy the constraints of (WC), we have that the optimal solution $\delta_{i}$ , whenever it exists, will be given by

[TABLE]

Hence, (WC) is feasible if $\alpha_{i}\leq 2/3$ . Accordingly, to prove the claim, we need to show that there exists a $T\geq 1$ such that $\alpha_{T}>2/3$ . According to Table II, the deposit-shares at the start of epoch $t+1$ of the initially $\alpha_{0}$ -strong honest validators and the $\left(1-\alpha_{0}\right)$ -strong validators who follow the (WC) plan will be

[TABLE]

Hence,

[TABLE]

where for the inequality $(*)$ , we used that $D_{\tilde{\upnu},i}<D_{\tilde{\upnu},0}$ by Lemma 2-(i). Now, since the limit $\alpha$ of $\alpha_{i}$ as $i\to\infty$ exists – the sequence $\alpha_{i}$ is increasing by Lemma 2-(i) and (iii) and bounded by $1$ – and since $\left(1+\rho_{i}\right)^{-1}$ vanishes as $i\to\infty$ , we can take limits in the last inequality to obtain

[TABLE]

Hence, the possible limits of the sequence $\alpha_{i}$ is the locus of all points $\alpha\in[0,1]$ that satisfy inequality (5) for any given value of $\left(1-\alpha_{0}\right)\in[1/3,1)$ (adversarial stake at the outset of the attack). To obtain a contradiction, assume that $\alpha\leq 2/3$ . Then, $\left(1-\alpha_{0}\right)\left(2/3-\alpha\right)\leq 0$ for any initial honest stake $\alpha_{0}\in(0,2/3]$ and (5) becomes

[TABLE]

which is a contradiction, since we have assumed that $\alpha\leq 2/3$ . Hence, in the limit it holds that $\alpha>2/3$ , which implies that there exists $T\in\mathbb{N}$ , i.e., finite, such that the stake $\alpha_{t}$ of voting validators at each epoch $t\geq T$ exceeds $2/3$ and hence finalisation of checkpoints resumes. This concludes the proof. ∎

III-B3 Checkpoint Liveness

Even in the case described in Theorem 3, the adjustment of the deposits of non-voting validators will continue until the (consistently) voting validators will acount for more than $2/3$ of the total stake on the chain that they are voting on. From this point on, they will resume finalisation of checkpoints and hence, the ESF will reset to $2$ , hence making changes in deposits much slower. This is the main argument behind Casper’s liveness which is formalised in the Theorem 4 and illustrated in Figure 3.

Theorem 4.

The Casper contract is $\alpha$ -live for any $\alpha\in\left(0,1\right]$ .

Proof.

If the supporting validators control more than $\frac{2}{3}$ of the stake, then finalisation and hence, liveness are immediate. To treat the remaining case, assume that voting validators control $\alpha<\frac{2}{3}$ of the stake at epoch [math]. Without loss of generality999Possibly after renumbering epochs so that the (WC) policy mentioned in the worst case above, does not apply. In any case, the intention is to provide an intuitive proof about Casper’s checkpoint liveness devoid of the technicalities of the worst-case scenario that was treated in Section III-B2. All arguments carry over to that case as well but with different bounds on the time before finalisation is resumed., also assume that after epoch [math] the remaining $\left(1-\alpha\right)$ -strong validators stop voting. In this case, finalisation will resume after epoch $k\geq 1$ , if $D_{\upnu,k}\geq\frac{2}{3}D_{k}$ or equivalently if $D_{k}\leq\frac{3}{2}\alpha D_{0}$ , since, by the proof of Lemma 2, $D_{\upnu,k}=D_{\upnu,0}$ . Hence, by Lemma 2(ii)

[TABLE]

which is equivalent to $\prod_{i=0}^{k-1}\left(1+\rho_{i}\right)\geq 2\left(1-\alpha\right)/\alpha$ . This implies that finalisation will resume after epoch $k_{\alpha}$ , where $k_{\alpha}$ is the solution to the following minimisation problem

[TABLE]

Hence, it remains to show that the above problem has a finite solution $k_{\alpha}\in\mathbb{N}$ for every $\alpha\in\left(0,\frac{2}{3}\right)$ . Since $\rho_{i}=\gamma D_{i}^{-p}+\beta i\geq\beta i$ by the proof of Lemma 2 (iii), the standard inequality $\prod_{i=0}^{k-1}\left(1+\rho_{i}\right)\geq 1+\sum_{i=0}^{k-1}\rho_{i}$ , implies that it suffices to find a $k$ such that $\textstyle\sum_{i=0}^{k-1}\beta i=\beta\frac{k\left(k-1\right)}{2}\geq 2\left(1-\alpha\right)/\alpha$ . Since $k^{2}$ is unbounded and $\beta>0$ is constant, such a $k$ exists for every $\alpha\in\left(0,2/3\right)$ . ∎

Given the benchmark parametrisation of the contract, cf. Sections II-D and IV-A, the number of epochs needed to resume finalisation can be computed numerically: let $\phi(\alpha)$ be the minimum number of epochs required before finalisation is resumed if an $\alpha$ -strong group of of validators permanently stops voting. The evolution of $\phi(\alpha)$ is illustrated in Figure 4 for different values of $\alpha$ .101010Lemma 2 and Theorem 4 assume that faulty validators stop voting completely. More elaborate voting/non-voting strategies which can delay finalisation beyond the rate given by $\phi(\alpha)$ are discussed in Section 3.. We emphasise the following values which we will use in the study of Casper’s safety properties: for $\alpha=0.67$ , $0.51$ , and $0.49$ , the number of epochs needed for $\alpha$ -strong validators to resume finalisation is 3733, 2698, and 2546 respectively.

III-B4 Discussion of the Liveness Proof

We conclude the section on liveness with a discussion about the implications of some of the assumptions of Theorem 4. First, the theorem states that liveness is recovered within a finite number of epochs, but the time duration of those epochs depends on the underlying block proposal mechanism. For example, if an $(1-\mu)$ -strong group of miners in Ethereum’s current PoW chain also go offline, then the average time between blocks goes up to $14/\mu$ seconds. If all miners have gone offline (i.e., $\mu=0$ ), then the number of epochs before liveness recovery is still finite, but the time duration of each epoch is infinite. However, the PoW chain’s permissionless nature allows anyone (including the validators) to join the protocol, so this situation would be unlikely to persist in practice.

As discussed in Section III-A, the block proposers also have other methods to influence liveness, e.g., by censoring vote messages. Note that our definition of $\alpha$ -strong support precludes more than an $(1-\alpha)$ -strong group of validators being censored by the block proposers. Also, a coalition of validators can ignore the standard fork-choice rule to prioritise a chain that includes their votes. As such, the proof of checkpoint safety holds for all supporting block proposer strengths $\mu\in(0,1]$ , assuming that the underlying block proposal mechanism is still live (which is the case for Ethereum’s PoW chain).

Finally, although we have proven the liveness of Casper’s checkpointing mechanism, we have so far not discussed its impact on transaction liveness, i.e., the ability of honest nodes to append transactions to the ledger. If a coalition of malicious validators is at least $\frac{2}{3}$ -strong, then it is free to perform censorship by refusing to vote for checkpoints that include a blacklisted transaction. Furthermore, as we will see in the next section, if the malicious-nodes are $1-\alpha$ -strong with $\alpha\in(\frac{1}{3},\frac{1}{2})$ , then they can vote for checkpoints on a censored chain, and be able to finalise checkpoints before the $\alpha$ -strong nodes that support the main chain (i.e., the chain that observes the protocol’s fork-choice rule) do so. Hence, although the checkpointing protocol is by itself live for any $\alpha>0$ , it will only produce meaningful checkpoints for users if $\alpha>\frac{1}{2}$ .111111If $\alpha\leq\frac{1}{2}$ , the system may still be recovered using a minority fork as mentioned in Section III-A.

III-C Safety

Having proved the liveness of our checkpointing protocol, we now move on to safety, which we define as follows:

Definition 5 (Checkpoint safety).

We say that a checkpointing protocol $\Pi$ is safe if the following holds: any protocol-following node who considers a checkpoint $i$ as final at some time point $\tau\geq 0$ , will also consider $i$ as final at any time point $t>\tau$ .

To explore the trade-off between liveness and safety, we distinguish two scenarios: in the first, we assume a unified network in which clients have a view of all active chains, and in the second, a partitioned network, in which each client has a view of only a single chain.

In the first scenario, we seek to prevent the nothing-at-stake problem, which occurs when there is an incentive to finalise conflicting checkpoints on different chains during a fork. Casper’s mechanism ensures that in the short term, different checkpoints cannot be finalised unless at least $1/3$ of validators violate one slashing condition. Intuitively, this relies on the fact that a checkpoint can be finalised if and only if a direct child of this checkpoint has been justified, see Section II-C. Hence, for two conflicting checkpoints to have been finalised, there must exist two pairs of consecutive justified checkpoints on two different (conflicting) chains. Taking into account that votes between different chains are identified by the protocol as invalid and are ignored, two cases may have occured:

•

two of the conflicting checkpoints have the same height: this directly violates slashing condition I.

•

all conflicting checkpoints have different heights: this implies that one pair of consecutive justified checkpoints must be included within the span of two justified checkpoints on the conflicting chain, which violates slashing condition II.

This is the statement of Theorem 6, whose proof formalises the above intuition and is similar in nature to [11, Theorem 1].

Theorem 6.

Assuming that the network is not partitioned, two conficting checkpoints cannot be finalised unless at least $\frac{1}{3}$ of the validators violate a slashing condition.

Proof.

Let $B_{1}$ and $B_{1}^{\prime}$ denote two conflicting finalised checkpoints with direct children $B_{2}$ and $B^{\prime}_{2}$ , respectively. Also, let $M$ denote the maximal – in terms of block height – common element in the chains of the two conflicting justified checkpoints, i.e.,

[TABLE]

$M$ exists since at least $g\in C\left(B_{2}\right)\cap C\left(B^{\prime}_{2}\right)$ by assumption. Then, there exist $m,n\geq 2$ such that

[TABLE]

with $P^{m}\left(B^{\prime}_{1}\right)\neq P^{n}\left(B_{1}\right)$ by definition of $M$ . If there exist blocks

[TABLE]

with $h\left(B\right)\neq h\left(B^{\prime}\right)$ , then this creates a violation of slashing condition I. In other words, given that all blocks in the chains up to $B_{2}$ and $B^{\prime}_{2}$ are different after $C\left(M\right)$ , they must be at different heights for slashing condition I to not be violated. To proceed, let’s assume that condition I is not violated, i.e., that $h\left(B\right)\neq h\left(B^{\prime}\right)$ for all $B\in\left(B_{2},B_{1},P\left(B_{1}\right),\dots,P^{n}\left(B_{1}\right)\right)$ and $B^{\prime}\in\left(B^{\prime}_{2},B^{\prime}_{1},P\left(B^{\prime}_{1}\right),\dots,P^{m}\left(B^{\prime}_{1}\right)\right)$ . However, since $B_{2}$ and $B^{\prime}_{2}$ are both direct children of $B_{1}$ and $B^{\prime}_{1}$ respectively, this means that $h\left(B_{2}\right)=l+h\left(B_{1}\right)$ and $h\left(B^{\prime}_{2}\right)=l+h\left(B^{\prime}_{1}\right)$ where $l$ denotes the epoch length. In turn, this implies – after possibly renaming $B^{\prime}_{1}$ to $B_{1}$ and $B^{\prime}_{2}$ to $B_{2}$ and hence without loss of generality – that

[TABLE]

Hence, since $B^{\prime}_{2}$ and $B^{\prime}_{1}$ have consecutive heights (in terms of checkpoints), there must be a $k\in\{1,2,\dots,n\}$ with

[TABLE]

which creates a violation of slashing condition II. ∎

Remark 7 (Theorem 6 during a network partition).

We have required for the proof of Theorem 6 that the network is not undergoing a partition. This assumption can be loosened somewhat, but the duration of the partition does have an impact on the minimum amount of stake that needs to be slashed to achieve a safety fault. The reason is that the deposit sizes on the different branches of the fork evolve as the partition continues. For example, if the honest nodes are $80\%$ -strong but split evenly across two branches during a fork, and the malicious nodes are $20\%$ -strong but able to vote on both branches, then the malicious voters will not be able to cause a safety fault immediately. Also, since the honest nodes cannot see that the malicious nodes are voting on both branches, no slash messages will be broadcast for the duration of the partition. However, in the long term, the liveness recovery mechanism will ensure that the voting validators on both branches achieve a two-thirds supermajority. Although the validators who voted on both branches can be slashed in retrospect, the total amount that gets slashed is only $20\%$ of the deposit size at the start of the partition.

For a complete analysis, the minimum amount of stake required to cause a safety fault would need to be expressed as a function of the number of epochs since the network was partitioned, and the distribution of the stake across the different branches of the blockchain. We do note that the penalty mechanism, which increases in intensity as the ESF grows larger, does not have a major effect during short-term partitions. In the remainder of this section, we will discuss the effect of long-term network partitions without considering the additional effect of votes that violate slashing conditions, and leave analysis of the precise interplay between slashing and network partitions as future work.

We now turn to the scenario of a long-term network partition. In this case, Casper’s checkpointing mechanism provides an additional layer of security which improves over classic PoW protocols against long-range attacks. This is the statement of Theorem 8 which we prove for Casper’s current parametrisation, cf. Sections II-D and IV-A. To address this case in full generality, we need to take into account the way that the network is partitioned. For this, we distinguish between the validators and the block proposers who support the user’s chain, which we assume to be $\alpha$ -strong and $\mu$ -strong, respectively, with $\alpha,\mu\in[0,1]$ . For example, if $\alpha=0.6$ and $\mu=0.2$ then $60\%$ of the deposit-weighted validators are on the user’s side of the partition, but only $20\%$ of the mining power. Given this notation, we will refer to a chain with $\alpha$ fraction of validators and $\mu$ fraction of block proposers as an $\left(\alpha,\mu\right)$ -chain. In what follows, we define the canonical chain as the chain on which checkpoints are finalized first in terms of time (so not in terms of blocks or epochs). As mentioned before, we assume that this is a genuine network partition, i.e., that no validators vote on both branches of the chain. We then have the following.

Theorem 8.

Consider a $\left(\alpha,\mu\right)$ -chain with $\alpha>0.5$ and $\mu\in[0,1]$ . Then,

Case I.

If $2/3<\alpha\leq 1$ , the $\left(\alpha,\mu\right)$ -chain will finalise checkpoints after at most $3$ epochs. For a conflicting checkpoint to be finalised, the partition should last at least $\phi(2/3)=3733$ epochs. In this case, the probability that a checkpoint on the $\left(\alpha,\mu\right)$ -chain will be finalised first, is at least $P\left(B<\mu\right)$ with $B\sim\text{Beta}\left(3,3733\right)$ , which for $\mu\geq 0.004$ is larger than $0.9999$ .

Case II.

If $0.51<\alpha\leq 2/3$ and $0.5<\mu\leq 1$ , the $\left(\alpha,\mu\right)$ -chain will finalise checkpoints first with overwhelming probability, after at most $\phi(0.51)=2546$ epochs. For a conflicting checkpoint to be finalised, the partition should last at least $\phi(0.49)=2698$ epochs.

Proof.

Case I.

In the first case, i.e., if more than $2/3$ of validators are voting on the same chain, then they will be able to finalise checkpoints without any need for the liveness recovery mechanism. After the start of the partition, the conflicting chains will need to wait for less than one epoch before reaching the first potentially conflicting checkpoint. After another epoch, this checkpoint will be justified, and after another epoch it will be finalised, resulting in a total of 3 epochs. The amount of time that it takes for a corresponding number of blocks to be proposed depends on the speed of the block proposal mechanism, which in turn depends on the fraction $\mu$ of miners that are supporting the $\left(\alpha,\mu\right)$ -chain. For the likelihood of a conflicting checkpoint, in the worst-case scenario, all remaining $1-\mu$ miners will be coordinated on the same (competing) chain as the remaining $1-\alpha$ validators. Thus, using the finalization bounds of Figure 4, we have that the (at most) $1/3$ of validators on the competing chain will need (at least) $3733$ epochs to exceed the $2/3$ threshold (in terms of stake) on that chain and finalise checkpoints. Hence, that chain will be able to finalise first, if $\mu$ is so small that $3$ epochs of blocks on the $\left(\alpha,\mu\right)$ -chain will take more time to be created than $3733$ epochs of blocks on the $\left(1-\alpha,1-\mu\right)$ chain. Since individual block creation times on a chain are exponentially distributed with mean equal to the fraction of the total mining power that is active on that chain, the time of the $n-$ th block creation in a chain with $\mu$ mining power has the Erlang distribution with parameters $n$ and $1/\mu$ . This follows from the well-known fact that the sum of $n$ exponential distributions with the same parameter $1/\mu$ has the Gamma distribution with parameters $\left(n,\mu\right)$ , which is called the Erlang distribution when $n$ is an integer, cf. [36]. Thus, if we denote with $X$ the blocks on the $\left(\alpha,\mu\right)$ -chain and $Y$ the blocks on the $\left(1-\alpha,1-\mu\right)$ chain, the probability that $X$ reaches 3 epochs of blocks after $Y$ reaches $3733$ of blocks is equal to

[TABLE]

where ${B^{\prime}}$ has a Beta distribution with parameters $n_{1}=3733$ and $n_{2}=3$ . This result is based on the well-known fact from (textbook) probability that if $X\sim\text{Erlang}\left(n_{1}=3,\mu\right)$ and $Y\sim\text{Erlang}\left(n_{2}=3733,1-\mu\right)$ , then (i) $X/\mu\sim\text{Erlang}\left(n_{1},1\right)$ and $Y/\left(1-\mu\right)\sim\text{Erlang}\left(n_{2},1\right)$ and (ii) $Y/(X+Y)\sim\text{Beta}\left(n_{2},n_{1}\right)$ . Finally, (using properties of the Beta distribution), we can simplify the above equation to obtain that

[TABLE]

which is precisely the statement of Case I.

Case II.

In this case, validators voting in the $\left(\alpha,\mu\right)$ -chain will have to wait for at most $2546$ epochs, cf. Figure 4, for their stake, $\alpha$ , to account for $2/3$ of the total stake in that chain. Assuming that all other $1-\alpha$ validators are voting on a $\left(1-\alpha,1-\mu\right)$ , then they will need at least $2698$ epochs to resume finalisation, cf. Figure 4. With a similar argument as in Case I, the probability that finalisation in the $1-\mu$ chain will precede finalisation in the $\mu$ chain is less or equal to the probability that an Erlang random variable with parameters $n_{1}=2698,\mu_{1}=0.49$ will be less or equal than a random variable $n_{2}=2546,\mu_{2}=0.51$ , which is negligible (Python calculation: 0E-537). ∎

The bounds in all the cases treated in Theorem 8, refer to the worst case scenario – in terms of the likelihood that a safety fault will occur – in which the network is perfectly split into two competing chains. In the case that $\alpha>0.5$ and $\mu<0.5$ , then checkpoints on an $\left(1-\alpha,1-\mu\right)$ -chain may be finalised first. However, as explained in Section II-C, these cases refer to extreme network conditions and can be expected to rarely occur in practice. In case that they indeed occur, then either the network will permanently fork or one part will need to incur considerable economic losses to reunite. In such occasions, the conflicts are expected to be resolved by an off-chain governance mechanism.

Remark 9.

To visualize the magnitude of the probabilities in Case I of Theorem 8, we provide the plot of the cumulative function of the Beta $\left(3,3733\right)$ distibution in Figure 5. For $\mu=0.003$ (or 3/1000), the probability that the $\left(\alpha,\mu\right)$ -chain finalises first is almost equal to $1$ (precisely equal to $0.999$ ). For lower $\mu$ , the probability that this chain finalises first remains the largest. More precisely, this will be the case as long as

[TABLE]

which shows that if at least $\mu_{0}\approx 8.036\times 10^{-4}$ miners are working on the chain of the $\alpha\geq 2/3$ validators, then this chain is more likely than not to finalise checkpoints first. We note, that such scenarios are extreme and only of theoretical interest. In the case that only such a small fraction of miners is working on a chain, then the $\alpha>2/3$ validators will be able to notice that something is “wrong” due to the extremely slow block creation times. Hence, such a scenario is expected to be resolved with some form of off-chain communication. In any case, these cases remain only relevant (if at all) for the hybrid PoW-PoS structure.

Remark 10 (Intuition of Theorem 8.).

The argument in the proof of Theorem 8 is illustrated in Figure 6. After the initiation of the fork, validators who keep voting in the upper branch know that they will be able to start finalising first, since they form the majority at any point in time. Validators in the lower branch will also be able to finalise checkpoints, yet this will take considerably longer, see Figure 4. In this case, conflicting checkpoints will be finalised and clients aware of either of the checkpoints will not be willing to revert them (under Casper’s fork-choice rule). In other words, even if a double-finality event does take place, users are not forced to accept the claim that has more stake behind it; instead, users will be able to manually choose which fork to follow along, and are certainly able to simply choose “the one that came first”. A successful attack in Casper looks more like a hard-fork than a reversion, and the user community around an on-chain asset is quite free to simply apply common sense to determine which fork was not an attack and actually represents the result of the transactions that were originally agreed upon as finalized. In any case, as shown in Theorem 8, the time of a network partition that is required for the double-finalization event to occur, is a period of time which is of theoretical interest only. Finally, note that these bounds are conservative, i.e., they represent a worst case scenario, since they assume that all the adversarial stake is coordinated on the same chain (fork). In case, of $n>2$ conflicting forks, these times increase even more for any given percentage of benevolent validators that remain on the “canonical” chain.

III-D Incentive Compatibility

In this section we will consider the system’s incentive compatibility, i.e., whether the reward scheme incentivises all types of nodes in the system to follow the protocol. We discuss the two main types of nodes, i.e., block proposers and validators, separately.

Block proposers: Currently, the incentives for block proposers on the PoW chain are similar to those in Bitcoin, for which it has been shown in [30, 62, 38] to be a Nash equilibrium to follow the protocol for anyone who controls less than roughly $\frac{1}{3}$ of the mining power. The checkpointing mechanism has a small impact on the profitability of selfish mining because it imposes limits on how many blocks can be reverted and when. After all, the new fork-choice rules prefers blocks that have the highest justified checkpoint, meaning that it is impossible for a selfish miner to convince other nodes to drop blocks that go beyond the last justified checkpoint. However, the epoch length (50 blocks) is likely to be too large for the impact to be considerable.

Block proposers also influence whether and when some Casper FFG protocol messages appear on the PoW chain (for vote messages, the “when” is very important because delaying them beyond the end of the epoch renders them invalid). Hence, the block proposers should have an incentive to include these messages. As mentioned in EIP 1011 [61], a miner who includes a vote message receives a fee equal to $\frac{1}{8}$ of the reward given to the validator (see also lines 297-301 of the Casper contract [26]). Meanwhile, according to EIP 1011 [61], the contract calls do not consume gas, and therefore also do not contribute to the block’s gas limit. Hence, block proposers are incentivised to include votes unless the computational cost incurred by the miner outweighs the reward for processing the vote message, which depends on the validator’s deposit, and the protocol’s total deposit.

Validators: The validators are the new class of nodes introduced by Casper FFG. Their most important action is to vote, so we will consider the impact on their deposits of producing a valid vote or not. In the following, we will consider the case of a validator $\upnu$ who controls a deposit share $\alpha\in(0,\frac{2}{3})$ . (If $\alpha>\frac{2}{3}$ then the validators have complete control over the protocol anyway.) The combined stake fraction of $\upnu$ and the other validators who vote is given by $\mu$ (the $1-\mu$ who do not vote could be doing so because they have unwillingly gone offline). We consider a single epoch, so we write $\rho$ instead of $\rho_{i}$ . Both the voting and non-voting validators are hurt when $\upnu$ does not vote due to the dependence of the collective reward factor of (1) on the total fraction of voting validators. Furthermore, the impact depends on whether the epoch is justified, and whether $\upnu$ has an impact on that (if so, we call $\upnu$ a “swing voter”). The impact of $\upnu$ not voting on all types of nodes and in all scenarios is summarised in Table IV. It can be seen from the values in Table IV that if $\upnu$ does not vote, then all validators lose a bit, but $\upnu$ loses by far the most. For example, if $\rho=10^{-6}$ , $m=1$ and $\alpha=0.2$ then the losses for $\upnu$ are more than ten times as high as the losses for both the voting and non-voting validators. This by itself shows that $\upnu$ is incentivised to follow the protocol, if $\upnu$ is motivated by maximising her protocol rewards. Also, because all validators lose a bit, it does not pay in the short term for a validator to cause another validator to not vote, e.g., by censoring.

For a validator $\upnu$ whose utilities go beyond the simple maximisation of their deposits, we can go a step further by providing upper bounds on the damage that $\upnu$ can do relative to $\upnu$ ’s own losses in a single epoch. We consider two measures: the ratio between the absolute losses of the other validators to $\upnu$ ’s, which we call the Griefing Factor (GF), and the ratio between the relative losses, which we call the Proportional Loss Ratio (PLR) [14].

In general, it holds that if the attacker controls $\alpha$ of deposits, then $\text{GF}=\frac{1-\alpha}{\alpha}\text{PLR}$ [14]. Table V displays the PLRs, obtained by dividing the relevant entries in Table IV by each other and applying the equality above. All PLRs are bounded from above by $\frac{1}{2}$ , and are much lower for small $\alpha$ . More concretely, if $\rho\approx 0$ , then the PLRs are ${\frac{1}{2}\alpha}/{(1+\frac{1}{2}\alpha)}$ , 0, and ${\frac{1}{2}\mu}/{(1+\frac{1}{2}\mu)}$ for voters in the three scenarios of Table V respectively, so the PLR is always between [math] (at $\alpha\approx 0$ ) and $\frac{1}{3}$ (at $\alpha>\frac{1}{3}$ and $\mu=1$ ) whereas the GF is always between $1$ (at $\alpha\approx 0$ ) and $\frac{1}{3}$ (at $\alpha>\frac{1}{3}$ and $\mu=1$ ). This means that $\upnu$ will always incur a relative cost that is higher than the damage done to the others by abstaining.

IV Implementation

In this section, we discuss implementation specifics of the Casper contract, in particular the financial cost in terms of rewards to validators in Section IV-A, its impact on transaction throughput in Section IV-B, and potential issues and limitations in Section IV-C.

IV-A Impact of the Parameter Choice

Finding appropriate values for each of $\gamma$ , $\beta$ , and $p$ as discussed in Section II-D involves a tradeoff. In general, to find appropriate values for $\gamma$ , $\beta$ , and $p$ , there are several factors to consider.

Regarding $\gamma$ :

•

Setting the reward too high makes the protocol expensive to operate.

•

Setting the reward too low means that fewer people will be willing to deposit, which in turn implies that the protocol is more centralized and less secure [44].

•

Setting rewards too low also increases the possibility of discouragement attacks [14], where an attacker either performs a censorship attacks or finds a way to cause high latency (e.g., by splitting the network), causing validators to lose money; the threat of this may encourage validators to leave or discourage them from joining.

Regarding $\beta$ :

•

Setting the penalty factor too high implies improved liveness, i.e., faster recovery from situations in which more than $1/3$ stop voting properly.

•

Setting the penalties too high, however, also implies higher risks for validators and bigger losses even if they accidentally are not able to stay online.

Regarding $p$ :

•

Setting the deposit size dependence higher means that validators can make a larger profit by performing censorship or DoS attacks against other validators.

•

Setting the deposit size dependence too low means that the protocol does not automatically adjust the interest rate depending on how risky potential validators perceive depositing to be, as argued in [20].

•

Users are looking for not just low issuance and high security, but also stability of the level of issuance and security. Having rewards decrease as the total deposit size increases (i.e., setting $p$ high) accomplishes the former goal trivially, and the latter goal by “trying harder” to attract validators when the total deposit size is small. However, low values of $p$ mean that from the perspective of a single validator, the interest rate is stable (e.g., if you deposit when the interest rate is $5\%$ , you know that this will not drop dramatically even if a large sum is deposited by other validators).

Funding

Rewards are paid to validators by the protocol. As discussed in [61], the Casper contract was planned to receive an initial amount of 1.5M newly created ETH after a hard fork (coinciding with the changes to the fork-choice rule used by the clients). If 10M ETH were deposited, then this would keep the contract funded for roughly 2 years.121212Meanwhile, the mining reward was planned to be reduced substantially from 3ETH per block to 0.6ETH per block [61, 57]. This amount of ETH is intentionally kept limited to maintain an informal (i.e., dependent on further hard forks) deadline for the transition to full PoS.131313A similar decision was made for the PoW difficulty, which has a built-in “difficulty bomb” as a deadline for the transition to partial or full PoS, see also Cryptocompare.com. If the contract has insufficient funds, validators still earn interest (as their deposits are kept as contract variables), but are unable to withdraw their deposits.

IV-B Overhead of the Hybrid Casper FFG Contract

Based on the discussion of the previous section, it is now immediate that the calls to the Casper contract impact the throughput of the protocol because they use the same client bandwidth and processing power as regular transactions. To understand this extent of this impact, we will study the contract’s consumption of gas (which, as discussed in Section II-A, measures the computational load) relative to the total gas limit. The total block gas limit is variable and can be influenced by the miners, although since December 2017 it has been close to 8M gas (see Etherscan.io). The estimated gas costs of the six main types of function calls in the contract are displayed in Table VI. Although the exact gas consumption of function calls depends on various external factors, including the exact numerical values of the arguments, the functionality to produce estimates is built into the Vyper compiler.

Per epoch, there is ideally one initialize_epoch call, and one vote call per validator. The cost of the deposit, logout and withdraw functions is assumed to be negligible, in part because of the minimum time period between depositing and withdrawing. We assume the same for slash because of the high cost of violating a slashing condition. The load of the two other calls is unevenly distributed across the epoch: the initialize_epoch call will come early in the epoch, but most of the vote calls are expected to arrive in the later part of the epoch when the probability of voting for a ‘losing’ block in a temporary PoW chain fork is small enough. In the benchmark parametrisation, there are 50 blocks per epoch, and we assume that votes arrive in the final three quarters of the epoch, i.e., the last 37 blocks. The impact of the initialize_epoch call during the first 13 blocks is roughly equal to $742\textnormal{K}/(13\cdot 8\textnormal{M})\approx 0.7\%$ , which is small. However, the impact of the votes during the last 37 blocks can be considerable. With 100 validators, the expected gas cost per epoch is roughly equal to $100\cdot 532\textnormal{K}/(37\cdot 8\textnormal{M})\approx 18\%$ . This confirms similar observations by Ethereum researchers that, even under proper protocol updates, no more than 592 (or even 400) validators could be supported [59]. The implementation of Casper FFG as a smart contract is illustrated in Figure 7.

Several approaches can be taken to limit the number of participating validators. The intended approach by Ethereum was to impose a fixed minimum deposit size of 1500 ETH. Alternative approaches would be to not accept new deposits beyond a hard limit of $N$ validators, to only accept votes from the $N$ validators with the highest deposit size, or to dynamically adjust the minimum deposit size based on the number of validators. Accurate predictions of the impact of the minimum deposit on the number of validators require economic modelling that is outside the scope of this paper. As for other PoS-based blockchain platforms: in EOS, 21 delegates [8] chosen by the stakeholders control the consensus algorithm, whereas Cardano aims for 100 stake pools [39, 7].

Off-Chain Messages

Another approach to mitigate the network load is to move hybrid Casper FFG messages onto a separate chain. As a result, two interdependent blockchains operate simultaneously: the traditional PoW chain, and a side chain called the beacon chain.141414The beacon chain is named for its originally envisaged role in producing a random beacon [23, 25]. The core protocol messages (vote and slash) are then moved to the latter, and the evolution of the rewards is processed internally by clients. A contract on the main chain is still created to handle deposit, logout, and withdraw messages, and to process exchanges from ETH to/from the reward variables on the beacon chain. The initialize_epoch calls are no longer necessary as clients process the epoch transitions internally.

The advantages of this approach are the possibility of message processing optimisations (e.g., bit masks and signature aggregation [12, 28], or the parallel processing of vote messages which was found to be challenging in the contract set-up [48]), and facilitation of a transition to a sharded151515In a sharded blockchain, the network load is divided amongst several subchains that work in parallel. blockchain, by serving as the central chain connecting the various side chains. The disadvantage is that substantial modifications to the clients will be required. The block proposal/consensus mechanism on the beacon chain is still under active development – it is envisaged to use full PoS (with the same validator set as Casper FFG) in its final iteration. Given its long-term benefits, the dual-chain approach has been chosen as the way forward for Ethereum [25].

IV-C Other Issues & Limitations

We conclude with remarks of a general nature and issues that we detected from our study and the implementation of the Casper FFG contract. First, the “finder’s fee”, cf. Section II-D, for detecting a violator of slashing conditions may create conflicting incentives and competition between validators. Second, in the case that the network experiences a large partition or fork, cf. Figure 6, honest validators who have voted and finalised on the non-canonical chain will sustain heavy losses to return to the main chain. Third, to focus on validators’ mechanics, we ignored potential collusions between validators and PoW miners. This point is not relevant in a pure PoS implementation, as currently put forward, and would have shifted the present analysis away from Casper’s properties of interest. The way that new (entering) nodes will choose between conflicting checkpoints depends on the choice of bootstrapping nodes by the client, and is therefore a question of proper client implementation. Finally, despite increasing security, the checkpointing mechanism does not reduce confirmation times (2 epochs = 100 blocks). Instead, the full benefits of Casper in terms of block-confirmation times are expected to be realised in a pure PoS implementation of the Ethereum blockchain.

V Conclusions

In this paper, we analysed the Casper FFG contract that was evaluated on a dedicated Ethereum testnet. We described its core mechanism and showed that its incentives scheme ensures liveness whilst providing security against the finalisation of conflicting histories, i.e., checkpoints. As a finality protocol that can be overlaid on both PoW and PoS blockchains, hybrid Casper FFG can be of interest to a broad audience within the blockchain ecosystem. Our findings on liveness, safety, incentive compatibility, and implementation remain particularly relevant for Ethereum’s transition to a sharded design in which the Casper FFG philosophy is carried over.

Although the focus of this paper was on the incentives scheme implemented in the Casper contract, an interesting direction for future work would be to explore different schemes, in particular alternatives to equations (1), (2), and (3). All schemes will involve a trade-off: although heavy penalties for offline validators improve liveness and safety, they also negatively affect honest participants who suffer from unavoidable network or computer failures. Also, the impact of dynamic validator sets are an interesting research direction.

Acknowledgements

The authors would like to thank Pieter Hartel, Chih-Cheng Liang, Ivan Homoliak, and Vi for their helpful comments.

Bibliography67

The reference list from the paper itself. Each links out to its DOI / PubMed record.

1[1] I. Bentov, A. Gabizon, and A. Mizrahi. Cryptocurrencies without proof of work. In International Conference on Financial Cryptography and Data Security , pages 142–157. Springer, 2016.
2[2] I. Bentov, R. Pass, and E. Shi. Snow White: Provably secure proofs of stake. IACR Cryptology e Print Archive , 2016:919, 2016.
3[3] J. Bonneau. Hostile blockchain takeovers (short paper). In Proceedings of the 5th Workshop on Bitcoin and Blockchain Research , 2018.
4[4] J. Bonneau, E. Felten, S. Goldfeder, J. Kroll, and A. Narayanan. Why buy when you can rent ? Bribery attacks on Bitcoin consensus, 2015.
5[5] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten. So K: Research perspectives and challenges for Bitcoin and cryptocurrencies. In 2015 IEEE Symposium on Security and Privacy , pages 104–121, 2015.
6[6] J. Brown-Cohen, A. Narayanan, C.-A. Psomas, and S. M. Weinberg. Formal barriers to longest-chain proof-of-stake protocols. Ar Xiv e-prints , 2018.
7[7] L. Brünjes, A. Kiayias, E. Koutsoupias, and A. Stouka. Reward sharing schemes for stake pools. ar Xiv:1807.11218 , 2018.
8[8] S. Buchko. What is an EOS delegate? A basic explainer, 2018. Available [ online ]. [Accessed: 4-12-2018].

TL;DR

Contribution

Findings

Abstract

Peer Reviews

Videos

Abstract

Index Terms:

I Introduction

Outline

II The Hybrid Casper FFG Protocol

II-A The PoW Chain

Formal Framework

II-B Execution of Hybrid Casper FFG

Validators

Checkpoints

Votes in Casper

II-C Finalisation

Finality in Proof of Work

Finality in Casper FFG

Fork-Choice Rule

II-D Rewards and Penalties Mechanism

The Scheme

Slashing Conditions

III Analysis

III-A Execution Model

Node Types

Network Synchrony

Interactions Between Block Proposers and Validators

III-B Liveness

Definition 1** (Checkpoint liveness).**

III-B1 Delaying Finalisation: Liveness Recovery from Offline Users

Lemma 2**.**

Proof.

III-B2 Delaying Finalisation: Liveness in the Worst-Case Scenario

Theorem 3**.**

Proof.

III-B3 Checkpoint Liveness

Theorem 4**.**

Proof.

III-B4 Discussion of the Liveness Proof

III-C Safety

Definition 5** (Checkpoint safety).**

Theorem 6**.**

Proof.

Remark 7** (Theorem 6 during a network partition).**

Theorem 8**.**

Proof.

Remark 9**.**

Remark 10** (Intuition of Theorem 8.).**

III-D Incentive Compatibility

IV Implementation

IV-A Impact of the Parameter Choice

Funding

IV-B Overhead of the Hybrid Casper FFG Contract

Off-Chain Messages

IV-C Other Issues & Limitations

V Conclusions

Acknowledgements

Definition 1 (Checkpoint liveness).

Lemma 2.

Theorem 3.

Theorem 4.

Definition 5 (Checkpoint safety).

Theorem 6.

Remark 7 (Theorem 6 during a network partition).

Theorem 8.

Remark 9.

Remark 10 (Intuition of Theorem 8.).