Blockchain Research Newsletter #5: Incentives in Ethereum’s Hybrid Casper Protocol

By Mikerah and John Adler

In this edition of the Blockchain Research Newsletter, we will be covering Incentives in Ethereum’s Hybrid Casper Protocol by Vitalik Buterin et al. This paper provides a mathematical framework for analyzing the incentives of Casper FFG as originally planned in EIP1011. Moreover, it analyzes the liveness and safety properties of Casper FFG and shows that the hybrid Casper protocol provides better guarantees than pure PoW.

Motivation

Pure Proof of Work (PoW) has several properties that aren’t necessarily desirable for blockchain systems, namely probabilistic finality and possibility of block reversions. Probabilistic finality is the property that it is harder and harder to revert a block the deeper it is in the blockchain. It doesn’t guarantee that once your transaction is sent, then it can never be reverted. This is problematic especially for large transactions. As everything is public, a well-resourced adversary can see this transaction and try to revert it. This is why we want to be able to have deterministic finality in blockchain systems. Deterministic finality gives us a guarantee that once a block has been included in the blockchain, that it will not be reverted. This makes it such that large transactions, even though public, can be done without having to worry about a potential block reversion.

Overview

Casper FFG is a stake-based overlay network for PoW that provides deterministic finality to the base PoW chain.

Casper FFG Description

At its core, Casper FFG is a smart contract deployed onto a PoW chain with enough expressiveness like Ethereum. In order to become a validator, one needs to make a deposit to the smart contract. One can cease being a validator by requesting their deposit back from the smart contract but not before a particular exit period has elapsed. In practice, this exit period is around 120 days.

The validators’ primary task is to vote for checkpoints every epoch. An epoch is the number of blocks between 2 checkpoints. A checkpoint is essentially a snapshot of a block in which once it’s finalized, any blocks before that checkpoint cannot be reverted. A checkpoint is said to be justified if at least ⅔ of the validators, in terms of stake, vote for a checkpoint. A checkpoint is said to be finalized if it is justified and it comes before a checkpoint that has been justified. Two checkpoints are conflicting if they are at the same height and neither comes before the other.

In order to gain the property of economic finalization on the PoW chain, amendments to the PoW chain’s fork choice rule need to be made in order to take into account finalized checkpoints. In addition to taking into account a block’s difficulty, clients need to take into account whether a block is a finalized checkpoint. Clients need to periodically query the smart contract to check for these checkpoints and if there is a tie, consider the amount of accumulated work in a block. Clients only need to consider epochs in which the total stake deposited meets a specified threshold. In the case where there are no justified checkpoints after the genesis block, the fork choice rule simply reverts to the PoW’s chain original fork choice rule.

Incentive Analysis

In order to ensure that the validators in Casper FFG behave properly, i.e., finalize and justify checkpoints in according to the protocol description, validators are rewarded and penalized according to how they vote. As we will explain, Casper’s incentives are designed to be incentive compatible.

Each validator has a deposit `D_v`. If a validator votes properly in an epoch, i.e., they vote for non-conflicting blocks and those blocks get finalized, then their deposit `D_v` increases by a positive interest rate. This positive interest rate is dependent on the total deposited from all the validators and the total number of validators voting. If a validator doesn’t vote during an epoch, then they are penalized and their deposit decreases. The amount by which their deposit decreases is dependent on the total number of non-validators. These penalties for non-voting get worse if blocks don’t get finalized for long periods of time. We consider validators who submit incorrect votes as non-voters. As such, they get penalized as would a non-voter. A validator that submits conflicting votes gets their deposits entirely removed or partially penalized depending on how serious the violation was and in proportion to how the protocol is performing, i.e., how many blocks have been finalized so far in proportion to the number of validators.

How much a validator makes is dependent on 3 network parameters, base interest rate, total deposit dependence and base penalty in addition to the number of epochs since the last block has been finalized and whether the validator is voting or not. The math is presented in the paper, which we will not cover in the newsletter. At a high level, each validator deposit for each epoch, `D_{v,i}`, is calculated as a function of a validator’s individual reward factor, which is then used to calculate the collective reward factor. Then, based on the validator’s individual reward factor and the collective reward factor for an epoch, the validator’s deposit increases or decreases for the epoch.

For misbehaving validators, i.e., validators that trigger the slashing conditions:

• Voting for 2 blocks at the same height
• Voting for blocks that are within each others span, i.e., surround votes

They get there deposits entirely or partially slashed and the validator that finds these violations get a finder’s fee that is 4% of the offending validator’s deposit.

Liveness and Safety Analysis

For the purposes of analyzing the liveness and safety guarantees of hybrid Casper FFG, the usual definitions of liveness and safety have been adapted to fit hybrid Casper FFG, a threat model needs to be defined and fault types within this threat model need to be specified.

Recall, liveness is the guarantee that something good will eventually happen and safety is the guarantee that something bad will never happen. In the context of hybrid Casper FFG, liveness is the guarantee that a proportion of the nodes will finalize checkpoints in finite time and safety is the guarantee that a proportion of the nodes that consider a checkpoint finalized at time `t` will consider that same checkpoint finalized at some time `t’` such that `t’ > t`.

The threat model that is considered is the following:

Assume that an adversary controls 49% of the total stake for an infinite amount of time. Moreover, assume that the honest majority assumption holds. Collusion between miners and validators is not considered. Finally, the network is partially synchronous.

As finalization is dependent on the total amount of validators in terms of stake, liveness and safety are dependent on validator deposits and as such, total stake.

First, let’s consider the liveness of Casper. As defined above, if at least ⅔ of the total stake is controlled by correctly voting validators, then liveness is guaranteed as blocks are getting finalized as per the protocol specification. If less than ⅔ of the total stake is controlled by correctly voting validators, we need to be a bit careful. In this case, finalization doesn’t occur since the total stake is mostly controlled by non-voting validators. However, notice that with each epoch, the non-voting validators deposits decreases and the voting validators deposits increases. Thus, every epoch the total stake controlled by voting validators increases. Eventually, the total stake controlled by voting validators will reach and exceed ⅔ of the total stake. Thus, finalization has resumed and liveness is guaranteed.

Now, let’s consider the safety of Casper. We consider 2 cases: one in which the network is not partitioned and the other in which the network is partitioned. In the case in which the network is not partitioned, we need to worry about the nothing at stake problem. In a non-partitioned network, validators can view all the possible chains that are being finalized and decide to vote on all on them in order to increase their chances of increasing their deposits. Remember that in order for a block to be finalized, it has to be a child of a previously finalized block. So, different checkpoints on different chains can’t be finalized unless ⅓ of the total stake is controlled by incorrectly voting validators, i.e., slashing conditions have been violated. Now, let’s consider the case in which the network is partitioned. Now, we need to worry about long range attacks. Long range attacks are attacks in which an adversary tries to provide an alternative history of the chain with the same genesis block. Due to weak subjectivity, nodes can’t immediately distinguish between the canonical chain and alternate chain. Using reasoning similar to how we showed liveness, notice that the honest validators will always be able to finalize checkpoints on the canonical chain due to how much of the total stake they control. The fork choice rule defined previously ensures that validators will vote on a chain that i) will remain the same in the future, i.e., the canonical chain and ii) such that checkpoints won’t be overwritten.

Conclusion

We summarized Casper FFG, a stake-based finality gadget that adds deterministic finality to a PoW chain. You can read the full paper here. Although EIP1011 has been deprecated, Casper FFG has been modified to fit a pure PoS blockchain and there are plans to use its finality to potentially finalize the legacy PoW chain.

If you like what you have read, you can subscribe to the Blockchain Research Newsletter here.