原标题：《观点|一种状态保质期和无状态性的路线图》
以太坊的状态的规模正迅速增长。当前仅存储状态大概是35GB，如果加上默克尔证明就是100GB了；而且现在预计每年都要增长这个数字的一半。此外，状态存储也是以太坊经济模型的一个短板：在这个机制中，用户只需付费一次就可以给共识节点施加永久的负担。为了保持以太坊的可扩展性和可持续性，我们需要一些解决方案。
有两种路径，而且都已经存在很长时间了：“弱无状态性”和“状态保质期”：
状态保质期：从状态中移除近期无人访问的状态对象，并要求在复活状态对象时提供见证数据。可以将每个节点都需要存储的状态数据减少到扁平的约20～50GB。弱无状态性：仅要求区块提议者存储状态，其他节点都可无状态验证区块。在实践中，需要把状态共识形式切换到“VerkleTree”，以缩减见证数据的规模。本文提出了一种多阶段的方案，来同时实现这两种方案。因为，可以证明，这会比按顺序实现这两个容易很多。如果不实现Verkle树，状态保质期方案下就需要非常大的见证数据来证明一个旧状态；如果不实现状态保质期，切换到Verkle树就需要一个一步到位的切换流程，这几乎跟只实现状态保质期一样复杂。如果合二为一，同时进行，它们就解决了彼此面临的挑战：状态保质期方案包含了每年创建一棵新状态树的机制，因此Verkle树可以分阶段逐步建构，而无需一个一步到位的切换流程，而Verkle树也解决了见证数据规模的问题。
链接：“状态保质期”和“无状态性”概念的历史
无状态客户端的概念，于2017年始发于ethresear.ch论坛：https://ethresear.ch/t/the-stateless-client-concept/172状态租金，始发于2015年：https://github.com/ethereum/EIPs/issues/35ReGenesis：https://medium.com/@mandrigin/regenesis-explained-97540f457807Verkle树：https://notes.ethereum.org/_N1mutVERDKtqGIEYc-Flw约束见证数据的大小：https://www.youtube.com/watch?v=qQpvkxKso2E一种状态规模管理理论：https://hackmd.io/@vbuterin/state_size_management最小化复活冲突的状态约束方案：https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739实现无状态性和状态保质期的路径：https://hackmd.io/@vbuterin/state_expiry_paths
回顾：状态保质期如何工作？
这里所描述的是此提案的机制。
核心想法是，每个周期都会有一棵状态树，每当一个周期开始时，就初始化一棵空状态树，所有的状态更新都写到这颗状态树上。在一个周期内，所有的写入都会发生在最新的状态树上。
-注意：我之前曾把这个约长一年的状态保质期周期称为“epoch”，现在都称为“period”，以免与信标链的术语相混淆-
两个关键原则是：
只能修改最新的那棵树。所有更老的树都不能再修改；更老的树上的对象只能在更新的树上创建副本，而且这些副本会取代更老的副本。可以预期全节点只会保存最近的两棵树，所以只有最近的两棵树上的对象才能不需要witness就能读取。读取更老的对象就需要提供见证数据了。“见证数据”就是一个简短的证据，证明某个值存在于某棵树的某个位置上，而且验证的一方只需具有树根即可。举个例子，可以制作一个witness来证明账户?0x124f...89ab?的存储空档?123?处在某时的状态下，包含的值为?50；任何人都只需要这棵状态树的根值就可以验证这个证据。
状态保质期产生了一种混合的状态机制：共识节点需要保存最近被人访问和修改过的状态，但可以使用基于见证消息的无状态客户端方法来验证更老的状态。也就是说，也可以维护一个“归档节点”，存储所有历史状态树，或者?一个完全无状态的节点，使用见证数据来验证哪怕是最新的状态。不过，gas消耗量的结构和默认的网络格式，都要围绕“节点会存储最近的两棵状态树”来开发。
路线图
迁移将按阶段来实现：
周期1硬分叉：需要一个硬分叉来开启第一个周期。分叉之后，就会出现两棵状态树：十六叉的帕特里夏树以及一棵新的Verkle树EIP草案：https://notes.ethereum.org/@vbuterin/verkle_tree_eip地址扩张周期：地址从20字节扩充到32字节，而新地址的格式包含一个“地址周期”的概念”）。这样新合约就可以无需提供见证数据而直接写入新的存储空档。这一步什么时候做都可以，只需要在最终状态保质期转型完成之前就可以了，在周期1分叉之前或之后都可以。VB的方案?：https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485Ipsilon团队的方案：https://notes.ethereum.org/@ipsilon/address-space-extension-exploration周期2硬分叉：需要一个硬分叉来开启周期2，并安排未来周期的时点。周期0的十六叉的帕特里夏树将被一棵Verkle树替换，客户端仅存储其状态根。从这时开始，周期0的状态将需要见证数据来访问。并且，状态保质期方案也算是完整实现了。EIP草案：https://notes.ethereum.org/@vbuterin/state_expiry_eip
原文链接:
https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal
作者:Vitalik
翻译:?阿剑
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。