2026/9/15 22:42:06
FEATURED · 精选文章 
EIP-7927 历史过期History ExpiryMeta EIP 全解析与 Pectra 联动的历史数据裁剪激活计划【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本文以 EIP-7927History Expiry Meta为主体系统梳理以太坊执行层历史数据过期机制History Expiry的激活流程、配套 EIP 体系、兼容性影响与安全边界。你将从本文掌握历史数据为什么必须被裁剪、主网 / Sepolia / Devnet 三阶段的激活时序、执行层与共识层客户端各自 MUST / SHOULD 的职责划分以及裁剪后 pre-merge 数据由 e2store 归档、Portal 网络与etha子协议接管的生态方案。全文以当前仓库 EIPS 目录下的 EIP 文档与规范为唯一事实依据。一、什么是 EIP-7927一份历史过期的路线图文档EIP-7927 是一份Meta 类型的 EIPStatus: StagnantCreated: 2025-03-28Author: 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 与 receiptsMAY在本地裁剪这些数据。正因如此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将义务分配到两类客户端客户端要求对应 EIP执行层客户端MUST实现eth/69协议以支持 DevP2PEIP-7642执行层客户端MAY依据规则丢弃 pre-merge 历史EIP-7639共识层客户端SHOULD NOT依赖执行层提供 pre-merge 区块的存款日志SHOULD实现链上存款供给机制EIP-6110注意这里的力度差异执行层是可以丢MAY而不是必须丢MUST——这是 EIP-7927 反复强调的兼容性边界详见第五节。3.1 执行层 MUST升级到 eth/69EIP-7642EIP-7642Status: Final是历史过期在 DevP2P 层的落地载体主要做三件事Status 消息新增区块范围通告让对等节点知道对方还保留着多早的历史eth/68[version, networkid, td, blockhash, genesis, forkid]eth/69[version, networkid, genesis, forkid, earliestBlock, latestBlock, latestBlockHash]其中tdtotal difficulty在合并后已无意义post-merge 难度恒为 0被移除移除 Receipts 消息中的Bloom字段网络层此前要求每条收据携带 256 字节 bloom 过滤器而客户端实际都不存储它、需要时再重算。全量同步时服务端要重新生成约530GB的 bloom 数据约 2.3B 笔交易 × 256 字节在网络上传送接收方校验后也不存储——纯属浪费带宽。eth/69 将收据编码简化为扁平字段列表[tx-type, post-state-or-status, cumulative-gas, logs]每个同步节点可节省约 530GiBsnappy 压缩后约 95GiB带宽新增BlockRangeUpdate (0x11)消息编码为[earliestBlock, latestBlock, latestBlockHash]在节点可用区块范围变化时通知对等节点为降低流量最多每 epoch32 个区块发送一次。3.2 执行层 MAY丢弃 pre-merge 历史EIP-7639EIP-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-6110Status: 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-7642eth/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_getBlockTransactionCountByHasheth_getBlockTransactionCountByNumbereth_getUncleCountByBlockHasheth_getUncleCountByBlockNumbereth_getBlockByHasheth_getBlockByNumbereth_getTransactionByHasheth_getTransactionByBlockHashAndIndexeth_getTransactionByBlockNumberAndIndexeth_getTransactionReceipteth_getUncleByBlockHashAndIndexeth_getUncleByBlockNumberAndIndexEIP-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)^nn 为对等节点数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其价值不在于定义新机制而在于把历史过期的执行计划编排成一张清晰的任务清单协议层执行层升级eth/69EIP-7642获准停止服务 pre-merge 数据EIP-7639共识层切换到链上存款供给EIP-6110时间线Devnet 先行实验 → Sepolia 自 2025-05-01 起可丢弃 → 主网在 PectraEIP-7600激活后数天至数周内跟进生态兜底e2store 归档、Portal 网络与etha子协议EIP-7801共同保证 pre-merge 历史数据仍然可获取边界与安全JSON-RPC 服务不强制降级但 12 个历史端点需替代数据源全量/部分同步算法必须适配数据缺失并对带外数据保持校验。对于执行层与共识层客户端开发者、节点运维者以及依赖历史数据的 DApp 团队而言EIP-7927 就是理解以太坊历史数据何去何从的最佳入口文档配合本文梳理的各下游 EIP 原文均可在本仓库 EIPS 目录下找到即可掌握从协议变更到部署节奏的完整图景。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
EIP-7927 历史过期（History Expiry）Meta EIP 全解析：与 Pectra 联动的历史数据裁剪激活计划
EIP-7927 历史过期History ExpiryMeta EIP 全解析与 Pectra 联动的历史数据裁剪激活计划【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本文以 EIP-7927History Expiry Meta为主体系统梳理以太坊执行层历史数据过期机制History Expiry的激活流程、配套 EIP 体系、兼容性影响与安全边界。你将从本文掌握历史数据为什么必须被裁剪、主网 / Sepolia / Devnet 三阶段的激活时序、执行层与共识层客户端各自 MUST / SHOULD 的职责划分以及裁剪后 pre-merge 数据由 e2store 归档、Portal 网络与etha子协议接管的生态方案。全文以当前仓库 EIPS 目录下的 EIP 文档与规范为唯一事实依据。一、什么是 EIP-7927一份历史过期的路线图文档EIP-7927 是一份Meta 类型的 EIPStatus: StagnantCreated: 2025-03-28Author: 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 与 receiptsMAY在本地裁剪这些数据。正因如此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将义务分配到两类客户端客户端要求对应 EIP执行层客户端MUST实现eth/69协议以支持 DevP2PEIP-7642执行层客户端MAY依据规则丢弃 pre-merge 历史EIP-7639共识层客户端SHOULD NOT依赖执行层提供 pre-merge 区块的存款日志SHOULD实现链上存款供给机制EIP-6110注意这里的力度差异执行层是可以丢MAY而不是必须丢MUST——这是 EIP-7927 反复强调的兼容性边界详见第五节。3.1 执行层 MUST升级到 eth/69EIP-7642EIP-7642Status: Final是历史过期在 DevP2P 层的落地载体主要做三件事Status 消息新增区块范围通告让对等节点知道对方还保留着多早的历史eth/68[version, networkid, td, blockhash, genesis, forkid]eth/69[version, networkid, genesis, forkid, earliestBlock, latestBlock, latestBlockHash]其中tdtotal difficulty在合并后已无意义post-merge 难度恒为 0被移除移除 Receipts 消息中的Bloom字段网络层此前要求每条收据携带 256 字节 bloom 过滤器而客户端实际都不存储它、需要时再重算。全量同步时服务端要重新生成约530GB的 bloom 数据约 2.3B 笔交易 × 256 字节在网络上传送接收方校验后也不存储——纯属浪费带宽。eth/69 将收据编码简化为扁平字段列表[tx-type, post-state-or-status, cumulative-gas, logs]每个同步节点可节省约 530GiBsnappy 压缩后约 95GiB带宽新增BlockRangeUpdate (0x11)消息编码为[earliestBlock, latestBlock, latestBlockHash]在节点可用区块范围变化时通知对等节点为降低流量最多每 epoch32 个区块发送一次。3.2 执行层 MAY丢弃 pre-merge 历史EIP-7639EIP-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-6110Status: 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-7642eth/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_getBlockTransactionCountByHasheth_getBlockTransactionCountByNumbereth_getUncleCountByBlockHasheth_getUncleCountByBlockNumbereth_getBlockByHasheth_getBlockByNumbereth_getTransactionByHasheth_getTransactionByBlockHashAndIndexeth_getTransactionByBlockNumberAndIndexeth_getTransactionReceipteth_getUncleByBlockHashAndIndexeth_getUncleByBlockNumberAndIndexEIP-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)^nn 为对等节点数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其价值不在于定义新机制而在于把历史过期的执行计划编排成一张清晰的任务清单协议层执行层升级eth/69EIP-7642获准停止服务 pre-merge 数据EIP-7639共识层切换到链上存款供给EIP-6110时间线Devnet 先行实验 → Sepolia 自 2025-05-01 起可丢弃 → 主网在 PectraEIP-7600激活后数天至数周内跟进生态兜底e2store 归档、Portal 网络与etha子协议EIP-7801共同保证 pre-merge 历史数据仍然可获取边界与安全JSON-RPC 服务不强制降级但 12 个历史端点需替代数据源全量/部分同步算法必须适配数据缺失并对带外数据保持校验。对于执行层与共识层客户端开发者、节点运维者以及依赖历史数据的 DApp 团队而言EIP-7927 就是理解以太坊历史数据何去何从的最佳入口文档配合本文梳理的各下游 EIP 原文均可在本仓库 EIPS 目录下找到即可掌握从协议变更到部署节奏的完整图景。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
