Vitalik 的新文章：以太坊的未来（V）— The Purge

36 0 1

原标题：以太坊协议的未来，第五部分：大清洗

原创文章，作者：Vitalik Buterin

原文翻译：Odaily星球日报老公如何

自 10 月 14 日起，以太坊创始人 Vitalik Buterin 陆续发表关于以太坊未来可能的讨论。合并 , 浪潮 , 天灾 , 边缘更新至最新版本清除，都凸显了Vitalik对于以太坊主网未来发展的愿景，以及如何解决当前的问题的解决方案。

合并：讨论以太坊转向 PoS 后需要改进单槽最终性和降低质押门槛，以增加参与度并加快交易确认速度。

The Surge：探索扩展以太坊的不同策略，特别是以 Rollup 为中心的路线图，以及其在可扩展性、去中心化和安全性方面的挑战和解决方案。

《天灾》：探讨以太坊在向 PoS 转型过程中面临的中心化和价值提取风险，开发多种机制以增强去中心化和公平性，并改革质押经济以保护用户利益。

The Verge：探索以太坊无状态验证的挑战和解决方案，重点关注 Verkle 树和 STARK 等技术如何增强区块链的去中心化和效率。

10 月 26 日，Vitalik Buterin 发表了一篇关于 The Purge 的文章，讨论了以太坊面临的挑战是如何在长期内降低复杂性和存储要求，同时保持链的持久性和去中心化。关键措施包括通过历史过期和状态过期减少客户端存储负担，并通过功能清理简化协议，以确保网络的可持续性和可扩展性。

以下为原文内容，由Odaily星球日报翻译。

特别感谢 Justin Drake、Tim Beiko、Matt Garnett、Piper Merriam、Marius van der Wijden 和 Tomasz Stanczak 的反馈和评论。

以太坊面临的挑战之一是，默认情况下，任何区块链协议都会随着时间的推移而变得臃肿和复杂。这发生在两个地方：

历史数据：历史上任何时间点进行的任何交易和创建的任何账户都需要由所有客户端永久存储，并由任何新客户端下载，以完全同步到网络。这会导致客户端负载和同步时间随着时间的推移而增加，即使链的容量保持不变。
协议特性：添加新功能比删除旧功能要容易得多，这导致代码复杂性随着时间的推移而增加。

为了使以太坊能够长期可持续发展，我们需要对这两种趋势施加强大的反压力，随着时间的推移减少复杂性和臃肿。但与此同时，我们需要保留使区块链变得伟大的关键属性之一：耐用性。你可以把一个 NFT、一封交易调用数据中的情书，或者一个价值 $1 百万的智能合约放在链上，进入一个山洞十年，出来后发现它仍然在那里等着你阅读和与它互动。为了让 DApp 安心地完全去中心化并移除升级密钥，他们需要确信他们的依赖项不会以破坏它们的方式升级——尤其是 L1 本身。

Vitalik 的新文章：以太坊的未来（V）— The Purge

如果我们下定决心，绝对有可能在这两种需求之间取得平衡，在保持连续性的同时，尽量减少或扭转膨胀、复杂性和衰退。生物体可以做到这一点：虽然大多数生物体会随着时间推移而衰老，少数幸运儿没有 . 即使是社会系统也可以寿命极长以太坊在某些情况下取得了成功：工作量证明已经消失，SELFDESTRUCT 操作码基本消失，信标链节点存储了长达六个月的数据。以更通用的方式为以太坊找到这条道路，并朝着长期稳定的最终结果前进，是以太坊长期可扩展性、技术可持续性甚至安全性的终极挑战。

清除：主要目标。

降低客户端存储要求 通过减少或消除每个节点永久存储所有历史记录甚至最终状态的需要。
通过消除不必要的功能来降低协议复杂性。

文章目录：

历史到期

它解决了什么问题？

截至撰写本文时，完全同步的以太坊节点需要约 1.1 TB 磁盘空间执行客户端，共识客户端则需要数百 GB 以上的空间。其中绝大部分是历史数据：有关历史区块、交易和收据的数据，其中大部分都是多年前的数据。这意味着，即使 gas 上限根本没有增加，节点的大小也会继续以每年数百 GB 的速度增加。

它是什么以及它是如何工作的？

历史存储问题的一个关键简化特性是，由于每个块通过哈希链接指向前一个块（并且其他结构），对当前的共识足以达成对历史的共识。只要网络就最新的区块达成一致，任何历史区块、交易或状态（账户余额、随机数、代码、存储）都可以由任何单个参与者提供 Merkle 证明，并且该证明允许任何其他人验证其正确性。共识是 N/2-of-N 信任模型，而历史是 N-of-N 信任模型 .

这给我们留下了很多关于如何存储历史的选择。一个自然的选择是每个节点只存储一小部分数据的网络。这就是 Seed 网络几十年来的运作方式：虽然网络总共存储和分发数百万个文件，但每个参与者只存储和分发其中的几个。也许有悖常理，但这种方法甚至不一定会降低数据的稳健性。如果通过降低运行节点的成本，我们可以建立一个拥有 100,000 个节点的网络，每个节点存储随机的 10% 历史记录，那么每条数据将被复制 10,000 次——与 10,000 个节点的网络（其中每个节点存储所有内容）的复制因子完全相同。

如今，以太坊已经开始摆脱所有节点永久存储所有历史记录的模型。共识区块（即与权益证明共识相关的部分）仅存储约 6 个月。Blob 仅存储约 18 天。 EIP-4444 旨在引入历史区块和收据的一年存储期限，长期目标是建立一个统一的时间段（大概是18天），在此期间每个节点负责存储所有内容，然后建立一个以分布式网络方式存储旧数据的以太坊节点对等网络。

Vitalik 的新文章：以太坊的未来（V）— The Purge

可以使用纠删码来提高稳健性，同时保持复制因子不变。事实上，blob 已经采用纠删码来支持数据可用性采样。最简单的解决方案可能是重用此类纠删码，并将执行和共识块数据也放入 blob 中。

与现有的研究有何联系？

还需要做什么以及需要做出哪些权衡？

剩下的主要工作涉及构建和集成一个具体的分布式解决方案来存储历史——至少是执行历史，但最终也是共识和 blob。最简单的解决方案是 (i) 简单地引入现有的 torrent 库，以及 (ii) 一个名为的以太坊原生解决方案门户网络。一旦引入其中任何一项，我们就可以启用 EIP-4444。EIP-4444 本身不需要硬分叉，但需要新的网络协议版本。因此，同时为所有客户端启用它是有价值的，否则客户端可能会失败，因为它们连接到其他节点，期望下载完整的历史记录，但实际上却没有得到它。

主要的权衡涉及我们为提供“古代”历史数据付出的努力。最简单的解决方案是明天停止存储古代历史，并依靠现有的存档节点和各种中心化提供商进行复制。这很容易，但它削弱了以太坊作为永久记录场所的地位。更困难但更安全的方法是首先构建和集成 torrent 网络以分布式方式存储历史记录。在这里，“我们有多努力”有两个维度：

我们如何确保最大的节点集实际上存储了所有数据？
我们将历史存储集成到协议中的深度有多深？

对于（1）的一种极端偏执的做法是监护权证明：实际上要求每个权益证明验证者存储一定比例的历史记录，并定期加密货币图形化地检查他们是否这样做。更温和的方法是为每个客户端存储的历史记录百分比设置一个自愿标准。

对于 (2)，基本实现仅涉及今天已经完成的工作：Portal 已经存储了一个包含以太坊整个历史的 ERA 文件。更彻底的实现将涉及实际将其连接到同步过程，这样如果有人想要同步完整的历史存储节点或存档节点，他们可以通过直接从 Portal 网络同步来实现，即使没有其他存档节点在线存在。

它如何与路线图的其余部分互动？

如果我们想让运行或启动节点变得极其简单，那么减少历史存储需求可能比无状态更重要：节点所需的 1.1 TB 中，约 300 GB 是状态，其余约 800 GB 是历史。只有无状态和 EIP-4444，我们才能实现在智能手表上运行以太坊节点并在几分钟内完成设置的愿景。
限制历史存储也使得较新的以太坊节点实现仅支持最新版本的协议变得更加可行，这使得它们变得更加简单。例如，现在可以安全地删除许多代码行，因为 2016 年 DoS 攻击期间创建的空存储槽都已删除。现在，权益证明的转变已成为历史，客户端可以安全地删除所有与工作量证明相关的代码。

状态到期

它解决了什么问题？

即使我们消除了客户端存储历史记录的需求，客户端存储需求仍将继续增长，每年约 50 GB，因为状态会继续增长：账户余额和随机数、合约代码和合约存储。用户可以支付一次性费用，从而永远加重当前和未来的以太坊客户端的负担。

状态比历史更难过期，因为 EVM 从根本上是围绕这样的假设设计的：一旦创建了状态对象，它就始终存在，并且可以随时被任何交易读取。如果我们引入无状态，有些人认为这个问题可能不会那么糟糕：只有专门的区块构建器类才需要实际存储状态，而所有其他节点（甚至列表生成！）都可以无状态运行。然而，有一种观点认为，我们不想过分依赖无状态，最终我们可能希望让状态过期，以保持以太坊的去中心化。

它是什么以及它如何工作

如今，当您创建一个新的状态对象时（可以通过以下三种方式之一实现：（i）将 ETH 发送到新帐户，（ii）使用代码创建新帐户，（iii）设置以前未触及的存储槽），该状态对象将永远保持该状态。相反，我们希望对象能够随着时间的推移自动过期。关键挑战是以实现以下三个目标的方式来做到这一点：

效率：运行到期过程不需要大量额外的计算。
用户友好性：如果有人进入洞穴五年后再回来，他们不应该失去对其 ETH、ERC 20、NFT、CDP 头寸的访问权……
开发人员友好性：开发人员无需切换到完全陌生的思维模式。此外，目前僵化且未更新的应用程序仍可继续正常运行。

解决不符合这些目标的问题很容易。例如，你可以让每个状态对象也存储一个到期日期计数器（到期日期可以通过销毁 ETH 来延长，这可以在读取或写入时自动发生），并有一个循环遍历状态以删除过期的状态对象的过程。然而，这引入了额外的计算（甚至存储要求），而且它肯定不符合用户友好性的要求。开发人员也很难推断涉及有时会重置为零的存储值的边缘情况。如果你在合同范围内设置到期计时器，这会让开发人员的工作在技术上更轻松，但会让经济变得更加困难：开发人员必须考虑如何将持续的存储成本转嫁给用户。

这些都是以太坊核心开发社区多年来一直致力于解决的问题，其中包括“ 区块链租金 “ 和 ” 再生 ”最终，我们整合了提案中的最佳部分，并重点关注两类“已知解决方案中最好的一个”：

部分状态过期解决方案
根据地址周期提出状态到期建议。

部分状态到期

部分状态过期提案都遵循相同的原则。我们将状态拆分成块。每个块永久存储一个顶层映射，其中块要么为空，要么为非空。每个块中的数据只有在最近访问过后才会存储。如果块不再存储，则有一个复活机制可以将其复活。

这些提案之间的主要区别在于：（i）我们如何定义ne“最近”，以及（ii）我们如何定义“阻止”？一个具体的建议是 EIP-7736 以“茎叶”设计为基础引入 Verkle 树（尽管与任何形式的无状态状态兼容，例如二叉树）。在这种设计中，彼此相邻的头、代码和存储槽都存储在同一个“主干”下。存储在主干下的数据最多可达 256 * 31 = 7,936 字节。在许多情况下，帐户的整个头和代码以及许多密钥存储槽都将存储在同一主干下。如果给定主干下的数据 6 个月内未读取或写入，则不再存储该数据，并且只存储对该数据的 32 字节承诺（“存根”）。未来访问该数据的交易将需要“复活”数据并提供与存根核对的证明。

Vitalik 的新文章：以太坊的未来（V）— The Purge

还有其他方法可以实现类似的想法。例如，如果账户级别的粒度不够，我们可以制定一个方案，让树的每个 1/2 32 部分都由类似的茎叶机制控制。

由于激励因素，这变得更加棘手：攻击者可以通过将大量数据放入单个子树并每年发送单个交易来更新树，从而迫使客户端永久存储大量状态。如果使更新成本与树大小成正比（或与更新持续时间成反比），那么有人可能会通过将大量数据放入与其他用户相同的子树中来损害其他用户。可以尝试通过使粒度相对于子树大小动态化来限制这两个问题：例如，每个连续的 216 = 65536 个状态对象可以被视为一个组。然而，这些想法更为复杂；基于词干的方法很简单，并且可以调整激励措施，因为通常词干下的所有数据都与同一个应用程序或用户相关。

基于地址周期的状态到期建议

如果我们想完全避免任何永久性的状态增长，即使是 32 字节的存根，该怎么办？这是一个难题，因为复活冲突：如果删除了状态对象，而 EVM 稍后执行时将另一个状态对象放在完全相同的位置，但随后关心原始状态对象的人又回来并尝试恢复它，该怎么办？当部分状态过期时，存根会阻止创建新数据。当状态完全过期时，我们甚至无法存储存根。

基于地址循环的设计是解决此问题最著名的想法。我们不再使用一棵状态树来存储整个状态，而是拥有一个不断增长的状态树列表，并且任何读取或写入的状态都保存在最新的状态树中。每个时期（例如：1 年）都会添加一棵新的空状态树。旧树被冻结。完整节点仅存储两棵最新的树。如果状态对象在两个时期内都没有被触及，因此落入过期树中，它仍然可以被读取或写入，但交易需要证明其 Merkle 证明——一旦证明，就会在最新的树中再次保存一份副本。

Vitalik 的新文章：以太坊的未来（V）— The Purge

使用户和开发人员友好的一个关键思想是地址周期的概念。地址周期是地址的一部分的数字。关键规则是地址周期为 N 的地址只能在周期 N 期间或之后读取或写入（即，当状态树列表达到长度 N 时）。如果您要保存新的状态对象（例如，新合约或新的 ERC 20 余额），如果您确保将状态对象放入地址周期为 N 或 N-1 的合约中，那么您可以立即保存它，而无需提供之前没有任何东西的证明。另一方面，在旧地址期间进行的任何添加或编辑都需要证明。

这种设计保留了以太坊目前的大部分属性，不需要额外的计算，允许应用程序几乎像现在一样编写（需要重写 ERC 20 以确保地址周期为 N 的地址余额存储在子合约中，而子合约本身也有地址周期 N），并解决了用户在洞穴中呆五年的问题。但是它有一个很大的问题：地址需要扩展到 20 多个字节才能容纳地址周期。

地址空间扩展

一项提议是引入一种新的 32 字节地址格式，其中包括版本号、地址循环号和扩展哈希。

0x 01 （红色）0000（橙色）000001（绿色）57 艾 408398 dF 7 埃 5 f 4552091 一个 69125 d5 频率 7 乙 8 碳 2659029395 bdF（蓝色）。

红色的是版本号，橙色的四个零是空白，以后可以填分片号，绿色的是地址循环数，蓝色的是26字节的哈希值。

这里的关键挑战是向后兼容性。现有合约是围绕 20 字节地址设计的，并且通常使用严格的字节打包技术，明确假设地址长度恰好为 20 字节。解决这个问题的一个想法涉及转换映射，其中与新式地址交互的旧合约将看到新式地址的 20 字节哈希值。然而，确保其安全性存在相当大的复杂性。

地址空间收缩

另一种方法则相反：我们立即禁止一些大小为 2 128 的子范围（例如，所有以 0x ffffffff 开头的地址），然后使用该范围引入具有地址循环和 14 字节哈希值的地址。

0x 呸 000169125 d5 频率 7 乙 8 C2659029395bdF

这种方法的主要牺牲是引入反事实地址的安全风险：持有资产或权限但其代码尚未发布到链上的地址。风险在于有人创建一个地址，声称拥有一段（尚未发布的）代码，但还拥有另一段有效代码，该代码的哈希值与同一地址相同。今天计算这样的碰撞需要 2 80 个哈希值；地址空间缩减将把这个数字减少到易于访问的 2 56 个哈希值。

主要风险领域是非单一所有者持有的钱包的反事实地址，目前这种地址相对较少，但随着我们进入多 L2 世界，这种地址可能会变得更加常见。唯一的解决方案就是简单地接受这种风险，但要确定所有可能出错的常见用例，并提出有效的解决方法。

与现有的研究有何联系？

早期提案

部分状态到期提案

EIP-7736 ;

地址空间扩展文档

还需要做什么以及需要做出哪些权衡？

我认为有四条可行的前进道路：

我们使其无状态，并且永远不会引入状态过期。状态在增长（尽管速度很慢：几十年内我们可能都不会看到它超过 8 TB），但只有相对特殊的一类用户才会这样做：甚至 PoS 验证者也不需要状态。
需要访问部分状态的功能之一是包含列表生成，但我们可以采用去中心化的方式实现这一点：每个用户负责维护包含自己帐户的状态 trie 部分。当他们广播交易时，他们会将其与验证步骤中访问的状态对象的证明一起广播（这适用于 EOA 和 ERC-4337 帐户）。然后，无状态验证器可以将这些证明组合成整个包含列表的证明。
我们执行部分状态过期，并接受低得多但仍为非零的永久状态大小增长率。这一结果可能类似于涉及对等网络的历史过期提案如何接受低得多但仍为非零的永久历史存储增长率，其中每个客户端必须存储较低但固定百分比的历史数据。
我们正在通过地址空间扩展来实现状态过期。这将涉及一个多年的过程，以确保地址格式转换方法有效且安全，包括对于现有应用程序。
我们通过缩小地址空间来实现状态过期。这将涉及一个多年的过程，以确保处理涉及地址冲突（包括跨链情况）的所有安全风险。

重点在于，无论是否实施依赖地址格式变化的状态过期方案，地址空间扩展和收缩这一难题最终都必须得到解决。如今，生成地址碰撞需要大约 2 80 次哈希运算，这种计算负荷对于资源极其丰富的参与者来说已经是可行的：GPU 可以执行大约 2 27 次哈希运算，因此一年内可以计算 2 52 次，因此所有全球约有 230 个 GPU 大约 1/4 年就能计算出一次碰撞，而 FPGA 和 ASIC 可以进一步加速这一过程。未来，这种攻击将对越来越多的人开放。因此，实现完整状态过期的实际成本可能没有看起来那么高，因为我们无论如何都要解决这个非常具有挑战性的地址问题。

它如何与路线图的其余部分互动？

执行状态过期可能会使从一种状态 trie 格式转换为另一种格式变得更容易，因为不需要转换过程：您可以简单地开始使用新格式创建新树，然后进行硬分叉以转换旧树。因此，虽然状态过期很复杂，但它确实具有简化路线图其他方面的好处。

功能清理

它解决了什么问题？

的一个关键先决条件是安全性、可访问性以及值得信赖的中立是简单性。如果协议美观而简单，则不太可能出现错误。它增加了新开发人员能够参与其中任何部分的机会。它更有可能是公平的，并且更容易抵御特殊利益。不幸的是，协议就像任何社会系统一样，随着时间的推移会默认变得更加复杂。如果我们不想让以太坊陷入日益复杂的黑洞，我们需要做以下两件事之一：（i）停止进行更改并僵化协议，或（ii）能够实际删除功能并降低复杂性。中间路线也是可能的，对协议进行较少的更改并随着时间的推移至少消除一点复杂性。本节讨论如何降低或消除复杂性。

它是什么以及它是如何工作的？

没有任何单一的重大修复可以降低协议的复杂性；问题的本质是存在许多小的修复。

一个已经基本完成的例子，可以作为如何处理其他例子的蓝图，它是删除 SELFDESTRUCT 操作码。SELFDESTRUCT 操作码是唯一可以修改单个块内无限数量的存储槽的操作码，需要客户端实现更高的复杂性以避免 DoS 攻击。该操作码的最初目的是实现自愿状态清算，允许状态规模随着时间的推移而减少。实际上，很少有人最终使用它。操作码被削弱仅允许在与 Dencun 硬分叉相同的交易中创建自毁账户。这解决了 DoS 问题，并且可以显著简化客户端代码。将来，最终完全删除操作码可能是有意义的。

迄今为止确定的一些协议简化机会的关键示例包括：首先，一些 EVM 之外的示例；这些示例相对非侵入性，因此更容易达成共识并在更短的时间内实施。

RLP → SSZ 转换：最初，以太坊对象使用一种称为远程链路管理。RLP 是无类型的，并且不必要地复杂。如今，信标链使用南海，这在很多方面都有显著改善，包括不仅支持序列化，还支持哈希。最终，我们希望完全摆脱 RLP，将所有数据类型移至 SSZ 结构，这反过来会使升级变得更加容易。当前的 EIP 包括 [1] [2] [3] .
删除旧交易类型：如今的交易类型太多，其中许多类型都有可能被删除。除了完全删除之外，还有一个更温和的替代方案，即账户抽象功能，智能账户可以根据需要包含处理和验证旧交易的代码。
LOG 改革：日志创建布隆过滤器和其他逻辑增加了协议的复杂性，但由于速度太慢，客户端实际上并没有使用它们。我们可以删除这些功能并研究替代方案，例如使用 SNARKs 等现代技术的协议外分散日志读取工具。
最终删除Beacon Chain Sync Committee机制：同步委员会机制最初是为了实现以太坊的轻客户端验证而引入的。然而，它显著增加了协议的复杂性。最终，我们将能够使用 SNARK 直接验证以太坊共识层，这将消除对专用轻客户端验证协议的需求。潜在的，共识变化可以让我们通过创建更原生的轻客户端协议来更早地移除同步委员会，该协议涉及验证来自以太坊共识验证器随机子集的签名。
数据格式统一：目前，执行状态存储在 Merkle Patricia 树中，共识状态存储在 SSZ 树，并且 blob 通过以下方式提交 KZG 承诺。未来，为区块数据和状态使用单一统一格式是有意义的。这些格式将满足所有重要要求：（i）无状态客户端的简单证明，（ii）数据的序列化和擦除编码，以及（iii）标准化数据结构。
移除信标链委员会：引入这一机制最初是为了支持特定版本的执行分片。相反，我们最终进行了分片通过 L2 和 blob 。因此，该委员会是不必要的，所以正在采取措施消除它 .
删除混合字节序：EVM 是大字节序，共识层是小字节序。协调并使所有内容都以某种方式进行可能是有意义的（可能是大字节序，因为 EVM 更难更改）

现在，EVM 中的一些示例：

简化 gas 机制：当前的 gas 规则尚未得到很好的优化，无法明确限制验证区块所需的资源量。这方面的关键示例包括 (i) 存储读/写成本，旨在限制区块中的读/写次数，但目前相当随意；以及 (ii) 内存填充规则，目前很难估计 EVM 的最大内存消耗。建议的修复措施包括无状态 gas 成本变化（将所有与存储相关的成本统一为一个简单的公式）和内存定价建议 .
删除预编译：以太坊目前拥有的许多预编译既不必要地复杂，又相对较少使用，当几乎没有任何应用程序使用时，它们会造成很大一部分共识失败。解决这个问题的两种方法是 (i) 简单地删除预编译，以及 (ii) 用一段实现相同逻辑的（不可避免地更昂贵的）EVM 代码替换它。本 EIP 草案提出首先对身份预编译执行此操作；稍后，RIPEMD 160、MODEXP 和 BLAKE 可能成为删除的候选。
移除 gas 可观察性：让 EVM 执行不再能看到剩余的 gas 量。这将破坏某些应用程序（最明显的是赞助交易），但会使将来更容易升级（例如升级到更高级的版本，多维气体 ). EOF 规范已经使得 gas 不可观察，但是为了简化协议，EOF 需要是强制性的。
静态分析的改进：EVM 代码目前很难进行静态分析，尤其是因为跳转可能是动态的。这也使得优化 EVM 实现（将 EVM 代码预编译为其他语言）变得更加困难。我们可以通过以下方法解决这个问题：删除动态跳跃（或者使它们更加昂贵，例如，合约中 JUMPDEST 总数的 gas 成本呈线性关系）。EOF 就是这么做的，尽管强制执行 EOF 是获得协议简化优势所必需的。

与现有的研究有何联系？

还需要做什么以及需要做出哪些权衡？

进行此类功能简化的主要权衡是（i）我们简化的程度和速度与（ii）向后兼容性。以太坊作为一条链的价值在于它是一个平台，您可以在其中部署应用程序并确信它在几年后仍能正常工作。同时，这种理想也可能走得太远，用威廉·詹宁斯·布莱恩的话来说，“把以太坊钉在向后兼容的十字架上”。如果整个以太坊中只有两个应用程序使用某个功能，并且其中一个应用程序多年来没有用户，而另一个应用程序几乎完全没有使用，并且总共获得了 $57 的价值，那么我们应该删除该功能，并在必要时自掏腰包向受害者支付 $57。

更广泛的社会问题是创建一个标准化的管道，用于进行非紧急、向后兼容性破坏的更改。解决此问题的一种方法是检查和扩展现有先例，例如自毁过程。管道看起来如下：

开始讨论删除功能X；
进行分析以确定删除X对申请的影响，并且根据结果：（i）放弃该想法，（ii）按计划进行，或（iii）确定一个修订的“破坏性最小”的方法来删除X并继续进行；
制定正式的 EIP 来弃用 X。确保流行的高级基础设施（例如编程语言、钱包）尊重这一点并停止使用该功能。；
最后，实际删除X；

在第 1 步和第 4 步之间应该有一个多年的流程，并明确说明哪些项目处于哪个步骤。目前，需要在功能删除过程的力度和速度与更为保守并在协议开发的其他领域投入更多资源之间进行权衡，但我们距离帕累托前沿还很远。

末梢血

对 EVM 提出的主要变更包括 EVM 对象格式 (EOF) 。EOF 引入了很多变化，比如禁用 gas 可观察性、代码可观察性（即没有 CODECOPY），以及只允许静态跳转。目标是让 EVM 能够以更强大的方式进行升级，同时保持向后兼容性（因为 EOF 之前的 EVM 仍然存在）。

这样做的好处是，它为添加新的 EVM 功能创造了一条自然的路径，并鼓励迁移到更严格、保证更强的 EVM。缺点是，除非我们能找到一种方法最终弃用和删除旧的 EVM，否则它会显著增加协议的复杂性。一个主要问题是：EOF 在 EVM 简化提案中扮演什么角色，特别是如果目标是降低整个 EVM 的复杂性？

它如何与路线图的其余部分互动？

路线图其余部分中的许多改进建议也是简化旧功能的机会。重复上面的一些例子：

切换到单槽最终性使我们有机会消除委员会，重新设计经济学，并进行其他与权益证明相关的简化。
完全实现账户抽象将使我们能够删除许多现有的交易处理逻辑，并将其移至所有 EOA 都可以替换的“默认账户 EVM 代码”。
如果我们将以太坊状态移动到二叉哈希树，这可以与新版本的 SSZ 相协调，以便所有以太坊数据结构都可以以相同的方式进行哈希处理。

更激进的方法：将协议的大部分内容转换为合约代码

简化以太坊的更彻底的策略是保持协议完整，但将大部分内容从协议功能移到合约代码中。

最极端的版本是让以太坊 L1 在“技术上”仅包含信标链，并引入一个最小的虚拟机（例如 RISC-V , 开罗或更简单的，专门用于证明系统）允许其他人创建自己的汇总。 EVM 将成为这些汇总中的第一个。讽刺的是，这与 2019-20 年执行环境提案，尽管 SNARK 使得实际实现变得更加可行。

Vitalik 的新文章：以太坊的未来（V）— The Purge

更温和的方法是保持信标链与当前以太坊执行环境之间的关系不变，但更换 EVM。我们可以选择 RISC-V、Cairo 或其他 VM 作为新的官方以太坊 VM，然后强制将所有 EVM 合约转换为解释原始代码逻辑的新 VM 代码（通过编译或解释）。理论上，甚至可以将目标虚拟机作为 EOF 版本来完成此操作。

本文来源于网络：Vitalik 新文：以太坊的未来（V）—The Purge