Testnet specification

Owned by Medha Parlikar (Unlicensed)
Last updated: Jun 13, 2018 by Kelly Foster
3 min read

Purpose of this Document

To lay out the requirements for the initial RChain test net.

Goals

The test net is very much akin to a beta system, where users can interact with features before they hit production.  

  • To demonstrate performance of the system to the community.
  • Create an environment where dApp developers can begin testing their applications.

Machine Requirements

Number of nodes

  • The initial test net should comprise of approximately 12 nodes.  This is an arbitrary number.
  • The test net needs to have at least 1 bootstrap node in each geographical region to support the network.

System footprint

  • Physical Ubuntu Linux Nodes  - 4
  • Physical Centos Linux Nodes - 4
  • Docker Nodes - 4

Physical machine requirements

  • 4 GB RAM
  • 2 Cores
  • Physical storage - default is fine - 50 GB Henry Till I don't think we need much - please confirm.

Networking requirements

  • Nodes should exist behind a router that can be configured to blacklist inbound IP address to shield against DOS attacks.
  • Bootstrap nodes have to have a static IP address.

Monitoring & DataCenter

The node software will have the necessary metrics to support monitoring of the node health.  In addition to remote monitoring, there needs to be monitoring of the physical system.  

  • Monitoring will send alerts in the event of an issue.
  • There is a team of NOC engineers monitoring the bootstrap nodes.
  • The bootstrap nodes have an uptime SLA of 99%, so that nodes can join the test net.
  • Security of the physical system - Rack location is secured via badge access or equivalent.
  • Personnel are available to address any hardware issues on the systems.

Network Topology

Nodes should be deployed as following:

  • United States  - Utah - 12 Nodes -(1 of which is a bootstrap)

Deployment of Software Updates

The RChain software is available in Debian, rpm packages and Docker images.  These nodes must be configured using these packages and images.  The packages have a built in update mechanism.  Updates on each node will take place in the following fashion:

Debian:

apt-get update


RPM:

rpm -U


Docker

docker pull rchain/rnode


Timing of Updates:

The test net will be updated after every release.  Releases generally take place on Thursdays.  Updates to the test net will take place on Monday mornings.  The reason for this, is to ensure that the development team is available to support any possible issues that users may encounter after the update is deployed.

Updates would need to be co-ordinated with the validator set, including the deployment of the update on all the nodes, and then deployment of the genesis block.  This will need to become part of the release deployment process. Kelly Foster - Note that we will Release on Thursday, then co-ordinate with Validators for a test net push on Monday.  If data needs to be wiped, we will need to re-deploy the genesis block.  If there is a network wipe, this is an opportunity for new validators to join the validator set if desired.

Data and State on the Test net:

The RChain platform is still very much under development.  There are no guarantees on data stored on the test net.  An update may require that the history on the network be wiped.  If the network needs to be wiped, this will occur as part of the update.  In this event, contract authors would need to re-deploy their contracts, and restart any tests that were in flight.  

Addressing issues & Support:

dApp developers that encounter an issue or unexpected behavior while working with the test net should file a bug in Jira.  ToDo: Create a component in Core for test net related issues and triage workflow.