node-0.5 release plan
- Kelly Foster
- Henry Till
- Former user (Deleted)
Release summary
Simple overview
This release completes the core features needed for dApp developers writing smart contracts on RChain. In this version of RNode dApp developers can use unforgeable (private) names in Rholang contracts. This release does not include sharding, costing or validator slashing.
Technical overview
The structure of the RChain blockchain is a Block DAG (Directed Acyclic Graph). It requires a specific set of features for the internal representation of the blockchain as blocks are processed and validated where the state of the machine will 'roll back' and 'snapshot' to apply the results of consensus (agreement on a block).
This release introduces two features in RSpace which enable the Casper Consensus Protocol's creation of the Block DAG. One feature is the ability to take a "checkpoint" or "snapshot" of the contents of RSpace, and to be able to "reset" or "roll back" to this checkpoint at any given time. RSpace now records trace logs which contain a record of the actions performed in RSpace. While Rholang itself uses a non-deterministic execution model, these trace logs enable the deterministic execution of Rholang code, which is a fundamental piece of the puzzle that enables RChain Nodes to deterministically execute the Rholang code contained in blocks.
The Rholang language & RChain platform also supports unforgeable names. An unforgeable name is a core concept in the Object Capability Security Model. An object is a process that listens on a name for method invocations. If a process is in possession of the name, operations can be performed on the object. In an object capability language, it is impossible to get hold of an unforgeable name unless the process created it itself or the process received the name in a message. Using the 'new' operator within a Rholang smart contract will generate an unforgeable name during the deployment process.
The RChain blockchain has a unique event, inherent to the concurrency of the RChain platform. A COMM event occurs when a listening process and a sending process synchronize, substituting the messages for variables in the body of the listening process, and execution continues. The RChain architecture derives from the Reflective Higher Order Calculus, enabling Rholang processes to reduce and execute independently of each other. The execution of a Rholang contract can involve a single COMM event or several. Each COMM event can execute independently of others within the tuplespace. Concurrency doesn't just exist across smart contracts, it also exists within any given smart contract. This concurrency and non-determinism of the platform and the Rholang language has implications on the blockchain. Validators have to update their state as part of their work; in order for this to happen in the same way for all validators, RSpace has been enhanced to include execution traces, which are included in the block data structure. When a validator receives a block, the execution trace is used as a 'map' to the proposing validator's state. These execution traces also communicate any unforgeable names that are part of the block to the validator set.
What is this release able to demonstrate?
RNode v0.5 demonstration scenario:
- Setup requirements
- A mini net of 3-5 nodes all running the software.
- A configuration file for all the nodes in the network that defines the validator set and their bonds.
- Steps
- Start up the nodes and generate a genesis block on each node.
- Demonstrate the deployment of the wallet contract.
- Demonstrate executing some transactions, followed by a block proposal from a validator which is then accepted by the other validators.
- Execute transactions in such a way as to demonstrate an orphaned block.
- Review the metrics for the COMM events that were processed as a result of the demonstration.
- Demonstrate the API call that returns one of the blocks that was committed.
- Demonstrate a review the contents of the genesis block to show how the token swap will take place.
Includes Rholang code build process integrated into RChain build process (needed for the work to build the genesis block)
- The RChain State on the blockchain: Lead: Michael Birch (Unlicensed)
- Demonstrate a proposed block being added to the chain.
- Demonstrate a basic wallet app (contract) being deployed.
- Demonstrate a fork, where a block is orphaned.
- Demonstrate the safety oracle (a normalized fault tolerance value for each block will be part of the GRPC block API).
- API to view the fault tolerance for a block (a node's view of the safety for any given block)
- Demonstrate the genesis block.
- Includes the Rev contract
- Includes the Proof of Stake contract (alpha version)
- Includes a few example addresses to demonstrate how the token swap would work.
| Key | Summary | Assignee | Status |
|---|---|---|---|
| RCHAIN-366 | Implement latest message of latest message checks | Former user | Done |
| RCHAIN-365 | Add sequence number to block and corresponding validation checks | Former user | Done |
| RCHAIN-362 | Implement an API that provides information on the blocks the node considers safe | Former user | Done |
| RCHAIN-355 | Include execution traces in blocks and apply those traces when receiving new blocks | Former user | Done |
| RCHAIN-352 | Rev blessed contract as part of the RChain State | Michael Birch | Done |
| RCHAIN-349 | Reinsert check for transaction validations in Casper | Former user | Done |
| RCHAIN-346 | Have casper ignore blocks that do not come from a bonded validator | Michael Birch | Done |
| RCHAIN-335 | Refactor casper `Checkpoint` into `RuntimeManager` | Former user | Done |
| RCHAIN-334 | Add timestamp to block and add weak synchrony condition | Former user | Done |
| RCHAIN-333 | Keep track of invalid blocks of other validators as cache for slashing other validators that include those invalid blocks | Former user | Done |
| Key | Summary | Assignee | Status |
|---|---|---|---|
| RCHAIN-359 | Example Rev token transactions for RHOC holders at genesis | Michael Birch | Done |
| RCHAIN-358 | Engineering Design: Validators signing Genesis block | Michael Birch | Done |
| RCHAIN-356 | Implementation: Validators can sign the Genesis block | Michael Birch | Done |
- History, Rollback and Execution Traces: Lead Henry Till
- Demonstrate Execution traces & replay
- Demonstrate checkpoint
- Demonstrate rollback
- Wallets/Purses/Tokens: Lead: Michael Birch (Unlicensed)
- Basic wallets and purses and Tokens. Users can create their own types of Wallets and Purses and corresponding token.
- Create a transaction to transfer token using the Node API.
- An API that will deploy code to transfer token from one wallet to another.
- Rholang Features
- Support for Unforgeable names
- Channel Sorting
- Runtime error handling mechanism for Rholang
- Build Rholang files along with project source code
- Support for evaluating multiple files in a specific order
| Key | Summary | Assignee | Status |
|---|---|---|---|
| RCHAIN-2230 | Create unforgeable names | Michael Stay | Done |
| RCHAIN-370 | Create documentation for a developer audience on the use of unforgeable names | Kyle Butt | Done |
| RCHAIN-363 | Make the eval parameter accept multiple files in order. | Ovidiu Deac | Done |
| RCHAIN-353 | Integrate rholang source code into the build process | Michael Birch | Done |
| RCHAIN-350 | Spec: Support for Deterministic Unforgeable names | Kyle Butt | Done |
| RCHAIN-348 | Unforgeable names are created from the execution trace | Kyle Butt | Done |
Metric for tracking success
What is special about this release?
This release provides support for unforgeable names. The RChain platform implements the object capability security model. An unforgeable name is a reference that cannot be guessed. The only way for code to have access to an unforgeable name is if the code creates the name or if the code receives the name on a channel. This feature enables contract authors to create unforgeable names on the RChain platform.
Are we doing something differently? If so, why are we doing it this way?
RChain uses a Proof of Stake consensus algorithm. This means that in order to participate in the protocol, validators need to bond by putting up stake. The proof of stake family of consensus algorithms aims to reduce the consumption of electricity by eliminating the proof of work portion of consensus.
The RChain platform is inherently both concurrent and non-deterministic. Rholang smart contracts are comprised of processes, which can execute independently of each other. Combined with a Proof of Stake consensus algorithm, RChain believes that excellent performance is possible on the platform.
Before these features were available, what were developers able to do with RChain?
Developers were able to develop their dApps and test them locally on the rNode.
After these features launch, what will developers be able (and not able) to do with RChain?
Developers can now take advantage of all the blockchain-dependent features of a dApp, including contract deployment, block proposals, transacting with their deployed contracts and exploring block data. Developers can also use unforgeable names within their Rholang contracts, and take advantage of Object Capabilities Security features on the blockchain.
Description of release packaging
Release packaging will include:
- Docker image and installer guide
- Debian package
- RMP package
- .zip file
- tar.gz file
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
JIRA issues in this release
