以太坊Purge阶段需要清除什么

最近的 Dencun 硬分叉中不太知名的 EIP 之一是EIP-6780，它删除了操作码SELFDESTRUCT的大部分功能。

该EIP是以太坊协议开发中经常被低估的部分的一个关键示例：通过消除复杂性和添加新的安全保证来简化协议的努力。这是我所说的"PURGE"的一个重要部分：精简以太坊和清除技术债务的项目。将会有更多的EIP具有类似的精神，因此值得得了解EIP-6780如何实现的目标，以及未来Purge中可能会清除哪些其他EIP。

EIP-6780如何简化以太坊协议？

EIP-6780对SELFDESTRUCT的功能进行了微调，它将销毁合约的操作码限制为仅当该合约存在交易期间才执行。这可以防止滥用SELFDESTRUCT合约销毁功能，以及清空代码和存储而导致的潜在问题。尽管这并没有强制执行更为严格的规范，但它引入了两个新变量来实现：交易期间是否存在、合约是否正在被调用。这项变更确保了合约只能在同一交易期间内创建合约并签订协议，以实现更高的可靠性。

1、EIP-6780 后，单个区块中可以编辑的存储槽数有最大数量（大致为：gas limit / 5000）。

2、如果合约在交易或区块开始时具有非空代码，则在该交易或区块结束时它将具有相同的代码。

之前，这些不变量都不是True：

1、SELFDESTRUCT拥有大量存储槽的合约可以在单个区块内清除无限数量的存储槽。这将使Verkle树的实现变得更加困难，并且使以太坊客户端的实现变得更加复杂，因为它们需要额外的代码来有效地处理这种特殊情况。

合约的代码可以通过SELFDESTRUCT从非空变为为空，实际上合约甚至可以在之后立即使用不同的代码重新创建。这使得账户抽象中的交易验证更加困难，因为交易验证需要使用交易中的代码库而不容易受到DoS攻击的影响。

现在，这些不变量都是True，使得构建以太坊客户端和其他类型的基础设施变得更加容易。几年后，希望未来的EIP能够完成这项工作并SELFDESTRUCT完全消除。

哪些其他“purges”正在进行？

• Geth 最近删除了数千行代码，删除了对pre-merge PoW网络的支持。

• 这个 EIP正式体现了这样一个事实：我们不再需要代码来担心“空帐户”（请参阅：EIP-161 ，它引入了这个概念作为上海 DoS 攻击修复的一部分）

• Dencun 中 blob 的存储窗口为 18 天，这意味着以太坊节点只需要约 50 GB 来存储 blob 数据，并且此数量不会随着时间的推移而增加

前两个显著改善了客户端开发人员的体验。后者显著提高了节点运营商的寿命。

还有哪些其他可能需要Purge的东西？

预编译（Precompiles）

预编译是以太坊合约，它没有 EVM 代码，而是具有必须由客户端自己直接实现的逻辑。这个想法是，预编译可用于实现无法在 EVM 中有效实现的复杂形式的密码学。

如今，预编译的使用非常成功，特别是通过椭圆曲线预编译启用基于 ZK-SNARK 的应用程序。然而，还有其他很少使用的预编译：

• RIPEMD-160：引入哈希函数是为了支持与比特币更好的兼容性

• Identity：返回与其输入相同的输出的预编译

• BLAKE2：引入哈希函数是为了支持与 Zcash 更好的兼容性

• MODEXP引入非常大的模幂以支持基于 RSA 的加密

事实证明，对这些预编译的需求远远低于预期。Identity被广泛使用，因为它是复制数据最简单的方法，但自从 Dencun 以来，操作码MCOPY已经取代了它。不幸的是，这些预编译都是共识错误的巨大来源，也是新 EVM 实现的巨大痛苦来源，包括 ZK-SNARK 电路、形式验证友好的实现等。

有两种方法可以删除这些预编译：

• 只需删除预编译即可，例如。EIP-7266删除了 BLAKE2。这很简单，但会破坏任何仍在使用它的应用程序。

• 将预编译替换为执行相同操作的 EVM 代码块（尽管不可避免地会产生更高的 Gas 成本），例如。本草案 EIP就是为了身份预编译而这样做的。这比较困难，但几乎肯定不会破坏使用它的应用程序（除非在极少数情况下，新 EVM 代码的 Gas 成本超过了某些输入的区块 Gas 限制）

历史区块 (EIP-4444)

如今，每个以太坊节点都有望永久存储所有历史区块。长期以来，人们一直认为这是一种非常浪费的方法，并且由于高存储要求而使得运行以太坊节点变得不必要的困难。在 Dencun 中，我们引入了 blob，它只需要存储约 18 天。使用EIP-4444，一段时间后，以太坊区块也将从默认以太坊节点中删除。

需要解决的一个关键问题是：如果旧历史记录并没有被每个节点存储，那么用什么来存储它呢？实际上，区块浏览器等大型实体将会这样做。然而，使 p2p 协议来存储和传递该信息也是可能的，而且并不困难，这对于任务来说更加优化。

以太坊区块链是永久性的，但要求每个节点永远存储所有数据是实现这种永久性的一种非常“矫枉过正”的方式。

一种方法是针对旧历史的简单点对点torrent网络。另一种是针对以太坊使用进行更明确优化的协议，例如门户网络。

或者，以模因格式：

减少运行以太坊节点所需的存储量可以大大增加愿意做节点的人数。EIP-4444 也可以减少节点同步时间，这也简化了许多节点运营商的工作流程。因此，EIP-4444可以大大提高以太坊节点的去中心化。潜在地，如果每个节点默认存储一小部分历史记录，我们甚至可以像今天一样在网络上存储每个特定历史记录的大致相同数量的副本。

日志改革

直接引用这个EIP草案：

日志最初的引入是为了让应用程序能够记录有关链上事件的信息，以便去中心化应用程序（dapp）能够轻松查询这些信息。使用bloom过滤器，dapp 将能够快速浏览历史记录，识别包含与其应用程序相关的日志的几个块，然后快速识别哪些单个事务具有所需的日志。

实际上，这种机制太慢了。几乎所有访问历史记录的 dapp 最终都不是通过对以太坊节点（甚至远程托管节点）的 RPC 调用，而是通过集中式额外协议服务。

我们可以做什么？我们可以删除bloom过滤器，并简化LOG操作码，这样它所做的就是创建一个将哈希值放入状态的值。然后，我们可以构建单独的协议，使用 ZK-SNARK 和增量可验证计算（IVC）来生成可证明正确的“日志树”，它表示给定的所有日志的易于搜索的表topic，以及需要日志和想要的应用程序去中心化可以使用这些单独的协议。

转向SSZ

如今，以太坊的大部分区块结构（包括交易和收据）仍然使用基于RLP和 Merkle Patricia 树的过时格式进行存储。这使得开发使用该数据的应用程序变得不必要的困难。

以太坊共识层已转向更清洁、更高效的SimpleSerialize (SSZ)：

资料来源：https://eth2book.info/altair/part2/building_blocks/merkleization/

但是，我们仍然需要完成转换，并将执行层移至相同的结构。

SSZ 的主要优势包括：

• 规范更加简单和清晰

• 与现状的六叉 Merkle Patricia 树相比，大多数情况下 Merkle 证明的长度缩短了 4 倍

• 与极长的最坏情况相比，Merkle 证明的长度有界（例如，证明合约代码或长收据输出）

• 无需实现复杂的位操作代码（RLP 需要）

• 对于 ZK-SNARK 用例，通常可以重用围绕二元 Merkle 树构建的现有实现

如今，以太坊中存在三种类型的加密数据结构：SHA256 二叉树、SHA3 RLP 哈希列表和十六进制 Patricia 树。一旦我们完成向 SSZ 的过渡，我们将只剩下两个：SHA256 二叉树和 Verkle 树。从长远来看，一旦我们在 SNARKing 哈希方面做得足够好，我们很可能会用使用 SNARK 友好哈希（一种适用于所有以太坊的加密数据结构）的二进制 Merkle 树来取代 SHA256 二叉树和 Verkle 树。

以上是以太坊Purge阶段需要清除什么的详细内容。更多信息请关注PHP中文网其他相关文章！