The following is a summary of a talk I gave at RCon3. The purpose is to introduce newcomers to RChain (or even blockchain in general) to the ideas behind “consensus”, motivating it from the ground up. By the end of the talk, you should have a general sense of what consensus means for the RChain platform and some sense of how it works, as well as links to the source code itself for those interested in doing a deeper dive.
It covers RChain’s use of the CBC Casper framework and the proof of stake protocol built on Casper. The video includes images and explanations of a blockDAG and what equivocation looks like.
The talk is followed by a Q&A about race conditions, determinism, scaling, block rate, and checkpoints from which you can download the blockDAG state up to a certain point.
Following the video is a summary of the talk.
Why do we need consensus?
Security: everyone agrees
- An exchange took place (enabling future such exchanges)
- Money was not created (no double spend)
Decentralization: replicated in multiple places
- Decentralization is its own kind of security; no single point of failure
Concurrency: independent tasks running simultaneously
- Can interact with each other if necessary
- Need to agree on the outcomes of race conditions
- Rholang is a fundamentally concurrent programming language
Correct-by-construction (CBC) Casper
CBC Casper is a framework for creating consensus protocols. There is no ‘The CBC Casper.’ It’s a mathematical tooling that you can use for consensus protocols that all have certain properties.
Two key elements of the framework are
- “Protocol executions,” how to update your state based on new information
The ways in which the protocol can evolve, e.g. you can receive a block and you can add it to your chain
- “Estimator,” a function that takes the protocol state and gives you some facts about the consensus
e.g., fork choice – can pick which block is the current head of the chain
Why we need proof-of-stake (PoS)
- Gives a disciplined way to decide who is participating in the protocol
- Provides an incentive structure to ensure the protocol is followed
How PoS works
The core idea is self-interest (you are personally at risk).
Validators put up a bond, participate in consensus, and bad actors get slashed (lose their bond) for consensus-related offenses.
What are we coming to consensus on?
The RChain state is essentially one big Rholang term.
If you put together all of the contracts, including REV wallets and proof of stake and dApps, this is the RChain state, and it can be represented as a Rholang term.
We’re trying to come to consensus on what that state is.
BlockDAG
- Blocks with multiple parents form a directed acyclic graph (DAG)
- When we agree on the DAG, we agree on the current state and its history
- We have an ordered list of tips (the current blocks) of the DAG
- Can have a preferred tip but also other valid tips
- The tip with the highest score is the current block, and the other tips are like other threads that are also running that might possibly be joined together in the future
- Blocks with different parents can merge later if they don’t conflict
Casper Estimator on GitHub
RChain’s consensus protocol
Block format
You can pass messages between nodes, so you can look at what the definition of a block is and everything that it contains.
- Blocks have a header containing hashes of the parent blocks
- They have a body containing
-
- The new code that was added to the state
- A log tracing the execution of the new code
- The hash of the final Rholang term that represents the state
- The current PoS bonds
- They have justifications (information about what other validators have seen)
- Validators propose blocks to the network
Casper Message protobuf on GitHub
Fork-choice
This is the mechanism by which we know what part of the blockchain we’re on currently. Given a local view of a blockDAG, a function says what blocks are the current tips. In RChain, the function is inclusive greedy heaviest observed sub-tree (GHOST).
The “heaviest” part of the blockDAG is the tip with the most weight behind the parents of that block. The weights are determined by the amounts of the bonds of the validators who created and supported those blocks.
Equivocations
- Equivocations are impossible protocol state transitions, which imply that the offender is not following the protocol
- Equivocations are detectable based on justifications
- A justification is a current view of the DAG
Equivocation example
Look at a particular validator and look at their DAG. If a validator node makes a new block, it must know about its old block because it made it. So justification of a new block has to include the old block. Otherwise, something bad has happened.
We have a chain of justifications from the first block a validator creates through to their last. Any fork in the chain is an equivocation. The validator created two blocks that don’t know about each other but that’s impossible, because they were created by the same validator node. This node is not following the protocol.
This is equivalent to saying that there are two instances of the protocol running under the same identity. There’s no way to order the two blocks with respect to each other. It looks as if they appeared from different instances of the protocol.
Q&A
See Vlad’s Casper Presentation for more information.