Page Comparison

Reference

Milestones

Development team

Marketing team

Stakeholders

Release summary

Simple overview

This release of the node will demonstrate consensus messages over the RChain peer to peer network.  

Technical overview

Consensus will send message across the peer to peer network.  The block data structure will be presented on the console.

• Node system features
  • Node should install and run as a systemd daemon when deb/rpm packages are installed.
  • Log system messages to Syslog 
  • Node should support starting in persistent mode, with an option to set the directory where data is stored.
    • Default is /var/lib/rnode
  • GRPC API - to run a contract on the interpreter in (repl mode)
  • A GRPC API  to evaluate a rholang via the interpreter.  (eval mode)
  • An API to obtain a list of node id's, where these id's can be used to as an identifier to send messages to other nodes.
  • Present an interface where the user can run Rholang contracts stored in a file.
  • Key storage.
  • Improved REPL experience supported by jline. Adds coloring, history, and completion.
• Consensus message passing
  • Demonstrate a consensus protocol that sends messages across the network.
  • Pretty print the block structure. 
• Packaging /Release
  • Create a set of example contracts that are available to run on the node after installation.
  • Installation packages will register the rnode with systemd as a service.  Write a systemd service file.
  • Suite of Integration tests for RNode, integrated with CI.
    • Automated build and deploy of Docker node, and send tests to it.
• Create side effects on system using Rholang
  
  • Create ambient channels for STDOUT and STDERR
  • Support for system processes in the tuplespace
    • Support for Scala continuations in the tuplespace
  • Creation of STDOUT & STDERR channel for use by Rholang contracts
    • Create a contract that sends a message to STDOUT
    • Create a Rholang contract that sends a message to STDERR

What is this release able to demonstrate?

Capabilities listed below should be included in any demo of this release.

• GRPC Protobuf API : Lead: Pawel Szulc (Unlicensed)
  • We are able to demonstrate a protobuf API call to run the evaluator in repl and eval mode.

• Improved Communications : Lead: Pawel Szulc (Unlicensed)
  • We are able to demonstrate the persistent storage of keys.
    • We can report on the number of keys being stored.
    • Show two nodes handshake and exchange keys. Kill and revive on of the nodes. At revival the nodes are able to reestablish a connection based on the stored keys.
  • We are able to show node owners can receive a list of nodes in the network by calling a GRPC API

• STDOUT & STDERR channels Lead: Henry Till
  • Rholang contracts can send messages to the STDOUT (console) independent of the RNode CLI or the RNode API (Node command interface). The message that is received by the system contract that listens on the STDOUT channel should be printed to the console.  
  • Processes are able to use the STDERR channel to print errors if something goes wrong when an error is encountered.  For example, if the communications channel experienced an error, it would return the error to the STDERR channel.  The Rholang system contract would check the STDERR channel for error messages.  Demonstrate a communications error that is returned to the STDERR channel.

• Consensus protocol Lead: Michael Birch
  
  • Demonstrate the consensus protocol working. 
  • Demonstrate the different message types associate with the protocol being sent over the network.
  • Create a specification for rSpace to support the blockchain.

• Installation of rpm / deb packages
  
  • Example Rholang contracts are in a folder /examples
  • Run rNode in persistent mode, puts data in /var/lib/rnode, demonstrate resuming a continuation after shutdown
  • Demonstrate rNode running as a process in Systemd

What is special about this release?

As we work toward the launch of the RChain blockchain, this pre-release version of the node is the first node to run a consensus protocol.  This version of RNode also adds several system engineering features that make it conform to SRE best practices: installation packages now register the RNode with systemd as a service, and the addition of a GRPC API. The GRPC API was chosen over JSON because it provides better backward and forward compatibility.

This version of RNode now demonstrates persistence as the node can hold onto it's state, including data in the storage layer and information related to keys. 

How do the features in this release work?

• Consensus - This is the protocol that brings about trust in a trustless network.  This form of communication is required in every blockchain architecture.  This feature is not user facing, but essential in order to have a blockchain in subsequent releases.
• GRPC API - With this release, the rNode software becomes a background process, which means that a programmable interface is required.  The GRPC API provides this interface, allowing users to create a web interface or scripted interface to interact with rNode as they wish.
• STERR and STDOUT channels - For security reasons, it's important to limit the ability of dApps (User Contracts) to affect the node local system.  For this reason, Rholang has limited ability to create 'side-effects' on the system.  The creation of the STDERR and STDOUT channels provides this access for Rholang processes running on the node.  These channels enable Rholang to be used as a multi-purpose language, instead of only being a blockchain language.

Are we doing something differently? If so, why are we doing it this way? 

The structure of the Rholang language works with channels and message passing.  This means that the Rholang language cannot have create side effects on the system without having channels for system processes such as Stdout- for example.  This release creates an architecture that supports the Rholang language sending messages to Standard out.  dApp authors will need a mechanism to test their code locally on the system, and these system channels will enable contract authors to do this.  

Before these features were available, what were developers able to do with RChain?

In previous pre-release versions of RNode, developers could only collect local metrics and run Rholang contracts on a node.  Nodes would perform handshakes and connect to each other, but the nodes could not send messages containing specific data.  

After these features launch, what will developers be able (and not able) to do with RChain?

Developers will be able to interact with the Node API, observe the behavior of the consensus protocol and execute Rholang contracts that can print output to the console.  Nodes will also persist their keys (and identities).  The system will also have a new option to run in ‘persistence’ mode, where the tuplespace will be stored to disk, instead of just in memory.  This will allow for continuations to resume after a system restart.  Developers will not be able to write contracts that interact with the blockchain in any way as yet.   

Description of release packaging

Release packaging will include:

• Docker image and installer guide
• Debian package 
• RMP package
• .zip file
• tar.gz file

What will the demo include?

See section above 'What is this release able to demonstrate?" 

Where do developers go to learn more and get started?

At release, links to installation packages and relevant documentation is available at https://developer.rchain.coop.

Are there any known issues or bugs at the time of release?

Where will bugs be filed?

Developers can report bugs here.

Where do developers go for support? What is the SLA? Who is on point?

Developers can post questions to the RChain developer forum: https://forum.rchain.coop. This forum is monitored and developers can expect a response within 24 hours.

What license will this be released under?

The RChain software is licensed under Apache License, version 2.0

Rholang is licensed under the MIT License (MIT)

The Docker image is licensed under the GPL 2.0 License

JIRA issues in this release