号称能够满足区块链扩展性要求的区块链3.0们，没有一百也有八十。这其中除开大部分的空气项目，真正有创新有作为的候选者，在笔者看来屈指可数。它们大都通过分片或者Layer 2的方案在传统的冯诺依曼体系架构下修修补补，不能说这样的选择有错。其实可扩展性难题来自于区块链之外，而在这些区块链3.0项目中，有一个却意义非凡 – RChain尝试从最根本的层次上解决可扩展性难题。
可扩展性难题的根源在哪？
尽管编程语言越来越多, 但它们都走进了同一个死胡同 – “λ演算” 。-- 包括C++、C#、Java、Scala、Haskell、Python、Erlang、Golang等等，基本上只要你能叫出名字的编程语言，都源于“λ演算” 。

λ演算(Lambda-Calculus)可以被视为最基本的编程语言。它最早是由Alonzo Church(图灵的博导)在20世纪30年代引入，之后的Church–Turing thesis证明了λ演算与图灵机是等价的。随后的50年代，以随机存储器为特征、通过纸带输入的冯诺依曼计算机的面世，λ演算有了用武之地。在输入指令的时候，为了避免重复劳动复用某个功能，将这个功能的指令打包成一条纸带。每当需要用到这个功能时就输入这条纸带，这条纸带就可以视为λ演算中的函数(function)，它将一组指令打包后允许重复地调用。即使发展到今天，虽没有了纸带，但本质上并没有任何改变 – 基于“λ演算”的语言的特征就是对函数调用的聚集。
λ演算和冯诺依曼计算机相辅相成，奠定了当今信息时代的辉煌成就。但是单一计算节点总是存在容量瓶颈，为了提高系统的整体容量，必须让多台计算机组成一个整体协同工作。
而可扩展性难题的根源就在于目前主流的冯诺依曼体系架构，因为它是不可组合的; 计算机与计算机之间的边界对于λ演算并不是透明的。
即，两台冯诺依曼计算机加在一起还是两台独立的计算机。这种隔阂对于程序来说是不可忽视的，也就导致了前文中提到的难题。
根本性的解决之道
既然根源在于缺乏可组合性(Compositionality)，那么根本性的解决之道呼之欲出。
λ演算从上世纪创立后并没有停止发展，在它的基础上逐渐发展出了以Rho演算(Rho-Calculus)和ϕ演算(Phi-Calculus)为代表的高阶演算(Higher Order Calculus)。其中Rho演算最为接近实用，它已经被成功地应用到了微软BizTalk服务中。从Rho演算衍生出的Rholang编程语言以及RhoVM虚拟机已经发布了0.6版本。

RhoVM虚拟出基于Rho演算的计算机–RhoMachine，而Rholang就运行在RhoMachine中。RhoVM虽然运行于冯诺依曼计算机之上，却和冯诺依曼计算机有本质的区别–它虚拟出的RhoMachine是可组合的！

多台RhoMachine可以组成一台RhoMachine，这对于Rholang程序来说是完全透明的。从程序的视角来看，只有一台RhoMachine，这台RhoMachine可能由多台RhoMachine组成，但是程序并不关心，这样RhoMachine的总体容量不再受限于单个物理节点，同时程序在设计和运维上也不需要为特定场景针对性地制定方案。
想知道Rho演算为什么具有可组合性？最直观的方式是从Rholang切入理解它的工作方式。《初始Rholang》和《元组空间》这两篇文章从原理上解释了可组合性的缘由。
Rholang设计为一种通用的编程语言，而RChain区块链项目只是它实践的第一个项目–搭建一台可以无限扩展的超级计算机。因此可以说Rho演算的征途是星辰大海，它的愿景是一劳永逸地从根本上解决冯诺依曼体系带来的弊端。
后·冯诺依曼
后·冯诺依曼时代已经悄悄来临，这是一片荒芜之地，也是一片可以大展拳脚的“蓝海”。可扩展性难题只是冯诺依曼计算机被诟病的众多缺点之一。Rho演算带来的不仅仅是可组合性一个特性，它还有其它许多方面的优势。

RChain通过Rho演算的无限扩展能力解决区块链的瓶颈，通过特有的名字空间技术实现状态分片，集Casper TFG(CBC)共识、形式化验证等诸多亮点，极有可能成为后·冯诺依曼时代的开创者。