北京时间 2018 年 7 月 17 日，标准共识发布针对区块链项目「RChain」（RHOC）的一般投资风险评级报告。以下为报告的主要内容。

报告将 RChain 风险等级定义为「B」，该项目属于「一般风险」水平，需要投资者注意。

依据「标准共识一般项目投资风险评级标准（初创期）」  获得「B」评级的主要原因是：RChain 项目开发难度大，上币交易所只有 5 家，筹码集中度高，流通性风险高。项目创新度高，开发社区活跃，整体履约情况好。

基于标准共识分析师团队调查和研究，项目主要风险及优势在于：

项目主要风险

风险点一：RChain 项目创新度高但难度大，项目最终落地存在高不确定风险。

RChain 项目融合了分片技术、Casper 协议、Rho 演算的形式化验证、高并发 RhoLang 语言及多虚拟机并行计算等五大创新技术，每一个单独的技术方向都有详细的文档说明，逻辑严密，充分显示了团队深厚的研发背景和技术实力。

虽然项目方理论功底深厚，但按时实现多个高难度技术目标的不确定性较高。即使技术目标实现，交易性能、稳定性、应用范围能否达到预期，也有很多不确定因素。

风险点二：用户社区热度低，登陆交易所数量仅 5 家，且均为中小交易所。

RChain 社区用户成员数量较低，Telegram 英文用户群人数 2,669，Facebook 关注者 455，Reddit 订阅者 2,317，Medium 账户关注者 756。

根据 Coinmarketcap 数据， RChain 共登陆 5 家交易所，成交主要集中于 3 家交易所，交易所覆盖面极低，所登陆交易所都为排名 50 之后，未进入主流交易所，市场影响力低，新生投资者增长空间狭窄。

风险点三：流通风险很高，筹码高度集中。

RHOC 近一个月的全市场平均换手率为 0.17%，交易频率极低，市场活跃度差，流通性风险极高。

RHOC 无明确释放计划，整体缺乏审查监管体系。个人投资者基础薄弱，筹码高度集中，这将严重限制交易的活跃性。项目二级市场流通性风险和价格被操纵风险高。

项目主要优势

优势一：RChain 开发团队技术实力强，项目创新度高。

RChain 团队开发人员拥有区块链行业经验及大公司管理经验，团队成员包括：曾供职微软的首席架构师、 Casper CBC 协议的研究者等技术人才，以及产品管理、财务、运营等专业人才。

RChain 的五大技术创新点均为当前解决公链的吞吐量的主流方案，每一个技术创新点 RChain 均做了详细说明文档，从数学、逻辑学和代码实现上做了详细的理论论证说明，充分证明了项目方极高的计算机理论功底及创新能力。

优势二：RChain 项目开发已取得一定进展，整体履约情况好。

RChain 整体开发难度大，线路图中提及关键技术难点：RhoLang 语言规格说明文档发布，展示 Casper CBC 共识协议及较高吞吐量，均已如期履约。

在代码层，RhoLang 的最核心的编译器、Casper 协议的基本架构已经基本完成。

优势三：开发者社群活跃度、关注度、开发热度高。

代码提交活跃，在 7 月 13 日 CryptoMiso 3 个月指数代码提交次数中排名第 5，一共 1,126 个 Commits。

开发者社群关注度较高，Watch 数量一般，Fork 和 Star 的数量较多；主力开发者数量较高，提交 Commits 数量超过 50 的有 18 位。

以上为项目主要风险点和优势，以下为完整报告。

如果任何项目方对标准共识的评级结果有疑问，或对相关数据提出申诉（包括但不限于项目运营数字、重要团队成员变更原因、代码更新和最新交易表现等），标准共识分析师团队会根据材料的真实性重新评估。

如果标准共识分析师团队在调查过程中使用了错误材料而影响评级结果，或任何项目变动可能导致评级等级变动时，标准共识也会重新调查和评估风险等级。

任何项目方、利益相关方和投资者可直接通过微信公众号（「标准共识」ID：SNCrating）后台与我们联系，也可以发送邮件至：contact@sncrating.com。

Rationale 依据

产品和技术模块

市场及产品分析

RChain 主要解决区块链底层协议扩展性的问题，希望成为下一代的以太坊。不同于以太坊， RChain 的智能合约是并发的，并由编译器进行形式验证，所以 RChain 理论上更加快速、通用且安全。

RChain 发明独有的 RhoLang 语言，用于编写智能合约。相较于以太坊的 Solidity 智能合约语言，RhoLang 是一种强类型、并发和自动建构校正的编程语言，适合于区块链智能合约。

RChain 旨在解决如下三个问题：

1）底层协议扩展性问题；

2）智能合约的形式化验证问题；

3）共识的安全和经济问题。

提出的核心技术主张如下所示：

1. 用于并发处理智能合约的 RhoLang 语言。

   
   

• RhoLang 是一个功能全面的图灵完整的通用编程语言，它使用 Rho 演算来进行构建。它是一个具备行为类型和反射机制的高阶进程语言（r-eflective, h-igher o-rder process language），也是 RChain 官方智能合约所使用的语言，其目的是具体化细粒度的并发编程。

• 目前主流的智能合约编程语言，比如 ETHereum 所用的 Solidity 、Bitcoin 所用的 Go 语言等，对于变量的处理方式均为单线程。多个线程同时访问并修改同一个变量，为了避免出现某一个线程修改变量的同时被另一个线程修改导致结果错误，上述语言将多线程的并发访问转换成了多个线程的逐个访问，大大降低了处理速度。

• RChain 的 RhoLang 语言是采取多线程并发的解决方案，即开多少线程并不是预先设定的，要取决于当时的交易量情况。当系统的计算量增加时，系统将自动增加更多的计算资源处理。

• 关于 RhoLang 语言，官方有详细的说明文档，详细见：https://developer.rchain.coop/assets/rholang-spec-0.2.pdf。

2. 基于 Namespace 理论的状态分片技术。

   
   

• RChain 构建的 Namespace 是一个虚拟空间，每个空间有很多通道，进程之间通过通道来进行联系，不同的命名空间中，进程可以并发执行而不用担心资源竞争和不一致。这可以理解为一种另类的分片技术：一个事务被拆成不同的问题集，每个节点只处理一个与其特定需求相关的小碎片事务。然后这些小碎片可以连接成更大的碎片，这些更大的碎片最终可以组成一个完整的事务。得益于并发以及分布式计算机制， RChain 每秒能处理 4 万个事务。

• 每个 Namespace 命名空间都是一个区块链，并可以生成次一级的 Namespace，最终形成一种树状结构。对每个命名空间内的访问，独立地经由服务于该命名空间的挖矿节点确认。超出该空间的访问会一直往上提升到相应级别的命名空间，由服务于该命名空间的挖矿节点确认。命名保证了资源的无冲突访问，使得一致性协议尽可能地保持在最小的范围内。

• RChain 的 Namespace 原理详见官方说明文档，地址为：http://rchain-architecture.readthedocs.io/en/latest/contracts/namespaces.html，下图为 Namespace 里区块的树状结构图。

3. 基于 Casper CBC 的 PoS 共识机制。

   
   

• RChain 的共识协议与以太坊一样，也是基于 Casper 协议，不过与以太坊采用的 Casper 协议的 FFG（Friendly Finality Gadget） 协议不同，RChain 采用 Casper 的 CBC （Friendly GHOST: Correct-by-Construction）协议。即 RChain 的节点会检查逻辑命题，而不是像以太坊一样每个全节点都要验证整个区块。

• 逻辑命题是关于区块链操作的表述，例如：区块链上必须包括哪些交易，以何种顺序，哪些交易不应该被包括，或者其他属性的表述。在这种设计下，因为不需要每个节点都参与对整个区块链的验证，区块链就可以进行切分，能够在某一时间段完成大量交易并达成共识。这种结构能够使 RChain 以极快的速度处理信息，与中心化服务器形成了竞争，在维持和运行互联网层面也对中心化服务器提出了挑战。

• 就 Casper CBC 共识机制，RChain 在 GitHub 上有官方的说明文档，详细见https://github.com/ethereum/research/blob/master/papers/cbc-consensus/AbstractCBC.pdf，下图摘自官方说明文档。

4. 形式化验证 Rho 演算。

   
   

• RChain 将自带形式化验证工具，通过数学方法来证明代码中是否存在某漏洞或缺陷，能够消除很多潜在的 bug，尽可能的让开发者开发出稳定并且安全的程序。

• RChain 执行模型源于 Rho 演算的语法和语义。Rho 演算是 π 演算的一个变种，π 演算于 2004 年被推出，它是第一个提出使用反射策略的并发计算模型。 「Rho」代表反射的，高阶的。

• 关于 π 演算的详细文档，详见创始人 Lucius Gregory Meredith 在 Cornell University 发表的论文《Higher category models of the pi-calculus》，地址为 https://arxiv.org/abs/1504.04311。

5. 多个虚拟机并行处理。

   
   

• RChain 的核心是 Rho 虚拟机 (RhoVM) 执行环境，与以太坊只有一个虚拟机不同的是，RChain 将支持运行多个 RhoVM 虚拟机，每个 RhoVM 可以并发且多线程地执行一个智能合约。即 RChain 的智能合约被分解为多个处理事务 ，在多个节点上并行执行，即使某个节点在运行中意外退出，也不会影响计算进程。

• Rho 虚拟机执行环境其背后的数学原理就是移动进程演算，是 RChain 创始人 Greg 潜心多年研究的成果。

标准共识分析：

RChain 是一个全新的区块链平台，是第一个真正意义上的可并行、扩展性极强的区块链，它来源于一种基于形式化验证的、去中心化的、并行计算模型。

RChain 利用该模型来开发一个可并发、可组合、可无限扩展的区块链平台，最终能为企业提供高性能的区块链服务。RChain 理论上每秒至少处理 40,000 笔交易，并可以扩展。

RChain 项目融合了分片技术、Casper 协议、Rho 演算的形式化验证、高并发 RroLang 语言及多虚拟机并行计算等五大创新技术，每一个单独的技术方向都有详细的文档说明，充分显示了团队极高的理论研究、技术实践能力。下表为官方公布的 RChain 与比特币、以太坊多维度对比的情况，整理如下所示：

但需要提醒的是，虽然项目方具有较高的理论功底，但按期实现这样高难度的技术目标不确定性很高。即使技术目标实现，交易性能、稳定性、应用范围是否真的能够达到预期，也很不确定。

技术分析

技术介绍

RChain 架构的主要构成组件如下所示：

RChain 的执行架构可能会依赖一些操作相关的外部组件，但是当运行在 JVM 上时，这些外部因素的影响会被控制到最小的程度。RhoVM 的执行环境运行在 JVM 之上，每一个 RhoVM 实例都拥有自己的执行环境。

1. RhoVM 执行环境：为合约的执行提供了前后信息，以及一个 RhoVM 实例的生命周期。

2. P2P 网络交互层：提供了节点间进行信息交互的机制。具体采用哪种方案需要根据商业级别进行确定，例如采用开源项目 ZeroMQ 或者 RabbitMQ 。

3. 存储 RChain：采用一种 KV 数据库 MongoDB 进行数据的存储，而内存中的数据主要通过前缀树来进行维护。

4. 数据抽象层：实现了对本地节点或者远端节点数据访问的一致性。数据抽象层是 SpecialK 技术演变得来（包括去中心化内容传递，键值数据库，节点间消息传递和数据访问模式）。这一层将使用 RhoLang 进行实现，因此该层将依赖于 RhoVM 执行环境以及 RhoLang 的外部函数接口来实现 P2P 节点信息交互以及本地数据的访问。 

5. 共识（Capser 一种基于权益证明的共识协议）：将确保区块链网络中所有节点状态的一致性。

在 RChain 网络中，所有节点都将包含最基本的使用 RhoLang 开发的系统合约。系统启动过程中将使用这些系统合约来实现 RhoVM 实例的运行、负载均衡、DApp 合约的管理、代币系统、节点信任以及其他一些功能。

Rho-Calculus

RChain 上的形式化验证采用的是 Greg 创立的「Rho-Calculus」来作为理论基础和数学模型。同时 Rho Calculus 也是整个 RChain 的核心理论，RChain 执行模型源自 Rho-calculus 的语法和语义。

Rho-calculus 其实是在 π Calculus（π 演算）的基础之上，进一步扩展和继承了原有的理论并添加了反射。π Calculus（π 演算）是第一个成功建模网络的正式系统，其中节点可以定期加入网络并从网络中退出。它假定细粒度的并发和进程通信，即两个进程可以由第三进程引入。

RhoLang 语言

受 The DAO 事件的影响，RChain 团队决定使用 Scala 语言重写了一种新语言 RhoLang，作为 RChain 上的一种图灵完备的智能合约的语言。与以太坊上的 Solidity 这种弱类型语言不同的是， RhoLang 是种强类型的语言，有更强的边界，一定程度上也更加安全，而他的虚拟机是以 JVM 为基础。但此语言尚处在开发早期阶段，未来是否能够推广开来以及大规模的商用还有诸多不确定性。

Namespace 原理

命名空间依据「if 条件」，将一组合约发送到命名地址，这些命名地址组成了一个命名空间：

1. 一组合约， contract1…contractn 被发送到一组通道(命名空间)，即 address1…addressn。

2. 一个进程并行地监听命名空间 address 中每个通道的输入。

3. 当任一通道上收到一个合约时，它被提供给 if cond.，检查命名空间的源点、发送者的地址、合约的行为、合约的接口以及合约所携带的数据大小。

4. 如果这些性质与命名空间 address 的定义相一致，P 将会被执行，并将 contract 作为它的参数。

   
   

命名的空间定义有效地限制了命名空间中可能发生的交互类型即驻留在命名空间中的合约所调用的状态更改操作都必须经过授权，定义并且对该命名空间是正确的。这种设计使在命名空间上的目录式快速查询非常方便有效。

命名空间可以控制如下行为：

• 接受的地址

• 接受的命名空间

• 接受的行为类型

• 数据大小的最大最小值

• I/O 结构

针对行为类型的检查，主要是为了确保合约所表达的操作串与命名空间的安全规范一致。行为类型检查可以用来评估可用性、边界、有无死锁和资源同步等特性，这些特性最大程度上保证了命名空间中的资源状态变化。因为行为类型意味着操作排序，所以行为类型条件可以指定合约的后置条件，这又可以满足后续命名空间的先决条件。因此，命名空间架构支持事务环境的安全组合，或「链接」在一起。

功能评测

RChain 的全节点（full node）叫做 RNode，并在 2018 年 9 月份会发布测试网，2018 年 12 月份会发布主网。

在白皮书中，可以看到 RVM 是图灵完备、拜占庭容错、可复制的 虚拟机。表现为每个 VM 处理一个智能合约，虚拟机之间可以协同工作，处理分片计算，以达到整体计算的目的。

从 GitHub 的代码提交历史来看，可以看到 Code 提交量是逐步上升的，如下图所示：

RChain 提出了一个新的 Namespace 的概念，每个 Namespace 都可以独立执行一个合约，利用 Namespace 可以和其他的智能合约进行交互。而且每个 Namespace 之间互相独立，互不影响，并且能够互相通信。

RChain 采用 POS 的 Casper 算法，而以太坊的权益证明 Casper 正是由 Greg Meredith 推荐给 Vitalik 。

根据 RChain 的官方路线图显示，在 2018 年 Q2，会实现 RhoLang 的详细说明文档、Casper 共识、阿尔法版本。

RChain 使用的主开发语言是 Scala，Scala 融合了静态类型系统、面向对象、函数式编程等语言特性。Scala 编译器和类型系统非常强大，是图灵完备的同时又是函数式编程语言，函数可以独立存在，可以定义一个函数作为另一个函数的返回值，也可以接受函数作为函数的参数。

这给组合函数带来了很大的便利，最终要的 Scala 会被编译成为 Jvm bytecode，所以 Scala 能无缝集成已有的 Java 类库。用 Scala 可以优雅地编写简洁的代码，同时又能快速进行开发，保证系统性能。可以看出代码模块基本完成。

GitHub 代码质量评测

首先评测 Casper 算法的完成度，它是 PoS（Proof of Stake 基于权益证明算法）的一种代称，共识协议架构基本完成。

目前，在核心的 Casper 文件中 Casper 所使用的 Multi Parent Casper Instances 已经完成。

全节点的 node 只完成了 runtime 部分，相应的智能合约编译及安全检查部分还未实现。

可以看到 RhoLang 的最核心的编译器已经基本完成。

标准共识分析：

RChain 创造性的设计了智能合约：通过 RhoVM 并行运算，编译器验证，快速且安全。

并且专门设计的 RhoLang 语言，是一种强类型语言，RhoLang 代表反射性的，基于进程演算，高阶的过程语言，作为 RChain 的智能合约语言。RhoLang 允许进程的并行执行和在不同智能合约基础上组合高阶智能合约。

根据 RChain 给出的开发路线图来看，2018 年 9 月份会发布测试网，2018 年 12 月份会发布主网。

虽然整体工程量比较庞大，从代码本身来看，属于遵守开发规范的正式团队的产品。代码质量比较高。

贡献者参与度、代码的更新频率、代码的查看与评论频率都属于较好水平，并没有出现延误的情况。软件工程的管理能力较强。但需要注意的是，RChain 的所有技术创新点尚处于探索状态，不确定风险很高。

对照官方的开发路线图和当前进展，虽然 RChain 面临很多技术难点，但当前进展还是基本符合开发路线图。

项目 2018 年 9 月份将发布测试网，技术难点的实现程度届时可以进一步验证。

Token 生态系统

RChain 目前发售的 RHOC 代币是通过 ERC20 发行的，RChain 主网上线后，持有的 RHOC 可以 1:1 比例兑换成 REV 代币，REV 是 RChain 平台上的原生经济代币。

1. RChain 初始生成总发行量： 1,000,000,000 RHOC ，销毁：129,336,426 RHOC，当前最大供给量： 870,663,574 RHOC。

2. RChain 官网公布了 RHOC 与 REV 兑换时间，兑换时间在主网上线后，具体方式（https://developer.rchain.coop/token-swap）。

   
   

注：

1. 根据 coinmarketcap 流通量数据，当前流通量：360,847,707 RHOC=私募+Pithia+Bounty+其他。

2.  RChain 合作社对锁仓直到平台上线议案，提出了销毁，锁仓等解决方案，销毁代币方案获得的投票数最高。

代币 Token 主要用途

REV 的用途包括：

1. 用户需要使用 REV，才能使用 RChain 网络。

2. REV 用于补偿节点运营商，以换取计算，存储和带宽资源。

3. REV 是共识协议中的权益货币（staking currency）。

4. 持有 REV 是成为 RChain 网络节点的必要条件（required for validator bonding）。

   
   

共识机制

Casper CBC（Correct-by-Construction）是 RChain 选择实现的 PoS 协议，CBC 作为一个共识框架，框架内的派生协议保证共识安全性。

1. Casper 项目有两个分支，分别为：Casper the Friendly Finality Gadget（FFG）、Casper the Friendly GHOST: Correct-by-Construction（CBC）。

2. Casper FFG：是一个混合 PoW/PoS 共识机制，一个权益证明协议被叠加在正常的工作量证明协议上。区块仍通过工作量证明来挖出，每 50 个区块就将有一个权益证明检查点，也就是网络中验证者评估确定性（Finality）的地方。Casper FFG 是 PoW 过渡到 PoS 的缓冲方案。

3. Casper CBC：提出了一个框架并证明了在拜占庭容错度内，估值安全(estimate safety) 保证共识安全(consensus safety)，在这个框架下派生(derive)了一系列的协议包括：

Casper the Friendly Binary Consensus Protocol: 二元共识

Casper the Friendly Ordinal Consensus Protocol: 基数共识

Casper the Friendly List Ordering Protocol: 有序列表共识

Casper the Friendly GHOST Protocol: GHOST共识

Casper the Friendly Concurrent Schedule Replication Protocol: 并行计划共识

Casper the Friendly Sharded Blockchain Protocol: 分区区块链共识

4. 其中 GHOST 共识是分支选择规则，GHOST 告诉「验证者」如何根据他们目前收到的信息来决定继续挖矿的分支，即从消息状态树(DAG 结构)中筛选出那条能够达成共识的子树 （GHOST 即 DAG 链）：

1）同一个命名空间内的「验证者」相互知悉，在消息树的状态中，每个验证者都有一个权重值，权重值与赌注成正比。

2）新区块选择父级区块时，验证者会依据以下两个规则选择：

• 首先，最新消息(latest message)的分数等于对应验证者的权重。

• 其次，只上而下地，每个区块的分数等于使用此区块作为父区块分数的和，如下图所示：

3）权重选择父级区块，如下图：

4）当两个区块验证信息出现冲突时，验证者选择分数较高的区块，作为挖矿分支。

5）当命名空间出现三个矿工时，选择不同的父级区块，形成了 DAG 链，如下图：

Casper CBC 协议如何解决其他 PoS 权益中的问题：

1. 在 CBC 框架协议下，如果某个「验证者」加入「验证组」后处理过慢或者出现了其它不能满足要求的行为，其它「验证者」通过 Casper 协议可以将其从「验证组」中踢出去。

2. 「验证者」押下一定比例保证金后才能验证区块，「验证者」通过押下赌注来验证区块，该区块被添加到 DAG 链上后，「验证者」将获得跟赌注成一定比例的奖励。

3. 在 Casper CBC 中不存在「无利害关系」，如果以一种恶意的，或者说是拜占庭叛徒式的方式行动，就会立即受到惩罚、失去保证金。

下图为 RChain Casper CBC （Correct-by-Construction） 共识机制模型：

标准共识分析：

Casper FFG 共识协议是 Casper CBC 共识协议的妥协版，Casper FFG  是解决 PoW 过渡到 PoW/PoS 的方案，RChain 直接采用 Casper CBC 共识协议实现 PoS 协议，相对以太坊过渡成本、迁移成本，RChain 的开发成本更低，有利于更快的大规模落地。

1. Casper 共识协议的几个方面使得参与者达成共识，包括以利益为基础的绑定，解绑定和周期性下注。

2. 分布式共识协议的目的是为了确保横跨多个节点的区块链或部分区块链（基于命名空间）的一致性。

3. 在错误频发的网络条件下，为了实现这一点，任何共识协议都应该产生一个确定的结果，并且证明协议的安全性和终止属性。Casper CBC 框架协议解决了这一问题。

4. RChain 的元组空间设计，实现了并行运算，提高了达成共识的效率及稳定性。

5. 就 Casper CBC协议，官方公布了详细的说明文档，见网址：http://architecture-docs.readthedocs.io/execution_model/consensus_protocol.html。

社群基础

用户社区

RChain 社区用户成员数量相较一般，但多数社区内互动频率很高，且在中国地区更为活跃（Google 趋势反应出中国地区指数趋近于其他地区总和），RChain 爱好者中国社区（www.rchain.site）成为活跃度主力贡献者。RChain 中文爱好者社区，主要沟通渠道为 QQ（492114454）。

Google 趋势

根据 Google 趋势，目前搜索「RChain」的热度较高的地区为中国，且热度与其他地区呈显著性差异，其他地区依次为斯洛文尼亚、克罗地亚、新加坡、澳大利亚。

下图为 Google 趋势截图：

开发者社群

官方的 GitHub 主页有 24 个库，主要的库是 rchain ，该库有 85 个 Watch、368 个 Star、105 个 Fork、4,488 个 Commits、21 个 Branches、9 个 Releases、36 个 Contributors。

下图为 RChain GitHub 主页：

标准共识分析：

代码提交活跃，在 7 月 13 日 CryptoMiso 3 个月指数代码提交次数中排名第 5，一共 1,126 个 Commits。

开发者社群关注度较高，Watch 数量一般，Fork 和 Star 的数量较多；

主力开发者数量较高，提交 Commits 数量超过 50 的有 18 位。