Ethereum Research recently released a paper called "Introducing the "Minimal CBC Casper" Family of Consensus Protocols
". Ethereum scalability research is an important topic as the network experienced severe scalability problems on the production network in 2017
. These were due to fundamental design issues in Ethereum itself (as predicted in 2016 for example
A close examination of the CBC Casper paper reveals a major shortcoming that calls in to question whether the paper contributes to the material advancement of working consensus protocols and scalability efforts. Liveness and safety are inseparable:
Specifically, the paper attempts to treatand provide Byzantine safety without respect to liveness
. However, liveness and safety are inseparable properties of Byzantine fault-tolerant protocols for achieving consensus.
Because of this, we believe that the approach presented in this paper is fundamentally the wrong approach to start the design of consensus protocols. Correctness
is a guarantee that once a decision has been reached, it will remain decided. Liveness
is a guarantee that a protocol will do something useful — i.e., process transactions — even in the face of failures. Without the liveness guarantee, users cannot actually do useful things with the protocol, because they do not know when they can consider that transactions have been processed successfully. For example, in Bitcoin, users need to know when they can consider a transaction confirmed.
This paper attempts to prove correctness without considering liveness. This is a problem because proving correctness without liveness is not practically useful, and most of the hard problems show up precisely when you consider liveness
— treating 1 out of 2 doesn't get you 50% of the way to a full protocol; it leaves you with almost nothing.
Further, the failure to address liveness leads to other problems for achieving Byzantine fault tolerance:
a) CBC Casper deals with only a subset of Byzantine faults
. Any blockchain network needs to be Byzantine fault tolerant since it is comprised of mutually-distrustful nodes. Nodes can fail for arbitrary reasons, including malice on the nodes' parts. This paper only discusses one type of failure — the failure when nodes "equivocate" i.e., send self-conflicting messages. However, such failures are only a subset of faulty behavior: there are other failures that are harder to deal with that this paper does not address e.g., a malicious node that intentionally tries to prevent consensus (but does not equivocate).
b) CBC Casper does not specify concrete decision-making mechanisms
. Example protocols in the paper depend on an "estimator function" whose consequences in the protocol are not clear, and not considered in the proofs. While we suspect from their examples that the estimator functions are used to inform a decision-making mechanism, the paper does not discuss the consequences of this nor does it consider them in its correctness proofs. As a consequence, the safety proof is not informative — it does not make significant progress towards reasoning about useful protocols. Most of the important elements are left unproven.
c) CBC Casper does not consider other relevant, hard problems for achieving consensus in blockchains
. Examples include reconciling chain forks, selecting which forks are valid, how reorganizations are detected and handled, recovering from accidental forks, and so on. This omission is problematic because these are precisely the problems to which CBC Casper protocols will be implemented to address. The safety proof does not yield any insights into how to address these issues because these are fundamentally liveness properties, which are left out of the proofs.
The proofs in the paper are useful to the extent an empty set of properties is useful. An empty set of properties might be "safe" but makes no progress towards having a practical protocol.
The paper's definition of Byzantine fault tolerance as "BFT safety but without liveness and only for equivocation faults"
is unconventional and, in our view, fundamentally the wrong approach to start the design of consensus protocols.
Below is a more detailed technical review: