作者：Ethereum创始人Vitalik；编译：邓通，金色财经

按：本文为Ethereum创始人Vitalik近期发表的“Ethereum协议的未来发展”系列文章的第五部分“PossiblefuturesoftheEthereumprotocol,part5:ThePurge”，第四部分见“Vitalik：Ethereum的未来TheVerge”。第三部分见“Vitalik：EthereumTheScourge阶段的关键目标”，第二部分见“Vitalik：TheSurge阶段Ethereum协议应该怎么发展”，第一部分见“EthereumPoS还有哪些可以改进”。以下为第五部分全文：

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

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

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

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

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

https://eips.ethereum.org/EIPS/eip-4444

Torrents和EIP-4444：https://ethresear.ch/t/torrents-and-eip-4444/19788

Portal网络：https://ethereum.org/en/developers/docs/networking-layer/portal-network/

Portal网络和EIP-4444：https://github.com/ethereum/portal-network-specs/issues/308

Portal中SSZ对象的分布式存储和检索：https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575

如何提高gas限制（范式）：https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2剩下要做什么，又有哪些权衡？

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

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

我们要多努力才能确保最大数量的节点确实存储了所有数据？

我们将历史存储与协议的集成程度有多深？

对于(1)来说，最严谨的方法将涉及保管证明：实际上要求每个权益证明验证者存储一定比例的历史记录，并定期通过加密方式检查他们是否这样做。更温和的方法是为每个客户端存储的历史记录百分比设定一个自愿标准。

对于(2)，基本实现仅涉及今天已经完成的工作：Portal已经存储了包含整个Ethereum历史记录的ERA文件。更彻底的实现将涉及将其实际连接到同步过程，这样如果有人想要同步完整历史记录存储节点或存档节点，即使没有其他存档节点在线，他们也可以通过直接从Portal网络同步来执行此操作。它如何与路线图的其他部分互动？

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

限制历史存储也使较新的Ethereum节点实现更可行地仅支持协议的最新版本，这使它们变得更加简单。例如，由于2016年DoS攻击期间创建的空存储槽已全部被删除，因此可以安全地删除许多代码行。既然切换到权益证明已成为历史，客户端可以安全地删除所有与工作量证明相关的代码。状态数据过期它解决了什么问题？

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

状态比历史记录更难“过期”，因为EVM的设计基本假设是，一旦创建了状态对象，它将永远存在，并且可以随时被任何交易读取。如果我们引入无状态，有人认为这个问题可能没那么糟糕：只有一类专门的区块构建器才需要实际存储状态，所有其他节点（甚至包含列表生成！）都可以无状态运行。然而，有人认为我们不想过分依赖无状态，最终我们可能希望状态过期以保持Ethereum的去中心化。它是什么？它是如何工作的？

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

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

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

开发者友好性：开发人员不必切换到完全陌生的思维模型。此外，如今僵化且不更新的应用程序应该继续合理地运行。

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

这些都是Ethereum核心开发社区多年来一直在努力解决的问题，包括“Blockchain租金”和“再生”等提案。最终，我们结合了提案中最好的部分，并集中于两类“已知最不坏的解决方案”：

部分状态到期解决方案。

基于地址周期的状态到期提案。部分状态过期

部分状态过期提案都遵循相同的原则。我们将状态分成块。每个人都永久存储“顶层映射”，其中哪些块是空的或非空的。每个块中的数据仅在最近访问过的情况下才会存储。有一个“复活”机制，如果某个块不再存储，任何人都可以通过提供数据是什么的证明来恢复该数据。

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

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

这种设计保留了Ethereum的大部分当前属性，额外计算量非常小，允许应用程序几乎像现在一样编写（ERC20需要重写，以确保地址周期为N的地址的余额存储在本身具有地址周期N的子合约中），并解决了“用户进入洞穴五年”的问题。然而，它有一个大问题：地址需要扩展到20个字节以上才能适合地址周期。地址空间扩展

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

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

红色是版本号。此处橙色的四个零表示空白，将来可以容纳分片号。绿色是地址周期号。蓝色是26字节哈希值。

此处的关键挑战是向后兼容性。现有合约是围绕20字节地址设计的，并且通常使用紧密字节打包技术，明确假设地址正好是20字节长。解决这个问题的一个想法是使用转换图，其中与新式地址交互的旧式合约将看到新式地址的20字节哈希值。但是，要确保其安全，需要付出相当大的努力。地址空间收缩

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

0xffffffff000169125d5dFcb7B8C2659029395bdF

这种方法做出的关键牺牲是，它为反事实地址引入了安全风险：持有资产或权限但其代码尚未发布到链上的地址。风险涉及有人创建一个地址，该地址声称拥有一段（尚未发布的）代码，但还有另一段有效代码，该代码的哈希值指向同一地址。计算这样的碰撞今天需要280个哈希值；地址空间收缩将把这个数字减少到非常容易获得的256个哈希值。

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

早期提案

Blockchain租用费：https://github.com/ethereum/EIPs/issues/35

Regenesis：https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582

Ethereum状态大小管理理论：https://hackmd.io/@vbuterin/state_size_management

无状态和状态过期的几种可能路径：https://hackmd.io/@vbuterin/state_expiry_paths

部分状态过期提案

EIP-7736：https://eips.ethereum.org/EIPS/eip-7736

地址空间扩展文档

原始提案：https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485

Ipsilon评论：https://notes.ethereum.org/@ipsilon/address-space-extension-exploration

博客文章评论：https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6

如果我们失去碰撞阻力会发生什么：https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356还剩下什么要做？需要权衡什么？

我认为未来有四条可行的路径：

我们实行无状态，并且从不引入状态过期。状态在不断增长（尽管增长缓慢：几十年内我们可能都不会看到它超过8TB），但只需要由相对专业的用户类别持有：甚至PoS验证者也不需要状态。

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

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

我们确实声明了到期日期，并扩展了地址空间。这将涉及一个多年的过程，以确保地址格式转换方法有效且安全，包括对于现有应用程序。

我们确实声明了到期日期，并收缩了地址空间。这将涉及一个多年的过程，以确保处理涉及地址冲突（包括跨链情况）的所有安全风险。

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

执行状态到期可能会使从一种状态树格式到另一种状态树格式的转换变得更容易，因为不需要转换过程：您可以简单地开始使用新格式制作新树，然后稍后进行硬分叉以转换旧树。因此，虽然状态到期很复杂，但它确实有助于简化路线图的其他方面。功能清理它解决了什么问题？

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

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

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

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

RLP→SSZ转换：最初，Ethereum对象使用一种称为RLP的编码进行序列化。如今，信标链使用SSZ，它在许多方面都明显更好，包括不仅支持序列化，还支持哈希。最终，我们希望完全摆脱RLP，并将所有数据类型移至SSZ结构，这反过来会使升级变得更加容易。目前为此提出的EIP包括[1][2][3]。

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

LOG改革：日志创建bloom过滤器和其他逻辑，增加了协议的复杂性，但由于速度太慢，客户端实际上不会使用它。我们可以删除这些功能，而是将精力投入到替代方案中，例如使用SNARK等现代技术的协议外去中心化日志读取工具。

最终取消信标链同步委员会机制：同步委员会机制最初是为了实现Ethereum的轻客户端验证而引入的。然而，它增加了协议的复杂性。最终，我们将能够使用SNARK直接验证Ethereum共识层，这将消除对专用轻客户端验证协议的需求。通过创建更“原生”的轻客户端协议，该协议涉及验证来自Ethereum共识验证器随机子集的签名。

数据格式协调：今天，执行状态存储在MerklePatricia树中，共识状态存储在SSZ树中，并且blob以KZG承诺的形式提交。在未来，为区块数据和状态创建单一统一格式是有意义的。这些格式将涵盖所有重要需求：(i)无状态客户端的简单证明，(ii)数据的序列化和擦除编码，(iii)标准化数据结构。

删除信标链委员会：最初引入此机制是为了支持特定版本的执行分片。相反，我们最终通过L2和blob进行分片。因此，委员会是不必要的，因此正在努力将其删除。

删除混合字节序：EVM是大端字节序，共识层是小端字节序。重新协调并使所有内容都为大端字节序（可能是大端字节序，因为EVM更难更改）可能是有意义的。

现在，EVM内部的一些示例：

简化gas机制：当前的gas规则尚未得到很好的优化，无法明确限制验证区块所需的资源数量。这方面的关键示例包括(i)存储读/写成本，旨在限制区块中的读/写次数，但目前非常随意，以及(ii)内存填充规则，目前很难估计EVM的最大内存消耗。建议的修复包括无状态gas成本更改，将所有与存储相关的成本协调为一个简单的公式，以及内存定价建议。

删除预编译：Ethereum当今拥有的许多预编译既不必要地复杂又相对未使用，并且占共识失败险情的很大比例，但实际上并未被任何应用程序使用。处理此问题的两种方法是(i)直接删除预编译，以及(ii)用实现相同逻辑的（不可避免地更昂贵的）EVM代码替换它。此EIP草案建议首先对身份预编译执行此操作；稍后，RIPEMD160、MODEXP和BLAKE可能会被删除。

删除gas可观察性：使EVM执行不再能够看到它还剩下多少gas。这会破坏一些应用程序（最明显的是赞助交易），但将来可以更轻松地进行升级（例如，对于更高级的多维gas版本）。EOF规范已经使gas不可观察，但为了有助于协议简化，EOF需要成为强制性的。

静态分析的改进：今天的EVM代码很难进行静态分析，特别是因为跳转可以是动态的。这也使得制作优化的EVM实现（将EVM代码预编译成其他语言）变得更加困难。我们可以通过删除动态跳转（或使它们更加昂贵，例如，gas成本与合约中JUMPDEST的总数成线性关系）来解决这个问题。EOF就是这样做的，但从中获得协议简化收益需要使EOF成为强制性的。现有哪些研究？

Purge的后续步骤：https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA

SELFDESTRUCT：https://hackmd.io/@vbuterin/selfdestruct

SSZ-ificationEIPS：[1][2][3]

无状态gas成本变化：https://eips.ethereum.org/EIPS/eip-4762

线性内存定价：https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw

预编译删除：https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg

Bloom过滤器删除：https://eips.ethereum.org/EIPS/eip-7668

一种使用增量可验证计算进行链下安全日志检索的方法（阅读：递归STARK）：https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw还要做什么，又有哪些权衡？

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

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

步骤1：开始讨论删除功能X。

步骤2：进行分析以确定删除X对应用程序的破坏程度，根据结果，选择(i)放弃这个想法，(ii)按计划进行，或(iii)确定一种经过修改的“破坏性最小”的删除X的方法并继续进行。

步骤3：制定正式的EIP以弃用X。确保流行的高级基础设施（例如编程语言、钱包）尊重这一点并停止使用该功能。

步骤4：最后，实际删除X。

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

针对EVM提出的一组主要更改是EVM对象格式(EOF)。EOF引入了大量更改，例如禁止gas可观察性、代码可观察性（即无CODECOPY）、仅允许静态跳转。目标是允许EVM进行更多升级，以具有更强大的属性，同时保持向后兼容性（因为EOF之前的EVM仍然存在）。

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

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

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

完全实现账户抽象让我们可以删除许多现有的交易处理逻辑，方法是将其移入一段“默认账户EVM代码”，所有EOA都可以用它替换。

如果我们将Ethereum状态移动到二进制哈希树，这可以与新版本的SSZ协调一致，以便所有Ethereum数据结构都可以以相同的方式进行哈希处理。更激进的方法：将协议的大部分内容转化为合约代码

更激进的Ethereum简化策略是保持协议原样，但将协议的大部分内容从协议功能转变为合约代码。

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

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

特别感谢JustinDrake、TimBeiko、MattGarnett、PiperMerriam、MariusvanderWijden和TomaszStanczak的反馈和评论。