以太坊节点连邻居的第一步是自我介绍，其中包含一个叫分叉指纹的字段：把创世哈希和已经历过的历次分叉按顺序算进一个CRC32校验和，生成四个字节，再附一个下一个分叉点的数值。对端拿自己的算一遍，四个字节对不上就说明彼此不在同一条链上，立刻断开。这套机制由EIP-2124定义，让节点不用下载任何区块就能把配错网络的邻居筛掉。EIP-6122在2022年12月提出，负责修它在合并之后的一个新盲区，提案状态是Final。
合并改变了分叉的排期单位
工作量证明时代，硬分叉按区块号排期：升级就写死在某一个高度。指纹算法照此设计，把每个已越过的分叉块号喂进校验和。合并之后情况变了：共识层按slot排分叉，slot本质是时间，于是执行层也被要求同步按时间戳排期，才能保证两层在同一刻切换。问题来了——按时间排期的分叉，块号永远不会精确命中预设值。老算法盯着块号等跨越，等不到，于是这些分叉在指纹计算里像不存在一样。
两个失灵的检测场景
第一个盲区是误判正常邻居。所有节点都完成了升级、也都按时间切换了新规则，但大家的指纹里都没包含这次分叉，看起来彼此一致——相安无事；真正的炸点在升级前后：一部分节点先升级、指纹里带上了时间戳分叉，另一部分没升级，老算法算出的指纹两边竟可能撞车，坏连接不会被立刻切断，错误要到执行交易时才暴露。第二个盲区更隐蔽：分叉之后很久，某节点才完成升级，它算出的指纹和早已升级的邻居不同，老算法会拒绝这些其实合法的邻居，节点陷入谁都连不上的孤岛。EIP-6122的修法顺理成章：时间戳和块号一视同仁，按升序喂进CRC32；同一高度或同一时刻的多个分叉只计入一次；两类数值都按无符号64位大端编码。
修完之后规则长什么样
按这份提案，每个节点维护两个量：FORK_HASH是把创世哈希加历次分叉（块号或时间戳）算出的四字节校验和；FORK_NEXT是下一个已知分叉的块号或时间戳，不知道就填0。握手时对端报上这对数值，节点按自己已越过和即将越过的分叉集合逐条核验：对得上继续聊，对不上握手失败。由于指纹只统计已经过去的分叉，同一条链上处于相同阶段的节点必然算出相同结果——这是整套判定可靠性的根基。
一次误判的完整旅程
设想攻击者想把你引上一条影子链。他需要先让你连上一群看似正常、规则却不同的邻居。在指纹机制下，这条路极其昂贵：影子链要么改创世哈希（立刻暴露），要么在不同时间激活分叉（指纹对不上），要么完全复刻（那就是正链本身）。EIP-6122补上时间戳盲区后，攻击者连利用升级空窗期做时间差都做不到——只要目标链和影子链在任何一次分叉的排期上出现差异，握手阶段的四个字节就会先于任何区块下载把分歧暴露。反过来说，握手判定也解释了为什么配置错链号的节点连不上公开网络：不是防火墙挡你，是它的自我介绍里那四个字节与你算的不一样。
快速问答
问：这和EIP-2124是什么关系？ 答：是修改而非替代。2124定义指纹这套机制本身，6122把喂给校验和的素材从块号扩展到块号加时间戳。 问：普通钱包用户需要做什么吗？ 答：不需要。这是节点间协议；用户能感知的仅是全网同步更快、错连更少。 问：如果我不升级会怎样？ 答：握手判定可能变慢变粗，你更可能在执行阶段而不是连接阶段发现链不一致，报错也更晦涩。
风险提示：本文描述协议机制，不构成任何投资建议。分叉排期以以太坊官方客户端发布说明为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。