This article will build on the previous one, with the explicit intent of presenting examples of specific protocol instances to illustrate the general framework. In terms of the paper, this post covers Section 4, while the previous dealt with Sections 2 and 3. Before diving in, let’s take a minute to remember what happened there. It’s also a good idea to read again Aditya’s post on the topic, as well as part one of this post and to keep the paper handy at your side while reading. Vlad’s latest Devcon talk can be helpful to understand the general philosophy behind CBC.

The good news however is that we have done a lot of hard work in the previous post, and this part will make some of the more difficult ideas very practical with examples.

Aditya’s post

Part one

The abstract CBC Casper (part one recap)

A group of validators attempts to reach consensus over some object. They can talk to other validators by sending messages. Each time a validator sends a message, it has to give an estimate, i.e. state the value it believes should be the consensus, and justify its message by referring to some previous protocol state. This justification is none other than a set of previous messages, acknowledging “I have seen these messages, and my new message is a continuation of that”. Meanwhile, nodes observe the messages and the protocol state transitions, in an asynchronous fashion: not everyone lives in the same state, but all states are made of messages referencing earlier states.

Now, if I am a validator, I can derail the protocol by doing the following: I send two different messages m and m’, none of which references the other. Here I am basically saying “I am continuing history with m. But m’ belongs to a different world, where history continues with m’ instead, and vice versa”. This is an equivocation fault. The protocol now runs two different versions (or threads, in the paper), none of which is compatible with the other.

The problem with equivocation is that if validators start saying everything and its opposite (tout et son contraire), a consensus failure may occur. Nodes decide on something if they hold it to be true from a certain state onwards. How do we guarantee that these decisions will not be inconsistent?

The answer lies with the safety guarantee. We give ourselves some weight t, and assume that among all states observed by our nodes, the total weight of validators that have equivocated there is less than t. Then, by the safety guarantee, we know that there is a common future for the nodes and thus the nodes cannot make contradictory decisions.