观点：以太坊状态规模管理诸提议（上）

以太坊协议所面对的一个最为持久且尚未处理的挑战，便是由于状况数据规划不断增长而带来的问题。以太坊区块链上的许多操作（创立账户、写入一个合约存储槽、发送 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 操作码创立新的合约并运用这些合约来充任存储槽。不论是哪种办法，最终都会变成等价于存储槽层面的过期计划。因而，我个人认为，咱们应该仅在合约存储槽层面完成状况过期计划。

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

视野开拓

产业空间行为的另一个方面是它的分散性。有两种不同类型的分散形式。第一种，各行业通过把一些生产环节分散到外围地区，从而将常规化（降低技术含量）、低贸易成本以及提高规模经济结合起来。第二种，在之前的外围地区形成新的集聚，容纳那些分散在世界范围内的成熟活动，但是通过在欠发达地区的再聚合来完成。-《城市发展的逻辑》