状态规模日益恶化？以太坊状态规模管理诸提议

以太坊中国 view 7913 2021-2-22 14:24

以太坊协议所面临的一个最为长久且尚未解决的挑战，就是由于状态数据规模不断增长而带来的问题。以太坊区块链上的许多操作（创建账户、写入一个合约存储槽、发送 ETH 到一个新的账户……）都会给以太坊添加状态内容（也即是给状态数据增加数据对象），而所有全节点都必须存储全量的状态数据，这样才能验证新区块以及制造新区块。这些操作只需事务的发送者一次性缴交按 gas 用量来计量的手续费，但会给整个网络造成永久的持续性成本，因为节点需要存储这些新数据（而未来加入的节点也需要在同步过程中下载这些数据）。

这是系统设计中的一个显著的失衡，可能会让以太坊系统变得越来越难用，因为状态中充斥着不再有用处的 “垃圾数据”。本文的目的是详细解释问题产生的根源，以及一些解决该问题的方法。如果我们能实现某个解决方案，这将为安全地大幅提高区块 Gas 上限铺平道路。

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

引言：问题出在哪？

“状态” 指的是节点若想处理新产生的区块和事务就必须存有的信息。状态与 “历史” 完全不同，后者是关于过去时间的信息，节点可以保存这些信息以便日后重新广播或归档，但并不是处理区块链所必需的。

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

账户的 ETH 余额和 nonce（流水号）

智能合约的代码

智能合约的存储项（storage）

与共识机制相关的数据（近期的区块哈希值，叔块；权益证明的共识数据还包括验证者的公钥以及及其记录在信标链上的活动，等等）

历史信息则由旧的区块和收据组成。EVM 中没有操作码可以让你访问旧区块、旧事务和内容和收据输出，所以节点丢弃这些数据也仍然能验证新区块，所以这些是历史信息。

上述状态信息列表中的最后一项 —— 共识机制相关数据 —— 在设计上已经精心限制了其规模，因此我们不太需要为此困扰。但前面三项，就令人头大了。这三类状态信息的规模会随着时间推移而不断增大，因为不断会有新用户加入网络，他们会创建新的账户、新的合约，还会加入合约、收到 token 什么的。

难办的是，许多状态用过之后就会静静地躺在那里（不会再被触及）；一旦某个用户停用某个应用之后，就会产生一些 “垃圾状态” —— 不会再派上用场，但会永远存在那里。

理论上，用户可以做到 “垃圾不落地”。用户可以仅发布带有 SELFDESTRUCT 条件的合约，等他们再也用不上这个合约的时候，就调用这个操作码移除这个合约、清空其 token 余额；他们还可以使用智能合约钱包，通过一个已有的外部持有账户（EOA）来发送交易，而无需生成一个新的 EOA（EOA 状态是没法删除的）。

但是在实践中，这样的激励非常少，而适当的状态清理的技术复杂性又太大了。在许多合约中，给任何人赋予这样调用 SELFDESTRUCT 的权限都是不合适的（人们想要的就是 “无法终止” 的应用！），而且，也会给用户体验和代码上也会增加很多复杂性。实际上，由于 SELFDESTRUCT 用处极其有限而副作用极大，我更倾向于永远移除这个操作码。如果我们真想控制状态数据的规模，我们需要的是一个网络中的节点可以默认丢弃不再被使用的 “垃圾状态” 的方法。

无状态客户端

这个问题的一类解决方案基于 “无状态客户端” 的观念（此文是论述这个观念的出处，此处是演讲视频）。

基本原理是，让区块验证不再以持有全局状态为前提。相反，区块会自带证据（或者叫 “见证数据（witness）”），证明其所访问状态的值。就跟现在的设计一样，区块内会包含一个 “状态根（state root）”，所访问的值可以对应着状态根得到证明（译者注：默克尔证明即是一种常见的证明技术）。以太坊现在的状态树方案（默克尔帕特里夏树）支持这样的证明技术，像二进制树或者 Verkle Trie 这样更高效的方案也可以。见证数据也会证明处理完该块后新状态根的正确性。

无状态性有两种形式：

弱无状态性：出块者仍然需要完整的状态，以为（自己制造的）区块生成见证数据；但验证区块的阶段可以是无状态的；

强无状态性：没有任何节点需要完整的转台。反过来，是交易发送者需要提供见证数据，而出块者可以聚合这些数据。交易发送者自己负责存储为所关切的账户生成见证数据所需的部分状态树。

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

此外，所有类型的无状态性都提高了网络所需的数据带宽；而强无状态性还需要交易声明其所交互的账户及存储项的键（概念上这个叫做 “访问列表”）。

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

更温和的解决方案可以归结为不同形式的 “状态过期” 方案。必须持续得到访问的状态才能保持 “激活状态”；而长期无人问津的状态会变成 “失活”（或者叫 “过期的”）。具体用什么机制来更新状态，有很多选择（例如预付 “租金”，或者只需访问那个状态），但一般原则是，除非某个状态对象被显式地更新，否则就以某种形式处于失活状态。因此，任何创建新状态对象（以及更新已有状态对象）的活动，都只能成为节点在一段时间内的负担，而不像现在这样变成永久负担。

失活状态，故名思义，就不是 “状态” 的一部分；想要处理区块或创建区块的节点无需存储失活状态。不过，失活状态不是被完全删除了！在所有类型的状态过期提案中，都预设了某种方法可以 “复活” 已经失活的状态。

一般原则是，激活状态的使用与当前相同，而失活状态则需通过上述无状态客户端的机制来使用。复活一个过期状态对象的事务需要提供一个证据（见证数据），来证明该对象是失活状态的一部分。为了能够生成这样的证据，用户自己需要存储和维护至少一部分失活状态（对应于其所关切的失活状态对象的那部分）。

何时过期

决定过期条件的设计也有很多种。最常见的几种是：

直接租金：逐块逐块收取 “租金”，直接以每个账户（或其他状态对象）的余额来支付；状态对象的余额降到了零，该账户就过期了。

剩余存活时间值：每个状态对象都存储一个 ”剩余存活时间“ 值，这个值可以通过支付费用来增加

触达即刷新：每个状态对象都存储一个 ”剩余存活时间“ 值，并且每逢读取或写入该账户都会增加该值

所有状态对象定期过期（例如每 6 个月一次）：也就是 ReGenesis 提案（中文译本）

我自己越来越喜欢 ”触达即刷新“ 方案，因为（1）它避免了应用需要创造复杂的经济模型来让用户承担状态租金；以及（2）它保证了激活状态的规模有一个清晰的上限（区块 Gas 上限 / 触达状态对象的 Gas 消耗量 × 状态存活的时长）。让大量状态按照规律的时间间隔过期的方案（也就是 ReGenesis）也有同样的好处，但也有一些有趣的权衡：关键好处是，过期方案更简单（无需遍历整棵状态树而逐个逐个地灭活状态对象），但关键不足是，跨过一个过期时点后，你再激活自己的状态对象时，需要多少见证数据会跟你触达状态对象的时间点有关。

账户层面的过期 vs. 存储槽层面的过期

状态过期的逻辑既可以运营到账户层面，也可以运用到单个存储槽层面。当前，我强烈偏向于在存储槽层面实现状态过期方案。因为很多合约账户的存储槽数量是不受限制的，任意用户都能加入合约并增加合约名下的存储槽的数量（例如，空投就是一个已经出现过的案例）。不管使用什么样的账户层过期方案，想要实际限制状态的规模，租金的数量都必须与合约内存储槽的数量成比例（或者存活时间与之成反比）。结果是，用户还是能够仅支付一次性的费用就给合约及其用户施加永久的持续性成本。

要解决这个问题，合约要么加入复杂的内部逻辑，将存储操的租金 “转嫁” 给用户，要么重新设计自己合约的模式，转向使用 CREATE2 操作码创建新的合约并使用这些合约来充当存储槽。不管是哪种办法，最后都会变成等价于存储槽层面的过期方案。因此，我个人认为，我们应该仅在合约存储槽层面实现状态过期方案。

但是，存储槽层面的过期方案也有自己的缺点：每个存储槽都要增加一个元数据，指明它何时过期（或者说是否已经失活），这也意味着 “复活冲突问题”（详见下文）不仅会影响账户，也会影响存储槽。

从状态树上移除 vs. 给状态树安排一个 “退休” 部分

另一个区分不同状态过期提议的技术角度是 “一树流” 和 “二树流”。也就是说，我们到底是像现在这样，只有一棵状态树，只不过把某些状态标记为过期；还是直接把失活的状态从主状态树上移除，转移到另一棵专门的（只包含过期状态的）树（或者其他数据）上？

一树流

状态规模日益恶化？以太坊状态规模管理诸提议

激活节点以白色标记，失活节点以灰色标记

注意，即使是树上的中间节点，也会被标记为激活或者失火（或者，更现实一点的方案，每个节点都会带有失活日期的标记，所以能够容易检查其活性）；标记工作可以在状态树上的每个节点（叶子节点和中间节点）处完成。

二树流

状态规模日益恶化？以太坊状态规模管理诸提议

白色的树包含激活状态；灰色的树存储失活状态

一树流的好处是，最起码，其工作方式看起来会跟当前的状态树相似，失活和复活的流程也比较简单：复活流程只需刷新树上相关节点的 “过期日期” 参数，而失活则是自动化的。但它的缺点在于：它需要一种能够在节点中以此种方式存储过渡信息（intermediate information）的树结构，而且不能很好地扩展到 Verkle 树。此外，它还需要额外的默克尔证明元件，不仅要能够下沉到叶子节点，还要能够（在需要证明某部分状态已经过期时）停在中间节点处。

二树流的好处是：当前的、形式纯粹的状态累加器就能支持这类方案，而无需为每个节点增加元数据。缺点是，它需要对整个协议做一些更深层次的变更，而且需要一个显式的流程来灭活状态（所以过期不再是自动化的了）。另外，它也没有为复活冲突两难（见下一节）提供内置的解决方案，所以需要在两种办法中作出选择。

注意，在二树流中，存储失活状态的数据结构不是非树不可。事实上，完全有可能出现这样一种设计：需要复活一个状态对象时，只需提供一个指向该对象失活时候收据的默克尔树，再附上一些密码学证据，证明此前该对象未被复活过（或者最近又重新过期），即可。

复活冲突

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

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

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

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

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

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

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

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

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

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

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 开销就是一样的。这会导致两个结果：

访问近期状态的 Gas 开销也需要进一步提高

包含了见证消息的区块大小上限可能非常之大，如果一个区块里满是访问老旧状态的事务的话（大概是 800 bytes * 12.5 m gas / 2400 gas per access ~= 4.1 MB，已假设实行了 EIP-2929，转成了二进制树）

如果我们想避免这些不利因素，就需要在共识中跟踪哪些状态对象（包括尚未填满的地址空间区域）是活跃状态，这又会让我们回到接近于状态过期方案的属性。这再一次地说明了，“无状态性 vs. 状态过期（状态租金）” 是一条光谱，是一个复杂的权衡空间，而不是一个非此即彼的选择。

Rollup 也需要，也可以，使用同样的解决方案

以太坊的一种重要的中期可扩展性解决方案是 rollups（中文译本）。不过，rollup 本身并非不再需要担忧状态数据规模问题；实际上，rollup 系统的状态规模问题，与以太坊链本身的，性质完全相同。

幸运的是，如果我们能推出一种解决方案，则至少 EVM rollup（尝试最大程度复制以太坊运行环境的 rollup 方案）能够使用同样的解决方案，来解决其内部状态的规模问题。因此，状态规模管理方案，与 rollup 和分片等可扩展性方案是互补的（state size management is complementary to rollups, sharding and other scaling strategies）。

（译者注：个人认为此处的 “互补”一词有严重误导性。）