历史数据要过期，节点就得先学会回答一个问题：我手里有从哪到哪的区块。这个问题在协议里有两种解法。EIP-7642 走的是「推」：握手时把范围一次报清，之后范围有变就主动发一条更新通知，它已经作为 eth/69 的一部分落地。EIP-7542 走的是「拉」：握手时也带上范围，但重点在两个新消息——我想知道你现在有什么，就开口问，你答我一次。这份提案 2023 年 10 月起草，作者 Ahmad Bitar，最终状态是已撤回（Withdrawn）；有意思的是，后来真正落地的 EIP-7642 文档里专门写了一句：类似的想法在 EIP-7542 提过，之所以被撤回，是因为当时关于历史数据过期还没有政治层面的决定——输赢不在图纸，在时机。
两种解法长什么样
先把两边规格摆平。eth/69 的做法是把范围写进状态消息：原来的握手包里有协议版本、网络标识、累计难度、最佳区块哈希、创世哈希和 forkid，新版本删掉合并后已无意义的难度字段，末尾加上最早区块号、最新区块号与最新块哈希三样；范围之后有变，再通过新增的 BlockRangeUpdate（消息编号 0x11）推送，且为省流量限定最多每纪元（三十二块）发一次。EIP-7542 提议的版本 eth/70 则另起炉灶：状态消息在 forkid 后追加一个 blockRange，内容是一对无符号六十四位整数——起始块和结束块；此外定义两个新消息，RequestBlockRange（0x0b）用来问，SendBlockRange（0x0c）用来答，答案同样是起止块号一对。连接后先换状态消息，之后谁关心变化谁再开口问。
一推一拉的工程取舍
差别比看起来大。推送路线的优点是零查询成本：范围信息随连接和更新自然到达，接收方不需要为「先弄清该问谁」多花一次往返；代价是频率管制——每纪元最多一次的节流条款，正是为了压制通知风暴。拉取路线的优点是新鲜度：什么时候想知道、想知道几轮，由需求方决定，节点修剪完磁盘立刻就能被问到；代价是每位对端、每一轮关心都多一次消息往返，协议面也多出两个要各自测试的消息类型。还有一个网络生态的隐账：握手字段每加一项，都会把落后客户端的兼容矩阵弄宽一格，两条路线对「复杂度该由谁扛」的回答并不相同。
撤回的真实理由
EIP-7542 的文档从头到尾技术上都成立：它不改共识引擎、不需要硬分叉，新旧 eth 版本可以在同一台节点上并行服务；它还专门安排了礼貌条款——节点不能仅仅因为对端的可用范围不合自己意就断开，只有在连接位全满、又缺少所需范围的对端时，才允许腾位置另寻。真正让它出局的是价值前提：整套设计的回报，取决于「会有节点真的开始大量修剪历史」这件事被全链接受。在历史过期路线尚未定案时先立一套问话标准，等于为一种没人保证会出现的节点形态预支协议版本。这几乎是所有前瞻性协议提案的共同赌局，EIP-7542 输在时机而非方案。
一条判断线
读「已撤回」提案时，把撤回等同于方案错误是常见误读，更准的读法是把状态徽章看成时机判断。同一问题的答案后来由另一条路线交付：eth/69 的握手范围字段加纪元级推送就是现行标准。若你在组网里遇到「该向哪个节点请求历史数据」的需求，现在能用的仍是这套已上线机制，未上线的那条分支只活在文档历史里。顺带一个易混点：eth 协议版本号反映的是软件新旧，forkid 与创世哈希反映的才是链身份——范围公告又不同，它只描述库存，不改变是非。
快速问答
问：现在网络里有 eth/70 吗？ 答：没有。它随提案撤回而消失，主流节点之间的版本协商停在已上线的版本线上。
问：修剪过历史的节点会谎报范围吗？ 答：范围本是自我声明，规范不做链上验证；对端会用实际请求的成败来校验声明，谎报者会被反复拒单、自然失去用途。
风险提示：本文讲解节点网络机制与提案历史，不构成投资建议；组网行为请以当期客户端文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。