最近的Dencun硬分叉中不太知名的EIP之一是EIP-6780，它删除了操作码SELFDESTRUCT的大部分功能。
该EIP是以太坊协议开发中经常被低估的部分的一个关键示例：通过消除复杂性和添加新的安全保证来简化协议的努力。这是我所说的PURGE的一个重要部分：精简以太坊和清除技术债务的项目。将会有更多的EIP具有类似的精神，因此值得了解EIP-6780如何实现的目标，以及未来Purge中可能会清除哪些其他EIP。
EIP-6780减少了操作码SELFDESTRUCT的功能，它会销毁调用它的合约并清空其代码和存储，因此只有在同一交易期间创建合约时它才有效。这本身并没有降低规范的复杂性。然而，它确实通过引入两个新的不变量来改进实现：
1、EIP-6780后，单个区块中可以编辑的存储槽数有最大数量（大致为：gaslimit/5000）。
2、如果合约在交易或区块开始时具有非空代码，则在该交易或区块结束时它将具有相同的代码。
之前，这些不变量都不是True：
1、SELFDESTRUCT拥有大量存储槽的合约可以在单个区块内清除无限数量的存储槽。这将使Verkle树的实现变得更加困难，并且使以太坊客户端的实现变得更加复杂，因为它们需要额外的代码来有效地处理这种特殊情况。
2、合约的代码可以通过SELFDESTRUCT从非空变为空，事实上合约甚至可以在之后立即用不同的代码重新创建。这使得账户抽象钱包中的交易验证更难使用代码库而不容易受到DoS攻击。
现在，这些不变量都是True，使得构建以太坊客户端和其他类型的基础设施变得更加容易。几年后，希望未来的EIP能够完成这项工作并SELFDESTRUCT完全消除。
Geth最近删除了数千行代码，删除了对pre-mergePoW网络的支持。
这个EIP正式体现了这样一个事实：我们不再需要代码来担心空帐户（请参阅：EIP-161，它引入了这个概念作为上海DoS攻击修复的一部分）
Dencun中blob的存储窗口为18天，这意味着以太坊节点只需要约50GB来存储blob数据，并且此数量不会随着时间的推移而增加
前两个显著改善了客户端开发人员的体验。后者显著提高了节点运营商的寿命。
预编译是以太坊合约，它没有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限制）
如今，每个以太坊节点都有望永久存储所有历史区块。长期以来，人们一直认为这是一种非常浪费的方法，并且由于高存储要求而使得运行以太坊节点变得不必要的困难。在Dencun中，我们引入了blob，它只需要存储约18天。使用EIP-4444，一段时间后，以太坊区块也将从默认以太坊节点中删除。
需要解决的一个关键问题是：如果旧历史记录并没有被每个节点存储，那么用什么来存储它呢？实际上，区块浏览器等大型实体将会这样做。然而，使p2p协议来存储和传递该信息也是可能的，而且并不困难，这对于任务来说更加优化。
以太坊区块链是永久性的，但要求每个节点永远存储所有数据是实现这种永久性的一种非常矫枉过正的方式。
一种方法是针对旧历史的简单点对点torrent网络。另一种是针对以太坊使用进行更明确优化的协议，例如门户网络。
或者，以模因格式：
减少运行以太坊节点所需的存储量可以大大增加愿意做节点的人数。EIP-4444也可以减少节点同步时间，这也简化了许多节点运营商的工作流程。因此，EIP-4444可以大大提高以太坊节点的去中心化。潜在地，如果每个节点默认存储一小部分历史记录，我们甚至可以像今天一样在网络上存储每个特定历史记录的大致相同数量的副本。
直接引用这个EIP草案：
日志最初的引入是为了让应用程序能够记录有关链上事件的信息，以便去中心化应用程序（dapp）能够轻松查询这些信息。使用bloom过滤器，dapp将能够快速浏览历史记录，识别包含与其应用程序相关的日志的几个块，然后快速识别哪些单个事务具有所需的日志。
实际上，这种机制太慢了。几乎所有访问历史记录的dapp最终都不是通过对以太坊节点（甚至远程托管节点）的RPC调用，而是通过集中式额外协议服务。
我们可以做什么？我们可以删除bloom过滤器，并简化LOG操作码，这样它所做的就是创建一个将哈希值放入状态的值。然后，我们可以构建单独的协议，使用ZK-SNARK和增量可验证计算（IVC）来生成可证明正确的日志树，它表示给定的所有日志的易于搜索的表topic，以及需要日志和想要的应用程序去中心化可以使用这些单独的协议。
如今，以太坊的大部分区块结构（包括交易和收据）仍然使用基于RLP和MerklePatricia树的过时格式进行存储。这使得开发使用该数据的应用程序变得不必要的困难。
以太坊共识层已转向更清洁、更高效的SimpleSerialize(SSZ)：
资料来源：https://eth2book.info/altair/part2/building_blocks/merkleization/
但是，我们仍然需要完成转换，并将执行层移至相同的结构。
SSZ的主要优势包括：
规范更加简单和清晰
与现状的六叉MerklePatricia树相比，大多数情况下Merkle证明的长度缩短了4倍
与极长的最坏情况相比，Merkle证明的长度有界（例如，证明合约代码或长收据输出）
无需实现复杂的位操作代码（RLP需要）
对于ZK-SNARK用例，通常可以重用围绕二元Merkle树构建的现有实现
如今，以太坊中存在三种类型的加密数据结构：SHA256二叉树、SHA3RLP哈希列表和十六进制Patricia树。一旦我们完成向SSZ的过渡，我们将只剩下两个：SHA256二叉树和Verkle树。从长远来看，一旦我们在SNARKing哈希方面做得足够好，我们很可能会用使用SNARK友好哈希（一种适用于所有以太坊的加密数据结构）的二进制Merkle树来取代SHA256二叉树和Verkle树。
以上就是以太坊Purge阶段需要清除什么的全部内容，望能这篇以太坊Purge阶段需要清除什么可以帮助您解决问题，能够解决大家的实际问题是非常好学习网一直努力的方向和目标。