更温和的解决方案可以归结为不同形式的「状态过期」方案。必须持续得到访问的状态才能保持「激活状态」；而长期无人问津的状态会变成「失活」（或者叫「过期的」）。具体用什么机制来更新状态，有很多选择（例如预付「租金」，或者只需访问那个状态），但一般原则是，除非某个状态对象被显式地更新，否则就以某种形式处于失活状态。因此，任何创建新状态对象（以及更新已有状态对象）的活动，都只能成为节点在一段时间内的负担，而不像现在这样变成永久负担。

失活状态，故名思义，就不是「状态」的一部分；想要处理区块或创建区块的节点无需存储失活状态。不过，失活状态不是被完全删除了！在所有类型的状态过期提案中，都预设了某种方法可以「复活」已经失活的状态。

一般原则是，激活状态的使用与当前相同，而失活状态则需通过上述无状态客户端的机制来使用。复活一个过期状态对象的事务需要提供一个证据（见证数据），来证明该对象是失活状态的一部分。为了能够生成这样的证据，用户自己需要存储和维护至少一部分失活状态（对应于其所关切的失活状态对象的那部分）。

何时过期

决定过期条件的设计也有很多种。最常见的几种是：

• 直接租金：逐块逐块收取「租金」，直接以每个账户（或其他状态对象）的余额来支付；状态对象的余额降到了零，该账户就过期了。
• 剩余存活时间值：每个状态对象都存储一个「剩余存活时间」值，这个值可以通过支付费用来增加
• 触达即刷新：每个状态对象都存储一个「剩余存活时间」值，并且每逢读取或写入该账户都会增加该值
• 所有状态对象定期过期（例如每 6 个月一次）：也就是 ReGenesis 提案

我自己越来越喜欢「触达即刷新」方案，因为（1）它避免了应用需要创造复杂的经济模型来让用户承担状态租金；以及（2）它保证了激活状态的规模有一个清晰的上限（区块 Gas 上限 / 触达状态对象的 Gas 消耗量 × 状态存活的时长）。让大量状态按照规律的时间间隔过期的方案（也就是 ReGenesis）也有同样的好处，但也有一些有趣的权衡：关键好处是，过期方案更简单（无需遍历整棵状态树而逐个逐个地灭活状态对象），但关键不足是，跨过一个过期时点后，你再激活自己的状态对象时，需要多少见证数据会跟你触达状态对象的时间点有关。

账户层面的过期 vs. 存储槽层面的过期

状态过期的逻辑既可以运营到账户层面，也可以运用到单个存储槽层面。当前，我强烈偏向于在存储槽层面实现状态过期方案。因为很多合约账户的存储槽数量是不受限制的，任意用户都能加入合约并增加合约名下的存储槽的数量（例如，空投就是一个已经出现过的案例）。不管使用什么样的账户层过期方案，想要实际限制状态的规模，租金的数量都必须与合约内存储槽的数量成比例（或者存活时间与之成反比）。结果是，用户还是能够仅支付一次性的费用就给合约及其用户施加 (责任编辑：admin)