SELFDESTRUCT 是唯一一个能在单个区块中变更无限个状态对象的操作码

其他所有的操作码都只能操作账户中的单个值或者存储树上的单个 key，所以它们能变更多少固定大小的对象是有限制的（通常，调用一个操作码只能变更一个对象）。但是，SELFDESTRUCT 可以删除整棵存储树。

在目前的状态树结构中，这是可以容忍的。但是，考虑一种特殊的情况：当调用 SELFDESTRUCT 删除许多存储插槽后，下一个事务又在同一个地址上创建一个合约并访问同一些存储槽。为了处理这种情况，需要额外设计复杂的缓存机制。此外，SELFDESTRUCT 还阻碍了我们变更状态存储格式。

以 SELFDESTRUCT 会阻碍的两类状态存储格式为例：

请注意，这不是在空想，从根本上变更状态存储格式（如采用二进制树、Verkle 树等）的讨论已经开始了，如果状态存储的数据结构能够接近单一的的键/值存储结构，并且单个区块中可以变更的状态数量有一个较低的上限，那将大大扩展我们的选择空间。

SELFDESTRUCT 是唯一一个会导致合约代码变动的操作码

如果在一个特定的地址上存储了一段代码，那么这段代码就会永远保留在链上。这样的恒常性质是有用的，因为在构建应用时不需要担心这些代码会出现变动。

账户抽象化（Account abstraction）非常依赖该恒常性质用以支持库调用。因为代码存在变动的可能，还会导致应用的安全性变得复杂很多：2017 年 Parity 的多签钱包就曾因为其引用的库代码合约被偶然删除而彻底瘫痪。

而唯一破坏代码不变性的操作码就是 SELFDESTRUCT （是造成 Parity 多签猝死的罪魁祸首）。

SELFDESTRUCT 是唯一一个可以未经账户同意就能修改账户余额的操作码

SELFDESTRUCT 有一个内置的 “转账” 的功能，其并不走正常的转账流程，因而可以绕过避免合约地址接收 Ether 的守护功能，以及对转账事件的日志记录。这为智能合约钱包埋下了隐患，让一些潜在有用的技巧没法使用，加重了开发者和审计者的心智负担（需要考虑更多的例外条件）。

SELFDESTRUCT 当前的用例

如今 SELFDESTRUCT 有两类重要的应用：