保持以太坊可扩展性和可持续性的两种方案：“弱无状态性” 和 “状态保质期”

以太坊的状态的规模正迅速增长。当前仅存储状态大概是 35 GB，如果加上默克尔证明就是 100 GB 了；而且现在预计每年都要增长这个数字的一半。此外，状态存储也是以太坊经济模型的一个短板：在这个机制中，用户只需付费一次就可以给共识节点施加永久的负担。为了保持以太坊的可扩展性和可持续性，我们需要一些解决方案。

有两种路径，而且都已经存在很长时间了：“弱无状态性” 和 “状态保质期”：

状态保质期：从状态中移除近期（比如，去年）无人访问的状态对象，并要求在复活状态对象时提供见证数据（witness）。可以将每个节点都需要存储的状态数据减少到扁平的约 20 ～ 50 GB。

弱无状态性：仅要求区块提议者存储状态，其他节点都可无状态验证区块。在实践中，需要把状态共识形式（从默克尔树）切换到 “Verkle Tree”，以缩减见证数据的规模。

本文提出了一种多阶段的方案，来同时实现这两种方案。因为，可以证明，这会比按顺序实现这两个（无论什么顺序）容易很多。如果不实现 Verkle 树，状态保质期方案下就需要非常大的见证数据来证明一个旧状态；如果不实现状态保质期，切换到 Verkle 树就需要一个一步到位的切换流程（例如 EIP 2584），这几乎跟只实现状态保质期一样复杂。如果合二为一，同时进行，它们就解决了彼此面临的挑战：状态保质期方案包含了每年创建一棵新状态树的机制，因此 Verkle 树可以分阶段逐步建构，而无需一个一步到位的切换流程，而 Verkle 树也解决了见证数据规模的问题。

无状态客户端的概念，于 2017 年始发于 ethresear.ch 论坛：https://ethresear.ch/t/the-stateless-client-concept/172（亦可见 EthHub）（中文译本）

状态租金（状态保质期的前身），始发于 2015 年：https://github.com/ethereum/EIPs/issues/35

ReGenesis（Alexey Akhunov 的提议，可以认为是 状态保质期 + 历史过期 的一种形式）：https://medium.com/@mandrigin/regenesis-explained-97540f457807 （中文译本）

Verkle 树：https://notes.ethereum.org/_N1mutVERDKtqGIEYc-Flw

（演讲）约束见证数据的大小：https://www.youtube.com/watch?v=qQpvkxKso2E

一种状态规模管理理论（2021 年 2 月）：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 硬分叉：需要一个硬分叉来开启第一个周期（此前的则都算是第 0 个周期）。分叉之后，就会出现两棵状态树：十六叉的帕特里夏树（已冻结，不可再编辑）以及一棵新的 Verkle 树（包含所有新的状态 编辑/增加，还有旧状态的副本）

EIP 草案：https://notes.ethereum.org/@vbuterin/verkle_tree_eip

地址扩张周期：地址从 20 字节扩充到 32 字节，而新地址的格式包含一个 “地址周期” 的概念（曾用名 “地址空间（address space）”）。这样新合约就可以无需提供见证数据而直接写入新的存储空档。这一步什么时候做都可以，只需要在最终状态保质期转型完成之前就可以了，在周期 1 分叉之前或之后都可以。

VB 的方案：https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485

Ipsilon 团队的方案：https://notes.ethereum.org/@ipsilon/address-space-extension-exploration

周期 2 硬分叉：需要一个硬分叉来开启周期 2，并安排未来周期的时点。周期 0 的十六叉的帕特里夏树将被一棵 Verkle 树替换，客户端仅存储其状态根。从这时开始，周期 0 的状态将需要见证数据来访问。并且，状态保质期方案也算是完整实现了。

EIP 草案：https://notes.ethereum.org/@vbuterin/state_expiry_eip