五年以太扩容梦 破壁原是枕边人——记2016年G神与V神的ETH 2.0路线之争

rchain

作者:莫给机狂

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

视频地址:https://www.bilibili.com/video/BV12K4y1M7PN/

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的重要性。 当然,士别三日当刮目相看,何况是区块链这种知识飞速更新的领域,现在就可能要另说了。

rchain

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

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做了关键的理论准备,等待近月内外部节点开放之后,就该向金星启航了。

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

rchain

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

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

嗟乎,原不过:五年以太扩容梦,破壁原是枕边人!

2021年6月17日于新泽西