标准模板的两个痛点
比特币软分叉的常规部署工具是 BIP9 版本位：一段起止时间内，矿工用区块版本号的某个比特表达赞成，回看两千零一十六个区块的窗口内赞成占比达到阈值即锁定，锁定后的窗口结束后激活。这个从 segwit 时代服役的机制有两条被反复抱怨的性质。一是阈值默认 95%：留给不升级节点的时间很短，历史上多次部署都贴着窗口尾部才凑够数，社区称之为“最后一分钟的悬崖”。二是激活时机由算力投票的随机性决定——阈值何时被跨过没人能预告，交易所、钱包、服务商面对的是一个日期分布而不是日期。
Taproot 没有推翻模板，而是给它打了两个补丁。BIP341 的部署段落写得清楚：沿用版本位、名字 taproot、第 2 位，但改用降低的阈值，并新增一个 min_activation_height 参数，替换 DEFINED、STARTED、LOCKED_IN 三个状态的部分迁移逻辑。
逐项读参数
主网参数一共四项。起点时间是 2021 年 4 月 24 日午夜（Unix 时间戳 1619222400），到点开始计数；超时是 2021 年 8 月 11 日午夜，到期未达阈值则整轮失败；阈值取 1815 块，即窗口内的 90%，而不是标准的 1916 块（95%）；min_activation_height 取 709632。
90% 这个数值的算术很直白：九成的窗口内区块表明赞成，网络共识的密度已经足够，剩下的一成更可能是没来得及更新的老实矿工，继续用 95% 逼他们挤在八月截止线前表态，收益换不来部署压力。测试网侧更宽松：同一组起止时间，阈值 1512 块（75%），高度下限取零，测试链越早激活越好。
min_activation_height 解决的则是“日期”问题：锁定状态一旦达成，区块高度未到下限就不进入激活，过了下限才翻转。它把“算力何时凑够”与“功能何时上线”解耦，运营方拿到的是一个确定的生效日期。实际结果与这套参数严丝合缝：主网部署在区块 709632 激活——2021 年 11 月 14 日（协调世界时凌晨 5 点 15 分，核验于公开区块数据）；测试网在 2011968 块激活；签名网则设计为始终激活。
这套补丁没动什么
值得注意的是一份克制清单：状态机骨架没动，两千零一十六块的回看窗口没动，超时逻辑没动——而且超时判断依旧用中位时间戳而非区块高度，这一点沿袭了 BIP9 的原始设计。没有引入“超时强制锁定”（lockinontimeout）：如果八月截止时没凑够九成，这轮部署就干净地失败重来，而不是靠例外条款强推。后来的部署讨论里，这两个参数成了默认选项，说明一次成功的部署参数同样在塑造模板本身。
一条时间线
把参数放到日历上再看一遍：4 月 24 日起开始计数，投票窗口内跨过九成线后进入锁定，然后静静等待高度到达 709632——激活日期提前被确定下来的好处在钱包与交易所侧体现得最直接：升级公告、风险预案、回滚方案都有了一个可以印在标题里的日子，而不是一段概率区间。测试网用 75% 阈值、零高度下限，同一个参数体系在测试环境里把节奏调到最快，为的就是让主网这套保守数值先经过演练。
快速问答
问：降低阈值会不会让少数算力强推升级？ 答：九成窗口内区块仍然意味着绝大多数出块算力赞成。争议主要发生在“95% 太晚”与“更低太急”之间，90% 是一次明确取向，后续软分叉会怎么调仍有讨论。
问：min_activation_height 和绝对时间锁是一类东西吗？ 答：不是。前者是部署参数，决定协议规则何时翻转；后者写进单笔交易脚本。两者共享“把未来钉进现在”的思路，作用层面完全不同。
风险提示
本文描述协议部署机制与公开历史参数，不构成投资建议。后续软分叉的具体阈值以各自的 BIP 文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。