node-0.5 release plan

Release summary

Simple overview

This release completes the core features needed for dApp developers writing smart contracts on RChain. In this version of RNode dApp developers can use unforgeable (private) names in Rholang contracts. This release does not include sharding, costing or validator slashing. 

Technical overview

The structure of the RChain blockchain is a Block DAG (Directed Acyclic Graph). It requires a specific set of features for the internal representation of the blockchain as blocks are processed and validated where the state of the machine will 'roll back' and 'snapshot' to apply the results of consensus (agreement on a block).   

This release introduces two features in RSpace which enable the Casper Consensus Protocol's creation of the Block DAG.  One feature is the ability to take a "checkpoint" or "snapshot" of the contents of RSpace, and to be able to "reset" or "roll back" to this checkpoint at any given time.  RSpace now records trace logs which contain a record of the actions performed in RSpace.  While Rholang itself uses a non-deterministic execution model, these trace logs enable the deterministic execution of Rholang code, which is a fundamental piece of the puzzle that enables RChain Nodes to deterministically execute the Rholang code contained in blocks.

The Rholang language & RChain platform also supports unforgeable names.  An unforgeable name is a core concept in the Object Capability Security Model.  An object is a process that listens on a name for method invocations. If a process is in possession of the name, operations can be performed on the object.  In an object capability language, it is impossible to get hold of an unforgeable name unless the process created it itself or the process received the name in a message.  Using the 'new' operator within a Rholang smart contract will generate an unforgeable name during the deployment process.  

The RChain blockchain has a unique event, inherent to the concurrency of the RChain platform.  A COMM event occurs when a listening process and a sending process synchronize, substituting the messages for variables in the body of the listening process, and execution continues. The RChain architecture derives from the Reflective Higher Order Calculus, enabling Rholang processes to reduce and execute independently of each other.   The execution of a Rholang contract can involve a single COMM event or several.  Each COMM event can execute independently of others within the tuplespace.  Concurrency doesn't just exist across smart contracts, it also exists within any given smart contract.  This concurrency and non-determinism of the platform and the Rholang language has implications on the blockchain.  Validators have to update their state as part of their work; in order for this to happen in the same way for all validators, RSpace has been enhanced to include execution traces, which are included in the block data structure.  When a validator receives a block, the execution trace is used as a 'map' to the proposing validator's state.  These execution traces also communicate any unforgeable names that are part of the block to the validator set.    

What is this release able to demonstrate?

RNode v0.5 demonstration scenario:

• Setup requirements
  • A mini net of 3-5 nodes all running the software.
  • A configuration file for all the nodes in the network that defines the validator set and their bonds. 
• Steps
  • Start up the nodes and generate a genesis block on each node.
  • Demonstrate the deployment of the wallet contract.
  • Demonstrate executing some transactions, followed by a block proposal from a validator which is then accepted by the other validators. 
  • Execute transactions in such a way as to demonstrate an orphaned block.
  • Review the metrics for the COMM events that were processed as a result of the demonstration. 
  • Demonstrate the API call that returns one of the blocks that was committed.
  • Demonstrate a review the contents of the genesis block to show how the token swap will take place.  

Includes Rholang code build process integrated into RChain build process (needed for the work to build the genesis block)

• The RChain State on the blockchain: Lead: Michael Birch (Unlicensed)
  • Demonstrate a proposed block being added to the chain.
  • Demonstrate a basic wallet app (contract) being deployed.
  • Demonstrate a fork, where a block is orphaned.
  • Demonstrate the safety oracle (a normalized fault tolerance value for each block will be part of the GRPC block API).
  • API to view the fault tolerance for a block (a node's view of the safety for any given block)
  • Demonstrate the genesis block.
    • Includes the Rev contract
    • Includes the Proof of Stake contract (alpha version)
    • Includes a few example addresses to demonstrate how the token swap would work.

• History, Rollback and Execution Traces: Lead Henry Till
  • Demonstrate Execution traces & replay
  • Demonstrate checkpoint
  • Demonstrate rollback