EIP-6873: 原像保留
执行客户端必须保留前导分叉和 Verge 之间访问的地址和插槽的原像，直到 Verge 本身。
| Authors | Guillaume Ballet (@gballet) |
|---|---|
| Created | 2023-04-14 |
| Discussion Link | https://ethereum-magicians.org/t/eip-6873-preimage-retention-in-the-fork-preceding-the-verge/15830 |
摘要
强制网络上的每个节点从前导分叉到 Verge 之间的时段收集原像，以防每个节点负责自己的转换。
规范
本文档中的关键词 “MUST”，“MUST NOT”，“REQUIRED”，“SHALL”，“SHALL NOT”，“SHOULD”，“SHOULD NOT”，“RECOMMENDED”，“NOT RECOMMENDED”，“MAY” 和 “OPTIONAL” 应按照 RFC 2119 和 RFC 8174 中的描述进行解释。
设 T_p 为前导分叉的时间戳，T_v 为 Verge 的时间戳。
-
EL 客户端必须保存它们在
T_p和T_v之间生成的所有区块的执行过程中，生成的每个地址和插槽哈希的原像 -
EL 客户端可以开始存储此时间范围之外的原像
-
给定在
T_p和T_v之间生成的哈希，EL 客户端应该能够证明它们在其数据库中具有该哈希的原像 -
EL 客户端应该能够从公开可用的数据存储中下载在
T_v之前生成的地址和插槽哈希的原像
理由
切换到 Verkle 树需要对所有树密钥进行完整的重新哈希。大多数执行客户端存储所有哈希的密钥，没有其原像，在发布时，这在主网上占用 70GB。为了使每个人都可以使用这些原像，每个用户都可以使用以下操作过程：
- 启用原像保留的情况下重新启动完全同步
- 以下载文件形式下载原像
第二种选择在实践中是唯一可接受的选择，因为完全同步要求同步机器离线几天，因此不应同时强加给整个网络。但是，文件下载会带来数据过时的问题，因为随着链的进行和访问新的地址，立即需要将新的原像添加到列表中。更新原像文件是不够的，因为下载超过 70GB 的数据需要超过一个插槽的时间。
为了保证在 Verkle 转换时间附近及时提供所有原像，因此每个节点负责更新前导分叉和 Verge 之间的原像列表。
向后兼容性
没有发现向后兼容性问题。
参考实现
所有客户端都已经实现了原像保留，至少作为一个选项。
安全注意事项
需要讨论。
版权
在 CC0 下放弃版权和相关权利。
Citation
Please cite this document as:
Guillaume Ballet (@gballet), "EIP-6873: 原像保留 [DRAFT]," Ethereum Improvement Proposals, no. 6873, April 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6873.