RChain intends to be a PoS platform for smart contracts that is scalable, efficient, dependable, and truly decentralized. Although RChain admires the contributions that Ethereum, Bitcoin, and other platforms have made, they believe none of them have the correct blockchain architecture to support the scalability and high amount of transactions per second (tps) required for industrial use. According to the RChain team, what differentiates it from other platforms is the fact that its architecture and computational model natively supports concurrency, security, and process-orientation. This in theory should allow it to scale linearly. At the heart of this is RhoLang, a programming language based on Rho-Calculus innovation, which is the language used to write smart contracts on RChain.
The RChain network is secured by a PoS model that uses the CBC Casper framework, which is similar to Ethereum’s Casper design. The way it works is if you’d like to participate in consensus on the network, you have to put up a bond, if you try to go against the consensus rules of the network, other validators of the network will notice and slash you, resulting in you losing the initial bond you put up. The central idea behind it is that by not playing by the rules you risk losing the bond you had to put up to participate.
RChain’s architecture is based on a branch of mathematics called mobile process calculi, which has approximately 30 years of history. Reflective Higher-Order Calculus (Rho Calculus) is the computing model that powers RChain. The heart of RChain is the Rho Virtual Machine (RhoVM) Execution Environment. With RhoVM, transactions don’t have to be processed sequentially, but rather concurrency is built into the protocol. Concurrency allows the nodes to share the load and process transactions in parallel, utilizing multiple RhoVMs. This, essentially, creates a structure in which there are multiple blockchains per node.
RChain hopes to avoid explicit routing where all the validators wouldn’t need to know what the entire set of validators are doing or who they are if it doesn’t concern them. Unlike most blockchains where addresses are public keys, RChain’s address space is structured by Namespaces. The Namespaces serve as virtual channels on the network that are independently and concurrently processing transactions. The smart contracts would execute independently and only share data with one another when necessary, meaning they wouldn’t need to watch all transactions in all of the namespaces. Nodes would not have to download the entire blockchain, but rather they’d be able to subscribe to selected address spaces and allow developers to choose the optimal validation path for every transaction.
Use of LADL (Logic as a Distributive Law)
A form of compression that will allow for more throughput on the blockchain. Most blockchain designs have their blocks contain transactions. With RChain, rules are included in the blocks instead. These rules define what transactions can be included in that block. This makes it possible for a massive amount of transactions to be represented by a small set of rules.
The LADL algorithm will also help with detecting possible bugs in contracts before they are deployed. It can generate type system for untyped languages, which makes it possible to write reliable code. Contracts written in RhoLang can detect race conditions. Race conditions occur where an output is dependent on the sequence of other events, and the events do not occur how the programmer intended. An example of this is with the famous DAO contract bug on Ethereum. If the DAO contract had been written in RhoLang, the bug could’ve been detected and prevented.