复活冲突

然后我们就到了状态过期方案的一个关键难题上：「复活冲突」。复活冲突的概念如下。假设某个账户由地址 A 生成；这个账户过期了；然后，地址 A 又创建了一个新的账户（例如，使用 CREATE2 操作码保证两次生成的账户的地址是同一个）；最后，地址 A 再尝试复活那个最开始的账户。这时候会出现什么情况？

这里有几种可能的解决方案：

1. 显式的「账户合并」流程：类似于规定「除了两个账户的 ETH 余额相累加以外，以旧账户的状态为准」或者「除了累加 ETH 之外，以新账户的状态为准」；甚至于，可以由旧账户的合约代码来规定特殊的合并流程

2. 通过消除同一地址重复部署的功能来确保复活冲突不会发生：也就是调整 CREATE2 的功能，比如在最终哈希成地址的数据原像中包含当前时间，因此即使未来使用同样的数据来生成，也无法得到同样的地址

3. 向状态对象增加一个「存根」，以防止在同一位置生成新账户（上述一树流方法自动实现了这一功能）

4. 要求生成新账户时都必须附带该账户此前未过期的证明：某种意义上等价于存根方案，只不过这种办法是把存根放在状态的一个单独部分中，所以任何想要创建合约账户的用户都必须跟踪这部分状态

（注意，如果我们使用存储槽过期方案，则上述任一解决方案都必须延伸到单个存储槽层面，而不能止步于账户层）

主要的担忧有：（1）会给应用增加很多复杂性，他们需要加入合并的逻辑；（2）这样做了之后，除非在链上「注册」一个地址，否则用户就没法再轻易获得可以与之交互、可以积累资产（例如 ERC20 token）的地址了。未注册的地址是很重要的：任何第一次收到 ETH 的用户都是在使用一个尚未注册的地址。这第 （2） 的担忧的根源是：未注册的地址实际上有了时间限制，如果用户生成了一个地址、收到了资金，但在接下来一年里忘了发送交易（也就是忘了「注册」），那他的资金就会被锁住。

注意，EOA 也不能幸免。虽然看起来能够，因为 EOA 的合并流程比较简单（只需把旧的 ETH 余额加到新的里，对 nonce 则有 EIP 169）这样的方案。不过，这里也有两个问题。首先，账户抽象的目标是用合约来替代 EOA，而账户抽象化的合约的合并流程可能并不简单。其次，会受过期和复活事件影响的不仅有 EOA 本身，还有该 EOA 所参与的应用中的相关存储键（例如 ERC20 token 余额），所以还是需要复杂的合并逻辑。

因此，从我的角度来看，破坏性最小的是某种形式的存根方案。不过，存根方案里存在一个信息理论问题，会导致一些奇怪的结果。为了防止新的状态对象在 N 个已经过期的状态对象位置处创建，一个覆盖（cover）了这 N 个地址（以及 / 或者 存储键）的集合必须是状态的一部分。如果这个集合是信息最小化的（即，只包含了这些地址），那么这个集合的大小会是 O(N)，因此其状态规模也是 O(N)；那么， (责任编辑：admin)