编译：GaryMa 吴说区块链
Vitalik在近期的韩国区块链周、新加坡演讲甚至是以太坊执行层核心开发者会议(ACDE)上，都共同提及过一个话题：状态（State），而随之左右的则是与其相关的各种解决方案概念，如无状态、状态过期（StateExpiry）、历史数据过期（HistoryExpiry，EIP-4444）、Verkle树、甚至是地址空间的扩展\压缩（Address Space Expand\Compression）。当然，这其实也不是什么新的路线图调整规划，在 Vitalik 去年 11 月发布的以太坊的最新路线图中，这些主要归属于TheVerge和ThePurge关键路线。
本文便结合这两大关键路线以及一些新的思路挑战，一起回顾一下 Vitalik 心中的状态解决路线。
状态（State）
以太坊中的状态指的是一个包括所有外部拥有账户（EOAs）、它们的余额、智能合约部署以及相关存储的综合账本。这个状态不是静态的；它会随着新用户的增加和新智能合约的部署而不断扩展。
目前，全节点必须存储这个不断增长的数据集，以正确验证区块并确保状态转换正确，使验证过程本质上是有状态的。而这种不断增长的存储要求因此提高了运行全节点的硬件要求，将导致验证者越来越中心化。
根据 etherscan.io/数据，当前运行一个快速同步全节点至少需要 1200 Gb（以 Geth 客户端为例），这还是在已经进行了状态修剪，删除了较早之前的状态数据，只保留最近的状态的前提下。如果是存档节点，即全节点会保留所有历史状态，包括每个区块的状态，那么需要的容量需要约 15,400 Gb，并且未来还是一直增长，即社区常说的“状态爆炸”。
这也是 Vitalik 在韩国区块链周上所强调的：节点的中心化是以太坊网络面临的最大问题之一，应该通过使节点的运行更便宜、更容易来解决。
为了应对这一系列挑战，以太坊社区一直在努力寻找改进和优化的方法，即我们开头所例举的各种解决方案概念。
状态解决方案
无状态（Statelessness）
无状态（Stateless）核心概念是将状态数据外部化，不再需要每个节点存储完整的状态。在这种模式下，节点只需维护区块头和相关交易信息，通过状态证明（State Proofs）来验证和重建状态。
无状态的主要作用和意义在于减轻节点的存储负担，提高网络可扩展性，使更多节点能够轻松参与验证，同时仍然保持了以太坊的去中心化性质。
Verkle 树
目前，以太坊依赖 Merkle-Patricia 树来哈希和压缩其状态数据。然而，这种树结构中Merkle证明的大小可能会变得太大，使它们不太适用于无状态模型所需的见证。
为了解决这个问题，以太坊计划过渡到 Verkle 树，这是一种更高效的数据结构。Merkle-Patricia 树和 Verkle 树都共享一个重要的能力，即生成见证——密码学证明，允许任何人轻松确认状态根中特定信息的存在与公开可用。
Verkle 树的优势在于它们在生成较小的证明大小方面效率更高。
历史数据过期（HistoryExpiry，EIP-4444）
EIP-4444 旨在实施历史数据过期，这是一项升级，要求节点停止在点对点网络上托管超过一年的历史区块。删除历史数据显著减轻了节点运营者的磁盘空间需求。同时，它还通过消除适应历史区块不同版本的代码的需要，简化了客户端软件。此外，EIP-4444与PDS（Proto-danksharding）的结合确保了定期数据修剪；EIP-4444 每年修剪一次，而 PDS 每月修剪一次数据区块。尽管这有助于减少节点的数据存储需求，但也引发了有关历史数据的保存和恢复的担忧。
状态过期（StateExpiry）
无状态性消除了验证者在验证区块时需要维护完整状态的必要性。但状态并不会消失；它的持续增长仍然是网络的长期挑战。
为了解决这个根本问题，社区便提出了状态过期（State Expiry）方案。
状态过期将自动修剪那些保持不变的状态部分，比如一年，将它们移到一个单独的树结构中，并从主要的以太坊协议中删除它们。
值得一提的是，状态过期只有在迁移到 Verkle 树后才变得可行。另外，Vitalik 在韩国区块链周 KBW2023 上表示：如果有无状态和 PBS，状态过期可以是低优先级的。
因为如果届时区块提议者构建者分离（Proposer-Builder Separation、PBS）实现后，在无状态下，尽管区块构建者仍需要访问状态来创建区块，但届时的区块构建者已经被预期能够有效处理状态的增长，因为这领域允许一定程度的中心化，构建者们的节点性能自然能够满足需求。
尽管目前协议级别 PBS 尚未纳入以太坊主网，但是我们大致通过了解 Mev-Boost PBS 当前的市场分布，也能大致了解未来主网的一个趋势走向，mevboost.pics 的数据统计如下：
另外，状态过期（State Expiry）的实现涉及以太坊地址格式的改变，目前有两种方案：地址空间扩展（address space extension）vs 地址空间压缩（address space compression）。前者是将地址长度增加到 32 字节（当前地址格式为 20字节），但需要复杂的逻辑来向后兼容并且现有的合约也必须更新；后者虽然保留 20字节格式，不过将前 6 字节用于前缀以及地址周期的标识，虽然这样大大减少了兼容难题，但也随之引来另一个难题，地址长度只剩下 14 字节便不再具有抗碰撞能力，从而引入一些地址创建的潜在安全问题，这也是目前社区所面临的重大挑战。
总结
现在，我们大致可以根据上述技术解决方案的实现难题以及缓急，排除前后优先级（2\3\4 或许可以同等）：
1. Verkle树
2. PBS
3. 无状态
4. 历史数据过期（EIP-4444）
5. 以太坊地址格式的改变（压缩/扩展）
6. 状态过期
综上，可降低节点运行门槛，保持节点的去中心化以及潜在的状态爆炸问题，减轻状态增长以优化网络通信负载。
当然，目前依旧是任重道远。
参考链接：
https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356
https://public.bnbstatic.com/static/files/research/ethereum-beyond-the-merge-.pdf
https://www.fx168news.com/article/295525
