Tree rot

解决这个问题的唯一办法就是覆盖超过那 N 个账户的信息；实际上，我们将不得不让整棵树都变得不可访问（再次提醒，这就是一树流解决方案的实质：如果两个账户过期了，它们之间的所有空间都会隐式过期（ if two accounts get expired, all the space in between them also implicitly gets expired））。

而这里还有一个问题：这产生了一种形式的「树发霉（tree rot）」，随着时间推移，对于新帐户的创建来说，状态树的所有部分都是不可访问的，至少对那些没有跟踪该区域过期状态的用户来说是这样的。

而树发霉导致的次生问题也必须解决。举个例子：如果一个合约要创建子合约，它必须能够在要么未发霉，要么用户具有见证数据的状态区域创建合约（也许需要用户提供的「提示」）。树发霉问题的一个解决方案见此处：持续地开放状态的新区域以供账户创建。另一种思路是每个用户都选择状态的某些区域（例如状态的 1/256），跟踪该区域的变化（包括过期状态）以便能创建见证消息，并且只在该区域创建帐户。

树发霉的另一个问题是，它需要一个显式的数据结构来存储和检查范围。如果一棵树有能够放在节点中、指明该节点以下的哪些部分已经过期的数据（就像一树流解决方案所用的那样），那是最好的，但一个键值对存储要做到这一点还是相当有难度的。

回头再看强无状态性

在状态过期方案中使用树结构所产生的许多问题，都可以被追溯到这样一个事实：我们需要对哪些状态是活跃的、哪些状态是失活的，达成共识。在二树流模式中，这一点更加明显；但即使是在一树流模式中，状态树上也需要有显式的标记，以便近期使用快速同步下载了状态的以太坊节点能够确定一笔尝试访问某个账户、但又没有提供见证消息的交易，应该成功还是失败。那我们能不能做到不需要明确这个区别呢？

如果我们实现了完全的无状态性，然后能帮助交易发送者和区块生产者可靠地获得见证消息生成所需的状态，不就解决这个问题了吗？那什么办法能帮助交易发送者和区块生产者做到这些呢？

一种自然而然的办法是：网络中的节点都仅保存状态树的一部分，例如，在过去一年中访问到的那部分。只需在客户端设定中加入一个自愿的设定即可。如果我们想要更可靠一些，我们可以通过引入一种 proof of custody 方案，强制至少矿工（后面就是 PoS 的验证者）存储一些数据。

有一点需要注意：如果共识层不能感知哪些状态是活跃的、哪些状态是失活的，那访问近期状态和老旧状态的 Gas 开销就是一样的。这会导致两个结果： (责任编辑：admin)