• 我们给每个地址添加一个 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 年与这些地址产生关联。这很适合用于存储像代币余额这样的数据。