Page Comparison

Reference

Milestones

Development team

Marketing team

Stakeholders

Release summary

Simple overview

RNode v0.6 is the version that will support the launch of the RChain test net. This release introduces features that support the RChain genesis block creation and approval process, the RChain name registry, and client API's to retrieve data from the blockchain. This release also includes improvements to the communications module and bug fixes improving consensus functionality and RNode operator usability. 

Technical overview

RChain genesis block creation, approval and network launch

The RChain launch process, both for test net and main net, reflects the goals for the RChain Cooperative for this blockchain to be a community-sponsored platform. As such, this requires a transparent and validator-driven process to approve the genesis block and launch the network. The scripts to produce the raw genesis block consume a list of RHOC holder addresses and balances from a specified (still to be determined) Ethererum block height.  The genesis block will contain new RChain addresses and Rev balances that correspond to those RHOC balances and Ethereum addresses.  These RChain addresses are backward compatible with Ethereum, enabling RHOC holders to use existing primary keys to retrieve their newly issued REV.  This is how the launch will support issuance of REV based on RHOC balances.  

Following the creation of the genesis block by the bootstrap node, all validators have the opportunity to generate a genesis block independently from source code and compare it to the one provided by the bootstrap node at launch. To facilitate this, the bootstrap node will start up in a special mode, and will send the genesis block to a node that has a matching signature in the bonds file (a genesis validator). If the genesis block in the message matches the genesis block generated locally, the validating node will send a cryptographic signature and approval message back to the bootstrap node. The bootstrap node will tally up the signatures received, and once the required number of signatures is reached and a certain amount of time has passed, the network will launch. A gRPC challenge protocol has been implemented for this purpose. PR #1284 describes this process in code.

Initializing the Blockchain -- Protocol for generating the Genesis block further describes this process.

Updates to the communications module

RNode v0.6 includes improvements to the communications module to enhance functionality and stability.  The RChain network operates over a peer to peer network.  A peer to peer network requires a mechanism for nodes to discover peers in the network first, and then connecting to the node.  The prototype RChain communications layer implemented the Kademlia node discovery protocol over UDP.  With the introduction of TCP in the RChain Protocol, a refactor of the Kadelmia portion of the prototype implementation was necessary.   The Communications Module Specification further describes the RChain protocol and the refactoring work completed in this release.  The RChain protocol uses gRPC protobufs for lowel level communication pipeline, and the implementation defaults to a 4MB frame size.  As part of this release, we have increased the frame size to 100 MB, to support larger block sizes.  For the time being, Node 6 is limited to blocks 100 MB in size.  Prior to the launch of main net, this size limitation will be removed.

Configuration File

The RNode software offers multiple configuration flags for flexibility and ease of use.  This release introduces support for a TOML file to capture these configuration flags.  The file name is 'rnode.toml' and the file needs to be located in the rnode data directory.  RNode does not ship with a default TOML file yet.  Operators will have to create the file from scratch.  More information on the RNode options can be found here:  Command line options used during rnode startup will override options in the TOML file, giving operators the flexibility they need to quickly adjust configurations as needed. 

Fixes for stability and usability

Since the release of RNode v0.4, the RChain community has been actively involved in weekly testing of the software. They developed skills as RNode operators, helped test the software, found bugs and tested bug fixes. RNode v0.6 includes several of these fixes related to the consensus protocol and user-facing messaging. This dashboard shows bugs and their status.

Features planned to support test net

The launch of test net takes place on September 5th at RCon3. We will patch Node v0.6 with client APIs to retrieve data from the blockchain, a RChain name registry, and an integrated block store, which are requirements test net.  These patches will be in place by Aug. 30. Below is a more detailed description of these patches.

Client APIs to retrieve data from the blockchain 

These features support dApp developers and other users who want to run a distributed application on the RChain platform and obtain data from the blockchain. RNode v0.6 introduces transaction receipts giving dApp developers a way to listen for deploys with a name or set of names from their code API on the blockchain. Obtaining Data further describes this feature.

RChain name registry

The name registry is essential in allowing protected public access to unforgeable names. For test net, we will support universally unique identifier (UUID) registration and pubkey registration. The Name registry specification further describes this feature.

Integrated block store

Prior to this feature being implemented, finalized blocks in block chain were stored in memory, and users could see the blockchain by executing the 'show-blocks' or 'show-block <portion of block hash> ' gRPC calls. The blockchain cannot be stored in memory in the long run. This feature implements storage of the blockchain on disk.

What is this release able to demonstrate?

Genesis Launch Ceremony Michael Birch (Unlicensed)

• Demonstrate the genesis block signing ceremony with the launch of test net.

• Validators receive a message containing the genesis block to approve.
• A dashboard is available to track progress of the launch.

Consensus Updates: Michael Birch (Unlicensed)

• Performance improvements around block passing.
• Casper Error messaging

Metric for tracking success

Features described above can be demonstrated.

What is special about this release? 

The RChain launch process, both for test net and main net, reflects the goals for the RChain Cooperative for this blockchain to be a community-sponsored platform. As such the launch process is a transparent one where all validators have the opportunity to generate a genesis block and compare it to the one created by the bootstrap node. To facilitate this, the bootstrap node will start up in a special mode, and will send the genesis block to a node that has a matching signature in the bonds file (A Genesis validator) once it completes the communications handshake with the bootstrap node.  The node software will contain scripts to generate the genesis block locally.  The validating node will send an approval message back to the bootstrap node if the genesis block in the message matches the genesis block generated locally.  The bootstrap node will tally up the signatures received, and once the required number of signatures is reached and a certain amount of time has passed, the network will launch.

This release also provides the tools required to support the issuance of REV, the currency of the RChain blockchain, for RHOC, tokens sold by the RChain Cooperative as part of a private sale in 2017. The RChain community will demonstrate this process as part of the test net launch show RHOC holders how it will work and build confidence that they will successfully and accurately receive REV based on RHOC balances at the launch for the RChain main net.

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

The platform was limited by the default gRPC frame size of 4MB, and the system threw errors when a block exceeded 4 MB in size.  This would have presented a limitation on the number and size of deployments possible within a single block.  Developers would have had to break up their deployments into smaller blocks in order to work around this issue.  Developers would have also observed 'Untraced COMM event' errors when multiple nodes in a network were performing block proposals. 

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

At the release of RNode v0.6.1 some work is still in progress and will be released as patches to RNode v0.6 through August 30.   Developers will be able to propose larger blocks (up to 100 MB / block).  

Description of release packaging

Release packaging will include:

• Docker image (Supported on Linux only)
• Debian package 
• RPM package
• .zip file
• tar.gz file

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.

Where will bugs be filed?

Report a bug

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