以太坊状态规模治理诸提议（上）

免责声明：本文旨在通报更多市场信息，不组成任何投资建议。文章仅代表作者看法，不代表火星财经官方态度。

小编：记得关注哦

泉源：以太坊爱好者

以太坊协议所面临的一个最为恒久且尚未解决的挑战，就是由于状态数据规模不停增进而带来的问题。以太坊区块链上的许多操作（建立账户、写入一个合约存储槽、发送 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 操作码建立新的合约并使用这些合约来充当存储槽。不管是哪种设施，**都市酿成等价于存储槽层面的过时方案。因此，我小我私家认为，我们应该仅在合约存储槽层面实现状态过时方案。

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