The Inspector: An efficient finality test for CBC Casper Finality in CBC Casper is an emergent property of message-passing communication in the network. We explore how different degrees of finality can be tested by the Inspector. This essay will explore the question of finality in CBC Casper . CBC Casper is a protocol that allows validators to reach consensus on some value, for instance, the state of a blockchain. It is critical that consensus reached at some point cannot be reverted later: this property is called finality . Intuitively, finality says that a transaction all parties believe was executed cannot be reverted later in the future. We explore in this essay how finality is reached as a property of the messages passed by validators and how this property can be tuned to be more or less stringent. Although this excursion is self-contained, we also prepared a general introduction to consensus and finality for CBC Casper. We do not assume you know anything about blockchains, finality or CBC Casper. In fact, the remainder of the discussion will not be concerned with blockchains at all, although it is applicable there too. But as a primer for some, and a refresher for others, we prepared a five-minute introduction to CBC Casper, which can be expanded right below. Give it a try! We need in addition that validators acknowledge the agreement; otherwise, undelivered messages could tilt consensus another way. If you followed our essay on consensus and finality , you know that unfortunately, finality is not achieved when all validators agree on one consensus value.otherwise, undelivered messages could tilt consensus another way. Indeed, think of two friends, Alice and Bob, who know they must meet either at the cinema or at the park. Alice writes to Bob that she will be at the cinema, and Bob writes the same to Alice. They are in agreement and yet, Bob's phone has a very unstable network, with a long wait before sending or receiving messages. Not knowing where Bob is going, but knowing he definitely prefers to go to the park, Alice might instead decide to head there and write back to Bob that she is going to the park. This is a situation where although both agreed at some point, the agreement is not final. Contrast this with the case where both Alice and Bob receive their friend's message. This situation is much more stable as both expect the other at the cinema. It is even more stable if both write back that they received the initial message, etc. This idea of layers is exploited by the Inspector, a finality test for CBC Casper. The more layers of acknowledgement, the more final a decision. Detecting finality in large graphs We first introduce the simplest meaningful test for finality. We look for a pattern where validators all agree on a value and all acknowledge the agreement. In other words, the pattern we look for is a complete bipartite graph , as pictured here. But take a message transcript where 7 validators attempt to reach consensus on whether Blue or Red is the correct value. The color of a circle is the value estimated by the validator in its message.

Let's first discuss what we see here. Validators send messages, with older messages on the left and newer messages on the right. Each row contains the messages of one validator. This sample data is obtained by having validators speak once each in a predetermined sequence. When all validators have spoken, they start the sequence again, until we obtain all the messages presented here. A validator always observes its own last message.

There is a 15% probability that a validator observes each message sent since the last time it spoke.

If a validator observes a message m , it observes all messages referenced in m .

, it observes all messages referenced in . No one ever equivocates, so all validators have exactly 0 or 1 latest message. These assumptions model for instance a situation where all validators are honest but latency in the network prevents them from receiving some messages. What do validators say when they speak? First, they observe past messages according to the following principles:These assumptions model for instance a situation where all validators are honest but latency in the network prevents them from receiving some messages. After observing a set of messages, the sending validator must provide an estimate for the consensus value, based on the latest message of each validator. If, for instance, it has never received a message from validator v , then it ignores v . The sending validator tallies up the estimates contained in the latest messages it has received. If a strict majority of the latest messages estimate Blue, then the sending validator estimates Blue, and same for Red. If however, no strict majority exists for either color, the validator chooses between Blue and Red randomly. Hover above a message in the graphs to see the messages that justify its estimate! This tiny graph does not even begin to represent just how many validators and messages will be part of a blockchain consensus, but already finding such a pattern as in Image 1 is hard: the algorithmic time to find one is exponential in the number of messages . We need a better algorithm to do so. Levels of acknowledgement Fortunately, we have more structure: the graph can be partitioned by validator, assigning each message to its original sender. From there, we can find for each validator the messages after which they always estimate the consensus value. Let us call these messages level 0 and reveal them in the graph below.

When do validators acknowledge a final decision? We could check for validators who acknowledge level 0 messages from other validators. In particular, we could call level 1 a message for which a large number q of latest messages in its justification are level 0, where q is a quorum. This is beginning to look like a clique.

level 2 a message which acknowledges at least q level 1 messages in its justification. This looks like a multidimensional Minesweeper , but we keep going and calla message which acknowledges at leastlevel 1 messages in its justification.

We are looking for a committee—a set of validators—with the following property. Each member of the committee must have a level 1 message from the committee, meaning that its level 1 message must be justified by at least q level 0 messages from other members of the committee. Notice that validator 4 does not have a level 1 message, and thus cannot be part of the committee in any case. We ignore it and recompute the level of all messages.