我提议对方法 (2) 进行修改，可以解决以上的问题。正如很多方法 (2) 的提议实现方案所呈现的，账户有「活跃」与「失活」两种状态，失活账户是那些超过一年未被访问过的账户。要访问失活账户，你需要提供见证数据；当失活账户被访问了，该账户会自动解除失活状态 (触及任何账户都会重置它的一年失活期计算)。修改内容如下：

　　我们给每个地址添加一个 32 个字节的 「epoch 前缀」 （会被解译为一个整数）。例如，epoch 前缀是 9 的地址是这样：0x00000009de0b295669a9fd93d5f28d9ec85e40f4cb697bae，以 00000009 作为前缀。

　　默克尔路径会直接依赖 epoch 的前缀而不是它的哈希值 (因此 merkle_path_key = address[:4] + hash(address[4:]) 而不是现在在用的 merkle_path_key = hash(address) 。这确保了「没用过的」地址空间是连续的。

　　除非地址的 epoch 前缀是小于或等于区块链已运行的年数，否则地址不能被使用

　　会增加一个 CREATE3 操作码，它会把 epoch 前缀作为一个参数，并在具有该 epoch 前缀的一个地址上创建一个合约。

　　推荐用户和合约总是使用具有尽可能新的 epoch 前缀来创建账户，甚至设为默认设置，因为肯定会有具有最新 epoch 前缀的全状态仍然是可以访问的。为了还能保有「反事实地址 (counterfactual addresses)」（即在合约代码被发布前，用户在链上 [例如通过发送 ETH 或 ERC20 代币] 或链下 [通过在一个通道里互动] 交互的地址），用旧 epoch 前缀来创建合约还是可能的。但是，对于想要创建反事实地址的用户，如果长期不创建，他们就要负责为该账户存储旧状态的分支。

　　经过多年的运行，预计活跃状态会由两部分构成：(i) 有最新 epoch 前缀的全部地址空间，(ii) 与最近被活跃使用过的账户相对应的特定旧状态

　　请注意，这个方案正常情况下扩展到合约上；事实上，主动遵循这个方案是符合合约自身运作的。因为在这个方案里，地址中代表存储的部分以几个字节为前缀，它们所代表的数字 N 指的是这些数据是在 N 年与这些地址产生关联。这很适合用于存储像代币余额这样的数据。