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

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

· 历史数据：历史上任何时刻进行的任何交易和创建的任何帐户都需要由所有客户端永久存储，并由任何新客户端下载，从而完全同步到网络。这会导致客户端负载和同步时间随着时间的推移不断增加，即使链的容量保持不变。

· 协议功能：添加新功能比删除旧功能容易得多，导致代码复杂性随着时间的推移而增加。

为了使以太坊能够长期维持下去，我们需要对这两种趋势施加强大的反压力，随着时间的推移降低复杂性和膨胀。但与此同时，我们需要保留使区块链变得伟大的关键属性之一：持久性。你可以把一张 NFT、一封交易通话数据中的情书、或者一份包含 100 万美元的智能合约放在链上，进入一个洞穴十年，出来时发现它仍然在那里等待你阅读和交互。为了让 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 天），在此期间每个节点负责存储所有内容，然后建立一个由以太坊节点组成的点对点网络，将旧数据存储在分布式网络方式。

Erasure codes 可用于提高 robustness，同时保持复制因子相同。事实上，Blob 已经进行了纠删码，以支持数据可用性采样。最简单的解决方案很可能是重新使用这种 Erasure codes，并将执行和共识块数据也放入 blob 中。

与现有研究有哪些联系？

· EIP-4444 ；

· Torrents and 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 GB 已成为历史。只有实现无状态性和 EIP-4444，才能实现在智能手表上运行以太坊节点并且只需几分钟即可设置的愿景。

限制历史存储还使得较新的以太坊节点实现更可行，仅支持协议的最新版本，这使它们变得更加简单。例如，现在可以安全地删除许多代码行，因为 2016 年 DoS 攻击期间创建的空存储槽已全部删除。既然转向权益证明已经成为历史，客户可以安全地删除所有与工作量证明相关的代码。

State expiry

解决什么问题？

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

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

它是什么，它是如何工作的

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

1. 效率：不需要大量的额外计算来运行到期过程。

2. 用户友好性：如果有人进入洞穴五年并回来，他们不应该失去对 ETH、ERC 20、NFT、CDP 头寸的访问权……

3. 开发人员友好性：开发人员不必切换到完全不熟悉的思维模型。此外，目前已经僵化且不更新的应用程序应该可以继续正常运行。

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

这些都是以太坊核心开发社区多年来一直在努力解决的问题，包括「区块链租金」和「再生」等提案。最终，我们结合了提案中最好的部分，并集中在两类「已知最不糟糕的解决方案」上：

· 部分状态过期解决方案

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

Partial state expiry 部分状态到期

部分状态到期提案都遵循相同的原则。我们将状态分成块。每个人都永久存储「顶级映射」，其中块为空或非空。仅当最近访问过该数据时才会存储每个块中的数据。有一种「复活」机制，如果不再存储

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

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

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

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

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

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

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

这种设计保留了以太坊当前的大部分属性，不需要额外的计算，允许几乎像现在一样编写应用程序（ERC 20 需要重写，以确保地址周期为 N 的地址余额存储在子合约中，本身有地址周期 N)，解决了「用户进山洞五年」的问题。然而，它有一个大问题：地址需要扩展到 20 字节以上才能适应地址周期。

Address space extension 地址空间扩展

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

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

红色的是版本号。这里橙色的四个零旨在作为空白空间，将来可以容纳分片编号。绿色是地址周期号。蓝色是 26 字节的哈希值。

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

地址空间收缩

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

0xffffffff000169125 d5dFcb7B8C2659029395bdF

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

关键风险领域，即非单一所有者持有的钱包的反事实地址，在今天相对罕见，但随着我们进入多 L2 世界，可能会变得更加常见。唯一的解决方案是简单地接受这种风险，但要确定可能出现问题的所有常见用例，并提出有效的解决方法。

与现有研究有哪些联系？

早期提案

区块链清洁；

再生；

以太坊状态大小管理理论；

无状态和状态过期的一些可能路径；

部分状态到期提案

EIP-7736 ；

地址空间扩展文档

原始提案；

Ipsilon 评论；

博客文章评论；

如果我们失去碰撞抵抗力会破坏什么。

还需要做什么，需要权衡什么？

我认为未来有四种可行的道路：

· 我们做到无状态，并且从不引入状态过期。状态正在不断增长（尽管缓慢：我们可能看不到它 超过 8 TB 数十年），但只需要由相对 特殊类别的用户：甚至 PoS 验证器也不需要状态。

需要访问部分状态的一个功能是包含列表生成，但我们可以以分散的方式完成此操作：每个用户负责维护状态树中包含其自己帐户的部分。当他们广播交易时，他们会广播交易并附带验证步骤期间访问的状态对象的证明（这适用于 EOA 和 ERC-4337 帐户）。然后，无状态验证器可以将这些证明组合成整个包含列表的证明。

· 我们进行部分状态到期，并接受一个低得多但仍然非零的永久状态大小增长率。这个结果可以说类似于涉及对等网络的历史过期提案如何接受每个客户端必须存储较低但固定百分比的历史数据的低得多但仍然非零的永久历史存储增长率。

· 我们通过地址空间扩展来进行状态过期。这将涉及一个多年的过程，以确保地址格式转换方法有效且安全，包括现有应用程序。

· 我们通过地址空间收缩来进行状态过期。这将涉及一个多年的过程，以确保所有涉及地址冲突的安全风险（包括跨链情况）都得到处理。

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

它如何与路线图的其他部分交互？

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

Feature cleanup

它解决什么问题？

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

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

没有任何重大的单一修复可以降低协议的复杂性；这个问题的本质是有许多小的解决办法。

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

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

· RLP → SSZ 转换：最初，以太坊对象是使用称为 RLP 的编码进行序列化的。RLP 是无类型的，并且不必要地复杂。如今，信标链使用 SSZ，它在很多方面都明显更好，包括不仅支持序列化，还支持哈希。最终，我们希望完全摆脱 RLP，并将所有数据类型转移到 SSZ 结构中，这反过来会使升级变得更加容易。当前的 EIP 包括 [ 1 ] [ 2 ] [ 3 ]。

· 删除旧的交易类型：当今的交易类型太多，其中许多可能会被删除。完全删除的一个更温和的替代方案是帐户抽象功能，智能帐户可以通过该功能包含处理和验证旧式交易的代码（如果他们愿意的话）。

· LOG 改革：日志创建布隆过滤器和其他逻辑，增加了协议的复杂性，但实际上并没有被客户端使用，因为它太慢了。我们可以删除这些功能，转而致力于替代方案，例如使用 SNARK 等现代技术的协议外去中心化日志读取工具。

· 最终删除信标链同步委员会机制：同步委员会机制最初是为了实现以太坊的轻客户端验证而引入的。然而，它显着增加了协议的复杂性。最终，我们将能够直接使用 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。

与现有研究有哪些联系？

· 清除的后续步骤；

· 自毁

· SSZ 化 EIPS： [ 1 ] [ 2 ] [ 3 ]；

· 无状态 gas 成本变化；

· 线性内存定价；

· 预编译删除；

· 布隆过滤器移除；

· 一种使用增量可验证计算进行链下安全日志检索的方法（阅读：递归 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 提出的一组主要更改是 EVM 对象格式 (EOF)。EOF 引入了大量的改变，比如禁止 gas 可观察性、代码可观察性（即无 CODECOPY）、仅允许静态跳转。目标是允许 EVM 以具有更强属性的方式进行更多升级，同时保持向后兼容性（因为 EOF 之前的 EVM 仍然存在）。

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

它如何与路线图的其他部分交互？

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

· 切换到单槽最终性使我们有机会取消委员会、重新设计经济学并进行其他与权益证明相关的简化。

· 完全实现账户抽象可以让我们删除大量现有的交易处理逻辑，将其移至所有 EOA 都可以替换的「默认账户 EVM 代码」中。

· 如果我们将以太坊状态转移到二进制哈希树，这可以与新版本的 SSZ 协调一致，以便所有以太坊数据结构都可以以相同的方式进行哈希处理。

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

一个更激进的以太坊简化策略是保持协议不变，但将其大部分从协议功能转移到合约代码。

最极端的版本是让以太坊 L1「技术上」只是信标链，并引入一个最小的虚拟机（例如 RISC-V 、 Cairo 或更最小的专门用于证明系统），允许其他人创建自己的汇总。然后，EVM 将变成这些汇总中的第一个。具有讽刺意味的是，这与 2019-20 年执行环境提案的结果完全相同，尽管 SNARK 使其实际实施起来更加可行。

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

原文链接