企业官网建设流程全解析

EIP-7927 历史过期（History Expiry）Meta EIP 全解析：与 Pectra 联动的历史数据裁剪激活计划

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs

本文以 EIP-7927（History Expiry Meta）为主体，系统梳理以太坊执行层历史数据过期机制（History Expiry）的激活流程、配套 EIP 体系、兼容性影响与安全边界。你将从本文掌握：历史数据为什么必须被裁剪、主网 / Sepolia / Devnet 三阶段的激活时序、执行层与共识层客户端各自 MUST / SHOULD 的职责划分，以及裁剪后 pre-merge 数据由 e2store 归档、Portal 网络与etha子协议接管的生态方案。全文以当前仓库 EIPS 目录下的 EIP 文档与规范为唯一事实依据。

一、什么是 EIP-7927：一份"历史过期"的路线图文档

EIP-7927 是一份Meta 类型的 EIP（Status: Stagnant，Created: 2025-03-28，Author: Piper Merriam），它不直接修改任何共识规则，而是像项目说明书一样，把"历史数据过期"这件事的激活过程与计划集中记录下来，并为所有相关 EIP 提供索引入口。其requires字段明确指向 EIP-4444。

正如文档摘要所说：

该 Meta-EIP 记录了历史过期的激活过程与计划，并提供指向其他相关 EIP 的链接。

它的诞生背景是：随着 EIP-4444（限制执行客户端的历史数据）逐步落地，客户端将获准丢弃 pre-merge（巴黎合并之前）的历史区块数据。但"什么时候丢、在哪里先测试、各客户端分别承担什么义务、丢完之后 JSON-RPC 怎么办、数据去哪里找"这些问题散落在各个 EIP 中，没有一个统一入口。EIP-7927 正是为此而生：它自己本身不含技术规范细节，而是把规范要求分配到下游 EIP，并为激活节奏定下时间表。

二、为什么需要历史过期：来自 EIP-4444 的动机

EIP-7927 明确将"为什么需要历史过期"的动机论证委托给 EIP-4444。EIP-4444 给出的核心论据是存储成本失控：

• 历史区块与收据（receipts）已占用超过400GB 磁盘空间且仍在增长，普通用户通常需要 1TB 磁盘才能跑全节点；
• 历史数据对验证新区块毫无必要，只在显式 JSON-RPC 请求或对等节点追同步时才会被访问；
• 裁剪历史可显著降低磁盘需求，还能让执行客户端删除"处理历史区块"的代码路径，无需长期维护针对历次升级累积变更的兼容代码；
• 基于 PoS 弱主观性（weak subjectivity）假设的更轻量同步策略，也能降低网络带宽消耗。

EIP-4444 提出参数HISTORY_PRUNE_EPOCHS = 33024（对应共识层的区块保留窗口，源自最大弱主观性周期）：客户端SHOULD NOT在 p2p 网络层面提供早于该窗口的 headers、block bodies 与 receipts，MAY在本地裁剪这些数据。正因如此，DevP2P 上将不再可能执行"从创世开始的完整同步"，客户端必须使用有效的弱主观性检查点（Weak Subjectivity Checkpoint）进行"检查点同步"。

三、核心规范：执行层与共识层的 MUST / SHOULD 分工

EIP-7927 的 Specification 部分采用 RFC 2119 / RFC 8174 的关键词约定（MUST / MUST NOT / REQUIRED / SHALL / SHALL NOT / SHOULD / SHOULD NOT / RECOMMENDED / NOT RECOMMENDED / MAY / OPTIONAL），将义务分配到两类客户端：

注意这里的力度差异：执行层是"可以丢"（MAY），而不是"必须丢"（MUST）——这是 EIP-7927 反复强调的兼容性边界（详见第五节）。

3.1 执行层 MUST：升级到 eth/69（EIP-7642）

EIP-7642（Status: Final）是历史过期在 DevP2P 层的落地载体，主要做三件事：

1. Status 消息新增区块范围通告，让对等节点知道对方还保留着多早的历史：
   • eth/68：[version, networkid, td, blockhash, genesis, forkid]
   • eth/69：[version, networkid, genesis, forkid, earliestBlock, latestBlock, latestBlockHash]
   • 其中td（total difficulty）在合并后已无意义（post-merge 难度恒为 0），被移除；
2. 移除 Receipts 消息中的Bloom字段：网络层此前要求每条收据携带 256 字节 bloom 过滤器，而客户端实际都不存储它、需要时再重算。全量同步时服务端要重新生成约530GB的 bloom 数据（约 2.3B 笔交易 × 256 字节）在网络上传送，接收方校验后也不存储——纯属浪费带宽。eth/69 将收据编码简化为扁平字段列表[tx-type, post-state-or-status, cumulative-gas, logs]，每个同步节点可节省约 530GiB（snappy 压缩后约 95GiB）带宽；
3. 新增BlockRangeUpdate (0x11)消息：编码为[earliestBlock, latestBlock, latestBlockHash]，在节点可用区块范围变化时通知对等节点，为降低流量，最多每 epoch（32 个区块）发送一次。

3.2 执行层 MAY：丢弃 pre-merge 历史（EIP-7639）

EIP-7639 提出了eth/70协议版本：连接到该版本的客户端不得发起或响应关于 Paris 升级（block 15537393）之前区块数据（block bodies 与 receipts）的 p2p 查询。受影响的协议消息包括GetBlockBodies (0x05)、BlockBodies (0x06)、GetReceipts (0x0f)、Receipts (0x10)。

其动机数据同样触目惊心：截至 2024 年，客户端历史数据已膨胀至约500GB，其中近400GB来自 PoS 激活（Paris）之前的区块。EIP-7927 正是借 EIP-7639 的条款授予执行层"可以丢"的权利。

3.3 共识层 SHOULD：解除对存款日志的依赖（EIP-6110）

共识层客户端历史上依赖执行层提供 pre-merge 区块的存款合约日志（deposit logs）来完成验证者入金处理。一旦执行层丢弃历史，这些日志将无法通过本地执行层客户端获得。解决方案是 EIP-6110（Status: Final）：将验证者存款以存款操作列表的形式直接写入执行层区块，由执行层负责解析存款合约日志并生成 EIP-7685 请求，共识层从区块本身读取存款，从而移除对eth1data投票机制的依赖。其收益包括：

• 入金安全性显著提升：即使超过 2/3 的质押权益作恶，诚实的在线节点也不会被说服处理虚假存款；
• 存款从提交到在共识层处理的时间由约 12 小时缩短至约13 分钟；
• 消除共识层对 JSON-RPC 数据轮询的依赖（此前易受实现不一致与节点同步状态影响）；
• 无需再维护与分发存款合约快照（见 EIP-4881）。

EIP-6110 还给出了关键配置常量：主网DEPOSIT_CONTRACT_ADDRESS = 0x00000000219ab540356cbb839cbe05303d7705fa、DEPOSIT_EVENT_SIGNATURE_HASH = 0x649bbc62d0e31342afea4e5cd82d4049e7e1ee912fc0889aa790803be39038c5，以及pubkey(48B) + withdrawal_credentials(32B) + amount(8B) + signature(96B) + index(8B)的存款请求结构，并提供了完整的is_valid_deposit_event_data校验伪代码。

四、激活计划：主网 / Sepolia / Devnet 三阶段

EIP-7927 的核心贡献在于给出历史过期的分阶段激活时间表：

4.1 Devnet 激活

执行层客户端可以在 devnet 上先行测试丢弃历史。Devnet 是风险最低的实验场，目的是在触及正式测试网之前发现并修复问题，避免任何破坏蔓延到 Sepolia。

4.2 Testnet 激活（Sepolia）

历史过期的正式测试选在Sepolia 测试网：执行层客户端自 2025-05-01 起可以开始丢弃 pre-merge 的 Sepolia 历史。Sepolia 被选作测试场，是为了给主网激活提供真实的网络规模与客户端组合验证。

4.3 Mainnet 激活（紧随 Pectra）

主网激活将在 Pectra 硬分叉（EIP-7600）激活之后的数天到数周内发生。这段刻意保留的"短延迟"是为了确保分叉前的所有存款日志都已被处理完毕，客户端才开始丢弃历史。

为什么必须等 Pectra？因为共识层客户端对 pre-merge 存款日志存在依赖，而 EIP-6110 正是随 Pectra 分叉激活并移除该依赖的。EIP-7600 的 Included EIPs 列表证实了这一点：EIP-6110 属于 Pectra 的 Core EIP，而 EIP-7642（eth/69）属于 Pectra 的 Networking 类 EIP——其附注明确写道："虽然不是 Pectra 升级所必需，但客户端团队可以在升级激活时支持 EIP-7642，并且必须在下一个网络升级时支持它。"这正解释了 EIP-7927 中"执行层 MUST 实现 eth/69"与"主网激活紧随 Pectra"之间的逻辑闭环。

五、兼容性分析

5.1 DevP2Peth协议

所有 DevP2Peth协议的客户端都需要升级到 EIP-7642 定义的eth/69版本。由于线协议支持多版本并存，升级不会立即破坏旧客户端——它们仍可继续使用eth/68。EIP-7642 也明确声明：该 EIP不改变 EVM 共识规则，不需要硬分叉。

5.2 Pre-Merge 存款日志

共识层客户端对 pre-merge 区块的存款日志存在历史依赖；丢弃历史将使这些日志对共识层客户端不可达。该问题由 EIP-6110 缓解——正如 3.3 节所述，存款处理已内置于执行层区块结构。

5.3 服务 Pre-Merge JSON-RPC：受影响的 12 个端点

选择丢弃历史的执行层客户端，将不再能够为 pre-merge 区块提供以下 JSON-RPC 端点服务（除非从替代数据源获取数据）：

• eth_getBlockTransactionCountByHash
• eth_getBlockTransactionCountByNumber
• eth_getUncleCountByBlockHash
• eth_getUncleCountByBlockNumber
• eth_getBlockByHash
• eth_getBlockByNumber
• eth_getTransactionByHash
• eth_getTransactionByBlockHashAndIndex
• eth_getTransactionByBlockNumberAndIndex
• eth_getTransactionReceipt
• eth_getUncleByBlockHashAndIndex
• eth_getUncleByBlockNumberAndIndex

EIP-4444 进一步指出，裁剪后getBlockByHash等端点将无法区分"哈希无效"与"数据过旧"，getLogs等端点则直接拿不到用户请求的数据；这些回归在应用层如何处置，超出了协议范围。同时 EIP-4444 建议客户端分两阶段推进：第一阶段默认不裁剪、提供类似 geth--txlookuplimit的命令行选项让用户主动裁剪；第二阶段默认裁剪并移除该选项。

六、设计理由（Rationale）逐条解读

EIP-7927 的 Rationale 部分回答了五个关键质疑，逐一解读如下：

• 为什么等 Pectra？共识层客户端依赖 pre-merge 存款日志，而 EIP-6110 在 Pectra 分叉激活时才移除这一依赖。在主网历史丢弃前必须先完成"存款供给链路的去依赖化"，否则共识层将失去入金数据来源。
• 为什么在 Sepolia 丢历史？Sepolia 的历史丢弃是主网激活的测试场，让客户端在真实但低风险的网络上验证裁剪逻辑与配套生态。
• 为什么在 Devnet 丢历史？Devnet 丢弃用于在 Sepolia之前先行验证，避免破坏 Sepolia 网络。
• 这会不会破坏 JSON-RPC？不会。历史过期只是允许客户端移除数据，而不要求它们移除。希望保留历史以继续服务 JSON-RPC 的客户端完全有权继续保留。
• Pre-merge 历史存储在哪里？三条出路：① pre-merge 数据以e2store 归档格式提供，公开归档列表维护在eth-clients的历史数据端点列表中；②Portal 网络提供去中心化的点对点方案，存储与检索以太坊全部 pre-merge 区块数据；③ EIP-7801 的ethaDevP2P 子协议提供点对点数据检索。

其中 EIP-7801 值得展开：它定义了一个名为etha的独立子协议，通过10 位 bitmask通告节点所存储的区块分片（每个 bit 代表 1,064,960 个区块范围内的 106,496 个区块跨度），握手消息为[version, networkid, blockhash, genesis, forkid, blockBitmask]。节点通过 bitmask 承诺保留对应跨度，目标是覆盖至少 10% 的链历史；其消息类型直接复用eth/69的GetBlockBodies/BlockBodies/GetReceipts/Receipts。该方案源于 EIP-4444 的裁剪动机，且 106,496 / 1,064,960 是 Era1 文件最大区块范围 8,192 的整数倍，便于归档存储。其安全模型为：数据不可用的概率 P = (0.9)^n（n 为对等节点数），25 个对等节点时约 7%，32 个时约 3.4%。

七、安全考虑

7.1 全量历史同步（Full History Sync）

一旦历史过期落地，执行层客户端将无法再通过 DevP2Peth协议完成从创世开始的完整历史同步。希望保留此能力的客户端需要从替代来源获取 pre-merge 区块。EIP-7927 特别强调：客户端SHOULD确保对来自替代位置的区块数据继续做正确性校验——从 p2p 之外引入的数据不能"默认可信"。EIP-4444 也呼应了这一观点，建议构建专门的"full sync shim"客户端，将不同版本执行引擎拼接起来离线导入历史区块，以验证整条链。

7.2 部分历史同步（Partial History Sync）

执行层客户端做部分同步（partial sync）时，需要调整同步算法：只回溯到合并区块（merge block）即可，而非像过去那样一路追溯到创世。客户端SHOULD确保同步算法及其他功能能够正确处理"这些数据不再本地可用"的情况——例如上一节列出的 12 个 JSON-RPC 端点在历史范围内将返回缺失数据，客户端与上层应用都需适配。

从安全角度综合看：EIP-7927 借助 EIP-4444 的弱主观性假设——客户端必须使用有效且非过期的弱主观性检查点启动，否则会面临长程攻击（long-range attack）风险；同时若共识层改变区块保留窗口，HISTORY_PRUNE_EPOCHS必须同步更新，否则检查点同步可能因执行层 p2p 不再提供所需执行负载而失败。此外，历史数据缺乏留存激励存在审查/可用性风险，需由独立组织持续做种子化与可用性检查（EIP-4444 将这类机制视为协议范围之外）。

八、总结：从 Meta EIP 看历史过期的完整拼图

EIP-7927 作为一份 Meta EIP，其价值不在于定义新机制，而在于把历史过期的执行计划编排成一张清晰的任务清单：

1. 协议层：执行层升级eth/69（EIP-7642），获准停止服务 pre-merge 数据（EIP-7639），共识层切换到链上存款供给（EIP-6110）；
2. 时间线：Devnet 先行实验 → Sepolia 自 2025-05-01 起可丢弃 → 主网在 Pectra（EIP-7600）激活后数天至数周内跟进；
3. 生态兜底：e2store 归档、Portal 网络与etha子协议（EIP-7801）共同保证 pre-merge 历史数据仍然可获取；
4. 边界与安全：JSON-RPC 服务不强制降级，但 12 个历史端点需替代数据源；全量/部分同步算法必须适配数据缺失，并对带外数据保持校验。

对于执行层与共识层客户端开发者、节点运维者以及依赖历史数据的 DApp 团队而言，EIP-7927 就是理解"以太坊历史数据何去何从"的最佳入口文档；配合本文梳理的各下游 EIP 原文（均可在本仓库 EIPS 目录下找到），即可掌握从协议变更到部署节奏的完整图景。

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs