node-0.7 release plan
Reference
Document status | COMPLETE |
---|---|
Release status | RELEASED |
Related pages |
Milestones
Start date | |
---|---|
Sprint #16 | |
Sprint #17 | |
Demo | |
Release | |
Test Net |
Development team
Program manager | Project manager | Developer | Developer | Developer | Developer | SRE | Page owner |
---|---|---|---|---|---|---|---|
Mateusz Gorski (Unlicensed) | Michael Birch (Unlicensed) | Former user (Deleted) | Pawel Szulc (Unlicensed) |
Marketing team
Marketing lead | Content owner |
---|---|
Kelly Foster |
Stakeholders
Name | Role | Reviewed? |
---|---|---|
President, RChain Coop | ||
CEO, Pyrofex |
Release summary
Simple overview
RNode 0.7 introduces the name registry, validator bonding and cost accounting. Performance enhancements include a new threading model, fine grained locking in the tuplespace and in memory DAG storage.
Validator Bonding using a wallets file or a faucet, Name registry supporting the registration of names and public keys. The deployment of Rholang contracts now requires phlogiston to be passed in, along with a wallet address, phlogiston price. Evaluation of Rholang contracts now returns the execution cost and the number of reduction steps. Node's threading model has improved, and as a result, so has the performance of read requests from the chain. Fine grained locking has also been implemented. In Memory DAG storage, which improved the performance of show blocks. Show blocks now prints out the tuplespace contents
Technical overview
Validator Bonding
The RChain platform has a pure proof of stake consensus system (PoS). To secure the network, validators must provide a bond, an amount of tokens, which is 'locked' into the PoS contract on the chain. We call this process validator bonding. During the test net phase there is no way to acquire tokens for the network. So to support validator bonding, this version of RNode offers a faucet to dispense the bond amount. To start the validator bonding process a RNode operator joins the network as an unbounded validating node. In this state it is in read-only mode and can obtain the state of the network from other nodes and deploy contracts to existing validator nodes. Next RNode operators invoke the 'GenerateBondingDeploys' client api. They provide a public/private key pair and bond amount through this api to generate the Rholang files required to create the bonding request. RNode operators then make the bond request by deploying the Rholang files to an already bonded validator by specifying the --grpc-host option along with the bonded validators' IP address. The bonded validator proposes blocks containing the Rholang files. This updates the PoS contract to include the new validator's identity and bond amount. The network then recognizes the new validator as bonded and supports the new validator proposing blocks.
Name Registry
The RChain blockchain runs smart contracts authored in Rholang. Rholang implements the object capabilities security model. To do this properly, the system supports the creation of deterministic unforgeable names. The name registry enables contract authors to register a name, such that the unforgeable name, that can be looked up. Contract authors can register names by using a public key or a UUID. Contract authors that want to update their contracts on the chain should use a public key for registering the contract. This mechanism will enable the author to update the contract 2 64 times. Contract authors that prefer a fixed reference to names in their contracts should use the UUID mechanism, as these cannot be modified. To see examples of how the name registry can be implemented in smart contracts, go to the RChain Github (or developer.rchain.coop) and explore the Rholang examples.
Cost Accounting
As with all public blockchain platforms, there is an execution cost for performing transactions on the RChain platform. Miners, on the Bitcoin and Ethereum networks, and validators on the RChain platform receive transaction fees as payment for processing the transaction. These fees incentivize validators to provision hardware and stake the network.
Charging and distributing transaction fees requires a process for cost accounting within the platform. This version of RNode introduces cost accounting. Cost accounting includes evaluation of a Rholang file to determine an execution costs in Phlogiston, the base unit of cost in the RChain economic system. When users deploy a contract they specify both an amount of Phlogiston for the transaction, the 'palo-limit', and the exchange rate for Phlogiston b based on REV, the 'phlo-price'. Because no wallets exist yet on the platform, a wallet address need not be specified to fund contract deployment. This feature will be available in a future release.
Performance Enhancements
RChain has an ambitious goal of supporting Visa-level transactions on a public compute infrastructure. The team continues to investigate and implement performance improvements working toward a goal of 40,000 COMM events/second over all shards. As part of this release, the system now uses fine grained locking in the tuplespace, a new threading model, and an in memory DAG store.
Production Engineering Enhancements
RNode operators need tools to manage node instances. RNode 0.7 supports obtaining the GitHash version of RNode via a http request. MacOSX users can also use brew to install RNode on their system. The instructions for installing via Brew are available on Github.
Name Registry & Rholang Features: Kyle Butt
- Demonstrate the registration of a name to a public key hash or random identifier.
- Demonstrate how to create a public name, use the public name and delete a public name.
Economics & Incentives: Mateusz Gorski (Unlicensed)
- Demonstrate the cost to execute a contract. Goes into the block.
- Demonstrate execution halting if phlogiston runs out. Via a unit test.
- Consensus Updates: Lead: Michael Birch (Unlicensed)
- Demonstrate bond minimum and maximums in the genesis block
- Validator bonding:
- Demonstrate a new validator bonding through the faucet.
- Demonstrate minimum and maximum bond amounts.
- Node joins as a read-only node, catches up on state & then bonds.
- Data Retrieval: Lead Former user (Deleted)
- Listening on a name supports starting and ending block numbers.
- Node Updates: Lead: Sebastian Bach
- Improve threading model in the Node
- Performance Upgrades: Łukasz Gołębiewski (Unlicensed)
- The team will spend time focusing on identifying opportunities to improve performance.
- Production Engineering & Installation: Lead
- Test Java 10 with the Node.
- Monitoring of bootstrap nodes
- Support Brew installation for MacOS
Test Plan
Feature | Test Method | Executed by | Result |
---|---|---|---|
Performance Tests
| Internal Test on stress-docker | Tom Vasile, Medha Parlikar (Unlicensed) | |
Validator Bonding
| Engineering internal test Node Testing Tuesday | ||
Name Registry
| Rholang examples | Chris Williams | Pass: https://github.com/rchain/rchain/pull/1668 |
Cost Accounting
| Node Testing Tuesday | Pass | |
Threading
| Node Testing Tuesday RSong | Pass: Ran node without thread pool option. No OOM memory errors & performance was good. 1 user reported being unable to validate Genesis block, who had 2 GB RAM on the system. Pass: Improvement in song retrieval - from ~ 30-57 seconds to 8-11 seconds | |
Performance Updates
| Node Testing Tuesday | Pass | |
| Node Testing Tuesday | Of the 35 Nodes in the network, only ~ 2 nodes reported missing blocks. | |
| Node Testing Tuesday | Pass | |
| GitHub:CodeCov | ||
| Internal Test | Failed on MacOSX Mojave for Medha. Pass for Kelly Foster on MacOSX Sierra. |
Metric for tracking success
Performance of dupe5
What is special about this release?
RNode 0.7 supports Validator bonding, to support a pure Proof of Stake consensus system. The public name registry enables contract authors to create a reference to an unforgeable name and update the reference if so desired. Contract authors can create a package manager that uses functions from the registry to update and version their dApps on the blockchain.
Are we doing something differently? If so, why are we doing it this way?
The access to contracts is secured through an object capabilities security model. The name registry supports creating a fixed reference to an unforgeable name, which gives contract authors the option to provide a reference to their contract that can be shared or used in off-chain applications.
Before these features were available, what were developers able to do with RChain?
Developers were able to create Rholang contracts and observe the unforgeable names. These contracts could be deployed to a mini-network and developers could observe the contract in the blockchain state.
After these features launch, what will developers be able (and not able) to do with RChain?
With the name registry, developers can now register unforgeable names to a public key or UUID. Developers can also update the unforgeable name registered to a public key. Developers can also use a new function 'toUtf8Bytes'
to Rholang to turn UTF-8 strings into GByteArray
. This is useful to pass strings directly into one of the hash functions in Rholang. Release notes are available at Release Notes - RNode v0.7.
Description of release packaging
Release packaging will include:
- Docker image (Supported on Linux only)
- Debian package
- RPM package
- .zip file
- tar.gz file
- Brew installation
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?
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