Last week Yoichi released a blog post detailing the process of formally proving safety and liveness properties of my “minimal slashing conditions”. This is a key component of a Byzantine-fault-tolerant, safe-under-asynchrony and cryptoeconomically safe consensus algorithm that is at the core of my proof of stake roadmap. In this post I want to provide further details on what this algorithm is, what its significance is, and how it generally fits into proof of stake research.

A key goal of Casper is that of achieving “economic finality”, which we can semi-formally define as follows:

A block B1 is economically finalized, with cryptoeconomic security margin $X, if a client has proof that either (i) B1 is going to be part of the canonical chain forever, or (ii) those actors that caused B1 to get reverted are guaranteed to be economically penalized by an amount equal to at least $X.

Think X ~= $70 million. Basically, if a block is finalized, then that block is part of the chain, and it is very very expensive to cause that to change. Proof of work does not really have this; this is a unique feature of proof of stake¹. The intention is to make 51% attacks extremely expensive, so that even a majority of validators working together cannot roll back finalized blocks without undertaking an extremely large economic loss — a loss so large that a successful attack would likely on net increase the price of the underlying cryptocurrency as the market would more strongly react to the reduction in total coin supply than it would to the need for an emergency hard fork to correct the attack (see here for a deeper overview of the underlying philosophy).

Economic finality is accomplished in Casper by requiring validators to submit deposits in order to participate, and taking away their deposits if the protocol determines that they acted in some way that violates some set of rules (“slashing conditions”).

A slashing condition might look like this:

If a validator sends a signed message of the form ["PREPARE", epoch, HASH1, epoch_source1] and a signed message of the form ["PREPARE", epoch, HASH2, epoch_source2] where HASH1 != HASH2 or epoch_source1 != epoch_source2 , but the epoch value is the same in both messages, then that validator’s deposit is slashed (ie. deleted)

The protocol defines a set of slashing conditions, and honest validators follow a protocol that is guaranteed not to trigger any of the conditions (note: we sometimes say “violating” a slashing condition as a synonym for “triggering”; think of slashing conditions as being like laws that you are not supposed to break); never sending a PREPARE message in the same epoch twice is something that is not too difficult for an honest validator.

“PREPARE” and “COMMIT” are terms borrowed from traditional Byzantine fault tolerant consensus theory. For now, just think of them as being two different types of messages; in the later protocol that we will introduce you can think of consensus as requiring two rounds of agreement, where PREPARE represents the first round and COMMIT represents the second round.

There is also a finality condition, which describes when a client can determine that some particular hash is finalized. This is easier; we’ll just go ahead and state the sole finality condition in the current version of Casper right now.

A HASH is finalized if, for some particular epoch number, there exists a set of signed messages of the form ["COMMIT", epoch, HASH] and if you add up the deposited balances of the validators that created these signed messages then you get an amount that is more than 2/3 of the total deposited balances of the current active validator set.

As shorthand, we can say “the hash was committed in some particular epoch by 2/3 of validators”, or “the hash has 2/3 commits in some particular epoch”.

The slashing conditions need to satisfy two conditions:

Accountable safety: if two conflicting hashes get finalized, then it must be provably true that at least 1/3 of validators violated some slashing condition.² Plausible liveness: unless at least 1/3 of validators violated some slashing condition, there must exist a set of messages that 2/3 of validators can send which finalize some new hash without violating some slashing condition.

Accountable safety is what brings us this idea of “economic finality”: if two conflicting hashes get finalized (ie. a fork), then we have mathematical proof that a large set of validators must have violated some slashing condition, and we can submit evidence of this to the blockchain and penalize them³.

Plausible liveness basically means that “it should not be possible for the algorithm to get ‘stuck’ and not be able to finalize anything at all”.