In this episode, we speak with two of the leading software engineers working on the CBC Casper framework and its implementation in RChain, Michael Birch and Kent Shikama. In this conversation at RCon3, we discuss everything from blockDAGs to the GHOST fork-choice rule. Below, we give an overview of the topics covered.
CBC Casper Consensus Scheme
CBC Casper is a consensus protocol framework which RChain is implementing to achieve consensus on its Proof-of-Stake (PoS) blockchain platform. Casper is an asynchronous, byzantine fault tolerant family of consensus protocols which can be implemented in various ways and in various contexts depending on the parameters used. The parameters to be chosen are as follows:
- Consensus values (what we will come to consensus on)
- Logic (a language to reason about consensus values)
- Protocol evolution (rule for how information is updated)
- Estimator (what things are true about the current state)
- Safety oracle (rule for determining finality of a block in the DAG)
In the context of RChain, the consensus values correspond to the state of the RhoVM (or tuplespace), which is just a giant Rholang term. The logic corresponds to fork-choice tips in the blockDAG. Protocol evolution corresponds to message reception; we par Rholang terms into the current state to evolve it. The estimator corresponds to the GHOST fork-choices rule (discussed further below). Lastly, the safety oracle corresponds to the (weighted) clique oracle which selects the heaviest clique from the DAG.
Benefits of PoS Casper
There are several benefits of PoS Casper over other consensus protocols. The use of PoS Casper consensus saves electricity over Proof-of-Work (PoW) protocols by not doing several ultimately useless computations (in orphaned blocks). The protocol is byzantine fault tolerant, meaning that it is safe even in the presence of bad actor, breaking protocol. Casper, specifically, guarantees consensus safety without any liveness assumptions, which had not been achieved before.
BlockDAG & GHOST
DAG is short for directed acyclic graph. In a traditional blockchain, each block has one and only one parent. Blocks are arranged linearly in a chain, hence the name blockchain. In a blockDAG, blocks can have multiple parents. The advantage of this is that resources are not wasted on computations for blocks that will ultimately be orphaned. If the transactions in different child blocks are not conflicting (do not result in a double spend, for instance), no resources are wasted. This allows the blockDAG to achieve block-level concurrency and conserve precious resources.
RChain is implementing the GHOST (Greedy Heaviest Observed SubTree) fork-choice rule:
- Greedy: chooses locally optimal decision based only on currently available information
- Heaviest: most weight in terms of stake (bonding)
- Observed: you have seen it
- Subtree: subgraph of blocks in the DAG which is a tree
The GHOST rule dictates which block(s) a validator should build off, i.e. which blocks should be used as parents.
Safety & Liveness
There are different notions of safety in Casper; consensus and estimate. Consensus safety is a global property of the blockDAG. It means that all (honest) validators will eventually agree on a valid state that doesn’t conflict with any previous (valid) states. Estimate safety is a local property. It means that a validator’s knowledge of a previous state will never conflict with a future state.
Now, it’s one thing to have these notions of safety, but they are useful only if we can guarantee that there will always be a future state to come to consensus on. This is the role of liveness. Liveness means that the protocol state can always evolve to a future state, i.e. nodes that are up will produce a result.
Casper thankfully supports liveness and we want a coherence between estimate safety and consensus safety. Vlad Zamfir’s consensus safety theorem says exactly that; estimate safety (without too many byzantine faults) implies consensus safety.
Features to come
Several features are still being developed. As it stood at the time of RCon3, RChain’s Casper was a static platform where validators were not allowed to join/leave after genesis. The most notable features to come are bonding and unbonding. Bonding gives new validators the ability to join the network after genesis. Unbonding gives validators the ability to leave the network. These features will greatly increase the usability of the Casper system and allow it to be implemented in an actual blockchain setting where the validator set is in flux.
For more on consensus from RCon3, see Consensus on the RChain network
For more on CBC Casper, see Vlad Zamfir’s Casper presentation