本文描述了将 Reth 以太坊执行客户端从 Merkle 树迁移到 Verkle 树，并使其成为无状态客户端的 PoC 项目。该项目旨在集成 rust-verkle 密码学原语到 reth，并实现无状态客户端功能，从而支持以太坊的去中心化和与 Zk-EVM 的兼容性。主要工作包括构造区块执行的见证(witness)、传播见证以进行无状态验证，以及从 Verkle 区块见证获取预状态。
reth-verkle PoC
该项目将涉及将 reth EL-client 从 merkle 树迁移到 verkle 树，并使其能够充当无状态客户端。
动机
由于以下原因，无状态客户端对于以太坊的去中心化非常必要：
- 以太坊当前的 state size 对于许多节点来说太大，无法保存在工作内存中，需要昂贵的 SSD 进行存储，并减慢区块验证和链同步速度。无状态客户端将允许验证者在不维护完整状态的情况下验证区块，从而显著降低其资源需求并减少同步时间。
- 为无状态使用 verkle 树使客户端架构与 Zk-EVM 未来更兼容，并具有一些额外的探索性优势，例如大幅增加 gas-limits。
创建 reth-verkle poc 的主要动机是开发更多在 EL-clients 中实现 verkle 集成的可行方案，这将有助于与其他客户端进行互操作，进一步研究，并使 reth 能够为 The Verge 做准备，了解更多关于无状态为何重要的信息：Why it's so important to go stateless
项目描述
该项目旨在将 rust-verkle 密码学原语集成到 reth 中，并使其能够充当无状态客户端。
一个基本的 TL;DR 是：
- 允许在区块执行期间构建 witness。
- 将此 witness 与区块一起传播，以便其他客户端进行无状态验证。
- 在无状态交叉验证时，从 verkle-block witness 获取 pre-state。
- 然后使用此 witness 无状态地执行区块，而不是本地链。
规范
技术规范将涉及遵循已定义的 specs 和 Verkle serialization format in SSZ 以便在 reth 中进行更改：
-
将创建一个区块/执行 witness（即：无状态执行区块所需的 verkle 证明）结构，这是以下 ExecutionWitness 结构的 SSZ 编码序列化：
class ExecutionWitness(container):
state_diff: StateDiff
verkle_proof: VerkleProof
-
state_diff 将包含执行给定区块所需的所有 pre-state 数据，然后将由其他客户端无状态地执行（基本上是 verkle 树的叶节点键值对），StateDiff 定义：
MAX_STEMS = 2**16
VERKLE_WIDTH = 256
class SuffixStateDiff(Container):
suffix: Byte
# Null means not currently present
current_value: Union[Null, Bytes32]
# Null means value not updated
new_value: Union[Null, Bytes32]
class StemStateDiff(Container):
stem: Stem
# Valid only if list is sorted by suffixes
suffix_diffs: List[SuffixStateDiff, VERKLE_WIDTH]
# Valid only if list is sorted by stems
StateDiff = List[StemStateDiff, MAX_STEMS]
-
verkle_proof 将包含验证者重建 pre-state 树的部分视图所需的所有数据（使用 commitments、根节点和给定的区块值），用于证明 state_diff 中存在的数据，这将用于证明提供的此 pre-state 数据确实是树的一部分，其根节点是已存在于客户端中的 state_root_node（受信任的），VerkleProof 定义：
BandersnatchGroupElement = Bytes32
BandersnatchFieldElement = Bytes32
MAX_COMMITMENTS_PER_STEM = 33 # = 31 for inner nodes + 2 (C1/C2)
IPA_PROOF_DEPTH = 8 # = log2(VERKLE_WIDTH)
class IpaProof(Container):
C_L = Vector[BandersnatchGroupElement, IPA_PROOF_DEPTH]
C_R = Vector[BandersnatchGroupElement, IPA_PROOF_DEPTH]
final_evaluation = BandersnatchFieldElement
class VerkleProof(Container):
// [Group A]
other_stems: List[Bytes32, MAX_STEMS]
depth_extension_present: List[uint8, MAX_STEMS]
commitments_by_path: List[BandersnatchGroupElement, MAX_STEMS * MAX_COMMITMENTS_PER_STEM]
// [Group B]
D: BandersnatchGroupElement
ipa_proof: IpaProof
在这里，other_stems、depth_extension_present、commitments_by_path 是用于构建 verkle-trie 的此部分视图的数据，ipa_proof 是 verkle 证明，它将用于打开从提供的叶节点到 trie-root 的路径中的 commitment，这将证明所提供的数据确实是正确的
有关上述更改和术语的更多详细信息，请参阅 Ignacio 的这篇文章：Anatomy of a verkle proof
-
上述更改将需要修改 EL-client，以检索特定状态值以构建 block-witness，使用此 witness 并删除本地链进行验证，网络级别更改以传播 witness，删除 MPT 并切换到 VPT，以及相关的 DB 相关更改。
Roadmap
- 7 月 - 8 月中旬：理解 geth 和 ethereumJs 客户端实现，以及 rust-verkle 密码学。
- 8 月中旬 - 9 月底：实施建议的更改。
- 10 月 - Devcon：测试和正确评估建议更改的基准。
可能的挑战
这是一个漫长的项目，不仅需要深入了解与 verkle 相关的密码学，还需要了解完整的 EL 客户端架构，从数据库建模（用于树修改）、EVM（获取适当的存储数据以用于 witness）、网络协议（用于传播 witness）。
一旦代码库准备就绪，测试和正确评估性能基准将是最困难的瓶颈，这可能涉及进一步实施优化技术以提高性能。
项目目标
如果 reth 能够加入最新迭代的 Kaustinen devnet（用于 verkle-tries 的 devnet），通过此更改的所有 MPT-VPT 转换测试和 EL-spec 测试，并且性能与其他客户端实现相当，那么该项目的最终目标将实现。
合作者
Fellows
目前只有我：Aditya
Mentors
reth 团队：Georgios, Roman, Oliver, Matthias
EF 团队：Ignacio
资源
