作者：莫给机狂

起草这篇文章的缘起是有一天，我在Discord上收到了Darryl的一个请求，让我跟他解释一下发生2016年的一个技术讨论视频，在那次讨论中RChain的创始人Greg，以太坊的创始人Vitalik和Casper协议的创始人Vlad讨论了以太坊的扩容路线。

RChain社区的音乐制作人Darryl是个很有色彩的人，他不但坐拥几项格莱美奖的提名，同时对区块链技术保持着“学而时习之，不亦乐乎”，对中国区的宣传工作也甚是支持（岔个题，据未经证实的小道消息，高晓松也是Greg的朋友，曾经有过意向要和Greg合作在RChain平台上发歌）。所以对这个请求我自然是不会拒绝。 当然还有个更重要的一点就是，“以太不纳Rho演算，RChain由此自称雄”的说法，在社区里由来已久，但我毕竟不是当事人，所以翻出当年的讨论视频，对照一下这几年的公链发展复盘一下，还是很有意义的。

看完以后，发现Greg在这次讨论中就已经完全呈现了RChain的主要思想，没有对以太社区有任何保留。而V神确实也被向后兼容性束缚了手脚，并且2016年的V神对计算理论的理解还没那么深刻。但我不解的是，从2016年到2021年，整整5年币圈牛熊交替了两个轮回，然而公链圈里G神的思路还是没有被足够多的人重视，各路人马都在孜孜不倦地造各种以太坊的变种，跳不出各种“排队”的怪圈。 而按照G神的思路搭建的项目RChain仍是“养在深闺无人知”的状态，确实也是一个遗憾。

所以我和光之十一决定为这个视频制作中英双语字幕发布。一方面让大家知道一下RChain这个项目的历史渊源，另一方面也是给整个公链圈做个参考，为新公链的设计加入新的思路。

整个视频分为两部分，G神主导了前半部分的关于扩容部分的讨论，后半部分是Casper协议的一些设计细节，如果没兴趣可以跳过。我总结了一下，Greg提出了几个关键点，涉及的谈话部分摘录如下：

关键点1. 基于合约隔离 + 静态析上的并发共识

Greg: 我认为，因为我们控制名字空间——本质上是地址空间，这些地址空间应该足够做到使用静态分析来推断出合约间的（资源）隔离。 你可以说是否本质上是两个命题对应了两个不同的合约，调用两个不同合约的交易可以执行还是不可以执行。

Vlad: 它基本上是在帮助共识收敛，因为你可以在两个不同的集合上收敛共识。

Vlad: 但如果用户给了（地址限制），也许我们给他们个Gas费的折扣。

Vitalik: 总的来说，对以太坊2.0有一件事我是不会妥协的。那就是以太坊1.0里一切允许的，在以太坊2.0里应该继续允许。

关键点2. 基于Pi演算的并发虚拟机

Vlad: 我觉得执行肯定会在分片上，任何扩展的解决方案都需要并发执行。问题是EVM的内核是否需要基于Pi演算？我认为这个问题仍然存在。

Greg: 它不一定要基于Pi演算，而Pi微积分恰好是这类的最佳并发演算。

关键点3. 类型系统和形式验证

Vlad: 我确信，要求合约提供类型的另一个缺点是它增加了合约开发人员的负担。

Greg: 除非你有某种类型推断。

Vlad: 我认为我们并没有达成共识，即我们将使用一个虚拟机，它被设计来让合约在并发环境中很容易地进行形式化验证。对我来说，我们需要有这个选项，这点似乎是显而易见的。我希望关键任务的应用程序被部署到区块链中，我希望它足够安全。而形式验证似乎是唯一真正能做到这一点的方法。

Greg: 是的，你从来不需要类型化的执行，你总是可以给类型化的东西做一个非类型化版本。只是随着时间的推移，这样做的代价要大得多。

Vlad: 问题就是正如你所知，形式验证需要更高昂的理解和劳动成本。但你知道我觉得这很值得。

看到这里大家可能会很好奇，基本都是Greg和Vlad的谈话，但以太坊创始人Vitalik并没有参与太多。对的。从这个会议视频中可以看出，至少在16年，这三巨头的特长在于：Greg——计算理论； Vlad——协议设计； Vitalik——经济激励机制。

所以在讨论扩容路线时，Greg和Vlad是谈话的主人公， 而V神只是在一再坚持向后兼容ETH 1.0的重要性。 当然，士别三日当刮目相看，何况是区块链这种知识飞速更新的领域，现在就可能要另说了。

图1. RChain以外所有的公链，都需要把交易排队处理

图2. 从“需要排队”依次执行进化到RChain的“不需要排队”，正是公链扩容关键点

接下来简单解释一下以上几个关键点。

关键点1. 基于合约隔离 + 静态分析上的并发共识

这实际上就是RChain并发+分片的理论基础。 区块链做的就给交易做出共识。讲到底，你是把交易排成一条队进行共识呢？还是把它们按照一定逻辑分开进行并发共识？  

比如你在上海街头买烤串，我在纽约星巴克买咖啡，这两个交易显然不应该排队去共识，而是可以同时做。买烤串的共识和买咖啡的共识可以同时进行，无论底层用的是什么共识协议。 这个反应到区块链的行为上，就是“并发出块、并发投票、并发确认”。

而怎么才能判断两个交易能同时做呢？G神已经给出了答案：

首先，交易要根据一定规则作隔离， 比如根据名字/地址空间。在上述例子中，“上海街头”，“纽约星巴克”就是这个地址空间，你在上海街头买烤串的交易，是无论如何不会影响到纽约的星巴克的。这就是隔离。隔离开的两个交易，不但可以同时做，也可以分配到不同分片去做。

其次，交易要能够静态分析。所谓静态分析，就是一个交易在提交到区块链之前，就能分析出它访问的资源是什么，两个交易之间有没有冲突，等等。对应上述例子中，就是一个交易在提交前，编译期你就知道它只会去访问“上海街头”的资源，而绝不会跑出这个范围。只有这样，才能知道哪些交易可以同时交给区块链去共识，而不用排出先后次序。

在我的区块链和传统电脑系统的对应关系表中，区块链的共识层=传统电脑的IO层。有了关键点1的能力，相当于在IO层实现了并发，从以太坊的磁带存储器升级到了RChain的SSD。

关键点2. 基于Pi演算的并发虚拟机

关键点1既然是“并发共识”，而关键点2，就是“并发执行”了。为了能无限扩容，区块链必须没有单线程瓶颈，而底层的EVM，WASM之类的基于状态机的虚拟机，正是这个单线程瓶颈。 一个验证者同时收到了很多合约，它必须有并发执行他们的能力，才能真正实现“不用排队”，否则，相当于门外不用排队，进了门还要排队。

回到我的区块链和传统电脑系统的话题中，有了关键点2的能力，相当于在计算层实现了并发。1&2配合，计算、IO都实现了并发，区块链电脑才真正可以服务于几十亿人了。

关键点3. 类型系统和形式验证

当1、2都实现了，区块链可以并发出块、执行了，是不是万事大吉了呢？G神和Vlad对此非常一致：不行，并发下的形式验证必不可少。并且，最理想的途径是用类型推断来做形式验证，而不是推给客户做。而且，最终选择就是虚拟机要支持“类型化的执行”，这长远来说，代价比“非类型的执行”要低得多。“类型化的执行”相当于防火墙。合约在防火墙保护下执行、相互调用，安全性才会有保证，才能真正的把无数的合约编织成一张合约之网，形成无与伦比的网络效应。否则各种竞态、死锁问题，将会让DApps的开发人员们和用户一次次地被迫躺平。

那么，我们回顾一下，2021年的今天，上诉3个关键点上，RChain完成了多少呢？

首先，RChain上主网的时候早就实现了关键点2：并发虚拟机；现在，块合并正在RChain的测试网上运行，关键点1：并发共识，也快到了瓜熟蒂落的时候；最后，Greg的OSLF的论文，为关键点3做了关键的理论准备，等待近月内外部节点开放之后，就该向金星启航了。

反观继续走了状态机路线的以太坊，又有多少进步呢？

图3. ETH 2.0多条不能协作的排队方式绝非解决之道

Layer 2有了长足的发展，尤其是Roll up, 然而，因为Layer 2还只是“出门去排队”，队和队之间没有互操作性。ETH 2.0进展缓慢，但市场上各种分片项目，已经预示了ETH 2.0的未来了，就是“在门里面排很多条队”，队和队之间没有互操作性。无论哪个，都是不完整，甚至可以说是虚假的扩容。离开了计算理论的基础，五年的扩容之梦，到头来追逐的不过是海市蜃楼而已。即使英雄如V神，也没意识到“不可能三角”的破壁之道，正是2016年那次讨论中G神提出的“不用排队”的三板斧。

嗟乎，原不过：五年以太扩容梦，破壁原是枕边人！

2021年6月17日于新泽西