今天以太坊升级一次硬分叉，流程是：核心开发者会议敲定 EIP 名单，客户端团队发版，升级按约定区块号或时点自动生效——激活那一刻不需要任何链上投票，版本分布的「信号」散落在各个客户端仓库与升级公告博客里。EIP-7848 想把这场协调搬进区块本身：每个区块头携带一个「参考实现哈希」，节点用出块为自己运行的软件计票，票够就切换。这份 2024 年 12 月 22 日创建的 Standards Track Core 提案目前仍是 Draft，没有进入任何已排期升级。
参考实现哈希是什么
提案要求共识客户端在区块头里、紧跟 extraData 之后新增一个 referenceImplementationHash 字段。它的值不是随手写的版本号，而是「某份已发布、功能完备的参考实现的打包源码的 SHA-256 哈希」：提案者必须先给出一份公开的、行为描述完整的参考实现，客户端作者声明「我的软件忠实实现这份参考」，然后把自己的哈希写进每个块。参与者换软件的过程也被规范成两步：先读参考实现、决定是否支持该升级；再核对自己将要运行的软件是否与参考行为一致。新软件刚上线时不能立刻切换行为——必须等携带新哈希的区块积累到足够密度，新行为才生效。
计票窗口与阈值：提案里最诚实的部分
机制框架给了两个参数位：VOTING_WINDOW_BEGIN 与 VOTING_WINDOW_END，圈定哪些区块的哈希计入本轮；再加一个通过阈值。诚实地说，窗口长度与阈值在草案文本里仍是待定的——这恰是整份提案的缩影：它先把「用什么信号计票」定清楚，把「多少票算过」留给后续讨论。能确定的骨架是：每个升级提案（相当于过去的硬分叉 EIP）必须自带一个升级窗口与阈值；窗口内新哈希区块占比达标，所有实现在窗口结束后的首个区块同步切换；不达标则本轮作废，回到现状。
与 BIP 9 一脉，问题也不同
熟悉比特币的人一眼能看出这是版本位（versionbits/BIP 9）思路的以太坊移植：用区块字段携带立场、用窗口与阈值收敛共识。差别在载荷：BIP 9 挪的是版本字段里的几个 bit，一个升级一个 bit，粗粒度、可组合；7848 携带的是完整哈希，一次只能指向一个参考实现，换来的是「投的就是这份源码」的精确性——哈希指向哪份实现，链上可查、链下可比。由此带来的新问题也现成：哈希之争可能演变成参考实现之争（谁的源码算「那份」参考），多客户端生态里不同忠实实现共用一个哈希的表述成本，以及没有升级的绝大多数区块里这个字段填什么的默认值设计。这些在草案里都还没有完整答案，也是它停在 Draft 的原因之一。
现行流程仍然有效
需要把时态钉死：截至本文写作，以太坊升级仍按「名单 + 客户端版本 + 预定时间」推进，区块头里没有计票字段，7848 的所有机制都未生效。它对普通用户的现实含义是「未来可能多一种读升级状态的方式」：升级不再只有「到点没到点」，还能链上数出百分比。在生效之前，任何声称「以太坊正在链上投票升级」的说法都是误读。
快速问答
问：这是否意味着矿工的投票回来了？ 答：不是。计票主体是出块的验证者客户端，票的内容是「我在运行哪份实现」，与权益证明下的提议权分布一致。
问：哈希怎么防止有人伪造一份「同名实现」？ 答：机制本身不防，靠社区对「哪份参考实现作数」的共识；这也是提案把哈希绑定到「已发布、功能完备的参考实现」并要求参与者主动审阅的原因。
问：会不会出现两派各投各的哈希导致分裂？ 答：草案未给强制合并机制；阈值不达标时本轮升级作废是默认安全垫，分裂风险的讨论仍在提案里未决。
风险提示
本文为治理机制类草案解读，不构成投资建议。提案内容与参数可能随社区讨论修改或作废，升级安排以官方公告与提案仓库为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。