(deprecated) RSpace 0.2 Specification

This document is intended to specify the 0.2 release of the RChain storage layer (Storage.02)

Call out any related documents, pre-requisite documents, and documents that provide context or background.

Previous version (Storage.01) 

The version of the storage layer envisioned for Storage.02 is a simplified version of the layer described in this document.

Storage.02 will not include distributed operation. Storage.02 will not operate in a distributed setting. Storage.02 is designed to work in the context of a single Rholang interpreter running alone on a single node which does not communicate with other nodes.  Later releases of the RChain storage layer will work with multiple instances of the Rholang interpreter or RhoVM running on a single node which will be networked with other such nodes.

There are also some important differences from the storage layer described the architecture document:

• The underlying key-value store: Instead of MongoDB, the current design of the storage layer uses LMDB.  See Software Dependencies for more information.

• The query mechanism: Originally, SpecialK used a Prolog/Datalog-based query mechanism, which was included in the original design for the RChain storage layer . However, this feature will not be available in the Storage.02 release.  It will be replaced with a different approach to matching on keys.

This document contains relevant information about LMDB.

Old, somewhat weird solution to each key having multiple pieces of data

• a term that has a definition

• a term that is part of the interface

• a term that has a definition and is part of the interface

"A package file format typically used to aggregate many Java class files and associated metadata and resources (text, images, etc.) into one file for distribution." (Wikipedia)

From RChain Architecture Docs: Execution Model

RhoVM operates against a key-value data store. A state change of RhoVM is realized by an operation that modifies which key maps to what value. Since, like Rholang, RhoVM is derived from the rho-calculus model of computation, that operation is the low-level rho-calculus reduction rule. Effectively, the reduction rule, known as the “COMM” rule, is a substitution that defines a computation P to be performed if a new value is observed at a key. A key is analogous to a name in that it references a location in memory which holds the value being substituted.

A COMM Event is a consume that matched at least one produce.

consume or produce.

A consume is an action that can be issued on RSpace and is aligned with the Rholang conceptual model of using the tupelspace.

The consume represents a waiting continuation which can be matched in RSpace with a relevant produce.

A produce is an action that can be issued on RSpace and is aligned with the Rholang conceptual model of using the tupelspace.

The produce represents data that can be matched in RSpace with a relevant consume.

A variant on a blockchain, where each block is a node in a Directed Acyclic Graph (DAG).  In order to accommodate the CASPER consensus model, RChain's Blockchain is a BlockDAG. The storage layer stores the history of states and has means for rolling back to them to support the consensus model.

From https://github.com/ethereum/wiki/wiki/Patricia-Tree

Merkle Patricia tries provide a cryptographically authenticated data structure that can be used to store all (key, value) bindings

From the Cats Documentation

Type classes are a powerful tool used in functional programming to enable ad-hoc polymorphism, more commonly known as overloading. Where many object-oriented languages leverage subtyping for polymorphic code, functional programming tends towards a combination of parametric polymorphism (think type parameters, like Java generics) and ad-hoc polymorphism.

Original paper demonstrating how to encode type classes in Scala: https://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf

From http://www.lmdb.tech/doc/

LMDB is a Btree-based database management library modeled loosely on the BerkeleyDB API, but much simplified.

RSpace is the "RChain storage layer" implementation. It has an abstract interface IStore that holds the"RChain storage layer" contract.

A Checkpoint is a stable (once created it does not change over time) reference to a particular state of RSpace. It is implemented as a BLAKE2b256 hash.

A checkpoint is also an action of creating a Checkpoint.

A rollback is an action that can be performed on RSpace. It requires a valid Checkpoint and results in RSpace pointing to the state that the passed Checkpoint referenced. 

A Branch represents a named context in RSpace. Any data that found it's way into RSpace on one Branch will not be visible on a different Branch.

This allows RSpace to share the data store (different data spaces on different Branches) which in turns allow to run a replay (via rigged mode).

Every action (IO Event, COMM Event) that affects the state in RSpace is stored in the log. 

Puts RSpace in a mode that allows to replay results that were produced by a different RSpace based on log and incoming produce and consume events.

The RChain's Blockchain network composed of multiple nodes.

A validator is a node role responsible for the consensus algorithm (http://architecture-docs.readthedocs.io/execution_model/consensus_protocol.html).

RSpace 0.2 includes the features needed to support the RChain blockchain.  

As stated above, this document is only intended to describe the minimal initial version of the storage layer, known as Storage.02.

Storage.02 will implement the basic tuplespace functionality described below for use in the Rholang Interpreter.

Storage.02 

• will not operate in a distributed mode

• will not implement the "system processes" feature which allow a client to run arbitrary Scala code keyed to a particular channel.