为什么Rchain声称能够支持facebook及visa级别的应用?

RChain走的路线和其它任何一个项目都不同。这种差异是从计算机基础理论上就存在了。

首先，RChain的RhoVM虚拟机虚拟出基于Rho演算的RhoMachine。RhoMachine和冯诺依曼类型计算机完全不同，冯诺依曼计算机是CPU+RAM的指令式计算机。而RhoMachine的运算和状态都是基于Tuplespace，最大的特点就是可组合性--RhoMachine可以和RhoMachine叠加，组成新的RhoMachine，而这对于跑在RhoVM上的rholang代码是透明的。关于可组合性原理可以读读我这两篇文章的解释：

隔壁老王粑粑：RChain原理浅析[1]-初识Rholang​zhuanlan.zhihu.com隔壁老王粑粑：RChain原理浅析[2]-元组空间​zhuanlan.zhihu.comTuplespace的可组合性解决了一个大难题，就是可扩展性难题。由冯诺依曼计算机组成集群的话，对于代码来说每台计算机的边界都不是透明的。当其它链还在为状态分片、分片间状态同步等问题头疼的时候，RChain凭借Rho演算早已经跨过了这道坎。如果tuplespace彼此之间相互信任的话，分区间的交互通过name的消息机制完成，故事就到此结束了。

注意上文中“如果”两个字，在区块链环境中是肯定不能随随便便相互信任，所以接下来rchain设计了名字空间机制来解决tuplespace彼此间的信任关系。这又和其它链有很大的区别，其它链都是绞尽脑汁地建立节点间的信任关系，rchain却只需要合理地组织tuplespace。所以rchain设计了名字空间（namespace）,一个名字空间对应一个tuplespace，然后用rholang代码导出合约接口只允许其它相关名字空间和本名字空间交互。rchain这部分的实现代码都是rholang写的，在RhoMachine的基础上去解决，容易很多。具体可以读下文：

隔壁老王粑粑：RChain原理浅析[3]-名字空间​zhuanlan.zhihu.com解决了名字空间相互信任的问题，再回过头来看名字空间内部。同一个tuplespace由N个节点维护，首先这保证了高可用性。而Rho演算的并行性特点又允许这N个节点对tuplespace同时进行运算修改，保障了单个名字空间的吞吐率。具体请看下文：

隔壁老王粑粑：RChain原理浅析[4]-区块结构与DAG​zhuanlan.zhihu.com最后，解决名字空间內这N个节点对tuplespace运算修改的可信问题，使用了casper共识。使tuplespace运算的结果来自于N个节点的共识结果。具体请看下面三文：

隔壁老王粑粑：RChain原理浅析[5]-Casper共识之估值函数​zhuanlan.zhihu.com隔壁老王粑粑：RChain原理浅析[6]-Casper共识之安全证明​zhuanlan.zhihu.com隔壁老王粑粑：RChain原理浅析[7]-Casper共识之预言机​zhuanlan.zhihu.comRChain通过Rho演算一环接一环来解决区块链的可扩展性问题，姑且不论RChain在其它方便的微创新（比如形式化验证），单就采用全新的计算机理论这点上，它的意义不是其它项目可以同日而语的。

不管rchain最终能否普及，它都会成为一个里程碑，因为我们现在应用的计算机理论已经太多年没有改变了。

回到问题上，RChain的原话是“To become a blockchain solution with industrial-scale utility, RChain must provide content delivery at the scale of Facebook and support transactions at the speed of Visa.”

所说的VISA的速度和FB的规模是它的目标。通过namespace内部高度并行化的处理保证吞吐率，从而能够满足VISA那样对吞吐率要求很高的应用。同时名字空间可以无限扩展，也就能满足Facebook那种扩展性有极致要求的应用。