The RChain network will have the capacity to process 40,000 COMM events / second across the entire network.
A Validating node must be able to process an update without being slashed. The update process can include disconnecting from the network to apply the patch, and a restart of the node software.
The rate and speed by which a node processes transaction is bound by the resources of the physical machine, such as Memory, CPU, Disk and bandwidth. The node software should consume whatever resources are provided to it, and provide the best performance possible with those resources.
The node software releases physical resources that are not actively in use, particularly, RAM and CPU.
Retrieving data from the platform is at least as fast and reliable as sending transactions into the platform.
Node runs in any supported environment and performance varies based on the available CPU and RAM and uses available resources to achieve maximum throughput
Node stays up and stable barring hardware, network, or power failures.
Demonstrate a Proof of Stake consensus protocol that forms the basis of an economically secure, immutable blockchain system.
The consensus protocol will support the inclusion of Read Only nodes, which can receive blocks, but may not propose any blocks.
The protocol will provide a measure of transaction safety that is separate from the current best practice of confirmations, and this measure is made available to the application developer so that end users can view the level of transaction safety for themselves.
A user need only send a transaction 1 time to a validating node. The system shall send an acknowledgement of receipt of a transaction, and, provided enough monies have been sent to fund execution, the system shall ensure that the transaction will be processed.
Account for all computation on the blockchain, so that contract authors have to compensate node operators for storing and running the distributed application, and processing transactions against the application.
Execution costs on the platform correspond to execution intensity (computationally intensive actions must cost more).
Application developers are able to estimate execution costs in advance of deploying their contract to the blockchain.
Any request to execute code that is insufficiently funded is rolled back and no monies are refunded to the end user. The machine state of the nodes are not updated as a result of this failed execution, and the end user is notified of the failure along with a reason for the failure.
A given Rholang contract when executed multiple times will cost the same amount in terms of raw units of computation.
Validators are economically incentivized to process and validate transactions sent to the system.
There exists economic incentives for node operators to validate the RChain blockchain.
RNodes can send messages between one another as governed by the TcpTransportLayer
TcpTransportLayer when doing a round trip to remote peer when everything is fine - should send and receive the message when response takes to long - should fail with a timeout when there is no response body - should fail with a communication error when peer is not listening - should fail with peer unavailable error when there was a peer-side error - should fail with an internal communication error when sending a message - should deliver the message - should not wait for a response - should wait for message being delivered (pending) when brodacasting a message - should send the message to all peers when shutting down when doing a round trip - should not send the message when sending a message - should not send the message when broadcasting a message - should not send any messages
The RNode identity is separate from it's validator identity
To send a deployment to validators users need to know the validator's identification (the validator's public key)
RISK, DDOS of nodes
Alternatively, there is a pipeline for each shard that receives inbound deployments
Possibly similar what happens on Ethereum and/or Metamask
RNodes communicate via TLS
They can reliably and consistently send messages across the network
They can support the broadcasting of messages across the network
They can support messages of any size (message chunking and queueing)
Getting issue details...STATUS
RNode can bootstrap from any other node
RNodes can discover and connect to peersNodes remember their peers
RNodes remember their peers when running
RNodes remember their peers after restart
RNode can start in standalone mode
If no certificate is provided, system generates one
Description - The RNode software operates on a variety of platforms