要解决这个问题，合约要么加入复杂的内部逻辑，将存储操的租金「转嫁」给用户，要么重新设计自己合约的模式，转向使用 CREATE2 操作码创建新的合约并使用这些合约来充当存储槽。不管是哪种办法，最后都会变成等价于存储槽层面的过期方案。因此，我个人认为，我们应该仅在合约存储槽层面实现状态过期方案。

但是，存储槽层面的过期方案也有自己的缺点：每个存储槽都要增加一个元数据，指明它何时过期（或者说是否已经失活），这也意味着「复活冲突问题」（详见下文）不仅会影响账户，也会影响存储槽。

从状态树上移除 vs. 给状态树安排一个「退休」部分

另一个区分不同状态过期提议的技术角度是「一树流」和「二树流」。也就是说，我们到底是像现在这样，只有一棵状态树，只不过把某些状态标记为过期；还是直接把失活的状态从主状态树上移除，转移到另一棵专门的（只包含过期状态的）树（或者其他数据）上？

一树流

激活节点以白色标记，失活节点以灰色标记

注意，即使是树上的中间节点，也会被标记为激活或者失火（或者，更现实一点的方案，每个节点都会带有失活日期的标记，所以能够容易检查其活性）；标记工作可以在状态树上的每个节点（叶子节点和中间节点）处完成。

二树流

白色的树包含激活状态；灰色的树存储失活状态

一树流的好处是，最起码，其工作方式看起来会跟当前的状态树相似，失活和复活的流程也比较简单：复活流程只需刷新树上相关节点的「过期日期」参数，而失活则是自动化的。但它的缺点在于：它需要一种能够在节点中以此种方式存储过渡信息（intermediate information）的树结构，而且不能很好地扩展到 Verkle 树。此外，它还需要额外的默克尔证明元件，不仅要能够下沉到叶子节点，还要能够（在需要证明某部分状态已经过期时）停在中间节点处。

二树流的好处是：当前的、形式纯粹的状态累加器就能支持这类方案，而无需为每个节点增加元数据。缺点是，它需要对整个协议做一些更深层次的变更，而且需要一个显式的流程来灭活状态（所以过期不再是自动化的了）。另外，它也没有为复活冲突两难（见下一节）提供内置的解决方案，所以需要在两种办法中作出选择。

注意，在二树流中，存储失活状态的数据结构不是非树不可。事实上，完全有可能出现这样一种设计：需要复活一个状态对象时，只需提供一个指向该对象失活时候收据的默克尔树，再附上一些密码学证据，证明此前该对象未被复活过（或者最近又重新过期），即可。 (责任编辑：admin)