pRChain Architecture DocumentationRelease 0.8.1Ede Eykholt, Lucius Gregory Meredith, Joseph DenmanJanuary 12, 2017Contents1 Abstract 11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Comparison of Blockchains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Architectural Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6 Pseudonymous Identity and Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.7 Blockchain Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.8 Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.9 P2P Node Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.10 SpecialK Data amp; Continuation Access, Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.11 Content Delivery Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.12 Attention amp; Reputation Economy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.13 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.14 Contract Development amp; Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.15 Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.16 Implementation Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.17 Call for Participation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17iiiCHAPTER 1AbstractRChain’s plat architecture is a decentralized, economically sustainable public compute infrastructure. The plat- design results from the inspirations of earlier blockchains and builds on top of the shoulders of giants in thedisciplines of mathematics and programming language design.Intended audience This document is written primarily for software designers and developers who want to help seethis vision realized, and for others who want to support these efforts.1.1 IntroductionThe RChain Cooperative and its partners are building a public, Sybil-resistant, and censorship-resistant computingutility. This is an open source project. It will be a blockchain-based plat for specifying, verifying, building, andrunning decentralized protocols “smart contracts” that the base for decentralized applications. On top of thistechnology plat, a broad array of solutions can be built, including financial services, monetized content deliverynetworks, marketplaces, governance solutions, DAOs, and RChain’s own flagship decentralized social plat.The decentralization movement is ambitious and will spawn solutions that provide awesome opportunities for newsocial and economic interactions. Decentralization also provides a counter-balance to abuses and corruption thatoccasionally occur in some organizations where power is concentrated, including large corporations and governments.Decentralization supports self-determination and the rights of individuals to self-organize. Of course, the realities ofa more decentralized world will also have its challenges and issues, such as how the needs of international law, publicgood, and compassion will be honored.We admire and respect the awesome innovation and intentions of the Bitcoin and Ethereum creators, and other plat-s that dramatically advanced the state of decentralized systems and ushered in this new age of cryptocurrency andsmart contracts. However, we also see symptoms that those projects didn’t use the best engineering and mathematicalmodels for scaling and correctness in order to support mission-critical solutions. The ongoing debates about Bitcoinscaling and the June 2016 issues with The DAO smart contract are symptomatic of foundational architectural issues.As an example question Is it scalable to insist on an explicit serialization order for all transactions conducted on planetearthRChain’s requirements, originating from RChain’s decentralized social product and its attention amp; reputation econ-omy, are to provide content delivery at the scale of Facebook along with support for transaction volume and speedat the scale of Visa. After due diligence on the current state of many blockchain projects, after deep collaborationwith Ethereum developers, and after understanding their respective roadmaps, the RChain leadership concluded thatthe current and near-term Blockchain architectures cannot meet these requirements. Therefore, RChain and partnersresolved to build a better blockchain architecture. Together with the blockchain industry, we are still at the dawn ofthis decentralized movement, and it is now the time to lay in a more correct architectural foundation.The journey ahead for those who share this ambitious vision is as challenging as it is worthwhile, and this documentsummarizes that vision and how we seek to accomplish it. We compare the blockchains of Bitcoin and Ethereum,1RChain Architecture Documentation, Release 0.8.1outline the RChain architecture, rationale for its creation, and pointers to initial specifications.1.2 Comparison of BlockchainsThis document assumes the reader is familiar with the basics of Bitcoin and Ethereum. As one approach to introducingthe architecture let’s compare the characteristics of Bitcoin, Ethereum, and RChain as currently planned.2 Chapter 1. AbstractRChain Architecture Documentation, Release 0.8.1Bitcoin Ethereum RChainSemantic Data Structure Blockchain – a chain ofblocks. Each block containsa header that points at theprevious block, a list oftransactions, and other data.Blockchain – a chain ofblocks. Each block contains aheader that points at theprevious block, a transactionlist, and a ommers uncleslist.Blockchain – a graph of blocks.Each block contains a header thatpoints at one or more previousblocks, a list of transactions, andother data. For details, seeBlockchain Data Semantics, below.ConsensusAl-go-rithmProof of work Current Proof ofwork.Future Proof of Stake– stake-based betting onblocks.Proof of Stake Stake-based bettingon logical propositions.Fi-nal-ityProbability of transactionreversal diminishes overtime, at each new blockconfirmation.Probability of transactionreversal diminishes overtime, at each new blockconfirmation.Probability of transaction reversaldiminishes over time, at each newblock confirmation.Visi-bil-ityGlobal Private, consortium, or publicdepending on deployednodes.Private, consortium, or publicdepending on namespace and/ordeployed nodes.Re-vi-sionMech-a-nismSoft and hard forks Current Soft and hard forks.Future Block revisions incase of temporary networkisolation.Block revisions in case oftemporary network isolation.ShardingHet-ero-gene-ityHomogeneous, i.e., notshardedCurrent Homogeneous, i.e.,not shardedFuture two-levelSharding of address space allowsclients to subscribe to selectedaddress namespaces withoutdownloading the entire blockchain.Able to impose different policies ondifferent address namespaces.Ba-sisforshard-ingN/A Address range Dynamic composable shardingbased on namespace interactionNum-beroflev-elsN/A Future two levels cluster leavesUnbounded number of levelsCon-cur-rencyN/A Current No Future Yes Yes. Allows for concurrent bettingon propositions and committing ofblocks that don’t conflict.ContractsCom-pu-ta-tionalpowerStack-based language withfew instructionsTuring complete Turing completeRun-timear-chi-tec-tureScript runs on Bitcoin Core,Libbitcoin, and other nativeimplementationsEthereum Virtual Machineimplemented on multipleplatsRhoVM implemented on multipleplatsPro-gram-minglan-guageScript Solidity, Serpent, LLL andany other languages that getimplemented on the EVM.Rholang and any other languagesthat get implemented on theRhoVM.Block Size 1MB Dynamic DynamicMax Transaction or Contract Size 100KB Dynamic based on gas limit Dependent token type and itsper-namespace policies.Scalability -Transaction Throughput 7 tx/s 15 tx/s Target is 40,000 - 100,000 tx/secProtocol Token Bitcoin, plus tokens such asprovided by Omni LayerEther ETH, plus tokensissued by contracts.Multiple tokens issued by systemcontracts or application contracts.Concurrent VM N/A. Bitcoin’s stack-basedlanguage does not have orrequire its own VM.No. The EVM issingle-threaded.Yes. RhoVM is multithreaded. Thismakes concurrent shards easier toimplement since there are noassumptions on synchrony.Privacy Low at base protocol layer.Pseudononymous.Low at base protocol layer.Pseudononymous.Namespaces can be arbitrarilyobscure. Agent Service channelscan be encrypted.1.2. Comparison of Blockchains 3RChain Architecture Documentation, Release 0.8.11.3 Architecture OverviewThe primary components of the architecture are depicted belowLike all “layer cake” views of architecture, this diagram is a simplification of the actual architecture. At first glance,you’ll notice there are components expected in blockchain architectures, but also components that might not be asexpected All data managed by the plat requires some associated payment. Of course, an application could alsomanage its own data, and that data could be referenced via a pointer stored on the blockchain.In addition to the datastore at the base of the architecture, a consensus protocol and peer-to-peer gossip network the foundation.Above that, the SpecialK Data amp; Continuation Access and Cache layer is an evolution of the existing SpecialK tech-nology including its decentralized content delivery, key-value database, inter-node messaging, data access patterns,and privacy protecting agent model.The Casper consensus protocols assure that nodes reach agreement about the contracts, contract state, and transactionsfor which each node is interested.Blockchain contracts aka smart contracts, protocols, or programs will be written in a new domain-specific languagefor contracts called Rholang or in contract languages that compile to Rholang and then cuted on the Rho VirtualMachine on a number of native plats.Smart Contracts include some essential system contracts as well as those providing capabilities for tokens andapplication-supplied contracts.A metered and monetized content delivery network CDN is enabled through token and micro-payment contracts,accessing a mix of blockchain and off-chain data.The Attention amp; Reputation Economy provides a model and set of interactions for motivating respectful and economiccreation and dissemination of ination within social networks.In the architecture, there will be several APIs, especially at the top layers. Typed APIs will provide access to theRhoVM, Contract Services, and individual contracts. In addition other APIs including RESTful APIs will be pro-vided for accessing the CDN, and the Attention amp; Reputation Economy.4 Chapter 1. AbstractRChain Architecture Documentation, Release 0.8.1We’ll detail these components in the sections below, from the bottom-up. But first, let’s discuss the requirements andsoftware architecture approach motivating this plat solution.1.4 RequirementsLet’s look at the requirements for the plat from the vantage point of the developers building applications on topof it. Then, let’s look at what is required of the plat itself in order to achieve those requirements.Requirements for Decentralized Application Developers Fully decentralized Tamper-proof blockchain for “immutable” history Smart contract state conserved quantities and VM state reliably replicated Support for multiple tokens Ability to write predictably secure software contracts ScalableRequirements of the Architecture Design with provably correct approaches Data separation using namespace addressing to reduce unnecessary data replication of otherwise independenttokens and contracts Support for concurrent protocol cution Distributed and decentralized Minimal external dependencies Peer-to-peer and discoverable nodes Consensus protocol that is computationally efficient and not resource-intensiveNon-Requirements There is a long list of items the architecture will not address, but let’s list a few to dispel what might otherwisebe common misperceptions. For example, the architecture will not address Compatibility with smart contracts or scripts written on other blockchain technologies Automated coin conversion within the plat, since this can be better handled at the application level1.5 Architectural ApproachBuilding quality software is challenging. It is easier to hand-craft clever software; however, the resulting software isoften of poor quality, riddled with bugs, difficult to maintain, and difficult to evolve. Inheriting and working on suchsoftware can be hellish for development teams. When building an open-source system to support a mission-criticaleconomy, we reject a minimal-success mindset in favor of end-to-end correctness.Therefore, we resolved to meet the requirements stated in the earlier section, and to Build quality software that implements well-specified protocols. Build software based on software architecture patterns and other correct-by-construction approaches.1.4. Requirements 5RChain Architecture Documentation, Release 0.8.1 Take cues from mathematics. Use al verification of protocols, leveraging model checking and theoremproving. Make evidence-based decisions with supporting rationale for design decisions. Choose functional programming paradigm, since it better enables distributed and parallel processing. Apply best practices of software patterns, including compositionality.1.6 Pseudonymous Identity and CryptographyLike other Blockchains, RChain will use elliptic curve cryptography ECC. The exact curve and address ats havenot yet been selected.There are several areas in which cryptography is employed, including Transaction signing Data encryption per channel– based on Diffie–Hellman key exchange,– within and across nodes, and– in datastores Obscurity of keys and data in DHT1.7 Blockchain Data1.7.1 Data SemanticsLike Ethereum, the RChain blockchain will store contracts and their serialized state. UTXO-style transactions willbe implemented with simpler system-level contracts. Like Bitcoin and Ethereum, tamper-proof blockchain semanticswill be used to create a history of blocks. The blockchain’s main purpose is to efficiently store essential state, anynecessary sequencing, and timestamping.Note that the math underlying this blockchain semantic structure is known as a Traced Monoid/p