EIP-4444: 执行客户端中绑定的历史数据
裁剪客户端中超过一年的历史数据
| Authors | George Kadianakis (@asn-d6), lightclient (@lightclient), Alex Stokes (@ralexstokes) |
|---|---|
| Created | 2021-11-02 |
| Discussion Link | https://ethereum-magicians.org/t/eip-4444-bound-historical-data-in-execution-clients/7450 |
Table of Contents
摘要
客户端必须停止在 p2p 层上提供超过一年的历史头、主体和收据。客户端可以在本地裁剪这些历史数据。
动机
历史区块和收据目前占据超过 400GB 的磁盘空间（并且还在增长！）。因此，为了验证链，用户通常需要一个 1TB 的磁盘。
历史数据对于验证新区块不是必需的，因此一旦客户端同步到链的顶端，历史数据仅在通过 JSON-RPC 显式请求或当对等方尝试同步链时才会被检索。通过裁剪历史记录，此提案降低了用户的磁盘需求。裁剪历史记录还允许客户端删除处理历史区块的代码。这意味着执行客户端不需要维护处理每次升级的复杂变更的代码路径。
最后，由于客户端采用基于 PoS 弱主观性假设的更轻量级的同步策略，此更改将减少网络上的带宽使用。
规范
| 参数 | 值 | 描述 |
|---|---|---|
HISTORY_PRUNE_EPOCHS |
82125 | 信标链的纪元中的一年 |
客户端 不应 在 p2p 网络上提供早于 HISTORY_PRUNE_EPOCHS 纪元的头、区块主体和收据。
客户端 可以 在本地裁剪早于 HISTORY_PRUNE_EPOCHS 纪元的头、区块主体和收据。
引导和同步
此 EIP 影响客户端引导和同步的方式。由于历史数据将不再提供，客户端将无法使用 devp2p 进行完全同步。
客户端 必须 使用有效的弱主观性检查点从链的较新视图进行引导。为了同步的目的，客户端将弱主观性检查点视为创世区块。我们将此方法称为“检查点同步”。
为了本提案的目的，我们假设客户端始终以配置好的且有效的弱主观性检查点开始。实现此目标的方式不在本提案的范围内。
基本原理
此提案强制客户端停止通过 p2p 提供旧的历史数据。我们明确地这样做是为了强制客户端从其他来源寻求历史数据，而不是依赖于某些客户端的可选行为，这会导致质量下降。
为什么是一年？
此提案将 HISTORY_PRUNE_EPOCHS 设置为 82125 个纪元（一个地球年）。此常量足够大，可以为弱主观性周期提供足够的增长空间，并且也足够小，不会占用太多磁盘空间。
向后兼容性
保留历史数据
此提案影响使用历史数据的节点（例如，显示区块、交易或帐户历史记录的 web3 应用程序）。保留 Ethereum 的历史是根本的，我们相信有各种带外方法可以实现这一点。
历史数据可以通过 torrent magnet 链接或像 IPFS 这样的网络进行打包和共享。此外，像 Portal Network 或 The Graph 这样的系统可以用于获取历史数据。
客户端应允许导入和导出历史数据。客户端可以提供获取/验证数据并自动导入它们的脚本。
从创世区块完全同步
通过 p2p 网络将不再可能进行完全同步。但是，我们确实希望允许感兴趣的各方自行进行同步。
我们建议构建一个专门的“完全同步”客户端。该客户端是一个垫片，它将不同版本的执行引擎拼接在一起，并且可以导入历史区块以验证从创世区块开始的整个 Ethereum 链，并生成所有其他历史数据。
同样重要的是要注意，尽管具有“状态同步”功能的存档节点正在开发中，但完全同步是目前引导它们的唯一可靠方法。希望继续提供存档支持的客户端将需要导入带外检索的历史区块的能力，并保留对网络每次历史升级的支持。
用户体验
此提案影响设置使用历史数据的应用程序的 UX。因此，我们建议客户端分两个阶段引入此更改：
在第一阶段，客户端默认不裁剪历史数据。他们引入一个类似于 Geth 的 --txlookuplimit 的命令行选项，如果用户想要裁剪历史数据，可以使用该选项。
在第二阶段，默认情况下会裁剪历史记录，并删除命令行选项。客户端假设用户将以带外方式查找和导入数据。
JSON-RPC 更改
在此提案实施后，某些 JSON-RPC 端点（例如 getBlockByHash）将无法分辨给定的哈希是无效还是仅仅是过时的。其他端点（如 getLogs）将不再拥有用户请求的数据。如何处理此回归应由应用程序或客户端处理，这不在本提案的范围内。
安全考虑
依赖弱主观性
随着转向 PoS，由于远程攻击，使用有效的弱主观性检查点对于安全至关重要。
此提案依赖于弱主观性假设，并假设客户端不会使用无效或旧的 WS 检查点进行引导。
此提案还假设弱主观性周期永远不会长于 HISTORY_PRUNE_EPOCHS。如果发生这种情况，具有旧的弱主观性检查点的客户端将永远无法“检查点同步”，因为 p2p 网络将无法提供所需的数据。
中心化/审查风险
如果缺乏保留历史数据的激励，则存在审查/可用性风险。
重要的是，Ethereum 历史数据应由独立的组织保存和播种，并且应经常检查其可用性。我们认为这些机制不在本提案的范围内。
此外，由于设置完整节点将更加困难，因此存在更多 dapp 将依赖于集中式服务来获取历史数据的风险。
与其他提案混淆
因为有许多替代提案可以减少执行客户端在磁盘上的占用空间，所以我们决定强制执行 EIP 的特定发音。当发音 EIP 编号时，必须 将 EIP 发音为“four fours”。所有其他发音都是不正确的。
版权
Copyright and related rights waived via CC0.
Citation
Please cite this document as:
George Kadianakis (@asn-d6), lightclient (@lightclient), Alex Stokes (@ralexstokes), "EIP-4444: 执行客户端中绑定的历史数据 [DRAFT]," Ethereum Improvement Proposals, no. 4444, November 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4444.