This is the first of several articles about the RChain project, an innovative blockchain platform currently being developed in Seattle by a team led by Lucius Gregory (“Greg”) Meredith, a mathematician and computer scientist whose work over the years centered around mobile process calculi and their applications to a broad scope of practical problems — from consensus algorithms to modeling biochemical processes in the human body.
RChain is a blockchain platform, which means that it is a distributed system used to record and relay transactions under network consensus. Existing blockchain platforms, such as Ethereum, are commonly used to create decentralized applications with an economic component. Ethereum introduced and developed a framework for automated economic interactions between multiple parties usually termed smart contracts. RChain aims to achieve a similar goal: to create a global platform for decentralized economic applications using its own smart contract language, Rholang.
RChain is based on a formal mathematical framework called ρ-calculus. This blog post will explain what this framework is, where it fits with blockchain technology, and briefly outline other innovations behind RChain. The primary audience for this post is technical. In order to understand some concepts presented here you are expected to be familiar with such terms as consensus protocol, smart contract language, concurrency, process, and others, which I will use without providing detailed explanations. This series is being written as an early introduction to RChain for developers and will dive deeply into specialized topics that may be too in-depth for general audiences.
A mobile process calculus is a formal way to model an environment that consists of a number of concurrent processes that engage in communication with each other. Examples of such environments can be found everywhere, both in nature and in computer science. For example, we can look at every car and driver on the road as an independent process, with communication established through speed, turn-signals, and horns. Reducing the scale, we notice that every part of the car is also a concurrent process, where each mechanical part communicates with certain others by applying pressure and each electrical part communicates by producing electrical signal and current. The human body is also made up of a vast number of concurrent processes, cells, which communicate through a complex medley of chemical, electrical and mechanical signals. We can continue these illustrations, but the picture is clear: once you look at the world as a combination of concurrently proceeding processes, you see them everywhere.
But the model presented by the mobile process calculus doesn’t stop there. It is further augmented by the fact that configuration of the network and coordination between processes may itself be seen as a process, which is changing over time. In mobile process calculus therefore, we see a mechanism that describes and accounts for such fluidity.
The applicability of mobile process models to blockchain is easy to see. A blockchain platform, such as Ethereum, operates by running a vast number of concurrent processes in several different contexts. On one hand, each of the nodes on the network is a process. Every such node has threads that receive, resend and analyze transactions as they happen.
More importantly, however, is the fact that a smart-contract environment is inherently a mobile process environment, where each party to the interaction encoded in the smart contract is itself a process. These processes are of a special kind, because they do not operate continuously, but rather interact with the network as-needed. So for example, a multi-signature cryptocurrency wallet is a process which receives signed messages and occasionally performs a funds transfer to the destination address. Each of the parties to such contract sends signed messages to the wallet. From the perspective of the wallet, people that interact with it look like other processes.
A creation or a dissolution of a smart contract is an act of reconfiguration of a part of the mobile process network. It is governed by its own rules that are carried out by yet another set of processes that act to create or dissolve a contract under these rules.
I hope that what I have shown so far illustrates the power and versatility of this approach. Mobile processes calculi (of which there are several variations) are elegant models for programming both real-world systems and digital environments such as blockchain networks and smart contracts.
This is the primary insight behind the RChain project. Greg has spent many years developing a particularly powerful variation of a mobile process calculus called ρ-calculus (pronounced Rho-calculus), which closes the loop on several issues that are outstanding in a more traditional framework, π-calculus.
One of the features that ρ-calculus adds to π-calculus is reflexivity. In fact, Rho stands for reflexive higher order, which is to say that ρ-calculus supports processes referring to themselves and the code that comprises them. As we will see in subsequent chapters of this series, this feature proves to be particularly important for blockchain programming. It allows for an unprecedented level of automated analysis of smart contract code to definitively confirm that it adheres to specification and respects constraints set upon it by its creators. It also makes available the concept of namespaces, which are collections of communication channels with associated rules. Namespaces, in conjunction with automated analysis, allow a developer to verify that access to certain features of a smart contract is appropriately restricted, preventing such egregious security holes as the one recently discovered in the Parity multi-signature wallet. These are just some advances made possible by ρ-calculus, but there are also others that we will illustrate in subsequent chapters.
RChain is a blockchain framework fundamentally predicated on these ideas. Its core feature is its programming language, Rholang, which makes ρ-calculus concepts available to programmers as language constructs. Rholang is being developed both as a smart contract language and as a high-performance programming language that will eventually be used to implement the low-level functionality of the blockchain nodes themselves.
Rholang’s performance expectation comes from several sources. First, it is a highly concurrent programming language (obviously, since concurrency is its primary feature). As such it allows one to develop highly parallelizable software, whose speed of execution can be increased significantly by adding computing resources to the network. Secondly, it can be efficiently analyzed by automated tools that will eventually become an integral part of its compiler framework. As part of such analysis the compiler may automatically identify bottlenecks, perform optimizations, and even execute certain parts of your code in a vectorized fashion on your GPU(s).
In addition to performance Rholang offers significant guarantees of safety and determinism when it comes to such aspects of concurrent programming as deadlocks and race conditions. For example, it can find race conditions in your smart contract code (at compile time!) and ensure that all nodes on the network achieve consensus at the race-point only, which is expected to significantly reduce the amount of information that is required to flow through the blockchain network.
RChain’s innovative vision, however, doesn’t stop with Rholang. Another area of improvement as compared to existing blockchain networks is its resource-economics model (which I call a meta-resource model in one of my earlier posts). This model defines the way RChain accounts for the economics of carrying out blockchain transactions. A resource-economics model currently known to many is Ethereum’s gas, which is used to pay for smart contract computations performed under consensus. Ethereum’s gas, however, only accounts for the computing power required to run a smart contract, but leaves other node-related expenses uncompensated. Those are: disk storage, memory, and network utilization. A truly scalable blockchain requires that these expenses be properly accounted for, because if they aren’t, an incentive misalignment will prevent the network from growing. Imagine, for example, what happens when a blockchain grows to multiple petabytes of data (which is a conservative estimate for something truly global). A node desiring to become a validator needs to be able to pay for storage of such significant size. If they don’t get compensated by the network for doing so, they will simply not want to provide this important service and the network will be left without validators.
Another feature that contributes to the vision of scalability in RChain is the way it uses namespaces to limit the scope of transaction validation. Because data and code are unambiguously referred to by names within a rich namespace framework, validators are only required to achieve consensus related to a particular transaction within its specific namespace. This means network communication only needs to happen between a limited set of validators (those that record transaction in the same namespace), and only for relevant transactions, rather than every transaction in the global network. Essentially, one can think of namespaces as shards in more traditional parlance.
Similarly, an RChain node doesn’t need to download the entire blockchain as is the case today with Bitcoin and Ethereum. Nor do all transactions in the world need to be placed in sequential order, but just the ones whose order matters to resolving conflicts, such as a double-spend.
The ability to narrow the scope of consensus around a specific transaction allows RChain to do as little work as possible in validating specific transactions. At an extreme low end of the spectrum, this translates to being able to create an equivalent of state channels, which can be seen as transactions between a small number of counterparts, carried out cheaply and efficiently without engaging the consensus protocol of the larger network. Essentially, with RChain you can think of state channels as a feature you get for free, without the need to create additional software layers to support them.
RChain strives to cover many of the features that are either apparently missing from the current frameworks, or will soon become major bottlenecks preventing adoption and scaling. It is being developed as a platform for the future, one that plans to survive and be used for decades, rather than becoming obsolete at the next turn. In the subsequent chapters of this series I will dive more into specific features of Rholang and RChain, demonstrate a simple smart contract written in Rholang, further discuss its security model and economics, talk about the basis for automated compile-time analysis, as well as address many other aspects of this truly innovative framework.