握手时先报自家档案柜：EIP-7642 与 eth/69 的区块范围公告

握手消息里的化石

两个以太坊执行层节点相遇，第一件事是互发状态消息：协议版本、网络标识、创世哈希、分叉标识，以及各自链头。在 eth/68 及更早版本里，这条消息还带着一串总难度值——工作量证明时代用来比较链强弱的累加数。2022 年合并之后，链的选择早已改由信标层的最终性规则裁决，总难度成了握手包里的化石：没人用它做决定，但每次握手都要序列化、传输、解析。

EIP-7642 提出的 eth/69 同时清掉两处冗余：状态消息去掉总难度字段，换上一组区块范围声明——这个节点能提供的最早区块号、最新区块号与最新区块哈希；收据消息则删掉布隆过滤器字段。规范 2024 年 2 月创建，状态 Final，属于网络层规范。

为什么现在要报范围

直接动机来自历史到期（history expiry）工作组的一条决定：客户端可以在 2025 年 5 月 1 日之后丢弃合并前的历史记录。一旦部分节点真的开始删旧账，一个新的现实问题浮现——同步一个新节点时，你怎么知道对端还留着创世以来的全部历史，还是只从某个高度开始供货？过去默认人人都有全史，不必声明；如今范围本身成了需要交换的元信息。

于是 eth/69 的状态消息里多了最早区块与最新区块两个数。请求方先比对范围，再决定把哪段同步任务派给这个邻居，避免向一个没有合并前历史的节点反复索要早已不存在的区块。更早在同一方向上有过 EIP-7542 的类似提案，因为当时历史到期还没有形成政治决定而被撤回；7642 等到决定落地后才把机制补上。

收据瘦身：删掉没人存的字段

第二处改动更像一次对账。收据消息里的布隆过滤器字段，设计初衷是让轻客户端用概率过滤快速排除不相关区块。但实现层的现实是：没有一个主流客户端真的把布隆值存下来——它本来就能从日志即时重算。结果每次传输收据，节点都在为同一份数据做重复劳动：发送前现算、网络上白占带宽、接收方验完就丢。eth/69 直接把这个字段从传输编码里拿掉，服务节点省 CPU 与带宽，逻辑上零损失。需要布隆值的旧客户端仍可从日志自行重建。

升级怎么生效

eth/69 不是区块规则的改变，而是节点间协议的版本协商：客户端在发现阶段声明自己支持的 eth 协议子协议集合，双方挑最高公共版本连接。不支持 eth/69 的节点继续按 eth/68 交流，两边互不阻塞。这类网络层变更因此总是平滑铺开——先跑测试网，再随主干升级周期进入默认支持列表，最后随旧版本退场成为唯一语言。

对普通用户意味着什么

日常使用里你不会直接感知 eth/69，但它的两个方向都关乎公共节点池的健康：历史范围公告是历史到期路线图的前置件，决定“将来还能不能从公共节点拉到早期历史”这个长期问题怎么落地；收据瘦身则是每天数十亿字节的带宽回收。跑节点的人值得留意的是：当你的客户端支持丢弃合并前历史时，节点日志与监控里出现的首个可服务区块号就会不再是零。

快速问答

问：删了布隆字段，轻客户端查日志会变慢吗？ 答：传输层不再顺路带布隆值，需要时按日志重算。对按区块批量筛查的场景有成本影响，但主流量路径上多数客户端本就不依赖它。

问：范围声明里的最早区块会随时间变化吗？ 答：会。如果节点执行裁剪或删除旧历史，最早可服务区块号上升，后续握手都会带上新的数。

风险提示

本文描述协议演进，不构成任何投资或节点运营建议。历史到期的执行节奏与客户端支持以官方文档为准。