对运行以太坊执行层节点的人来说，磁盘上最沉重也最少被再次触碰的部分，是合并之前那五年多的链史。EIP-7639 提出的思路非常干脆：节点之间仍然继续同步、继续应答合并之后的数据，但对于区块 15537393（巴黎升级，也就是合并生效的那一个区块）之前的区块正文和收据，在 eth/70 这个协议版本上既不再主动请求，也不再应答。这条提案在 2024 年 2 月创建，目前的状态是 Stagnant（停滞），并没有在主网激活，但它是以太坊历史过期路线上第一个把边界画进 p2p 协议文本的尝试。
为什么偏偏是合并这条线
提案给出的直接动机是体积。文档写道，按 2024 年的情况，客户端里的历史数据大约 500 GB，其中近 400 GB 是合并之前的区块数据。这些数据每天被重复下载、重复校验的可能性极低，却占据着几乎每个全节点的磁盘。
为什么可以只按合并切开，而不是任意挑一个时间点？提案的解释是：合并那一刻区块结构发生了实质变化。今天执行层软件在磁盘上继续沿用与合并后形态相近的区块数据，但规范意义上的权威链已经由信标链定义。因此一个信标区块就足以同时记录执行层与共识层两侧的历史承诺，历史证明体系可以挂在信标链上重建，而不必依赖合并前执行层原始数据的逐字节可取。这种写法刻意对客户端架构保持中立，关注的是数据本身的形状。
哪些消息会被关掉
受影响的是四类 p2p 消息：GetBlockBodies 与 BlockBodies（消息编号 0x05、0x06），以及 GetReceipts 与 Receipts（0x0f、0x10）。在 eth/70 上连上的对端，如果要这些编号的消息指向合并前的区块，应当得到拒绝或空响应；反过来也不会发出这样的请求。区块头不在此列——区块头可以继续被请求，链的结构与工作量证明般的历史骨架并没有被抹掉，被收起来的只是正文交易明细和收据这两类最占体积的东西。
全量同步之后从哪里拿数据
提案里有一个坦率的承认：这条线生效后，节点将无法再单纯从 devp2p 网络做全量同步，合并前的数据必须走带外渠道。换句话说，网络同步负责追到边界附近，边界之下的历史交给归档存储、第三方分发或专门的下载工具。文档在这一处留下了待补充的规范细节，这也是它整体停在 Stagnant 的原因之一：停供容易，替代供给渠道尚未在同一个提案里闭环。与之配套的相关工作（例如给合并前数据建累加器证明的 EIP-7643）走的是同一方向：先把数据形状确定下来，再谈谁负责保管。
一笔体积账
用提案自己的数字做个除法：近 400 比 500，约八成的磁盘负担来自只占链龄一小段的合并前时期。如果历史停供逐步铺开，普通节点的存储曲线将从”跟着链龄线性涨”变成”只跟着新增数据涨”。这正是历史过期路线想换来的那条曲线——节点留住最近的数据，远古数据的可用性交给可证明的归档层。
快速问答
问：eth/70 现在能用吗？ 答：这是一份处于 Stagnant 状态的提案，描述的是尚未在主网激活的行为边界，写作时不应把它当成已上线的协议规则。
问：停供之后，我还能查五年前的某笔交易吗？ 答：链上事实本身不变，变的是”从哪里取”。普通节点不再应答这类查询，需要归档节点、浏览器后端或其他带外来源。
问：区块头也查不到了吗？ 答：不是。提案只关闭正文与收据这两类消息在合并前区间的应答，区块头不在受限名单里。
风险提示：本文描述的是协议提案与网络机制，不构成任何投资建议；节点存储与同步方案变更前请以当期客户端官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。