引介 | 值得考虑删除的 EVM 功能

到 2020 年，我们对如何设计智能合约和区块链协议的理解已经远超 2013-15 年。因此，如果我们在 2021 年从头开始搭建以太坊，我们就不会引入很多早期添加的功能了。然而从一条正在运行的、拥有活跃生态的区块链中移除功能，远比在一个新系统中不添加它们要难得多。

有些 “缺陷功能” 是无害的。有些可以安全而缓慢地移除或改进。还有些已经深深地嵌入到了太多的应用中，以至于根本改不动（例如 EVM 的 256 位字长）。另一方面，也有一些功能要么已经被移除，要么已经被改进，要么即将被移除（例如对状态树格式的改进、用 SSZ 编码规则代替 RLP 等）。

但是还有一些中间情况：有些功能过于复杂，对生态的发展造成了中等程度的伤害，我们可以移除它们，但是需要冒一点风险。如果我们移除这些功能，可能会有少量的应用被破坏。但是不移除的话，它们会继续拖累生态。

就跟别的 “长痛短痛” 抉择情形一样，人们很容易低估短痛带来的长期收益。特别是在我们的情况中，由于解决复杂情况的代码已经写好了，所以感觉保留它们不需要付出任何成本。但实际上有两个重要的成本要考虑：

为协议开发新实现的成本若要改变功能 B，但 B 会跟没必要存在的复杂功能 A 交互，可能会产生 “交互 bug”以重新设计状态树为例：若以太坊的状态越是遵循一些简单的恒常性质（invariants），那么替换更高效的双层十六进制 Patricia 树就会越容易。然而在现实情况中，因为SELFDESTRUCT操作码可以在单笔事务中不受限制地删除大量存储插槽，这给改良状态树带来了很大的困难。另一个例子是 2300 gas 津贴机制（见下文）使 gas 重新定价变得更复杂。\\\”合并\\\”（放弃 eth1 的 PoW 链，并将其状态导入 eth2 的 PoS 信标链的事件）可能是我们扯掉一些痛苦绷带的最后机会，这篇文章就是解释这样做的理由。合并是进行最后一轮不兼容更新的一个非常自然的时间节点，有以下几个理由：合并后构建的客户端很可能不处理 PoW 链，而是专门验证 PoS 信标链。因此，如果在合并时或合并前去除不必要的复杂功能，客户端最容易从中受益，因为它们根本不需要实现这些功能。(从技术上讲，即使是在合并前建立的客户端也可以设计成只处理最近 1-2 个硬分叉之后的数据，但是 “PoS 信标链作为一条独立的链而不需要处理 PoW 链上过于久远的数据” 的说法更容易让人接受)以太坊已经发生了很大的改变，社区对这将是 “以太坊的一次重大升级” 达成了共识。特别是 “在分片和合并完成之前会出现快速的进化，但合并之后就会趋于稳定” 的观点也得到了社区的一致认可。必要的向后不兼容的改变（例如，BLOCKHASH 操作码不再是一个好的随机性来源）已经发生了。这篇文章将介绍一些可以考虑删除的功能的例子。