Vitalik：以太坊的可能未来，The Purge

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

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

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

为了使以太坊能够长期维持下去，我们需要对这两种趋势施加强大的反压力，随着时间的推移降低复杂性和膨胀。但与此同时，我们需要保留使区块链变得伟大的关键属性之一：持久性。你可以把一张 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)，基本实现只涉及今天已经完成的工作：Portal 已经存储了包含整个以太坊历史的 ERA 文件。更彻底的实现将涉及实际将其连接到同步过程，这样，如果有人想要同步完整历史记录存储节点或存档节点，即使没有其他存档节点在线存在，他们也可以通过直接同步来实现来自门户网络。

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

如果我们想让节点运行或启动变得极其容易，那么减少历史存储需求可以说比无状态性更重要：在节点需要的 1.1 TB 中，约 300 GB 是状态，剩余的约 800 GB GB 已成为历史。只有实现无状态性和 EIP-4444，才能实现在智能手表上运行以太坊节点并且只需几分钟即可设置的愿景。

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

State expiry

解决什么问题？

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

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

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

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

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

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

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

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

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

• 部分状态过期解决方案
• 基于地址周期的状态到期建议。

Partial state expiry部分状态到期

部分状态到期提案都遵循相同的原则。我们将状态分成块。每个人都永久存储"顶级映射"，