原文标题:《观点 | 以太坊的路线图应该改变吗?》
撰文:阿剑
自 《A Rollup-centric ethereum roadmap》(中文译本)一文发表以来,整个社区都对以太坊(尤其是以太坊 2.0)的路线图产生了疑问。
2020 年 11 月 18 日,在以太坊基金会的 Eth2.0 研究团队的第五次 AMA 活动(中文节选译本)中,Vitalik 明白地表示,路线图已经发生了变化:(1)暂时不再强调 Phase2 的重要性,Phase 1 致力于实现数据分片(shard data),供 Rollup 方式使用;(2)信标链将具备执行功能,即 Eth1-Eth2 合并之后,信标链区块将直接包含交易;(3) Phase 0 实现后的三大工作:轻客户端支持、数据分片、合并,将并行推进,任一模块只要准备好了就推出。
本文的目的不是为原来的三阶段路线图辩护。相反,本文是想主张,三阶段路线图虚无缥缈,新路线图食之无味,没有一种与 Eth2.0 相关的路线图值得以太坊放弃当前的运作模式、转向以 PoS 为基础的系统。
在这里,我会先讲解初始的三阶段路线图的论证思路及其技术难点;然后分析新路线图的可扩展性。最后论证,新路线图的可扩展性优势,已经渺小到不足以使以太坊冒险转入 PoS。
在过去两年,广为流传的 Eth2.0 路线图规划了三个依次序实现的组件:
Phase 0:以 PoS 为共识机制的信标链
Phase 1:多条分片链
Phase 2:为所有分片增加执行功能
从这一路线图可以清晰地看出,原来的以太坊 2.0 的目标是打造一个 「分片化执行(sharded execution)」 的系统,意思是:每个分片都有自己的状态,这些状态按各分片的状态转换规则来变更;变更后的状态由信标链来敲定;由此,以太坊 2.0 就成了一个多个分片可以并行处理交易的系统。这也意味着,以太坊 2.0 是一个 「共识」 和 「交易处理(验证)」 解耦的系统,被分配到各分片上的验证者负责验证交易和状态的正确性;但这些状态的敲定则依赖于信标链的 epoch 敲定机制,两个过程并不是完全同步的。
这种 「PoS 信标链 + 多分片」 的架构,似乎也非常好地利用了 PoS 算法本身的特点:为了解决 No-thing-at-stake 问题(PoS 出块不需要付出计算量,因此有资格出块的账户会尝试在不同的分叉上同时出块,使系统分崩离析),以太坊 2.0 所用的 Casper 算法要求用户先存入一部分押金才能获得出块资格,而如果验证者滥用了出块资格(比如同时支持两个分叉),则会被罚没押金;由此,像 Casper 这样的算法实际上在区块链上创造了两种可以相互沟通、但相互独立变更的状态:一种是普通用户的状态,另一种是验证者的出块权重状态;共识过程以出块权重状态为基础,达成共识也会更改出块权重状态;因此,共识过程先天独立于用户交易的验证,可以解耦;对任意的交易批次及结果状态而言,共识过程可以被抽象成一种 「终局性敲定机制」,逻辑上,多分片并行执行于是成为可能。
至于其可扩展性,以太坊分片技术的命名 「二次方分片(Quadratic sharding)」 透露了端倪:假设分片上的交易,其执行复杂性能够被化约到与区块头验证同样的难度,则分片化执行的架构,可以使整个系统的处理能力,随着参与节点处理能力的线性提高而呈平方级提高。通俗来说,如果参与网络的节点(平均而言)在一段时间内能验证 4 个区块头,这就意味着,在参与一个分片时,节点们可以在同等时间内验证 4 笔交易,此时系统总处理量是 4 条分片 × 4 笔交易 / 分片 = 16 笔交易;如果节点的处理能力变成了 8 (2 倍),则处理量会变成 64 笔交易(4 倍)。
听起来很美好,但是,这个「平方级扩展」 的论证中包含了如下假设:
(1)存在一种技术,使得分片交易的验证,可以简化到与验证区块头同样的难度;
(2)不存在跨分片的交易,即各分片内的交易是完全不会相互依赖的。跨分片的交易需要占用多个分片的处理容量,也要占据信标链的处理容量,会使可扩展性大打折扣。
关于(1),这个假设是有可能得到满足的,无状态性(statelessness)就是这样的一种技术,它的思路是,在传播交易(或者传播区块时),附带交易所访问状态的证明(witness),使得交易的验证者无需持有交易执行之时的状态数据,就能验证交易的有效性。这一点极为关键,如果没有无状态性,参与分片验证的验证者就必须保存分片的状态,因为验证者会被不断分配到不同的分片链上,那就意味着他们必须保存所有分片的状态,在实践中也就意味着他们要不断下载所有分片的区块并处理交易,从而使整个系统坍缩为一个大区块系统(例:投入能处理 16 笔交易的资源,处理 16 笔交易)。遗憾的是,至今,以太坊 1.0 也没有研究出足够轻量的无状态方法。
关于(2),那就没有什么好说的了。如果不能实现跨分片交易,分片化执行的系统就没什么意义,因为各分片各自为政。必须使得 ETH 有办法存在于各个分片上,这个系统才能仍然以 ETH 为主体。而直到今天为止,还没有出现一种跨分片交易方案,能够不增加信标链的处理量。道理也很简单,对于任意 A 分片来说,因为并行处理,任意 B 分片上正在发生什么交易,需不需要改写本分片的状态,是不可知的,因此必须存在一个通信层,可信地证明 B 分片上发生了一笔试图改写 A 分片状态的交易。而一旦需要让信标链具备处理交易的功能,平方级扩展的效果就会被打破。(顺带说一句,满足了这一可信通信层的需要的链,就变成了事实上的 Layer-1,而其它分片则变成了事实上的 Layer-2,像极了 「Layer-1 + Layer-2」。)
除了存疑的可扩展性,分片化执行还带来了许多经济上的有趣问题。例如,如果跨分片交易的处理时间超过一笔分片内交易的处理时间(这是必然的),这就意味着,不同分片上的 ETH 价值也不会相同。就好像美国国内的 1 美元,与美国国外的 1 美元,实际上并不是同一种东西。不论有多少个分片,都至少会有两种 ETH 价格,一种,是那个金融应用最繁茂的分片(也就是 Eth1 分片)上的 ETH 的价格;另一种是其它分片上的 ETH 的价格;后者必须支付一定的手续费并付出一定的时间,才能换成前者,因此对前者必定有一些折价。同理,即使每个分片上都有 uniswap,不同分片上市场的交易滑点也必定不相同,最终大家都会汇集到一个分片上,因为大家都在一起的时候,流动性最充沛,资金效率最高。某种程度上,可以认为跨分片交易的需要是很少的 —— 但这也意味着,其它分片上闲置的交易处理容量,也根本没有意义。
分片化执行系统的技术难点,此处不再赘述,感兴趣者可以自己想想分片化执行系统怎么支付手续费的问题。但我在这里想说的是,分片化执行系统的设计理念违背了大家的实际需要,也违背了事物的发展规律。全局状态(可组合性),并不是一个问题,而正是大家需要的东西;正是因为以太坊使得所有金融应用都能瞬间组合,创造了一个价值可以零摩擦流通的空间,以太坊才有了变革世界的潜力;在协议层为价值流通创造摩擦,是自废武功。有了一个良好的基础层时候,应该想办法维护这个基础层,剩下的事情让用户自己选择,让生态自己演化 —— 不要以为设计能设计出一个生态,过度设计只是给所有人强加成本。
分片化执行(Phase 2)的搁置,侧面印证了其中的难度 —— 在可预见的未来,这条道路无法产生令我们满意的成果。尽管如此,我并不认为 Eth2.0 的研究员们已经完全放弃了三阶段路线图,Vitalik 也还强调,变更后的路线图,跟 Phase 2 也是完全兼容的,只是 Phase 2 不再具有优先级。
但是实际上,放弃分片化执行,才是以太坊应该选择的道路。
在以太坊 2.0 的新路线图中,最令人瞩目的一点是:信标链区块将包含合并后的 Eth1 分片的交易,也即信标链具备了执行功能。其它分片仅具有保存数据的功能。
实际上,新路线图中 「数据分片」 的定位是 「供 Rollup 使用的数据可得性(data availability)层」。
没了执行化分片,平方级扩展就无从谈起了。那么,这种 「PoS Layer-1 + Rollup + Rollup 数据不占据主链区块空间」 架构的可扩展性如何呢?
要解答这个问题,我们先来看看 Rollup 方案与主链的交互模式。
首先,你可以把一个 Rollup 系统理解为一个无状态的合约,这个合约的内部状态(哪个用户有多少钱),对外是不可见的;但是,该合约内发生的所有交易,其数据会定期公开出来,发布到主链上,使得任一第三方,得到这些数据后,都可以重建出该合约的内部状态。
使用有效性证明的 Rollup (例如 ZK Rollup)的特点是:该合约每次公开交易数据时,都附带一个这些交易已被正确执行、因此新的状态根应是 XXX 的 「计算完整性证明」;如果该证明能通过合约的验证,则该合约更新状态根;如果该证明不能通过验证,则该合约拒绝更新。
使用错误性证明的 Rollup (例如 Optimistic Rollup)的方案则相反:任一人每次为合约公开交易数据时,都必须存入一笔押金,并断言合约的新状态根是 YYY;此后一段时间内,任意其他人都能存入押金、发出错误性证明来挑战该断言;错误性证明即证明该批交易有瑕疵,或者交易处理后的新状态根不是 YYY;如果挑战成功,则发布错误断言的人会损失押金;如果一段时间内无人挑战,则合约更新状态根为 YYY。
这两种方案,都必须在链上发布数据,因此会占用链上空间;而且,链上空间的大小,决定了 Rollup 系统在单位时间内的处理量(即 TPS)。想得更深一些,如果这些交易数据,能够发布在一个数据量的约束更小的地方,或者说,不去占用 Layer-1 区块的空间,则其处理量,能产生倍加的效果。如果这样的地方有很多,那还可以产生倍乘的效果。
这就是 「数据分片」 及 「以 Rollup 为中心的路线图」 的理念:让 Rollup 方案把交易数据都放到分片区块中,分片有多少个,处理量就能提升多少倍;当前的以太坊区块数据量大概是 20~30 KB,这个数据量显然是安全的,则,如果我们有 64 条分片,我们每 15 秒就能提供 64*30 = 1920 KB = 1.9 MB 的数据量。而且,使用端我提供了这么大的数据吞吐量,但它不会成为全节点的负担,因为这些数据你想下载就下载,不想下载就可以不下载(也就是 「分片」 的含义),大家你下载一点,我下载一点,节点的负担还是很轻的 —— 反正,验证这些 Rollup 合约的状态,并不要求我拥有该 Rollup 的所有历史交易数据。以太坊的状态仍然是安全的。
听起来很合理,但还是那句话,太乐观了,太多假设了:
(1)这种 「想下载就下载,不想下载就不下载」 的方法,在 ZK Rollup 上根本行不通:当 ZK Rollup 要更新状态根时,ZK Rollup 合约更新操作的验证者(也即 Layer-1 的全节点)在接受证明时也必须获得与该证明对应的交易数据,否则就无法通过验证。(不需要提供交易数据,仅验证证明就推进合约状态根的方案也有,叫 Validium,那不是 Rollup)。也就是说,如果仅考虑 ZK Rollup,那么 「数据分片」 的方法,从带宽上来说,与大区块没有任何分别。不管这些数据一开始被发到了谁手上、存到了哪里,全节点都要下载它们。
(2)对 Optimistic Rollup 来说,如果你愿意采取更乐观一点的假设,当然可以,你可以平时完全不下载交易数据,仅保留获得终局性的最新状态根,仅在发生争议时,再下载相关的交易数据,从全节点的角度看,并没有因此丧失对合约状态的验证能力;但是从用户的角度看,事情就完全不同了:你开始不确定自己到底是不是随时能够重构自己的状态,来完成取款。也就是说,用户将不能确定自己用的到底是 Optimistic Rollup,还是 plasma。本来,Optimistic Rollup 的方案就是保证了所有全节点都有历史交易的备份,所以用户可以容易地重建自己的状态,并提交状态证明(或断言)完成取款;但如果这一点保证失去了,你就不确定自己能不能重建状态了。Optimistic Rollup 的安全性也会受到影响:它的安全假设是,获得了交易数据的人之中至少有 1 个是遵守协议的;在数据分片模式下,你并不知道,有多少人会去请求这部分交易数据。
总而言之,「数据分片」模式搭配 ZK Rollup 时,在带宽的意义上,无法提供更大的可扩展性,而与扩大区块空间的效果相同;在搭配 Optimistic Rollup 时,相对于大区块,其可扩展性优势与挑战发生的频率成反比;更严重的是,它使 Optimistic Rollup 有退化为 plasma 的风险(从定义上来说,也不存在 Optimistic Rollup 了,应该用另一个名字来指称这种介于 Optimistic Rollup 和 plasma 之间的东西)。
Rollup 方案其实是从 Layer-2 发展过程中吸取了血淋淋的教训而飞出来的凤凰。它最大的特点在于,给用户的资金安全提供了充分的保护。因为任意得到了交易数据的人都可以重建状态,而区块链保证了这些交易数据的永续数据可得性,Rollup 方案得以提供 layer-2 方案中首屈一指的用户保护。只有这样的方案,用户才敢真的去使用。舍弃了这种好处,按最大化性能的乐观假设来设计系统,只能设计出用户不敢去用的东西。
只要你意识到,Rollup 本质上是一种合约的设计模式,「PoS + 数据分片 + Rollup 可以提供更大吞吐量」 的迷思便可一眼洞穿 —— Rollup 不管在哪个共识中,都可以提供同样的可扩展性,数据分片能提供更多,只是因为引入了别的安全假设,使 Rollup 牺牲安全性来换取吞吐量而已 —— 问题在于,这样的合约,比 Rollup 的安全性更弱、可扩展性更强的合约,不是没出现过,不是在 pow 链上就设计不出来,而是设计出来了也没人用而已。
自 2017 年以来,以太坊社区就为着实际的需要艰难地探索安全的可扩展性方案。许多人可能都相信过,「PoS + 分片」 能提供强大的可扩展性,但那是 「分片化执行系统」,有自身的一堆问题。眼前的 「可执行信标链路线」,也不过是牺牲合约本身的属性来换吞吐量而已。时至今日,已经找不到证据,证明为了可扩展性,以太坊应该拥抱 PoS。
归根结底,只有契合用户需要的性能提升,才是真正有意义的性能提升。如果不从用户的实际需要出发,相反,从技术美感或者最大化性能的假设出发,只能设计出空中楼阁。如果可以,那就让用户自己来做决定,在协议层操心太多,往往徒增摩擦。
以太坊的路线图应该改变吗?当然,应该放弃这些不切实际的幻想,回头问问用户需要什么。
声明:此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。本网站所提供的信息,只供参考之用。