来源|?ethresear.ch
作者|?VitalikButerin
译者按：本文需要读者对状态管理和stateexpiry机制作一定了解。
回顾：状态大小管理技术
为了防止以太坊的状态容量无止境地膨胀，我们需要用一些方法使旧状态“失活”,这样加入网络的节点就不再需要存储旧状态了。即使大多数的客户端都变成无状态，似乎也可以合理预见，最终这个系统会扩容到网络无法一直保证所有状态都可用的地步。有两个方法可以使旧状态失活：
1、直接删掉，然后可以把它移到另外的默克尔树，这样关心该状态对象的人可以获取相应的默克尔分支，在未来某个时候用它来激活该状态。
V神：可通过部分区块拍卖应对区块构建者的中心化风险，长远看区块生产需要第三者介入:10月3日消息，以太坊联合创始人Vitalik Buterin发文表示，可通过部分区块拍卖限制构建者权力以应对其中心化风险，并主要介绍了包含列表（Inclusion lists）、提议者后缀（Proposer Suffixes）两种可能方式：
在包含列表模式（Inclusion Lists）中，提议者提供一个包含列表，他们要求的事务列表必须包含在块中，除非构建者可以完全用其他事务填充块。这种设计相当简单，但弱点包括：激励相容性问题；提议者的额外负担；构建者仍然可以从事一些滥用行为；需要partial enshrining才能使账户抽象化发挥作用。
另一种构建方法是允许提议者为区块创建一个后缀。构建者在构建区块时不会看到关于提议者意图的信息，而提议者能够将构建者遗漏的任何交易添加到末端。这样的做法减少了激励的兼容性问题，尽管对提议者来说可能增加额外负担，但在从构建者那里得到响应和必须发布区块之间，提议者将得到一些MEV机会。
在任何情况下，我们需要在最大限度地减少构建者的权力和信息的同时，最大程度地减少强加给提议者的负担，而这似乎清楚地表明在区块生产中需要一些第三者介入。[2022/10/3 18:38:10]
2、不把对象移出树结构；相反，只在树的该位置标记“失活”，这样节点就不会存储它(且协议也不会要求它们这样做)。通过发送一个提供默克尔证明(即见证数据)的事务来访问该状态，失活的对象就可以重新被访问了。
V神：从1.0到2.0是从一个共识引擎系统到另一个的状态转换:基于以太坊的去中心化社交应用Status官方在推特称，像“从以太坊1.0迁移到以太坊2.0”这样的说法是行不通的。以太坊创始人V神则评论称，也许关键在于“迁移”是一个不好的词，因为它意味着它们是两个独立的系统。然而在现实中，它是一种从一个共识引擎系统转移到另一个的状态转换。[2020/11/14 20:48:01]
方法(1)对应于“经典的存储租金方案”，方法(2)对应于传统“无状态客户端”的最简单延伸——旧状态可以被遗忘的模型。这两种方法都允许关心特定状态对象的个人追踪默克尔分支，这样随后如果那些状态对象失活了它们可以用来激活这些对象。然而，这两种方法都是有明显问题的。
声音 | V神：通过回滚区块链找回被盗比特币带来的附带损失是巨大的:V神今日发推回应赵长鹏不通过回滚区块链找回被盗比特币的时候表示，“以太坊曾经做过不符合规则的状态改变”“由此带来的附带伤害将是巨大的，甚至是致命的”。
V神所说“不符合规则的状态改变”一事是指：2016年6月15日，因the DAO漏洞，以当时价格来算价值近6千万美元的以太币被盗，V神提议进行软分叉来将所有被盗的币都将“冻结”在那个地址上，再进行一次硬分叉将这些以太币找回。由此ETC的分叉币ETH产生了。[2019/5/8]
当要在某个已失效合约的同一个地址上再创建合约时，方法(1)会出现一些极端情况。那就是，如果一个合约在地址A上创建了，然后已经失效了，那么在地址A上创建这个合约的事务会被重新执行，这样会在地址A上创建一个新对象，这会影响原始对象的激活。另一种情况是当在地址A上创建了一个对象，然后经历失活、被激活、被修改(例如，发送合约上的资金到另一个账户)、再失活、再用第一次失活所在的默克尔分支激活。这违背了保留规则，且可能被用于铸币；需要增加额外的默克尔证明来证明一个合约还没有被另一个特定状态激活，而该状态也尝试被激活。
V神：中本聪编程水平并不高明，但运气不错:以太坊创始人Vitalik Buterin指出：“中本聪作为一个老派C++程序员，编程水平并不高明，但运气不错”。V神还评价说，“虽然中本聪在2008年为比特币做出的绝大多数决策我们仍坚持着，但他的选择绝对不是完美的，幸运的是他正确的次数经常比错误要多，事实上有几个实例，因为中本聪的选择我们获得了更好的结果”。[2018/3/17]
方法(2)遇到的是不同的问题。假设两个相邻的地址(也就是两者间没有对象)A1和A2都已失活。这样，不仅A1和A2都不再可以访问(除非有人存储了默克尔分支)，而且A1和A2之间的所有地址都不可以访问了。也就是说，如果总共有N个地址，那么大约1/N的可用地址空间都不再可访问了。当一半的地址都失活了，大约1/4的地址空间不再可访问。随着时间推移，会越来越难找到空间生成新的地址。而且由于新地址越来越集中在剩下的“可访问”空间上，每N年可访问空间减半的这种影响会呈指数增长。
提议
我提议对方法(2)进行修改，可以解决以上的问题。正如很多方法(2)的提议实现方案所呈现的，账户有“活跃”与“失活”两种状态，失活账户是那些超过一年未被访问过的账户。要访问失活账户，你需要提供见证数据；当失活账户被访问了，该账户会自动解除失活状态(触及任何账户都会重置它的一年失活期计算)。修改内容如下：
我们给每个地址添加一个32个字节的"epoch前缀"。例如，epoch前缀是9的地址是这样：0x00000009de0b295669a9fd93d5f28d9ec85e40f4cb697bae，以00000009作为前缀。
默克尔路径会直接依赖epoch的前缀而不是它的哈希值(因此merkle_path_key=address+hash(address)而不是现在在用的merkle_path_key=hash(address)。这确保了“没用过的”地址空间是连续的。
除非地址的epoch前缀是小于或等于区块链已运行的年数，否则地址不能被使用
会增加一个CREATE3操作码，它会把epoch前缀作为一个参数，并在具有该epoch前缀的一个地址上创建一个合约。
推荐用户和合约总是使用具有尽可能新的epoch前缀来创建账户，甚至设为默认设置，因为肯定会有具有最新epoch前缀的全状态仍然是可以访问的。为了还能保有“反事实地址(counterfactualaddresses)”，用旧epoch前缀来创建合约还是可能的。但是，对于想要创建反事实地址的用户，如果长期不创建，他们就要负责为该账户存储旧状态的分支。
经过多年的运行，预计活跃状态会由两部分构成：(i)有最新epoch前缀的全部地址空间，(ii)与最近被活跃使用过的账户相对应的特定旧状态
请注意，这个方案正常情况下扩展到合约上；事实上，主动遵循这个方案是符合合约自身运作的。因为在这个方案里，地址中代表存储的部分以几个字节为前缀，它们所代表的数字N指的是这些数据是在N年与这些地址产生关联。这很适合用于存储像代币余额这样的数据。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。