Reference

Milestones

Development team

Marketing team

Stakeholders

Epics for each Feature Set

• Performance and Stability: Lead: TBD
  • 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.

• Eliminate Test Net Faucet
  • With the launch of Main Net - no Faucet is supported. 

• Proof of Stake Casper Consensus: Lead: Michael Birch (Unlicensed)
  
  • 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.

• Rholang Language Interpretation: Lead: Kyle Butt
  • Support the Mercury Rholang language specification on the blockchain.
  • Provide a Rholang REPL interface
  • Evaluate Rholang contracts independently of a blockchain deployment.
  • Provide error messages for syntax errors with line numbers to aid in debugging contracts.

• Economically Secure Blockchain: Lead: Greg Meredith
  
  • 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.

Reliability & Monitoring

• Description RNode users expect reliable software and the ability to monitor operations
• Acceptance criteria
  • RNode supports industry best practices for SRE as described by Site Reliability Engineering: How Google Runs Production Systems
  • RNode exposes metrics so administrators can understand the health of the RNode
  • RNode supports upgrades with minimal impact to network performance
  • RNode provides a way to send logs for troubleshooting
  • RNode exposes its' version.
  • RNode exposes metrics about the following Node Functions: (Kelly Foster)
    • COMM Event (throughput) for Propose and Replay (Validation)
    • Deploy count
    • Blocks processed
    • Blocks proposed
    • 'Listen on a name' requests processed.

Client Experience 

• Description - RChain provides a piece of client software that supports developers deploying dApps to the platform.
• Acceptance criteria
  • Developers can deploy dApps to the platform and receive confirmation on the status of the deployment.
  • Developers are able to store and retrieve application data and transaction information related to their application from the blockchain.

Issuance of Rev

• At Genesis, RHOC holders are issued the correct amount of Rev token via a transparent and indpendently verifiable process. 
• Genesis validators sign the block, and only after a certain threshold is met, is the genesis block approved.  The threshold is subject to CoOperative governance.  

Peer to Peer Network: Lead Pawel Szulc (Unlicensed)

• Description The RChain system operates over a peer-to-peer network. RNode supports the creation and maintenance of this network.
• Reference Communications Module Specification
• Acceptance criteria
  • 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) 
  • 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

Platform support

• Description - The RNode software operates on a variety of platforms
• Reference Node Packaging, Distribution and Installation
• Acceptance criteria:
  • RNode installs and runs on
    • Linux
    • MacOS with installation of JRE and libsodium dependencies
    • Windows using Ubuntu/Centos VM in Hyper-V 

Installation 

• Description - The RNode software is available in a variety of common formats for installation.
• Reference Node Packaging, Distribution and Installation
• Acceptance criteria:
  • Debian packages (.deb)
  • Rpm packages (.rpm)
  • Tarballs (.tgz)
  • Docker images for Linux and Mac

Mercury release criteria

Metric for tracking success

What is special about this release?

Are we launching anything different than what’s out there? If so, what is it and how is it different? Use the ‘peel the onion’ approach, “there are three reasons why this feature is unique / 1 short sentence for each / 3-4 sentences about each vs. immediately going deep into the feature. 

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

If developers need to do something new/different to take advantage of this launch we should explain why we’re doing it differently to get them to buy into it. For example, why do we need a new language and why is it implemented in a specific way? 

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

Provide an overview of what developers were able to do without these new features. Please write this from the end user perspective. 

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

Provide an overview of what developers will be able to do after the new features launch. Please write this from the end user perspective. For example, after we launch the SDK dApps developers can run the RhoVM to create their first dApp on RChain. 

Description of release packaging

Where do developers go to learn more and get started?

CTA and link to the appropriate spot that marketing needs to point developers to. 

Where will bugs be filed?

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

What license will this be released under?