编者注:本文为 cdetrio 于 2018 年 11 月 24 日在 ethereum-magicians.org 上发布的文章。近期,一些社区成员已经表示了对这些想法的支持,并选择了“以太坊 1.0”而不是“1.x”来概括这种思路。

本文没有获得其他核心开发者的预先审阅或反馈意见,纯属我个人对 1.x 的看法。如果存在任何错误或误解,责任均由我个人承担。

摘要

以太坊 1.x 是近期以太坊主网的一系列全面升级的代号。1.x 采用的一系列升级将对主网进行重大改造,与此同时,以太坊 2.0 (又名 Serenity)正在进行原型设计与开发。1.x 计划包含三个主要目标:(1)通过优化客户端大幅提高区块的 gas limit,从而增加每秒交易吞吐量,提高主网的可扩展性; (2)通过“存储空间租赁”的方式降低并限制磁盘空间要求,确保全节点可持续运行; (3)通过升级虚拟机(包括 EVM 1.5 和 Ewasm)改善开发者体验。

背景介绍

“以太坊 1.x”的想法源自 Devcon4 期间核心开发者之间的讨论。在讨论 1.x 之前,以太坊 1.0 的路线图上仅有几处针对主网硬分叉(例如拜占庭和君士坦丁堡)提出的相对保守的变更。在拜占庭硬分叉前后(2018 年 10 月),Casper-FFG 正处于开发阶段,它引入了混合工作量证明(PoW)与权益证明(PoS)共识机制的区块奖励,是主网的一次重大变革。2018 年 6 月,Casper-FFG 被舍弃,PoS 的研究工作转向了开发“信标链(beacon chain)”,该链将作为独立于以太坊 1.0 主网的新链发布。这次开发重点的转移令以太坊 1.0 客户端的开发人员迷失了方向,以太坊 2.0 显然还要经历一段漫长的开发周期,我们不禁开始产生疑惑,这段时间内我们能对主网做些什么?

以太坊 1.0 客户端的维护人员有两个选择:一种是只对主网进行简单保守的改进,不作任何重大变更(将大刀阔斧的改进任务留给以太坊 2.0 )。另一种是对以太坊 1.0 的主网进行重大改革,同时将以太坊 2.0 的研发交给另外的团队进行。而这后一种选择则被称为 1.x 计划。

以太坊 1.x 计划的制定

在宣布 1.x 计划之前,一些核心开发者希望能有充足的时间制定详细的提案,并收集具体数据来回答相关问题(例如,在对客户端进行简单的优化后,可扩展性能立即提升到什么程度?2 倍,5 倍,还是更高?)。因此,核心开发者组成的工作小组希望在宣布计划之前有机会私下调整以太坊升级提案 (EIP),但是社区希望能尽早对 1.x 的初步计划进行公开讨论。因此,核心开发小组制定出了一个可靠的 1.x 分步计划固然不错,但这个计划最好从一开始就在一个包容、公开、透明的环境中制定

如果制定计划的过程从一开始就保持公开透明,还是会有不足之处,因为初期披露的只是一个半生不熟的计划,所以无法回答公众的所有疑问,就会出现含混不清的表述,从而引发其他开发者和社区成员的争议和反对。而且 1.x 计划是对主网进行大幅度改进,难免会引起争议,因此其核心开发小组不愿意将一个不成熟的计划公之于众

核心开发者对于 1.x 计划的开发进程也是难以评估的。1.x 改进计划不仅显示出了技术和治理上的野心,而且需要付出巨大的努力付诸实现,推进计划的动力还可能会因为早期的争议和阻力而受到削弱。简单一些的解决方式就是避免争议,将那些雄心壮志留给以太坊 2.0 去实现。由此可见,对主网进行重大改革将是一个巨大的挑战。

接下来,本文将概述 1.x 计划的三个主要目标。第一个和第二个目标(可扩展性和可持续性)可以说是相互关联的,而第三个目标(虚拟机升级)则是独立的。

1. 优化客户端,提高可扩展性

提高主网的交易吞吐量是 1.x 计划的第一个目标。交易吞吐量由区块的 gas limit 决定,目前在 800 万左右。矿工们会对每个区块进行投票,决定是提高还是减少区块 gas limit。如果 gas limit 过高,就会产生副作用,即,挖到叔块的机率会增加。叔块率过高的坏处在于会导致矿池中心化(主要是那些叔块率高的小矿池,导致它们的收入降低,无法与叔块率较低的大矿池竞争)。因此,矿工不能随意提高 gas limit,否则就会降低有竞争力的矿池的多样性。

一个好消息是,最近发现有一种客户端优化或能在大幅增加区块 gas limit 的同时保持较低的叔块率。这种优化改进了 Parity 广播区块的方式(是 turbogeth 创始人 Alexey Akhunov发现的)。 现在 Parity 在广播区块前都会仔细校验区块的工作量证明与交易流程。经过这种优化之后,Parity 只会校验工作量证明,然后在处理交易时开始广播区块。这种优化可能会大大降低网络的叔块率,使矿工能够大幅提高区块的 gas limit(注意还有另一种办法:如果不将区块 gas limit 提高 2 倍,也可以把计算操作码重新定价为原来的 1/2)。

那么通过这种优化,我们可以将区块的 gas limit 提高多少呢?目前还是一个未知之数,所以我们不能高兴得太早。核心开发者希望通过网络模拟和收集更多的数据来解答这个问题。然而,要解答这个问题,有许多复杂因素(例如全节点之间的网络拓扑结构和传播延迟)尚待研究。除了这这种优化方式之外,还有一些简单的方法可以优化区块广播。

除了简单的优化之外,开发人员还在研究一些更加激进的优化方法,以增加主网的吞吐量。一种方法是实现交易的并行处理,紧接着之前 EIP 中断的地方开始。另一种大幅提升主网可扩展性的方法是改变 PoW 协议,很早以前在 分片 FAQ 中提到过:“Bitcoin-NG 的设计能够......将交易量的可扩展性恒定提高 5-50 倍 ...... (这种方法)不会与分片相互排斥,而且两者可以同时运行。”

因此,一些简单的优化可能会立即提高主网的吞吐量(随便猜测一下,可能有 2-5 倍吧)。通过对协议进行更全面的修改,也许可以将主网吞吐量提升 50 倍(这可不是我猜出来的!而是在分片 FAQ 上看到的)。

但是,将吞吐量提高 2 至 5 倍也会将主网当前的问题放大 2 至 5 倍。最大的问题是磁盘空间的需求增大,如果我们要提高主网吞吐量,那么必须首先解决磁盘空间的问题

2. 减少磁盘空间使用量,实现可持续网络

减少磁盘空间使用量的长期解决方案,存储租金(storage rent),是 1.x 计划中最具争议的部分。关于实施存储租金的必要性,存在着许多争论和不同的观点。一方面,一些 1.0 客户端的维护人员认为状态数据已经增长得太快,即使不提升吞吐量,也需要作出改进。这些核心开发者认为,这样下去,以太坊主网最多还能维持三年。如果在此之前没有做出任何有效的措施来减少磁盘空间的负担,那么以太坊将会走向灭亡。

另一方面,专注于研发 2.0 扩展计划的研究人员认为,新的硬盘驱动器足以应对目前 1.0 主网状态数据的增长率,直到 2.0 推出,然后用户就可以从 1.0 的合约迁移到 2.0 中的合约。 他们还认为,在主网上作出大幅度的变更会违背用户对 1.0 合约的期望,而且 1.0 网络会在接下来三年中产生 70G 的状态数据也没什么大不了(我查了一下,目前的状态数据大小大约是 7 GB)。 此外,在以太坊 1.0 上引入租赁机制可能会使用户感到困惑,因为它可能与 2.0 中引入的租赁机制不同。

有一个存储租赁的替代方案是无状态客户端,但要想把无状态客户端付诸实现,那么就得把状态树的格式更改为适用于无状态范例的格式(即,客户端需要从当前的十六进制前缀树切换到二进制或稀疏默克尔树)。核心开发者认为从有状态转换为无状态是对 1.0 客户端的巨大改变,实现起来要复杂得多。因此,比较简单的方法的是保持当前有状态的十六进制前缀树,然后加入存储租赁。

一个好消息是,也可以采用一些简单,无异议的措施来减少所需的磁盘空间。PéterSzilágyi(go-ethereum 创始人)提出了减少磁盘空间使用量的三条措施中的前两条(简要说明一下这三条措施:1. 删除过去的区块;2. 删除过去的日志;3. 删除状态,即存储租赁)。目前, geth 节点同步需下载超过 100gb 的数据,其中大部分数据是以前的区块和日志。实际帐户状态只占总数据的一小部分。为了使数据条理更清晰,以前的区块和日志应该存储在其他某个地方方便以后使用,而不应该存储在占据网络主导地位的公共全节点上。相反,全节点将只存储一些最近的区块和日志记录,大概也就是几个月内产生的数据。

这两个简单的变更(删除以前的区块和日志)只会破坏一些希望通过全节点来检索和查询过去所有日志的 dApp。这些 dApp 将停止使用纯节点(它们将要求用户运行更加存储密集型的 Archive 节点(直译为归档节点),或查询能检索日志的服务)。对大多数用户来说,数据同步将变得快速而轻松(就像早期年轻且轻便的以太坊主网),但这只是一个临时性的修复,随着帐户数量的不断增长,同步数据将逐渐变得缓慢,负担也变得更重。

抑制帐户数量增长的解决方案是存储租赁。

在多个有潜力的存储租赁提案中,它们在用户友好性和可行性(核心开发者友好性)方面存在差异。最简单的方案对用户是不够又要的。例如,直接删除不支付租金的帐户,不向用户提供任何方式来“复活”或反对删除他们的帐户。相比之下,那种用户以后可以恢复未支付租金的帐户的租赁机制虽然对用户更有利,但实施起来更复杂。

存储租赁的另一个问题是多个用户签订合约时的激励问题。例如,一个代币合约涉及到若干持有代币的用户,但简单的租赁机制要求合约支付租金。这时就没有相应的激励机制使得单个用户愿意为合约支付租金,每个代币持有者都希望由其他用户来支付合约的租金。解决这一激励问题需要改善合约存储的所有权模式。

存储租赁提案是 1.x 计划中最难的部分。在治理上也是有争议的,因为对用户和开发者来说,存储租赁向主网引入了一个全新的模式,而且从技术上说,执行起来非常复杂,尤其是要提供用户友好型的租赁机制的话。因此,我们的目标是制定一个详细的提案,尽可能让大多数人满意(从核心开发者到 dapp 开发者,再到 dapp 用户)。

3. 升级 VM,改善开发者体验

升级 VM 是 1.x 计划中完全独立于前两个目标的第三个目标。EIP 615 提议升级 EVM。这个 EIP 也被称为“EVM 1.5”,因为它被认为是 EVM 的近期改进,相对于长期改进的 Ewasm (又名“EVM 2.0”)。

Ewasm 最初被设计为与 EVM 向后兼容(即 Ewasm 合约可以与 EVM 合约互动),以便运用在主网上。后来,Casper-FFG 遭到反对,PoS 路线图转向 Ethereum 2.0,在阶段 0/1 开发一条信标链,在阶段 2 开发基于 Ewasm 的执行引擎。但是因为 2.0 上的执行引擎是在一条独立的链上而不是在 1.0 的主链上,所以 2.0 Ewasm 就不需要与 EVM 向后兼容。 这意味着“Ewasm 2.0”设计是一个悬而未决的问题,而且可能与“Ewasm 1.0”(即当前与EVM向后兼容的 Ewasm 设计)大不相同。

Ewasm 的 1.x 计划意味着要追求最初的目标:适用于主网并能与 EVM 向后兼容的 Ewasm 版本。未来的提案会详细介绍在主网上引入 Ewasm 的多阶段路线图。

结论:1.x 路线图还说不上完备

上面的 1.x 计划只是一个不成熟的纲领。目前还无法回应所有相关的问题,仍需要进行研究来收集有关主网可扩展性潜力的数据。此外,我们还必须写清楚让全节点在中期和长期中可持续运行所需的革命性变更,出版详尽的提案以供社区参考。


原文链接: https://ethereum-magicians.org/t/ethereum-1-dot-x-a-half-baked-roadmap-for-mainnet-improvements/1995
作者: cdetrio
翻译&校对: 杨哲 & 闵敏