以太坊国家规模管理建议

以太坊协议面临的最长期和未解决的挑战之一是由不断增长的状态数据规模引起的问题。以太坊区块链上的许多操作（创建账户、写入合约槽、向新账户发送ETH……）所有节点都会向以太坊添加状态内容（即向状态数据添加数据对象），所有节点都必须存储全部状态数据，以便验证新块并制造新块。这些操作只需要事务的发送方支付以用气量计量的一次***费，但由于节点需要存储新的数据（未来的节点也需要在同步过程中下载数据），会给整个网络带来**性的持久性成本。

这是系统设计中的一个严重不平衡，这可能会使以太坊系统越来越难以使用，因为该状态充满了不再有用的“垃圾数据”。本文的目的是详细说明问题的根源，以及解决问题的一些方法。如果我们能够实施一个解决方案，它将为安全和大幅度提高区块气上限铺平道路。

本文讨论的研究领域仍在进行中，随时可能出现更新、更好的想法和更优雅的权衡。

导语：有什么问题？

“状态”是指节点要处理新的块和事务必须存储的信息。国家与“历史”完全不同，历史是关于过去时间的信息。节点可以保存这些信息以备将来重播或存档，但无需处理区块链。

在以太坊协议中，状态信息包括：

ETH账户余额和暂记（序列号）

智能合约代码

智能合约存储

与一致性机制相关的数据（最近的块哈希值、tert块；兴趣证明的一致性数据还包括验证者的公钥及其记录在信标链上的活动等）

历史信息由旧块和收据组成。EVM中没有允许您访问旧块、旧事务以及内容和收据的输出的操作码，因此节点丢弃这些数据，并且仍然可以验证新块，因此这些是历史信息。

上述状态信息列表中的**一项——与共识机制相关的数据——经过精心设计，以限制其规模，因此我们无需担心。但前三项会让人有远大的想法。随着时间的推移，这三类状态信息的规模将不断扩大，因为新用户将继续加入网络，他们将创建新帐户、新合同、加入合同、接收代币等等。

困难在于，许多状态在被使用后会静静地躺在那里（它们不会再被触摸）；一旦用户停止应用程序，就会生成一些“垃圾状态”——它们将不再被使用，但它们将始终存在于那里。

理论上，用户可以“拒绝登陆”。用户只能使用selfstruct发布当他们不能再使用合同时，他们调用此操作代码来删除合同并清除其代币余额。他们还可以使用智能合约钱包通过现有的外部持有账户（EOA）发送交易，而无需生成新的EOA（EOA状态无法删除）。

但实际上，这样的激励措施很少，适当的状态清理的技术复杂性太大。在许多合同中，允许任何人这样调用selfconstruct是不合适的（人们想要的是一个不能终止的应用程序！）而且，它会给用户体验和代码增加很多复杂性。事实上，我更喜欢永远删除这个操作码，因为它的用处和副作用有限。如果我们真的想控制状态数据的大小，我需要的是网络中的节点可以默认丢弃不再使用的“垃圾状态”的方法。

无状态客户端

解决这个问题的方法之一是基于“无状态客户机”的概念（本文讨论这个概念的起源，这里是讲座视频）。基本原理是块验证不再基于保持全局状态。相反，区块将带来自己的证据（或“证人数据”），以证明它正在访问的状态的价值。就像当前的设计一样，在块中会有一个“状态根”，并且可以证明访问的值对应于状态根。以太坊的当前状态树方案（Merkel-Patricia-tree）支持这种证明技术。也可以使用更有效的方案，如二叉树或verkle-trie。见证数据还将在处理块之后证明新状态根的正确性。

无国籍状态有两种形式

弱无状态：阻止程序仍然需要一个完整的状态来生成（自制）块的见证数据，但是块的验证阶段可以是无状态的；

强无状态：没有节点需要一个完整的转盘。相反，事务发送方需要提供见证数据，而阻止方可以聚合数据。事务发送方负责存储为相关帐户生成见证数据所需的部分状态树。

强无状态是一个非常“优雅”的解决方案，因为它完全将责任转移给用户。虽然为了在实践中保证良好的用户体验，我们需要创建一些类的协议来帮助不运行个人节点的用户维护状态，并处理用户需要与意外帐户交互的情况。很难达成这样的协议。

此外，所有类的无状态都会增加网络所需的数据带宽；强无状态还要求事务声明与其交互的帐户和存储项的密钥（概念上，这称为“访问列表”）。

温和的解决方案：状态过期

更温和的解决方案可以归因于不同形式的“状态过期”解决方案。必须连续访问的状态可以保持“活动”；而长期无人关心的状态将变为“不活动”（或“过期”）。关于使用哪种机制来更新状态，有很多选择（例如，预付“租金”，或者只访问该状态）。但一般原则是，除非状态对象显式更新，否则它将以某种形式停用。因此，任何创建新状态对象（和更新现有状态对象）的活动只能成为节点一段时间的负担，而不是成为**负担。

停用状态不是“状态”的一部分；要处理或创建块的节点不需要存储停用状态。但是，停用状态没有完全删除！在所有类的状态过期建议中，都有一个预设方法可以“恢复”停用状态。

一般原则是活动状态的使用与当前状态相同，而非活动状态需要通过上述无状态客户机机制来使用。恢复过期对象的事务需要提供证据（见证数据）来证明该对象是非活动状态的一部分。为了生成这样的证据，用户需要存储和维护失活状态的至少一部分（对应于他们关心的失活状态对象的部分）。

什么时候到期

有许多设计可以确定过期条件。最常见的是：

直接租金：分块收取“租金”，用每个账户（或其他状态对象）的余额直接支付；当状态对象余额降为零时，账户到期。

剩余生存期值：每个状态对象存储一个“剩余生存期”值，该值可以通过支付费用来增加

触摸时刷新：每个状态对象存储一个“剩余生存期”值，该值将在每次读取或写入帐户时增加

所有状态对象都会定期过期（例如每六个月一次）：即regenesis建议

我越来越喜欢“触摸和刷新”方案，因为（1）它避免了为用户创建一个复杂的经济模来承担地租；（2）它确保了活动状态的大小有一个明确的上限（块气体上限/触摸状态对象的气体消耗×状态生存时间）。大量状态定期过期（即重新生成）的方案具有相同的优点，但也有一些有趣的折衷：关键的优点是过期方案更简单（不需要遍历整个状态树并逐个停用状态对象），但关键的缺点是过期点，激活状态对象所需的见证数据量取决于到达状态对象的时间点。

帐户级别过期与插槽级别过期

状态过期逻辑可应用于帐户级别和单个存储插槽级别。目前，我非常喜欢在插槽级别实现状态过期方案。由于许多合同帐户中的插槽数量是无限的，因此任何用户都可以加入合同并增加合同名称下的插槽数量（例如，airdrop是一个现有的案例）。无论使用哪种帐户层过期方案，租金金额必须与合同中存储插槽的数量成正比（或者生存时间与极限状态的实际大小成反比）。因此，用户仍然可以对合同及其用户施加**性的持续成本，并收取一次性费用。

为了解决这个问题，契约要么添加复杂的内部逻辑，将存储操作的租金“传递”给用户，要么重新设计自己的契约模式，并使用create 2操作代码创建新的契约，并将这些契约用作存储插槽。无论哪种方式，它最终都将成为与存储插槽级别相当的过期解决方案。因此，我个人认为，我们应该只在合同时段层面实施国家到期计划。

然而，槽级过期方案也有其自身的缺点：每个槽都需要添加一个元数据来指示其何时过期（或是否已停用），这也意味着“复活冲突问题”（见下文）不仅会影响帐户，还会影响槽。