以太坊的重大变化几乎都打包在网络升级里：定一个区块高度，所有客户端在那一刻切换规则。但有一类改变从来没赶上任何一次升级，也永远不需要赶——因为它们在逻辑上「从创世起就是对的」。EIP-7675 是一份试图把这类规则登记在册的元提案，作者 Tim Beiko，2024 年 4 月提交，官方状态是已撤回（Withdrawn）。撤回原因写得很直白：这是一份永远不会走到 Final 的清单。听起来尴尬，但它回答的问题很真实：共识规则到底可以不通过「切换时刻」而生效吗？
追溯激活的判例逻辑
硬分叉存在的理由，是让全体节点在同一时刻同步改变判断标准——规则一旦改变，新旧节点对同一个区块的裁决会不一致，不升级就分裂成两条链。所以反过来，如果一条新约束满足两个条件，切换时刻就变得多余：其一，它从未在链上历史上被打破，也就是没有任何已确认区块因它而变成无效；其二，它大概率永远不会被打破。这时「支持新规则的节点」和「不支持的节点」对全部历史、对未来区块的判断都逐字节一致，规则像物理定律一样安静地生效。EIP-7675 给这类操作起了正式名字：追溯激活。生效日期统一写作创世区块，等于承认「这条规则一直如此，只是以前没人写下来」。
名单上的五条规则
清单收了五条核心提案。EIP-2681 限制账户 nonce 不得超过二的六十四次方减一——这个上限从未被任何账户摸到。EIP-3607 拒绝从已部署代码的地址发出的交易，堵上「合约伪装成外部账户签交易」的理论漏洞。EIP-4803 把交易 gas 上限钉在二的六十三次方减一，防止字节长度编码溢出。EIP-7523 处理空账户在合并后的命运。EIP-7610 规定创建交易撞上有存储的非空地址时直接回滚，终止「幽灵账户」隐患。五条规则的共同气质非常一致：它们都不新增能力，只给协议里本来就无人主张的自由度补一道栅栏，而这道栅栏立在全是安全区的空地上。
撤回背后：清单的尴尬
这份元提案为什么注定到不了 Final？清单式文档有个结构性麻烦：只要协议演化一天，就可能诞生新的「追溯规则」，清单就永远停在某天的快照上。把它挂成 Final，等于宣布一个仍在生长的东西定稿；挂成草案，又永远等不到那场可以让它定稿的升级。作者最终选择撤回，同时留下了概念本身——追溯激活作为治理手段继续存在，只是不再需要一份中央清单。顺带一提，撤回不否定名单上各条提案的效力，它们的生效状态在各条目自己的文档里由「自创世激活」这类表述承载，清单只是目录，目录撕掉不影响书。
快速问答
问：追溯激活会不会让旧节点悄悄掉队？ 答：不会。正因为约束从未被打破，旧节点对任何真实出现过的区块都不会产生分歧；只有在未来有人试图打破约束的那一刻，才需要升级来表态。
问：比特币有没有同款操作？ 答：思路上类似的先例存在，比如对某些从未被使用的脚本形态加限制，但两边社区的登记仪式不同，不宜逐条对应。
一份清单的三种命运
把追溯激活放进治理光谱里看会更清楚。多数共识变化走的是「日历式」：公告、定高度、各客户端按期发版，切换时刻就是规则生日，代价是所有历史数据都要在新旧两套规则下重验一遍才算安全。少数变化走「事件式」：某次执行事故后临时热修，用检查点把分叉强行熨平，代价是程序正义的观感。追溯激活是第三种：它宣布的不是改变，而是澄清——被约束的行为在全部历史中出现零次，所以任何时点上线这条约束，全网状态树纹丝不动，连重新同步都不必要。三种方式对应的信任成本完全不同：日历式买的是确定性，事件式买的是速度，追溯式买的是整洁。EIP-7675 想给第三种建立登记制度，登记制度本身夭折了，但第三种方式仍在被使用，这种「机制活着、名录死了」的错位，恰恰是研究协议治理文档时最需要肉眼分辨的地方。
风险提示：本文讨论协议治理机制，不构成投资建议；引用提案状态以 EIP 官方页面当期徽章为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。