原文标题:《引介 | 值得考虑删除的 EVM 功能》 到 2020 年,我们对如何设计智能合约和区块链协议的理解已经远超 2013-15 年。因此,如果我们在 2021 年从头开始搭建以太坊,我们就不会引入很多早期添加的功能了。然而从一条正在运行的、拥有活跃生态的区块链中移除功能,远比在一个新系统中不添加它们要难得多。 有些 「缺陷功能」 是无害的。有些可以安全而缓慢地移除或改进。还有些已经深深地嵌入到了太多的应用中,以至于根本改不动(例如 EVM 的 256 位字长)。另一方面,也有一些功能要么已经被移除,要么已经被改进,要么即将被移除(例如对状态树格式的改进、用 SSZ 编码规则代替 RLP 等)。 但是还有一些中间情况:有些功能过于复杂,对生态的发展造成了中等程度的伤害,我们可以移除它们,但是需要冒一点风险。如果我们移除这些功能,可能会有少量的应用被破坏。但是不移除的话,它们会继续拖累生态。 就跟别的 「长痛短痛」 抉择情形一样,人们很容易低估短痛带来的长期收益。特别是在我们的情况中,由于解决复杂情况的代码已经写好了,所以感觉保留它们不需要付出任何成本。但实际上有两个重要的成本要考虑:
以重新设计状态树为例:若以太坊的状态越是遵循一些简单的恒常性质(invariants),那么替换更高效的双层十六进制 Patricia 树就会越容易。然而在现实情况中,因为 「合并」(放弃 eth1 的 PoW 链,并将其状态导入 eth2 的 PoS 信标链的事件)可能是我们扯掉一些痛苦绷带的最后机会,这篇文章就是解释这样做的理由。 合并是进行最后一轮不兼容更新的一个非常自然的时间节点,有以下几个理由:
|