View Source

As a Node operator I need to be able to start my node, and know that the node started up properly.
- Requires that the startup process ensures that all components are instantiated correctly and have the necessary resources to function. System will display an error if it does not have the necessary components to start.
The RChain node will run as a process in systemd. The installation process registers the RChain node as a daemon in systemd.
A Node has to have a public / private key that represents the node's identity.
If a public key is not present on the node in the directory where it expects it, one is generated at startup.
A validator key is required at startup, for certificate signing.
Provide a configuration file option which will hold all the server configuration options in TOML format.

As a DApp Developer, I need the ability to start the node in standalone mode, so that I can set up a mini net, to test my smart contract locally without incurring any costs.
As a DApp Developer, I need the ability to connect the node to the network of my choosing, so that I can test my smart contract against a blockchain.

As a Node operator I want metrics on my node's performance.
RChain has to demonstrate measurement of COMM events over the network.
- Demonstrate Prometheus charts for each of these metrics.
  - COMM Events
  - CPU % utilization for the rNode process
  - RAM (in MB)
    - amount of memory being Utilized by rNode.
    - amount being consumed by rSpace
  - Disk consumption (in MB)
    - For blockchain storage
    - by rSpace (tuplespace storage)
  - Network core metrics at the core level
    - Messages by message type (include the message type in the metric)
    - Response time for network messages - raw numbers only
  - JVM performance
  - Garbage collection
  - Size of memory pools
  - Consumption of memory pools
As a Node operator I want all the logs to land in a place where I am used to finding system logs (follow best practice - use syslogs & apachelog4j)

The RChain system has to operate over a peer to peer network.
Each node should have a limited number of peers. This means that all nodes must not connect to all other nodes necessarily, unless the network size is small.
- An arbitrary limit of 50 peers was implemented by Chris Kirkwood. ToDo: Validate if this is the right number. Need to determine how rapidly slashing messages need to be propagated through the network.
The IP address of any given node is not material to the network.
Nodes can come and go from the network randomly, and this should not matter to the robustness and functioning of the network.
The Communications subsystem should allow for a generic message packet, where the calling process can define the message data structure.
The system should implement an industry standard protocol, that is generally accepted for its security, speed and reliability.
The communications subsystem has to support UPnP as an option.

There have to be multiple bootstrap nodes that will provide the initial configuration for the network, so that there is geographical redundancy and speed around on boarding nodes on to the network.
The bootstrap nodes should have a well known DNS identity
A node can boostrap from any other node, given the node identity, either DNS or node id.
The node software will accept a DNS name such as testnet.rchain.coop as the bootstrap location.
There is no economic incentive for being a bootstrap node.
The DNS of bootstrap nodes can be published on the rchain.coop website. This way the addresses of the nodes need not be hard coded into the package.

A node must have a unique identity, which is a cryptographic signature, comprising of public and private keys.
Node communications must be encrypted for security.
When 2 nodes connect for the first time, the nodes must exchange public keys and a shared secret.
If the node does not have a certificate (public key & identity) then the system must generate one upon startup. The Communications software should store the certificate in the data directory where application data is stored. If a certificate is not found in the designated location, then a certificate should be generated by the system.
A node knows where a message came from by virtue of the node's identity (public key). No other identification is required.
A node can have only a single identity.
In order for a node to be a validator, it must have a certificate that is signed with its validator key.
In order to prevent MITM attacks, the communications subsystem checks the validator key against the list of bonded validators in the Casper PoS contract.

Create an economic incentive for validators to join the network and participate in the protocol.
Create an economic incentive to finalize user transactions.
Create an economic cost to validators engaging in bad behavior.
- This behavior is identifiable by other validators in the network.
Validators can join and leave the network at will without damaging the network.
The validators can be anonymous with the exception of their public key.
Account for connectivity issues, validators will not receive 100% of messages or transactions.
The protocol is resistant to the following attacks:
- Army of ants attack
- Byzantine Generals problem
- Whales (Centralization, where the network is controlled by a few actors)

Not waste electricity (Proof of Stake protocol)
Be significantly faster than PoW
Run on simpler hardware (personal computers) given fast, reliable network connectivity (depends on software footprint of the node itself)
Store blocks on the node
Provide a mechanism for the end user to view the block data