该项目提出了一种新的基于 Verkle 树的状态过期方案，用于解决以太坊的状态膨胀问题。该方案将过期不活跃的状态值（如账户余额、nonce、合约代码等），并通过提交 Verkle 证明来恢复它们。该方案旨在减少节点存储需求，提高网络性能，并促进以太坊的无状态性和状态过期。
Post-Verkle 状态过期
🧬 赋能以太坊的永恒进化
概要
本项目介绍了一种新的状态过期方案，该方案利用 Verkle 树。所有非活跃值（即，账户余额、nonce、合约代码、插槽等）都将过期，并且可以通过提交 Verkle 证明来恢复。
动机
在以太坊上，状态 包括以下内容：
在任何给定时间，节点都需要知道当前状态才能处理新的区块和交易。随着越来越多的用户加入网络，会创建更多的状态（更多的账户和合约）。随着状态的增长，节点对存储的要求增加，因为它们需要存储完整的状态。
当区块链的状态显著增长时，会阻碍网络的性能，使许多人难以运行节点，最终导致中心化。这个问题被称为 状态膨胀 问题。
项目描述
我提出的解决方案是实现一种 post-verkle 状态过期方案，其中只有叶子节点中的值会过期。过期的值可以通过提交证明来恢复。
与其他方案（例如 Vitalik 基于 Epoch 的方法）相比，该方法相当直接。过期中间节点也可能是一个选项，但存在一些问题。首先，它增加了大量的复杂性，因为当前的 IPA 库不支持从子树获取证明的功能。其次，过期子树会导致树腐烂问题，如 Vitalik 的文章 中所述。
规范
Verkle 树是一种密码学数据结构，类似于 Merkle Patricia 树 (MPT)，不同之处在于它使用向量承诺来提交子节点，而不是常规的密码学哈希。在 Verkle 树中，为特定值生成 witness 比 MPT 证明小得多。较小的 witness 大小允许将 witness 包含在区块中，而不会使区块大小过载。因此，这为以太坊实现了一些重要的路线图，例如无状态性和状态过期。
状态架构的一个主要变化是，所有键值对都存储在一个 Verkle 树中，而不是将账户 trie 和合约 trie 分开存储。这还包括合约代码，其中字节码被分割成 32 字节，并以键值对的形式存储。
要更深入地了解 Verkle 树结构，Verkle 树有两种类型的节点：
- 内部节点：可以包含 256 个子节点，这些子节点可以是空的、内部节点或扩展节点。这类似于 MPT 的分支节点。
- 扩展节点：可以包含 256 个具有相同 stem 但不同后缀的值
在此状态过期方案中，元数据将被添加到值中，以指示它们是否已过期。元数据架构的决策将在设计阶段最终确定。
在开发方面，有一些组件需要解决，分为主要部分和次要部分，如下所示：
主要组件
- Witness 格式
- Verkle 树修改
- EVM
- Prune
- 状态存储
次要组件
对于本项目，将优先考虑主要组件，如果时间允许，可以完成次要组件。
路线图
W6 - W7：设计阶段
在此阶段，我的目标是完成主要组件的设计。这包括理解 Geth 中 Verkle 实现的代码库。
W8 - W15：编码阶段
大部分时间将用于与开发相关的任务。我的目标是在此阶段完成所有主要组件。这还包括使用 Verkle 节点设置本地开发网络。
W16：审查阶段
在最后一周，我将最终确定我的项目成果，并为伊斯坦布尔 DevConnect 期间的演示文稿做准备。我还将提供一个估计，说明使用此状态过期方案可以节省多少状态存储。
可能的挑战
对应用密码学的理解有限
我之前没有编写过与密码学相关的代码的经验，因此这肯定是一个重大的挑战。
Verkle 树的文档不足
我还预见到自己在尝试使用 Verkle 树 repo 设置开发环境时会遇到困难，因为没有很多文档可以这样做。但我会将其视为填补空白并做出贡献的机会。
项目目标
在本 fellowship 项目结束时，我应该能够演示一个基于以下流程的 PoC：
- 运行一个节点
- 部署一个简单的合约
- 等待合约过期
- 发送一笔交易以恢复状态
- 读取恢复的状态
除此之外，我还应该准备一份关于每个设计组件的详细文档，并估计可以节省多少状态存储。
合作者
导师
资源
