以太坊的未来：Vitalik Buterin谈《The Purge》

微小发报道：

以太坊的未来探索，系列中的第五篇：清理

以太坊创始人Vitalik Buterin从10月14日起，陆续分享了对以太坊未来的畅想。从《合并》到《清理》，每一篇都在描绘以太坊如何迎接挑战、解决问题。

1. 《合并》：转向PoS后，Vitalik谈了如何提高单槽最终性和降低质押门槛，以增强参与度和加快交易确认速度。

2. 《激增》：探讨了多种扩容策略，尤其是Rollup的路线图，并分析了其在可扩展性、去中心化和安全性方面的挑战与解决方案。

3. 《灾难》：分析了在向PoS转型中面临的中心化和价值提取风险，提出了多种机制以增强去中心化和公平性，同时进行质押经济改革。

4. 《边缘》：讨论了无状态验证的挑战与解决，重点介绍了Verkle树和STARK等技术如何提升区块链的去中心化与效率。

10月26日，Vitalik发布了《清理》，探讨了以太坊在长期内如何降低复杂性和存储需求，同时保持链的持久性与去中心化。他提出了通过“历史过期”和“状态过期”来减轻客户端存储负担的关键措施，并通过“特征清理”简化协议，以确保网络的可持续性和可扩展性。 微小发报道

以太坊面临的一个大坑就是，随着时间推移，区块链协议的膨胀和复杂性就像气球一样不断变大。这个问题主要在两个方面显现：

• 历史数据：所有客户端都要永久存储历史交易和帐户信息，新客户端还得从头同步，这可把负担和等待时间搞得越来越重，哪怕链的容量不变。

• 协议功能：新功能的添加比去掉旧功能简单得多，结果代码的复杂性就这样越积越多。

为了让以太坊在未来也能继续发光发热，我们得对这两个趋势施加点压力，让复杂性和膨胀感逐渐降低。但与此同时，得保留区块链的核心特性：持久性。想象一下，把一张 NFT、一封甜蜜的交易信息，或者一份价值百万的智能合约放上链，十年后再回来竟然还在等你。这让 DApp 能够安心去中心化，放心删掉升级密钥，因为他们要确保自己的依赖不会因为升级而被毁掉——尤其是 L1 本身。

如果我们下决心在这两个需求之间找到平衡，既保持连续性，又尽量减少或逆转臃肿与复杂性，这完全是可行的。生物体就是个好例子：虽然大多数生物会随时间衰老，但总有一些幸运的存在不会。社会系统也能有超长寿命。在以太坊的某些领域，已经取得了一些小成就：工作证明消失，SELFDESTRUCT 操作码也大部分不见了，信标链节点只存储最多六个月的旧数据。如何为以太坊找到一条通往长期稳定的道路，这可是以太坊在可扩展性、技术可持续性和安全性方面的最终挑战。

The Purge：主要目标

• 通过减少或消除每个节点永久存储所有历史记录甚至最终状态的需要，来 降低客户端存储要求。

• 通过消除不需要的功能来降低协议复杂性。

文章目录：

• History expiry（历史记录到期）

• State expiry（状态到期）

• Feature cleanup（特征清理）

History expiry 解决啥问题？🤔

截至目前，完整同步以太坊节点大概得用 1.1 TB 的磁盘空间来运行客户端，还得再加上几百 GB 的共识客户端空间。大部分存储的其实是历史数据：包括各种历史区块、交易和收据，这些数据大多数都有多年历史。这就意味着，即使 Gas 限制没变，节点的大小每年也会增加几百 GB。📈

它是啥，以及如何运作？🔍

历史存储问题的一个简化特征是，每个区块通过哈希链接等结构指向前一个区块，这样只需对最新的区块达成共识，就足够了。网络对最新区块达成共识后，任何历史区块、交易或状态（账户余额、随机数、代码、存储）都可以由任何参与者提供，并通过 Merkle 证明，其他人也能验证其正确性。共识是 N/2-of-N 信任模型，而历史则是 N-of-N 信任模型。

这给我们存储历史记录提供了很多选择。一种自然的选择是让每个节点只存储网络的一小部分数据。这正是种子网络多年来的运作方式：虽然网络存储和分发了数百万个文件，但每个参与者只需存储和分享其中的几个文件。或许听起来反直觉，这种方式反而不会降低数据的可靠性。如果让节点的运行成本更低，我们能建立一个拥有 100,000 个节点的网络，每个节点存储随机的 10% 历史记录，那么每条数据就会被复制 10,000 次，这与一个存储所有内容的 10,000 个节点网络的复制因子是一样的。

现在，以太坊开始摆脱所有节点永久存储历史的模式。共识区块（即与权益证明相关的部分）仅存储大约 6 个月，Blob 仅存储大约 18 天。EIP-4444 计划为历史区块和收据引入一年的存储期。长远目标是建立一个统一的存储周期（可能是 18 天），在这个周期内，每个节点负责存储所有内容，然后再建立一个由以太坊节点组成的点对点网络，以分布式方式存储旧数据。

纠删码可以用来提升数据的稳健性，同时保持相同的复制因子。其实，Blob 已经采用了纠删码，以支持数据可用性采样。最简单的解决方案很可能是重新利用这些纠删码，把执行和共识块的数据也放入 blob 中。💡 与现有研究的联系🔗

• EIP-4444 查看详情
• Torrents与EIP-4444 探讨
• 门户网络 了解更多
• 门户网络与EIP-4444 讨论
• Portal中的SSZ对象分布式存储与检索 阅读
• 如何提高gas限制（Paradigm） 方法

接下来的步骤🤔

剩下的主要任务是构建和整合一个具体的分布式解决方案，用于存储历史记录——至少是执行历史记录，最终还包括共识和blob。最简单的办法是（i）引入现有的torrent库，并且（ii）使用以太坊原生的Portal网络解决方案。一旦这两个方案中的任一个被采纳，EIP-4444就可以启动。虽然EIP-4444本身不需要硬分叉，但确实需要新的网络协议版本。因此，同时为所有客户端启用这一功能是非常重要的，否则客户端可能会因连接至其他节点而期望下载完整的历史记录，但实际上未能获取，导致故障风险。 主要的权衡在于如何高效地提供“古代”历史数据。最简单的方式就是明天停止存储这些历史数据，转而依赖现有的存档节点和各种集中式服务进行复制。虽然这看起来轻而易举，但会削弱以太坊作为永久记录保持者的地位。相较之下，构建和整合 torrent 网络来以分布式方式存储历史记录的方案虽然更复杂，但却更具安全性。在这里，“我们有多努力”可以从两个维度来衡量：

1. 确保最大数量的节点确实存储了所有数据的努力程度。
2. 历史存储的集成深度在协议中的体现。

对于（1），一种极端的做法是托管证明：要求每个权益证明验证器存储一定比例的历史记录，并定期通过加密方式进行核查。比较宽松的方式则是设立一个自愿标准，让每个客户端存储一定比例的历史数据。

至于（2），基本的实现只需依赖于目前已经完成的工作：Portal 已经存储了包含整个以太坊历史的 ERA 文件。更彻底的做法是将其连接到同步过程中，使得即便没有其他存档节点在线，想要同步完整历史的存储节点或存档节点也能通过直接同步实现。

如何与路线图的其他部分产生互动？

如果我们的目标是让节点的运行和启动变得超简单，那么减少历史存储的需求可能比无状态性更为关键：在节点所需的 1.1 TB 中，约 300 GB 是状态，剩下的 800 GB 则是历史数据。只有当实现了无状态性和 EIP-4444，才能让以太坊节点在智能手表上运行，并仅需几分钟进行设置。

限制历史存储同样使得新版本以太坊节点的实现更具可行性，专注于协议的最新版本，因此它们会更加简单。例如，许多代码行如今可以安全地删除，正因为自 2016 年 DoS 攻击以来创建的空存储槽已被清除。随着转向权益证明成为历史，客户也可以放心删除所有与工作量证明相关的代码。

状态过期

解决了什么问题？

即使我们消除了客户端存储历史记录的需要，客户端的存储需求依然会持续增长，每年约增加 50 GB，因为状态在不断扩大：账户余额、随机数、合约代码及合约存储等。用户可能需要支付一次性费用，未来的以太坊用户将承担这一负担。 状态的“过期”比历史更棘手💥，因为 EVM 设计的初衷就是确保状态对象一旦创建就永远存在，任何事务都能随时读取。有人提出，如果我们引入无状态性，事情或许不会那么糟糕：只有特定的区块构建器需要存储状态，而其他节点（包括生成列表的那些）可以无状态运行。但另一种观点则认为，过度依赖无状态性可能会削弱以太坊的去中心化，最终我们可能希望实现状态的过期。

它到底是什么，如何运作呢？

今天，当你通过以下三种方式之一创建新的状态对象时（(i) 发送 ETH 到新账户，(ii) 用代码创建新账户，(iii) 设置未触及的存储槽），这个状态对象就会永远存在。我们想要的，实际上是状态对象能够随时间自动过期。挑战就在于要同时实现以下三个目标：

1. 效率：不需要大量额外计算来驱动过期过程。

2. 用户友好性：如果某人五年后才从洞穴中出来，他们不应该失去对 ETH、ERC 20、NFT、CDP 头寸的访问权。

3. 开发人员友好性：开发者不该被迫转向完全陌生的思维模型。同时，现有的、已经固化且不再更新的应用也应该能继续运行。

如果不满足这些目标，问题就容易解决。例如，可以让每个状态对象存储过期日期计数器（通过燃烧 ETH 来延长过期日期），并设置循环遍历状态以删除过期对象。但这会增加额外的计算和存储需求，用户友好性也会受到影响。开发者同样会面临存储值被重置为零的边缘情况的推理挑战。尽管在合约范围内设置到期计时器能让开发者的生活稍微轻松，但却让经济变得复杂，开发者需要考虑如何将持续的存储成本“转嫁”给用户。

这些都是以太坊核心开发社区多年来努力解决的问题，比如“区块链租金”和“再生”等提案。最终，我们结合了这些提案的最佳部分，专注于两类“已知最不糟糕的解决方案”：

· 部分状态过期解决方案

· 基于地址周期的状态到期建议 部分状态到期提案的原则可谓相似。💡我们将状态划分为多个块，每个人都永久保存「顶级映射」，显示这些块是空的还是非空的。只有在最近访问过数据时，块中的内容才会被存储。这里还有个「复活」机制，倘若不再存储数据，便会触发它。

提案之间的核心差异主要体现在两个方面：（i）如何界定「最近」，以及（ii）如何定义「块」呢？以 EIP-7736 为例，它是基于为 Verkle 树引入的「茎叶」设计（当然也可以与任何无状态结构兼容，比如二叉树）。在这一设计中，相邻的标头、代码和存储槽都集成在同一个「主干」下。一个茎下最多能存储 256 * 31 = 7,936 字节的数据。在许多情况下，整个帐户标头、代码以及多个密钥存储槽会一起存于同一主干下。如果某个主干下的数据在 6 个月内未被读取或写入，它将不再存储，而是只保留 32 字节的承诺（即「存根」）。未来访问这些数据的交易需要对数据进行「复活」，并提供存根的验证证明。

当然，还有其他方案可以实现类似的效果。🚀如果帐户级别的粒度不够，我们可以设计一个机制，让树的每个 1/2 32 部分也采用类似的茎叶结构进行管理。

不过，激励因素让事情变得复杂：攻击者可能通过将大量数据放入同一子树并每年发起一次交易来「更新树」，从而迫使客户端永久存储大量状态。如果续订成本与树的大小成正比（或续订时长成反比），那么某些人可以通过将大量数据放入同一子树来损害其他用户。为了解决这两个问题，或许可以通过动态调整子树大小来限制。例如，每连续的 2^16 = 65536 个状态对象可以被视作一个「组」。不过，这些想法的复杂性不容小觑；基于茎的方法相对简单，且能调整激励措施，因为通常茎下的所有数据均与同一应用或用户相关。

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

假如我们想完全避免任何永久状态的增长，甚至连 32 字节的存根也不想要，那该怎么办？🤔这是个棘手的问题，尤其是复活冲突：假如一个状态对象被删除，稍后 EVM 执行又将另一个状态对象放在完全相同的位置，而原来关心这个状态对象的人又回来试图恢复它，那就麻烦了。当部分状态到期时，「存根」会阻止新数据的生成。随着状态完全到期，我们甚至无法存储存根。 基于地址周期的设计，真的是解决这个问题的超级明星。不是用一棵单树来存储所有状态，而是用一个不断扩展的状态树列表。每次读取或写入状态，都会保存在最新的状态树中。每过一个周期（比如一年），就加一棵新的空状态树，老树则被“冻住”。完整节点只需保存最近的两棵树。若某个状态对象在两个周期内没被用到，就会掉进过期树，但仍可以读取或写入，只要提供Merkle证明，一旦证明通过，就会把它备份到最新的树里。

地址周期的概念是让用户和开发者都能轻松上手的关键。它是地址的一部分，简单来说，具备地址周期 N 的地址，只有在周期 N 或之后（也就是状态树列表长度达到 N 时）才能被读取或写入。当你要保存新的状态对象，比如新合约或 ERC 20 余额，只要确保把它放在周期为 N 或 N-1 的合约里，就可以马上进行，不需要提供之前的证据。反之，在旧地址期间的添加或修改就得要证明了。

这样的设计几乎保留了以太坊当前大部分特性，不需要额外算力，应用开发几乎和现在一样简单（不过 ERC 20 得重写，确保地址周期为 N 的余额存储在子合约中，并且自身也要有地址周期 N），解决了“用户进山洞五年”的烦恼。但是，有个大问题：地址得扩展到超过20字节才能支持地址周期。

地址空间扩展

一个建议是引入新的32字节地址格式，包含版本号、地址周期号和扩展散列。

0x01（红色）0000（橙色）000001（绿色）57 aE408398 dF7 E5 f4552091 A69125 d5dFcb7B8C2659029395bdF（蓝色）。

红色部分是版本号，橙色的四个零是留给未来的分片编号的空白，绿色则是地址周期号，蓝色是26字节的哈希值。 这里的关键挑战是向后兼容性。现有合约围绕20字节地址设计，通常依赖严格的字节打包，假设地址正好是20字节。解决方案之一是转换映射，让旧合约看到新地址的20字节哈希值。不过，要确保安全性可不简单，复杂性堪比拼图游戏。

地址空间收缩

另一种策略则反其道而行：立刻禁用某些2^128大小的地址子范围（比如，所有以0xFFFFFFFF开头的地址），接着在这个范围内引入周期性地址和14字节哈希值的地址。

0xffffffff000169125d5dFcb7B8C2659029395bdF

这种方法的代价就是引入反事实地址的安全风险：某个地址声称拥有的资产或权限，其代码尚未在链上发布。风险在于，可能有人创建一个地址，声称有一段（尚未发布的）代码，同时另一段有效代码的哈希也落在同一个地址上。目前，计算这样的碰撞需要2^80个哈希值，而地址空间收缩将其降低到2^56个哈希值，简直是给黑客开了小门。

关键风险领域在于，非单一所有者持有的钱包的反事实地址现在相对少见，但随着我们进入多L2的世界，这种情况可能会愈发普遍。唯一的解决方案就是接受这种风险，找出可能出现问题的常见用例，并提出有效的应对策略。

与现有研究的关系？

早期提案包括：

• 区块链清洁 链接；
• 再生 链接；
• 以太坊状态大小管理理论 链接；
• 无状态和状态过期的一些可能路径 链接； 微小发报道：

关于状态到期提案的思考，EIP-7736 的提出引发了关于地址空间扩展的热议。以下是一些相关文档和评论链接，供大家参考：

1. EIP-7736 提案文档

   • EIP-7736

2. 地址空间扩展原始提案

   • 原始提案

3. Ipsilon 评论

   • Ipsilon 评论

4. 博客文章评论

   • 博客评论

5. 碰撞抵抗力的影响

   • 碰撞抵抗力讨论

接下来的步骤与权衡

未来的可能路径有四种：

1. 无状态设计：实现完全无状态，不引入状态到期。状态尽管慢慢增长，但用户（即便是 PoS 验证者）不需要直接管理状态。想要获取部分状态的功能，可以通过用户维护自己的状态树来实现。每次交易时，用户会广播交易及相应的状态证明，无状态验证器将这些证明合并，形成完整的包含列表。

2. 部分状态到期：接受一个较低的状态增长率，虽然仍然是非零的。这类似于历史过期提案，要求每个客户端存储相对较少的固定百分比历史数据，同时接受一种逐步增加的存储需求。

• 状态过期通过地址空间扩展来实现。这是一个长达数年的过程，确保地址格式转换的方式既有效又安全，涉及到现有的应用程序🛠️。

• 状态过期也可以通过地址空间收缩来进行。这同样是一个漫长的过程，确保涉及地址冲突的安全风险都能得到妥善处理，包括跨链的情况🔒。

关键在于，无论我们是否选择依赖地址格式变化的状态过期方案，最终都得解决地址空间扩展和收缩的问题。如今，生成地址冲突大约需要2的80次方个哈希值。对于资源充足的参与者，这样的计算负担是可以应对的：GPU大约能处理2的27次方个哈希值，因此一年内可以计算2的52次方次。全球约230个GPU可以在大约1/4年内计算一次碰撞，而FPGA和ASIC可以让这个过程更快。未来，这类攻击的门槛将会降低。所以，实施完全状态到期的实际成本可能没那么高，因为我们必须面对这个复杂的地址问题💡。

与路线图其他部分的互动

状态过期的实施可能会让从一种状态树格式到另一种状态树格式的转换变得简单，因为不需要繁琐的转换过程：可以直接用新格式创建新树，然后通过硬分叉转换旧树。尽管状态到期复杂，但它确实有助于简化路线图的其他部分。

功能清理

解决什么问题？

安全性、可访问性和可信中立性的基础之一是简单性✨。如果协议既美观又简单，就能减少错误的发生。这样一来，新开发者也能更容易参与其中，公平性提升，抵御特殊利益的能力也随之增强。不过，协议随着时间推移，像任何社交系统一样，默认会变得更加复杂。如果不想让以太坊陷入复杂性无底洞，我们得做两件事中的一件：（i）停止变更让协议僵化，或者（ii）实际删除功能来降低复杂性。还有一种折中方案，就是对协议进行较少的变更，随着时间推移至少减少一点复杂性。本节将探讨如何缩减或消除复杂性🔍。

这是什么，它又是如何工作的？

降低协议复杂性没有单一的解决方案；这个问题本质上需要很多小的解决办法🧩。 一个接近完成的案例是去掉 SELFDESTRUCT 操作码，这个操作码的处理方式也可以给其他示例提供参考。💡SELFDESTRUCT 是唯一能在一个块内修改无数存储槽的操作码，但这让客户端的实现复杂度大幅上升，容易导致 DoS 攻击。最初，这个操作码是为了自愿清算状态，允许状态随时间减少，然而实际上很少有人用到它。现在，被限制为只能在 Dencun 硬分叉中创建的自毁账户使用，从而解决了 DoS 的问题，并显著简化了客户端代码。未来，完全删除这个操作码可能会是个好主意。

至于协议简化的机会，以下是一些关键示例。👀首先，一些 EVM 之外的例子，比较非侵入性，容易在短时间内达成共识并实施。

1. RLP → SSZ 转换：最开始，以太坊对象是用 RLP 编码序列化的，RLP 是无类型且复杂的。现在，信标链使用 SSZ，这在许多方面都有明显优势，不仅支持序列化，还支持哈希。最终目标是完全抛弃 RLP，把所有数据类型换成 SSZ，这样升级会更方便。目前的 EIP 包括 [ 1 ] [ 2 ] [ 3 ]。

2. 删除旧交易类型：如今的交易类型太多，很多都可以删掉。更温和的选择是引入帐户抽象功能，让智能账户可以包含处理和验证旧交易的代码（如果他们愿意的话）。

3. LOG 改革：日志创建布隆过滤器和其他逻辑，增加了协议复杂度，但实际上客户端用得不多，因为速度太慢了。我们可以去掉这些功能，转向使用现代技术如 SNARK 的协议外去中心化日志读取工具。

4. 最终去除信标链同步委员会机制：这个机制最初是为了轻客户端验证而设，但却显著增加了协议复杂性。未来，我们可以直接用 SNARK 验证以太坊共识层，从而不再需要专用的轻客户端验证协议。潜在的共识改变可能让我们更早地通过创建一个更“本机”的轻客户端协议，来删除同步委员会，这个协议将验证来自以太坊共识验证器的随机子集签名。🔍 · 数据格式统一：现在，执行状态被存储在 Merkle Patricia 树中，而共识状态则是在 SSZ 树中，blob 则通过 KZG 承诺进行提交。未来，制定块数据和状态的单一统一格式是个好主意。这些格式将满足以下关键需求：

5. 无状态客户端的简单证明

6. 数据的序列化和擦除编码

7. 标准化数据结构

· 删除信标链委员会：这个机制最开始是为了支持特定版本的执行分片而设计的。但最终我们通过 L2 和 blob 完成了分片。因此，委员会显得多余，目前正在推进其取消的计划。

· 去除混合字节序：EVM 使用大字节序，而共识层使用小字节序。将所有内容协调成一种字节序（大尾数可能更合适，因为 EVM 更难调整）是有必要的。

现在，EVM 中的一些示例：

· Gas 机制的简化：目前的 Gas 规则优化得不够好，难以明确限制验证区块所需的资源量。关键问题包括：

1. 存储读/写成本，这本应限制一个块中的读/写次数，但现在相当随意
2. 内存填充规则，估算 EVM 的最大内存消耗相当困难

拟议的解决方案包括无状态 Gas 成本变更，统一所有与存储相关的成本为一个简单公式，以及新的内存定价提案。

· 删除预编译：以太坊的许多预编译既复杂又使用频率低，几乎未被应用程序使用，但却占据了共识失败的大部分。处理此问题的两种方法是：

1. 直接删除预编译
2. 用实现相同逻辑的更复杂（但不可避免更昂贵）的 EVM 代码替换它

这个 EIP 草案建议首步删除身份预编译，之后可能会考虑删除 RIPEMD 160、MODEXP 和 BLAKE。

· 去除 gas 可观察性：让 EVM 执行过程中无法看到剩余的 gas。这可能会影响一些应用（最显著的是赞助交易），但将来会让升级变得更简单（比如多维气体的高级版本）。EOF 规范已经让 Gas 变得不可观测，但为了简化协议，EOF 需要强制实施。

• 静态分析改进：现在 EVM 代码的静态分析难度颇高，尤其是动态跳转让人头疼。优化 EVM 实现（把 EVM 代码转成其他语言）也变得更加复杂。解决方案？可以考虑去掉动态跳跃，或者让它们的成本更高，比如合约中的 JUMPDEST 消耗的 Gas 成本可以线性增加。EOF 就是朝这个方向努力，虽然要真正享受到协议简化的好处，还得强制执行 EOF。

• 与现有研究的关联：

  1. 清除的后续步骤 ( https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA )；

  2. 自毁 ( https://www.odaily.news/post/%20//hackmd.io/@vbuterin/selfdestruct )；

  3. SSZ 化 EIPS： 1 2 3 ；

  4. 无状态 gas 成本变化 ( https://eips.ethereum.org/EIPS/eip-4762 )；

  5. 线性内存定价 ( http://https%20//notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw )；

  6. 预编译删除 ( http://https%20//notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg )；

  7. 布隆过滤器移除 ( http://https%20//eips.ethereum.org/EIPS/eip-7668 )；

  8. 一种使用增量可验证计算进行链下安全日志检索的方法 ( http://https%20//notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw ) （阅读：递归 STARK）。

• 接下来要做什么，以及需要权衡的事项？ 进行功能简化的权衡主要在于（i）简化的程度和速度与（ii）向后兼容性。以太坊的价值在于它是一个平台，可以部署应用程序，并确保在多年后仍然有效。然而，这种理想也可能过于理想化，就像William Jennings Bryan所说的，“将以太坊钉在向后兼容性的十字架上”。如果只有两个应用在使用某个功能，而其中一个多年来没有用户，另一个的总价值仅为57美元，那么我们就应该考虑删除该功能，并可能自掏腰包补偿那57美元。

更广泛的社会问题是如何创建一个标准化的流程，来进行非紧急的向后兼容性破坏。可以借鉴已有的自毁过程来解决这个问题。流程如下：

1. 开始讨论删除功能X；
2. 进行影响分析，决定删除X的后果：(i) 放弃，(ii) 按计划继续，或 (iii) 找出对应用破坏性最小的删除X的方法；
3. 制定正式的EIP以弃用X，确保流行的基础设施（如编程语言、钱包）遵循这一决定；
4. 最后，实际删除功能X。

在第1步和第4步之间，需要一个长达多年的流程，明确各项目处于哪个步骤。这个过程中要权衡特性删除的速度和活力与将更多资源投入协议开发的保守做法之间的关系，但我们距离理想的帕累托边界还有一段距离。

EOF（EVM对象格式）是一组主要变更，带来了显著的变化，比如禁止gas可观察性、代码可观察性（即无CODECOPY）和仅允许静态跳转。目标是让EVM能更强大地进行升级，同时保持向后兼容性（因为EOF之前的EVM仍然存在）。

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

它如何与路线图的其他部分交互？ 路线图中的许多「改进」建议其实是简化旧功能的绝佳机会，来看看几个例子：

1. 单槽最终性：这个调整为我们提供了取消委员会、重新设计经济模型及其他权益证明相关的简化空间。

2. 账户抽象：实现账户抽象后，我们可以剔除大量现有的交易处理逻辑，转而使用所有 EOA 可以替代的「默认账户 EVM 代码」。

3. 以太坊状态转移：如果将以太坊状态迁移至二进制哈希树，这能与新版 SSZ 协调一致，从而使所有以太坊数据结构以统一的方式进行哈希处理。

更激进的想法：把协议大部分变成合约代码。

一种极端的以太坊简化策略是保留协议不变，把大部分功能转移到合约代码上。最极端的情况是让以太坊 L1「技术上」仅仅是信标链，同时引入一个最小的虚拟机（比如 RISC-V、Cairo 或更小的专用证明系统），这样其他人就能创建自己的汇总，而 EVM 将成为这些汇总中的第一个。讽刺的是，这与2019-20年执行环境提案的结果完全一致，尽管 SNARK 的出现让实际实施变得更加可行。

另一种温和的方法是维持信标链与当前以太坊执行环境之间的关系不变，但对 EVM 进行就地替换。我们可以选择 RISC-V、Cairo 或其他虚拟机作为新的「官方以太坊 VM」，然后强制将所有 EVM 合约转换为解释原始代码逻辑（无论是通过编译还是解释）的新 VM 代码。理论上，这甚至可以通过将「目标虚拟机」视作 EOF 的一个版本来实现。