Incentives in Ethereum's Hybrid Casper Protocol

03/11/2019 ∙ by Vitalik Buterin, et al. ∙ 0

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.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

In 2008, the seminal Bitcoin paper by Satoshi Nakamoto [34] 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 [12] 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 [25, 26], 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 ballooning global energy consumption [45, 18] of PoW-based blockchains has made the concept increasingly controversial. One of the main alternatives to PoW is virtual mining or Proof-of-Stake (PoS) [3, 1, 37]. 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 [40, 39, 11]. To ensure a smooth transition with minimal impact to its users, Ethereum deployed and tested a hybrid version, Casper the Friendly Finality Gadget or Casper FFG, as a smart contract on a dedicated testnet [21, 35, 36]. Essentially, Casper FFG is a simplified version of a Byzantine fault tolerant protocol [14], 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 [31] and Algorand [15]), 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 [32, 4]: the nothing-at-stake problem through the slashing mechanism that penalises misbehaving violators [13], and long-range attacks through a modified fork-choice rule that prioritises (and never reverts) finalised checkpoints over PoW [43].

The high-level idea and fundamental properties of the hybrid Casper FFG have been outlined in [13]. The present paper is an extension of [13] that features a full description of the implemented incentives (reward–penalty) scheme and rigorous proofs of liveness and safety for the tested version. 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.

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 is -live, for any , i.e., online validators controlling any fraction of the stake will be eventually able to finalise checkpoints. Concerning safety, we first show that the property proved in [13] carries over to the updated incentives scheme, namely that two or more “conflicting” checkpoints can only exist if validators controlling at least of the stake misbehave conspicuously and hence, can be slashed (i.e., punished). In the case of a protracted network partition, the liveness guarantee has implications for safety, as it 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). Finally, we turn to the implementation of Casper FFG as a PoW chain contract and discuss the protocol’s impact on transaction throughput, the effect of different parametrisations and potential limitations.

To remain compatible with Ethereum’s evolution towards a sharded and hence more scalable design [40, 10, 22], the specifications of Casper FFG are constantly updated [8, 11]. However, 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 [7, 20, 11]. More broadly, since the protocol can be deployed as a smart contract on top of any chain-based blockchain, PoW or PoS [43], it can be of wider interest to the blockchain community beyond Ethereum.


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 and safety. 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 [17] may replace the EVM in the future. Two notable high-level languages that compile into the EVM are Solidity and Vyper222Hyperlinks: 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 contract.

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. The resulting 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 [47] 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 need a formal framework. Let denote the full set of nodes as identified by an integer denoting their index in the network, i.e., . At each time , each node is aware of a set of blocks which we denote by , i.e.,

The genesis block is the only block that all nodes are aware of at time , i.e., for all . Each block can be represented uniquely as an integer.333E.g., via the hash of its header, although this means that the range of possible blocks is “restricted to” . 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 and nodes such that . We assume that nodes cannot forget about blocks, i.e.,

Each block points to a previous block via a function , cf. [4], with

  • [leftmargin=*]

  • for any block ,

  • etc.

  • for all , where is the genesis block,

  • for any and , i.e., there are no cycles.444

    An 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


Based on this relationship, we define the chain of a block as the path from leading back to , i.e., . If is a block such that then is called an ancestor of and is called a child of . If , then is called a direct child of . The length of determines the block height of block , i.e., if . The height of the genesis block is , i.e., . The state of the blockchain in block is obtained by executing all transactions in starting from the genesis block , see also [27].

A fork occurs whenever two different blocks and exist such that . At any time , each miner needs to decide which block in to extend. This is done using a fork-choice rule, which in its simplest form is a function that maps a set to a single block . The block chosen is called the head. In PoW, the fork-choice rule is to select the block with the highest accumulated proof-of-work,555In the absence of serious attacks or network partitions [24, 44, 38], a naive measure of a chain’s PoW is the height of a block. and in case of ties to prefer the block seen first. Hybrid Casper FFG’s fork-choice rule is discussed in the next section.

Ii-B Execution of Hybrid Casper FFG


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 period666In the benchmark setting [43]

, this is 15000 epochs, i.e., around 120 days.

after depositing before being allowed to withdraw.


The central role of the validators is to vote for checkpoints[42]. A checkpoint is any block with block number , where and 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 (which is also a checkpoint) denotes the genesis block. We will assume throughout this paper [43]. 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,777Deposits also change between blocks but since withdrawals and deposits only occur at the end of epochs, it suffices to track the deposits at that point. we denote by the deposit of validator at the beginning of epoch , where denotes the set of active validators at epoch.888In practice, the validator set is dynamic and changes over time. For the present analysis it suffices to assume a fixed validator set. Hence, let denote the total stake (deposited value) at epoch .

Votes in Casper

In the Casper contract, voting is done by calling the vote function with the arguments , , where the entries are explained in Table I.

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 by the validator’s private key
TABLE I: Summary of vote function arguments.

We will say that a validator who generates a vote transaction to the Casper address votes correctly or casts a valid vote if includes the expected source and target epochs (checkpoints) returned to by a Casper contract call and a valid signature created by ’s private key [42, 43]. 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 is the checkpoint block with the correct height on the chain .999Hence, correctness depends on the chain that a node is voting on. We deal with this case in more detail in Section III.


A checkpoint t is justified if at least of validators – in terms of stake – publish a vote of the form for some checkpoint s, such that s is an ancestor of t and is itself justified. A checkpoint s is finalised if it is justified and a direct child101010Here we refer to the chain containing only checkpoints. t of s is also justified – i.e., if and are both justified, then s is finalised. We consider to be both justified and finalised, to serve as the base case for the recursive definition. Two finalised checkpoints are conflicting if neither is an ancestor of the other. When handling vote transactions the Casper contract only considers (includes) correct votes as defined above. Votes for the wrong targets and target epochs are considered invalid and ignored.

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 , the fork-choice rule essentially reverts to pure PoW [43].

Ii-C Rewards and Penalties Mechanism

Fig. 1: Illustration of the points in the blockchain where the different variables are updated. Blocks are mined by miners on the underlying PoW blockchain. Validators’ vote on checkpoints – blocks highlighted in green squares – typically late in an epoch, here . Correct votes concern the link between the previous two checkpoints. For instance, correct votes in epoch 3 have as source checkpoint and target checkpoint .

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 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.


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 penalties become gradually 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 (proportion of “correct” voters and whether epochs are being finalised or not).

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, and 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 .

Specifically, let ESF denote the Epochs Since Finalisation during epoch , defined as minus the height of the last finalised epoch. Since is finalised, ESF and ESF. For , ESF always equals 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 in epoch , the individual reward factor , is then defined as follows


if , and otherwise. Here, denote the base interest, total deposit dependence and base penalty factors, respectively.111111The name of the parameters are self-explanatory. See Section IV-A for more details on their values and choice. In the benchmark specification, , and . (The parameter choice will be discussed further in Section IV.) To define the collective reward factor, let

At the end of epoch , let denote the weighted fraction of correctly voting validators in epoch , defined as . The collective reward factor at the beginning of epoch , , is defined as


Validators’ deposits are then updated via the scheme


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, [13]: a validator who publishes two distinct votes

violates Casper’s slashing conditions, if

  1. [leftmargin=*]

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

  3. h(s1) h(s2) h(t2) h(t1): i.e.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 that do not include the offending vote calls, because the function arguments and signatures by themselves are sufficient evidence for misbehaviour. 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 Casper’s performance on the two integral goals of liveness and safety. To make the analysis self-contained, we start by providing the relevant definitions121212See also [28, 2, 30] and [46] for varying definitions of these concepts. We use the term -strong nodes (validators) for nodes who control a fraction of the protocol resources (stake). Also, let denote the random time until the finalisation of the next checkpoint by a set of -strong nodes. Randomness stems from block creation times in the underlying PoW chain.131313

Block creation times are typically assumed to be exponentially distributed.

Definition 1 (Liveness).

We say that a protocol is -live for some , if a group of protocol-following, -strong nodes will be able to extend the blockchain (finalise checkpoints) after a finite period of time with probability .

Definition 2 (Safety).

We say that a protocol is safe if the following holds: any protocol-following node who considers a checkpoint as final at some time point , will also consider as final at any time point .

Threat Model & Fault Types

To study liveness and safety, we assume an adversary that controls at most of Casper’s resources (stake) for an infinite period of time. We note that Casper also has a defensive mechanism against majority attacks, namely the minority fork [39]. Here, we will focus on the standard threat model that assumes an honest majority. We assume a partially synchronous network, i.e., messages that do not arrive within the timespan of the intended epoch, are ignored. As we discuss further in Section IV-C, we do not account for collusions between miners and validators. We will show that Casper’s reward mechanism disincentivises the following two core types of faults:


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.)

During any period of consecutive epochs in which more than 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, ESF which in turn affects both the individual (1) and the collective (2) reward factors, for . This is captured by Lemma 3. Without loss of generality, we assume that a fault involving ()-strong validators not following the protocol is initiated at epoch . All relevant notation is summarised in Table II.

Notation Description
length (in terms of blocks) of a Casper FFG epoch
current active validator set
deposit of validator at the beginning
total deposit at the beginning of epoch
weighted fraction of correct votes in epoch
individual reward factor in epoch
collective reward factor in epoch
base interest factor
base penalty factor
total deposit dependence factor (typically in )
stake fraction of honest validators
TABLE II: List of symbols.
Lemma 3.

Let denote the initial stake in epoch and let be and -strong validators, respectively, with . Assume that from epoch onwards, only -strong validator continues to vote correctly. Then, for the consecutive epochs that are not being finalised

  1. [label=()]

  2. the total deposits are decreasing in ,

  3. is given by ,

  4. the individual reward factors are increasing in .


By definition (2), as long as epochs are not being finalised, . Hence, by (3)

and similarly . The last inequality holds because for all by definition. Since for all , this implies , which shows (i). The expression in (ii) is obtained by repeated application of the previous recursive equalities, and , and the assumption . Finally, to prove (iii), observe that ESF, since the last finalised epoch is and hence, by (1)

Since is decreasing by (i) and , is increasing which concludes the proof. ∎

Discussion of Lemma 3

Intuitively, Lemma 3 says that as epochs are not getting finalised, Casper’s implemented incentives mechanism increases the deposits of validators who vote correctly – i.e., without violating any slashing conditions – and consistently and decreases the deposits of non-voting validators. As ESF increases, this process will continue until the voting validators will acount for more than of the total stake on the chain that they are voting on. The overall period that will be required depends on the initial proportion of their stake. From this point on, they will resume finalisation of checkpoints and hence, ESF will reset to 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 2.

Fig. 2: Casper’s liveness property, cf. Theorem 4: if some validators stop voting, the fraction of stake controlled by properly voting validators is adjusted over time to account for more than of the total stake. Finalisation resumes after some period of checkpoints that could not be finalised. In Figures 2 and 4, solid frames represent finalised epochs, dashed frames justified epochs, and dotted frames epochs that are neither justified nor finalised. The numbers inside the frames represent the stake fractions of the voting validators (in an exaggerated parameter setting).
Theorem 4.

The Casper contract is -live for any .


If correctly voting validators control more than of the stake, then finalisation and hence, liveness are immediate. To treat the remaining case, assume that voting validators control of the stake at epoch in which -strong validators stop voting. In this case, finalisation will resume after epoch , if or equivalently if , since, by the proof of Lemma 3, . Hence, by Lemma 3(ii)

which is equivalent to . This implies that finalisation will resume after epoch , where is the solution to the following minimisation problem

Hence, it remains to show that the above problem has a finite solution for every . Since by the proof of Lemma 3 (iii), the standard inequality , implies that it suffices to find a such that . Since is unbounded and is constant, such a exists for every . ∎

Given the benchmark parametrisation of the contract (to be discussed further in Section IV-A), the number of epochs needed to resume finalisation is illustrated in Figure 3 for different groups of -strong voting validators141414Lemma 3 and Theorem 4 assume that faulty validators stop voting completely. More elaborate voting/non-voting strategies can delay finalisation beyond the rate given here. However, liveness is retained, and since the rate depends on the parametrisation, we do not further analyse this technical issue.. We emphasise the following values which we will use in the study of Casper’s safety properties: for , , and , the number of epochs needed for -strong validators to resume finalisation is 3733, 2698, and 2546 respectively.

Fig. 3: Epoch of the first finalisation on a chain with non-voting validators controlling of the (initial) total stake.


We now turn to the study of Casper’s safety properties. 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 by the 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 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-B. 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:

  • [leftmargin=*]

  • 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 5, whose proof formalises the above intuition and is similar in nature to [8, Theorem 1].

Theorem 5.

Assuming that the network is not partitioned, two conficting checkpoints cannot be finalised unless at least of the validators violate a slashing condition.


Let and denote two conflicting finalised checkpoints with direct children and , respectively. Also, let denote the maximal – in terms of block height – common element in the chains of the two conflicting justified checkpoints (this element exists since ). Then, there exist such that and with , by definition of . For slashing condition I to not be violated, it must be that for all and . Since and , this implies (without loss of generality, if necessary after renaming to and to ) that . Hence, since and have consecutive heights ( is a direct child of ), there must be a with which creates a violation of slashing condition II. ∎

We now turn to the scenario of a 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. The intuitive reasoning for this improvement is that the majority chain – which is assumed to be controlled by honest nodes – will be able to finalise checkpoints ahead of any other chain with overwhelming probability. Hence, given Casper’s fork-choice rule, validators voting on this chain can be sure that this will also be the canonical chain in the future and that finalised checkpoints will not be overturned.

This is the statement of Theorem 6 which we prove for Casper’s current parametrisation, cf. Section IV-A. We focus on the most favourable case for the adversaries, i.e., competing chains, where all of the adversaries’ power is coordinated on the same chain.

Fig. 4: Casper’s safety property, cf. Theorem 6: in case of a fork, the branch with the majority of validators (here upper branch) will resume finalising checkpoints first. Nodes do not revert finalised checkpoints, so for an honest node to accept a minority attacker’s finalised block, it must have remained unaware of finalised blocks on the honest chain until the attacker was able to finalise, which for a -strong attacker would take epochs or over 29 hours. After finalisation resumes, the ESF drops to , which makes rapid changes in validators’ deposits once again impossible, cf. (1).
Theorem 6.

Assume that validators are honest and follow the protocol with the same input. Then,

  1. [leftmargin=*]

  2. if , honest validators will immediately finalise a checkpoint on the canonical chain. For a conflicting checkpoint to be finalised on a competing chain with of validators, the partition should last at least epochs.

  3. if , honest validators will finalise blocks first after at most epochs and this is the canonical chain with overwhelming probability. For a conflicting block to be finalised, the partition should last at least epochs.


Consider a fork (network partition) initiated at time and let denote the distribution of validators (in terms of resources) in fork (chain) at time . This information can be stored in a matrix ,

for , where denotes the initial stake of the validators voting in chain which we assume to be the honest group. Since, they vote only on chain , will be non-decreasing and will be decreasing. The opposite holds for the stakes for controlled by the malicious validators who are only voting on chain .


Case I: .

Checkpoints in chain are being finalised without interruption and hence, validators voting in know that they are in the canonical chain. By the reward scheme, their deposits in chain will shrink and at some point the deposits of (malicious) validators voting on will account for at least of the stake on . However, since at most of validators are voting on fork , the time that is required for this to happen is at least epochs under the current parametrisation, cf. Figure 3.

Case II: .

In this case, validators voting in will have to wait for at most epochs, cf. Figure 3, for their stake, , to account for of the total stake in . Validators voting in will need at least epochs to resume finalisation, cf. Figure 3. Since individual block creation times are exponentially distributed, the probability that finalisation in will precede finalisation in

is less or equal to the probability that an Erlang random variable with parameters

will be less or equal than a random variable , which is negligible (Python calculation: 0E-537). ∎

The argument in the proof of Theorem 6 is illustrated in Figure 4. 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 3. 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). However, this requires the network to be partitioned for a period of time which is of theoretical interest only.

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 , , and as discussed in Section II-C involves a tradeoff. A higher base interest means that the protocol becomes more expensive to operate, but also more decentralised as more people will be willing to deposit. A higher base penalty factor means improved liveness, i.e., faster recovery from a large number of validators going offline. However, higher penalties also mean bigger losses for validators during serious network partitions. A higher deposit size dependence means that validators can make a larger profit by performing censorship or DoS attacks against other validators. However, setting it too low means that the protocol does not automatically adjust the interest rate depending on how risky potential validators perceive depositing to be (an argument also made in [16]).

As discussed in [43], the benchmark parameters were set as , , and . Here, was chosen to strike a balance between (i.e., constant interest rate per validator) and (i.e., constant total amount of interest paid out by the protocol). In particular, given , and were derived by reverse-engineering the constants from two desired outcomes: assuming that 10M ETH has been deposited, i) validators earn 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 days.


Rewards are paid to validators by the protocol. As discussed in [43], 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.151515Meanwhile, the mining reward was planned to be reduced substantially from 3ETH per block to 0.6ETH per block [43, 39]. 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.161616A 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 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

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. In particular, 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

). The estimated gas costs of the six main types of function calls in the contract are displayed in Table 

III. 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.

Function Estimated gas cost
initialize_epoch 742 393
deposit 831 687
logout 131 308
withdraw 224 155
vote 532 031
slash 280 864
TABLE III: Gas costs for the six core functions of the Casper contract as estimated by 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 , 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 . This confirms similar observations by Ethereum researchers that, even under proper protocol updates, no more than 592 (or even 400) validators could be supported [41].

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 validators, to only accept votes from the 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 [6] chosen by the stakeholders control the consensus algorithm, whereas Cardano aims for 100 stake pools [29, 5].

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.171717The beacon chain is named for its originally envisaged role in producing a random beacon [19, 20]. 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 [9, 23], or the parallel processing of vote messages which was found to be challenging in the contract set-up [33]), and facilitation of a transition to a sharded181818In 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 [20].

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-C, 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 4, 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 and would have shifted the present analysis away from Casper’s properties of interest. Additionally, we have focussed on a static validator set in this paper and leave further analysis of dynamic validator sets to future work. Regarding new nodes needing to choose between conflicting checkpoints, we hope to investigate heuristics in future work. (In any case, this 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, and implementation remain particularly relevant for Ethereum’s transition to a sharded design in which the Casper FFG philosophy is being carried over.


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


  • [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] I. Bentov, R. Pass, and E. Shi. Snow White: Provably secure proofs of stake. IACR Cryptology ePrint Archive, 2016:919, 2016.
  • [3] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten. SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies. In 2015 IEEE Symposium on Security and Privacy, pages 104–121, 2015.
  • [4] J. Brown-Cohen, A. Narayanan, C.-A. Psomas, and S. M. Weinberg. Formal Barriers to Longest-Chain Proof-of-Stake Protocols. ArXiv e-prints, 2018.
  • [5] L. Brünjes, A. Kiayias, E. Koutsoupias, and A. Stouka. Reward sharing schemes for stake pools. arXiv:1807.11218, 2018.
  • [6] S. Buchko. What Is an EOS Delegate? A Basic Explainer, 2018. Available [online]. [Accessed: 4-12-2018].
  • [7] V. Buterin. Beacon chain casper FFG RPJ mini-spec, 2018. Available [online]. [Accessed: 14-9-2018].
  • [8] V. Buterin. Casper and Sharding chain v2.1, 2018. Available: [online]. [Accessed: 14-11-2018].
  • [9] V. Buterin. Casper FFG and light clients, 2018. Available [online]. [Accessed: 3-9-2018].
  • [10] V. Buterin. CBC-Casper in the face of the new PoS+Sharding plans on Ethereum [comment], 2018. Available [online]. [Accessed: 3-9-2018].
  • [11] V. Buterin. Ethereum 2.0 spec – Casper and sharding, 2018. Available [online]. [Accessed: 30-10-2018].
  • [12] V. Buterin et al. A next-generation smart contract and decentralized application platform, 2014.
  • [13] V. Buterin and V. Griffith. Casper the Friendly Finality Gadget. ArXiv e-prints, 2017.
  • [14] M. Castro, B. Liskov, et al. Practical Byzantine fault tolerance. In OSDI, volume 99, pages 173–186, 1999.
  • [15] J. Chen and S. Micali. Algorand. arXiv:1607.01341, 2016.
  • [16] J. Choi. Casper: The fixed income approach, 2017. Available [online]. [Accessed: 3-9-2018].
  • [17] CoinWire. eWASM Replaces the Heart of Ethereum, 2018. Available: [online]. [Accessed: 14-11-2018].
  • [18] Digiconomist. Bitcoin energy consumption index. Available [online]. [Accessed: 3-9-2018].
  • [19] J. Drake. Which BLS curve/DKG algorithm is going to be used for Casper? [comment], 2018. Available [online]. [Accessed: 3-9-2018].
  • [20] B. Edgington. State of Ethereum protocol #2: The beacon chain, 2018. Available [online]. [Accessed: 4-12-2018].
  • [21] Ethereum. The Casper contract ( Available [online]. [Accessed: 3-9-2018].
  • [22] Ethereum. Sharding roadmap. Available [online]. [Accessed: 14-9-2018].
  • [23] Ethereum. Ethereum core devs meeting 40 notes, 2018. Available [online]. [Accessed: 3-9-2018].
  • [24] I. Eyal and E. Sirer. Majority is not enough: Bitcoin mining is vulnerable. In N. Christin and R. Safavi-Naini, editors, Financial Cryptography and Data Security, pages 436–454, Berlin, Heidelberg, 2014. Springer Berlin Heidelberg.
  • [25] J. Garay, A. Kiayias, and N. Leonardos. The Bitcoin Backbone Protocol: Analysis and Applications. In E. Oswald and M. Fischlin, editors, Advances in Cryptology - EUROCRYPT 2015, pages 281–310. Springer Berlin Heidelberg, 2015.
  • [26] J. Garay, A. Kiayias, and N. Leonardos. The Bitcoin Backbone Protocol with Chains of Variable Difficulty. In CRYPTO, pages 291–323. Springer, 2017.
  • [27] J. A. Garay, A. Kiayias, N. Leonardos, and G. Panagiotakos. Bootstrapping the Blockchain, with Applications to Consensus and Fast PKI Setup. Cryptology ePrint Archive, Report 2016/991, 2016.
  • [28] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich. Algorand: Scaling Byzantine Agreements for Cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP ’17, pages 51–68, New York, NY, USA, 2017. ACM.
  • [29] A. Kiayias, E. Koutsoupias, M. Larangeira, L. Brünjes, D. Karakostas, and A. Stouka. Incentives and staking in Cardano, 2018. Available [online]. [Accessed: 4-12-2018].
  • [30] A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–388. Springer, 2017.
  • [31] J. Kwon. Tendermint: Consensus without mining, 2014.
  • [32] W. Li, S. Andreina, J.-M. Bohli, and G. Karame. Securing Proof-of-Stake Blockchain Protocols. In J. Garcia-Alfaro, G. Navarro-Arribas, H. Hartenstein, and J. Herrera-Joancomartí, editors, Data Privacy Management, Cryptocurrencies and Blockchain Technology, pages 297–315, Cham, 2017. Springer International Publishing.
  • [33] C.-C. Liang. Personal communication.
  • [34] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.
  • [35] W. Peaster. Alpha Casper FFG testnet released, Ethereum’s PoS excitement grows, 2017. Available [online]. [Accessed: 4-12-2018].
  • [36] W. Peaster. One step closer: Casper testnet arrives on Parity Ethereum client, 2018. Available [online]. [Accessed: 4-12-2018].
  • [37] QuantumMechanic. Proof of stake instead of proof of work. Available [online]. [Accessed: 28-11-2018].
  • [38] F. Ritz and A. Zugenmaier. The Impact of Uncle Rewards on Selfish Mining in Ethereum. In 2018 IEEE European Symposium on Security and Privacy Workshops (EuroS PW), pages 50–57, April 2018.
  • [39] D. Ryan. Analysis of Casper PoW Reward Reduction. Available [online]. [Accessed: 4-12-2018].
  • [40] D. Ryan. Casper Sharding. Available [online]. [Accessed: 3-9-2018].
  • [41] D. Ryan. Gas cost profiling, optimization, and management, 2018. Available [online]. [Accessed: 4-9-2018].
  • [42] D. Ryan. Validator Implementation Guide, 2018. Available [online]. [Accessed: 17-12-2018].
  • [43] D. Ryan and C.-C. Liang. Ethereum improvement proposal 1011. Available [online]. [Accessed: 3-9-2018].
  • [44] A. Sapirshtein, Y. Sompolinsky, and A. Zohar. Optimal selfish mining strategies in bitcoin. In J. Grossklags and B. Preneel, editors, Financial Cryptography and Data Security, pages 515–532, Berlin, Heidelberg, 2017. Springer Berlin Heidelberg.
  • [45] T. Swanson. How much electricity is consumed by Bitcoin, Bitcoin Cash, Ethereum, Litecoin, and Monero?, 2018. Available [online]. [Accessed: 19-12-2018].
  • [46] Team Rocket. Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family for Cryptocurrencies, 2018. Available [online]. [Accessed: 4-12-2018].
  • [47] G. Wood. Ethereum: A secure decentralized generalized transaction ledger, 2014.