意见 | 以太坊状态规模管理的提案（第 2 部分）

从状态树中删除与安排状态树的“退休”部分

区分不同状态过期提议的另一个技术角度是“一树流”和“二树流”。 换句话说，我们是不是像现在一样只有一棵状态树，但是把一些状态标记为过期了； 或者直接从主状态树中移除非活动状态并将其转移到另一个仅包含过期状态的专用（树（或其他数据）？

一书流

- 活动节点标记为白色，非活动节点标记为灰色 -

请注意，即使是树中的中间节点也将被标记为活动或失败（或者，更实际地，每个节点将被标记为停用日期，因此可以轻松检查活动）； 标记在状态树上的每个节点（叶节点和中间节点）上与 Done 一起使用。

二竖流

- 白树包含活动状态； 灰色树存储非活动状态 -

树状流程的好处是，至少它的工作方式看起来和当前的状态树很像，而且灭活和复活的过程也比较简单：复活过程只需要刷新状态树的“过期日期”参数即可树上的相关节点，并且停用是自动的。 但它也有缺点：它需要一个可以在节点中以这种方式存储中间信息的树结构，并且它不能很好地扩展到 Verkle 树。 另外，它需要额外的Merkle证明元素，不仅要能够下降到叶子节点，还要能够在中间节点停止（当它需要证明某部分状态已经过期时）。

二叉树流的优势在于，当前的纯状态累加器形式可以支持这种方案，而无需为每个节点添加元数据。 缺点是它需要对整个协议进行一些更深层次的更改，并且需要一个明确的过程来使状态失效（因此过期不再是自动的）。 此外，它没有为复活冲突困境提供内置解决方案（见下一节），因此需要在两种方法之间做出选择。

请注意，在二叉树流中，用于存储失活状态的数据结构不一定是树。 其实完全可以有这样的设计：当一个状态对象需要被激活时，只需要提供一个Merkle树指向该对象被去激活时的收据，并附上一些密码学证据来证明对象之前没有被销毁过。 复活（或最近重新过期），你可以。

复活冲突

然后我们来到状态过期方案难题的关键部分：“复活冲突”。 复活冲突的概念如下。 假设一个账户是由地址A生成的； 该帐户已过期； 然后，地址A创建一个新的账户（比如使用CREATE2操作代码，保证两次生成的账户地址相同）； 最后，地址A再次尝试复活原账号。 这时候会发生什么？

以下是几种可能的解决方案：

明确的“合并账户”过程：类似于“除两个账户的ETH余额相加外，以旧账户状态为准”或“除ETH累积外，以新账户状态为准”的规则为准”; even 因此，旧账户的合约代码可以指定一个特殊的merge过程，通过消除重复部署同一个地址来保证复活不会发生冲突：即调整CREATE2的功能，比如在data preimage中最后hash到地址中包含当前时间，所以即使以后用同样的数据生成，也不能得到同样的地址 当需要生成新账户时，必须附上证明之前账户没有过期：从某种意义上说，它等同于存根方案，只是这种方法将存根放在状态的一个单独部分，所以任何想要创建合约账户的人都必须跟踪这部分状态（请注意，如果我们使用存储槽过期方案，上述任何解决方案都必须扩展到单个存储槽级别，并且不能停止在帐户级别）。 主要关注的是： (1) 会给应用程序增加很多复杂性，他们需要添加合并的逻辑； (2) 这样做之后，除非一个地址被“注册”在链上，否则用户将无法再轻易获得与之交互和积累资产（如ERC20代币）的地址。 未注册地址很重要：任何首次接收 ETH 的用户都使用未注册地址。

这（2）个顾虑的根源在于，未注册地址其实是有时间限制的，如果用户生成地址，收到资金，但忘记在下一年内发送交易（即忘记“注册”），那么他的资金将被锁定。 请注意，EOA 并非免疫。 虽然看起来是可以的，因为EOA的合并过程比较简单（只需要将旧的ETH余额加到新的上，nonce就有EIP 169）。 但是，这里也存在两个问题。 首先，账户抽象的目标是用合约代替EOA，而账户抽象合约的合并过程可能并不简单。 其次，不仅EOA本身会受到过期和复活事件的影响，EOA参与的应用中的相关存储密钥（如ERC20代币余额）也会受到影响，因此仍然需要复杂的合并逻辑。 因此，从我的角度来看，破坏性最小的是某种形式的存根方案。 然而，存根方案中存在一个信息论问题，导致了一些奇怪的结果。 为了防止在 N 个过期状态对象的位置创建新的状态对象，覆盖这 N 个地址（和/或存储密钥）的集合必须是状态的一部分。 如果集合是信息最小化的（即仅包含这些地址），则集合的大小将为 O(N)，因此状态的大小将为 O(N)； 那么 active state 的大小就会和 disabled state 的大小一样 live state 的大小是成正比的，所以我们其实并没有解决这个问题。

Tree rot 解决这个问题的唯一方法是覆盖这 N 个帐户之外的信息； 实际上，我们必须使整棵树都无法访问（同样，这是树腐烂解决方案的本质：如果两个帐户过期，则它们之间的所有空间也会隐式过期））。 这就是问题所在：这会产生一种“树腐烂”的形式，随着时间的推移，状态树的所有部分都变得无法访问以创建新帐户，至少对于那些不跟踪区域过期状态的用户来说是这样。 树霉引起的次生问题也必须解决。 例如：如果合约要创建子合约，它必须能够在未发霉或用户有证明数据（可能带有用户提供的“提示”）的状态区域中创建合约。 可以在这里找到树模问题的解决方案：新区域不断开放以创建帐户。 另一种思路是，每个用户选择状态的某个区域（比如状态的 1/256），跟踪该区域的变化（包括过期状态）以便创建证明，并且只在该区域创建帐户。 tree musty 的另一个问题是它需要一个明确的数据结构来存储和检查范围。 最好是一棵树有数据可以放在一个节点中，指示该节点下面的哪些部分已经过期（就像单树流式解决方案使用的那样），但是键值存储做到这一点仍然相当困难。

回顾强无状态

在状态过期方案中使用树结构引起的许多问题都可以追溯到这样一个事实，即我们需要就哪些状态是活跃的，哪些是不活跃的达成一致。 在二叉树流模式中，这一点更为明显； 但即使在单树流模式中，也需要在状态树上进行显式标记，以便最近使用快速同步下载状态的以太坊节点可以识别尝试在不提供证明的情况下访问帐户的交易是否应该成功或失败。 那么我们能不能不弄清楚这个区别呢？ 如果我们实现完全无状态，那么帮助交易发送者和区块生产者可靠地获得证明消息生成所需的状态，不就解决了这个问题吗？ 那么什么可以帮助交易发送者和区块生产者做到这一点呢？ 一种自然的做法是网络中的每个节点只保存状态树的一部分，例如过去一年访问过​​的部分。 只需在客户端设置中添加一个自愿设置即可。 如果我们想要更可靠，我们可以通过引入监管证明方案来强制至少矿工（后来的 PoS 验证者）存储一些数据。 需要注意的一点是：如果共识层无法感知哪些状态是活跃的，哪些状态是不活跃的，那么访问最近状态和旧状态的 gas 开销是相同的。 这将导致两个后果：访问最近状态的 gas 成本也将需要进一步增加，并且包含证明消息的区块大小的上限可能非常大，如果一个区块充满了访问旧状态的交易状态（大约 800 字节 * 12.5 m gas / 每次访问 2400 gas ~= 4.1 MB，假设 EIP-2929 的实现，转换为二叉树）如果我们想避免这些缺点，我们需要跟踪共识中的哪些状态对象（包括尚未填充的地址空间区域）处于活动状态，这使我们回到接近状态过期方案的属性。 这再次表明“无状态与状态到期（状态租金）”是一个频谱，一个复杂的权衡空间，而不是非此即彼的选择。

Rollup 也需要并且可以使用相同的解决方案

以太坊的一个重要的中期可扩展性解决方案是 rollups()。 然而以太坊合约代码长度，rollup 本身不再需要担心状态数据的大小； 事实上，rollup 系统的状态大小与以太坊链本身的状态大小完全相同。 幸运的是以太坊合约代码长度，如果我们能想出一个解决方案，至少 EVM rollup（试图尽可能复制以太坊运行时的 rollup 方案）可以使用相同的解决方案来解决其内部状态的大小问题。 因此，状态大小管理是对汇总、分片和其他扩展策略的补充。 （译者注：个人认为这里的“互补”二字严重误导。）

综上所述

状态大小是一个日益严重的问题，状态大小的解决方案也可以为大幅提高区块 gas 限制铺平道路。 我们应该就某种形式的状态到期达成一致并实施它。 然而，不同解决方案之间存在重大的技术权衡，特别是如果我们还想保持当前设计的一些重要属性。 我们可能需要牺牲的一些特性包括： 如果我们准备好做出牺牲，一些程序可以很快开始实施。 另一方面，也许我们可以及时修补或更好地整合这些概念，减少问题，特别是使它们在技术上更容易实现（例如，允许使用“纯”键值存储）。 我们应该更好地了解我们更愿意/不愿意接受哪些牺牲，并继续积极致力于改进建议。

（结束）

（本文链接较多，可点击左下方“阅读原文”从EthFans网站获取）

原文链接：

@HWeNw8hNRimMm2m2GH56Cw/state_size_management