从“数版本”到“看高度”
比特币早期的软分叉激活走的是区块版本号路线：新规则要求矿工挖出版本号更高的块，回溯前一千个块里高版本块占比达到七成五，新版本块必须正确执行新规则；达到九五，低于该版本的块整体作废。BIP-34 要求在 Coinbase 里写入区块高度、BIP-66 强制签名严格 DER、BIP-65 启用绝对时间锁操作码，都是这么上线的。
问题出在验证成本上。要判断某个块该不该执行新规则，节点得回头数前一千个块的版本分布——一段纯粹服务于历史的逻辑。等到 2016 年，这三条规则早已在链上生效多年，这段数版本的代码只剩技术债的价值。于是 Suhas Daftuar 写了 BIP-90，标题直接叫 Buried Deployments，埋入式部署：把那三次部署的触发条件改写成三个写死的激活高度。主网上的数字分别是 BIP-34 的二十二万七千九百三十一、BIP-66 的三十六万三千七百二十五、BIP-65 的三十八万八千三百八十一——正是当年各自主网上九十五占比被触达的那个块高。
替换后的判定规则
改写后的逻辑朴素到几乎不像共识规则：验证一个块时，块版本低于二且高度已达 BIP-34 激活高度、版本低于三且高度达 BIP-66 高度、版本低于四且高度达 BIP-65 高度，三种情况之一直接判废。至于 Coinbase 写高度、严格 DER、时间锁操作码这些实体规则本身，一行都不用改——改变的只是『从哪个块开始算数』的判定方式，从此跟链上历史彻底解耦，不再需要一千块的回看窗口。
提案作者也没有回避理论风险。这个替换在极端情形下并非完全向后兼容：假如存在某条替代链，其九十五占比触发得比主网更早，老软件会在新旧两个高度之间就执行新规则，新软件则要等到写死的主网高度；又或者一条从激活块前一格分叉出来的低版本链，老软件认定它违规，新软件反而放行。但要让这种分歧真的造成共识分裂，需要一次深度大到足以把激活块本身从链上掀掉的重组——那意味着比特币的安全假设已经出了根本性问题，比这点兼容性边角严重得多。
埋入式与版本位的分工
BIP-90 是信息类提案，它不做任何新部署，只是清理旧机制，同时给后来者立了个路标：版本投票（在 BIP-9 版本位出现之前的那种）正式退场。此后比特币的软分叉激活进入两条轨道。一条是 BIP-9 版本位：给升级留名字、起始时间、超时和锁定窗口，矿工在版本字段的一个比特上表态，适合还需要观察信号、需要退出机制的复杂升级。另一条就是埋入式：既然激活高度早已不可动摇，或者部署目标干脆是随预定块高硬生效的改动，就直接写常数，省掉整套统计机器。后来的比特币历史上，这两种方式交替出现，判断某次升级属于哪种，看它有没有版本位名字和信号期就够了。
快速问答
问：埋入式部署会改变共识规则本身吗？ 答：不会。BIP-90 只改『何时开始执行』的判定来源，从统计前一千个块的版本，换成比较当前高度与常数。规则内容原封不动。
问：为什么三个高度不干脆全写成同一个？ 答：各次激活当年触达九十五的时刻不同，写死各自的历史触发高度才能保证对所有既有节点视角的规则边界不变。
一条直觉线
把协议想象成一部不断再版的法律汇编：旧条款一旦生效多年，与其让每个法官每次判案都翻一千页历史记录证明『这条从某年起适用』，不如再版时直接印上生效日期。BIP-90 就是那次再版——法律效力没变，变的是查法条的成本。
风险提示：本文内容为协议机制科普，不构成投资建议，也不构成对任何客户端实现的评价。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。