以太坊开发者社区正面临一些决定以太坊网络可用性的艰难决定，一些核心开发人员预测，如果以太坊的状态大小（state siz）继续以目前的速度增长，以太坊网络将在三年内崩溃。

减缓其增长的首要解决方案是征收“状态租金（state rent）”，即向服户收取存储数据的费用。（在有些情况下，这称为“存储租金(storage rent)”，但在本文中，我将使用“状态租金”这个术语）。

但这可能会对用户的体验产生不愉快的影响，并且可能对现有应用程序产生负面影响。此外，并非所有人都同意状态大小问题像有些人认为的那样紧迫。

虽然最终将由核心开发人员来编写修复程序，但他们似乎并不急于代表以太坊社区做出决定并选择适当的解决方案。这是因为尽管这个问题本质上是技术性的，但是解决方案涉及到一些会影响可用性的价值权衡。因此，围绕该问题进行协调有些困难。本文试图用相对容易理解的语言来描述这一问题和将收取存储租金作为解决方案的主张。

庞大而冗余的数据量

存储数据需要磁盘空间，同时对数据进行同步需要时间，这两者都是块链网络中的关键考虑因素，其中至少有一些节点必须同步并存储整条链的数据（或其中重要的数据块)。

这不仅仅是一个效率的问题，而且是有关可持续性和可扩展性的问题。按照目前的情况，完全同步和下载一个归档节点已经需要几个星期的时间，说实话，这还是使用以太坊网络频率最低的时候。

如果你不是一个超级技术人员，或者不了解以太坊区块链的详细情况，你可能会认为这是因为这条链太长了。但这只是部分原因。事实上，同步所有区块(块头、块哈希)只是这个过程的一部分。

问题在于，包括状态树(state trie)在内的大量必要信息块并不包含在区块本身中。状态树是一个复杂的结构，包含当前所有的账户和一组密码证明。在节点能够以加密方式证明任何账户的任何内容之前，需要将这些信息提供给节点。同步这些信息所花的时间和同步区块链本身所花的时间一样长，甚至更长。

这并不是一个新问题。以太坊黄皮书中写道，处理和存储整个状态树非常笨重，并建议：“或许可以将区块链压缩：状态树中没有发送/接收某个固定数量区块中交易的节点可以丢弃掉，从而减少状态数据库的增长。”

今年3月，在讨论构建Ethereum 2.0的想法时，Vitalik Buterin在Ethresearch提出了一个通过收取租金来限制状态增长的模型。

从不同的角度来处理这个问题

虽然有关状态大小的问题很早以前就意识到了，但它最近已成为开发者社区讨论的一个关键主题。以太坊魔术师团体（The Fellowship of Ethereum Magicians）有一个专门负责以太坊Casper/Sharding升级前的Ethereum 1.x开发的团队。这个团队包括两个工作组，他们致力于解决以太坊日益增长的大规模数据存储的问题，两个工作组的角度都不一样:一个工作组专注区块链剪裁和状态减少（删除旧的和不必要的数据）,另一个是研究状态租金的工作组，专注于管理以太坊状态的增长。虽然对状态缩减和区块链剪裁的需求与管理状态大小的需要密切相关，但是这些问题需要不同的解决方案，因此需要不同的权衡以及单独的讨论和文章。

简单地说，关于区块链剪裁和状态减少的讨论集中在效率和可扩展性之间的权衡，以及安全性和不可变性之间的权衡。围绕通过征收状态租金来减少状态增长的讨论需要面对这样一个事实，即征收状态租金将显著损害已经很棘手的用户体验，并对现有应用程序造成不必要的负担，这些应用程序的开发人员无法将状态租金纳入他们的设计之中。虽然两者都很重要，但本文的重点是讨论如何通过状态租金来限制状态树的增长。

为什么要收取状态租金

征收状态租金的解决方案是由Turbo Geth开发人员阿列克谢•阿赫诺夫(Alexey Akhunov) 提出，它适用于状态租金提议者所说的“活跃状态”， “活跃状态”由“所有非空账户和所有已创建但未自毁的合约”组成。

状态租金作为解决状态膨胀问题的一种方法，其背后的理念包含两个方面：其中一个好处是，通过未支付租金可以很容易识别出不活跃账户或无价值数据，然后将这些数据从状态中“驱逐”出去。如果在以太坊上做开发花费更多，人们会更加明智地对待他们在以太坊上所做的事，这说得过去。对账户活动消耗的磁盘空间收取租金，可以鼓励开发者开发出更多存储优化型合约，并吸引更多对数据敏感的用户。如果账户数量减少、活跃账户更少、而账户的效率提高，那么状态树的增长率必然会放缓。

征收状态租金的意义

目前，那些认为状态租金是最可行的人正在讨论谁应该支付租金，以及如何计算租金等细节。这些问题具有重大意义。

谁来支付租金是一个特别有意义的问题，尤其是考虑到抗审查制度时。对于社区中的许多人来说，以太坊最吸引人的承诺在于，它使很多组织能够在没有太多或任何人为干预的情况下运行，从而使企业永远不会被监管机构或任何人关闭。要求组织定期支付费用以维护数据可用性会有违最初承诺，至少对于已经部署的应用程序来说是这样，这些应用程序的开发人员无法预料到这种需求

不过，在阿赫诺夫的提议中，他承认即使提前通知，合约也可能难以向用户收取租金。此外，用户也有可能做出不负责任或恶意的行为，通过为合约灌输大量数据，从而推高租金。由于这些原因，基于数据存储对合约收取状态租金会比较复杂。

即使与应用程序交互的个人用户出于存储数据而支付费用，如果出于某种原因被阻止支付或无法跟上他们的费用，强制性状态租金也可能对抗审查制度产生负面影响。

需要注意的是，如果合约没有支付租金，合约或账户本身不会被删除，而只会删除活动状态中的信息(如账户余额)。如果数据通过其他方式可用，则合约可以继续执行; 阿赫诺夫和其他人讨论了个人或组织下载和存储他们自己的数据、以及某些节点选择这样做的可能性。

阿赫诺夫试图在他的提案草案中解决这些问题，但他承认，征收状态租金将产生严重后果。他说道：

“不幸的是，在我看来，大多数合约都需要重新编写、重新部署以及重新填充数据。对我来说，要么修改合约，要么平台走向灭亡，两者必选其一。”

也许状态租金可以缓一缓

凯西•德特里奥（Casey Detrio）是Ethereum 1.x的核心开发者，他撰写了一篇名为《Ethereum 1.x：主网升级路线图草案》（"Ethereum 1 dot X: a half-baked roadmap for mainnet improvements）的文章，概述了存储空间有限的问题以及提出了一些解决状态膨胀的方案。他在总结中指出，一些研究人员认为只要Ethereum 2.0能相对快速地启动，它将成为一种解决方案。当然，这是基于Casper和分片将很快到来的假设，如果真的是这样，将是一个相当大的飞跃。此外，断言状态大小在Ethereum 2.0下不再有问题并不是一个公认的事实，因为分片技术并不提供无限的可扩展性。

对此，德特里奥提到了这样一个担忧:“在Ethereum 1.0上引入租金机制可能会让用户感到困惑，因为它可能与在2.0上引入的租金机制不同。”

征收状态租金的主要替代方法是创建无状态客户端和无状态合约。不过，这种选择的可行性仍有争议。此外，它将迫使所有合约负责存储和维护它们自己的数据，这可能有点压力。

当前工作

想要了解更多关于阿赫诺夫状态州租金提案的细节，请查看GitHub，或者关注以太坊魔术师团体和Ethresearch论坛中的讨论。

与此同时，社区还需要做更多的工作来发展提案和概念证明，以检验任何状态租金机制所带来的后果。一旦发生这种情况，将由客户端和Dapp开发人员做出权衡，并决定愿意做出哪种选择。