Vitalik在近期的韩国区块链周、新加坡演讲甚至是以太坊执行层核心开发者会议(ACDE)上，都共同提及过一个话题：状态（State），而随之左右的则是与其相关的各种解决方案概念，如无状态、状态过期（StateExpiry）、历史数据过期（HistoryExpiry，EIP-4444）、Verkle树、甚至是地址空间的扩展压缩（Address Space ExpandCompression）。这些主要归属于TheVerge和 ThePurge关键路线
Vitalik在近期的韩国区块链周、新加坡演讲甚至是以太坊执行层核心开发者会议(ACDE)上，都共同提及过一个话题：状态（State），而随之左右的则是与其相关的各种解决方案概念，如无状态、状态过期（StateExpiry）、历史数据过期（HistoryExpiry，EIP-4444）、Verkle树、甚至是地址空间的扩展压缩（Address Space ExpandCompression）。这些主要归属于TheVerge和 ThePurge关键路线。
状态（State）
以太坊中的状态指的是一个包括所有外部拥有账户（EOAs）、它们的余额、智能合约部署以及相关存储的综合账本。这个状态不是静态的；它会随着新用户的增加和新智能合约的部署而不断扩展。
目前，全节点必须存储这个不断增长的数据集，以正确验证区块并确保状态转换正确，使验证过程本质上是有状态的。而这种不断增长的存储要求因此提高了运行全节点的硬件要求，将导致验证者越来越中心化。
当前运行一个快速同步全节点至少需要 1200 Gb，这还是在已经进行了状态修剪，删除了较早之前的状态数据，只保留最近的状态的前提下。如果是存档节点，即全节点会保留所有历史状态，包括每个区块的状态，那么需要的容量需要约 15,400 Gb，并且未来还是一直增长，即社区常说的“状态爆炸”。
这也是 Vitalik 在韩国区块链周上所强调的：节点的中心化是以太坊网络面临的最大问题之一，应该通过使节点的运行更便宜、更容易来解决。
为了应对这一系列挑战，以太坊社区一直在努力寻找改进和优化的方法。
状态解决方案
无状态（Statelessness）
无状态（Stateless）核心概念是将状态数据外部化，不再需要每个节点存储完整的状态。在这种模式下，节点只需维护区块头和相关交易信息，通过状态证明（State Proofs）来验证和重建状态。
无状态的主要作用和意义在于减轻节点的存储负担，提高网络可扩展性，使更多节点能够轻松参与验证，同时仍然保持了以太坊的去中心化性质。
Verkle 树
目前，以太坊依赖 Merkle-Patricia 树来哈希和压缩其状态数据。然而，这种树结构中 Merkle 证明的大小可能会变得太大，使它们不太适用于无状态模型所需的见证。
为了解决这个问题，以太坊计划过渡到 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）实现后，在无状态下，尽管区块构建者仍需要访问状态来创建区块，但区块构建者已经被预期能够有效处理状态的增长，因为这领域允许一定程度的中心化，构建者们的节点性能自然能够满足需求。
另外，状态过期（State Expiry）的实现涉及以太坊地址格式的改变，目前有两种方案：地址空间扩展（address space extension）vs 地址空间压缩（address space compression）。前者是将地址长度增加到 32 字节（当前地址格式为 20字节），但需要复杂的逻辑来向后兼容并且现有的合约也必须更新；后者虽然保留 20字节格式，不过将前 6 字节用于前缀以及地址周期的标识，虽然这样大大减少了兼容难题，但也随之引来另一个难题，地址长度只剩下 14 字节便不再具有抗碰撞能力，从而引入一些地址创建的潜在安全问题，这也是目前社区所面临的重大挑战
声明：本文内容来源自网络，文字、图片等素材版权属于原作者，平台转载素材出于传递更多信息，文章内容仅供参考与学习，切勿作为商业目的使用。如果侵害了您的合法权益，请您及时与我们联系，我们会在第一时间进行处理！我们尊重版权，也致力于保护版权，站搜网感谢您的分享！(Email:[email protected])
