写于 2021 年 2 月 12 日
以太坊协议所面对的一个最为持久且尚未办理的挑战，就是由于状态数据局限不绝增长而带来的问题。以太坊区块链上的很多操纵（建设账户、写入一个合约存储槽、发送 ETH 到一个新的账户……）城市赐与太坊添加状态内容（也等于给状态数据增加数据工具），而所有全节点都必需存储全量的状态数据，这样才气验证新区块以及制造新区块。这些操纵只需事务的发送者一次性缴交按 gas 用量来计量的手续费，但会给整个网络造成永久的一连性本钱，因为节点需要存储这些新数据（而将来插手的节点也需要在同步进程中下载这些数据）。
这是系统设计中的一个显著的失衡，大概会让以太坊系统变得越来越难用，因为状态中充斥着不再有用处的 “垃圾数据”。本文的目标是具体表明问题发生的来源，以及一些办理该问题的要领。假如我们能实现某个办理方案，这将为安详地大幅提高区块 Gas 上限 铺平阶梯。
本文所阐述的研究规模仍在推进中，随时有大概呈现更新、更好的想法和更优雅的衡量。
引言：问题出在哪？
“状态” 指的是节点若想处理惩罚新发生的区块和事务就必需存有的信息。状态与 “汗青” 完全差异，后者是关于已往时间的信息，节点可以生存这些信息以便日后从头广播或归档，但并不是处理惩罚区块链所必须的。
在以太坊协议中，状态信息包罗：
账户的 ETH 余额和nonce（流水号）智能合约的代码智能合约的存储项（storage）与共鸣机制相关的数据（近期的区块哈希值，叔块；权益证明的共鸣数据还包罗验证者的公钥以及及其记录在信标链上的勾当，等等）汗青信息则由旧的区块和收据构成。EVM 中没有操纵码可以让你会见旧区块、往事务和内容和收据输出，所以节点扬弃这些数据也仍然能验证新区块，所以这些是汗青信息。
上述状态信息列表中的最后一项 —— 共鸣机制相关数据 —— 在设计上已经经心限制了其局限，因此我们不太需要为此困扰。但前面三项，就令人头大了。这三类状态信息的局限会跟着时间推移而不绝增大，因为不绝会有新用户插手网络，他们会建设新的账户、新的合约，还会插手合约、收到 token 什么的。
难办的是，很多状态用过之后就会悄悄地躺在哪里（不会再被触及）；一旦某个用户停用某个应用之后，就会发生一些 “垃圾状态” —— 不会再派上用场，但会永远存在哪里。
理论上，用户可以做到 “垃圾不落地”。用户可以仅宣布带有SELFDESTRUCT条件的合约，等他们再也用不上这个合约的时候，就挪用这个操纵码移除这个合约、清空其 token 余额；他们还可以利用智能合约钱包，通过一个已有的外部持有账户（EOA）来发送生意业务，而无需生成一个新的 EOA（EOA 状态是没法删除的）。
可是在实践中，这样的鼓励很是少，而适当的状态清理的技能巨大性又太大了。在很多合约中，给任何人赋予这样挪用SELFDESTRUCT的权限都是不符合的（人们想要的就是 “无法终止” 的应用！），并且，也会给用户体验和代码上也会增加许多巨大性。实际上，由于SELFDESTRUCT用处极其有限而副浸染极大，我更倾向于永远移除这个操纵码。假如我们真想节制状态数据的局限，我们需要的是一个网络中的节点可以默认扬弃不再被利用的 “垃圾状态” 的要领。
无状态客户端
无状态性有两种形式：弱无状态性：出块者仍然需要完整的状态，觉得（本身制造的）区块生私见证数据；但验证区块的阶段可以是无状态的；强无状态性：没有任何节点需要完整的转台。反过来，是生意业务发送者需要提供见证数据，而出块者可以聚合这些数据。生意业务发送者本身认真存储为所关怀的账户生私见证数据所需的部门状态树。
强无状态性是一个很是 “优雅” 的办理方案，因为它把责任完全转移给了用户，固然为了担保实践中的精采用户体验，我们需要缔造某些范例的协议来辅佐不运行小我私家节点的用户维护状态、并处理惩罚用户需要与料想之外的账户交互的景象。打造这样的协议很是难。
另外，所有范例的无状态性都提高了网络所需的数据带宽；而强无状态性还需要生意业务声明其所交互的账户及存储项的键（观念上这个叫做 “会见列表”）。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
