协议演进 / BIP/比特币改进提案 / BIP-99

BIP-99 共识规则变更（软/硬分叉）的动机与部署

给共识分叉分类：意外分叉、单方面软分叉、分裂硬分叉与无争议升级各是什么，并为无争议软/硬分叉分别提出部署办法。本 BIP 目前处于已关闭状态。

一、档案卡

二、放在哪一族

共识升级的方法论族，也是紧接着的一组区块大小硬分叉提案——BIP-100、BIP-101、BIP-102、BIP-103、BIP-104——共同的背景读物。2015 年争论扩容时，各方对“什么叫软分叉、什么叫硬分叉、矿工投票到底算什么”并无统一语言，BIP-99 先把词定义清楚、把分叉分型，再谈每型怎么部署。读 100–104 号提案之前先读它，才分得清哪些争论是参数之争、哪些是部署路线之争。它与 BIP-9（version bits 投票机制，原文多处引用为版本位提案）互补：BIP-9 给工具，BIP-99 给工具的使用伦理。它无 Layer 字段，属信息类文件，不定任何协议规则。

三、它要解决什么

原文 Motivation 写得很直白：人们对 P2P 共识系统的安全假设理解并不一致，而最合适的升级机制取决于要部署的变更属于哪一类；没有统一视角，讨论规则变更时容易鸡同鸭讲、白白拖延部署。BIP-99 因此先做两件事：给出软件分叉、共识分叉、软分叉、硬分叉、libconsensus 等术语的定义；再建一套分类学（taxonomy），让每类分叉对应到“需不需要部署计划、需要谁同意”。

其中几个定义是全篇的地基：软分叉是“以前无效的仍然无效、以前有效的有一部分变为无效”，算力多数即可强制，具向后兼容的部署优势；硬分叉是“把以前无效的块变为有效”，要求所有用户升级；共识最终由网络实际运行的软件决定——“实现即规范”（the implementation is the specification），把共识校验从 Bitcoin Core 中剥离成 libbitcoinconsensus 库，正是为了让替代实现能安全地共享同一套校验代码。

四、规则本身

本节是分类与对应的部署主张，而非协议参数。

4.1 无需部署计划的三类

• 意外共识分叉：替代实现重写校验规则时的 bug 所致，如 2013 年 3 月 11/12 日高度 225430 处 Bitcoin 0.8 与旧版本因 Berkeley DB 换 LevelDB 而起的链分叉（事后分析见 BIP-50）。药方是 libbitcoinconsensus 这类共享校验库，而非部署计划。
• 单方面软分叉：算力多数若自认有利可图，可能不顾用户超多数意愿强行软分叉，这实质是对网络的攻击；防法在激励设计，不在部署流程。
• 分裂硬分叉（schism hardforks）：用户有意识地各验一套规则、形成两条链与两种货币，市值结果完全不可预测。原文举了三种设想场景——ASIC 被单家垄断时换 PoW 函数的“ASIC 重置”、区块创建过度集中时恢复区块大小上限、以及开发阵营藏后门偷币时弃用其代码——共同点是：对抗对象正是矿工时，“矿工投票”毫无意义。真走到这一步，部署办法只是选一个未来高度激活，并保持有多个独立实现随时能发起这种分叉，才是健康的去中心化。

4.2 无争议软分叉

软分叉是首选的升级机制：算力多数采用后，未升级用户跟随的仍是同一条链，新规则在他们眼里与矿工的策略规则无异，部署风险低。历史先例是 BIP-16（P2SH），早期仅靠未来时间点触发；此后为确保矿工先升级再执行，引入投票机制（用于 BIP-30、BIP-66）：原文写作时的通行参数是 95% 为共识强制阈值，75% 是矿工先行按策略执行的阈值。原文还期待 BIP-9 的版本位改进能让多个部署并行、单个被否不锁死后续部署。

4.3 无争议硬分叉

硬分叉要求全体先升级再激活，否则未升级者有跟错链、被欺诈的风险。最简办法是选一个足够远的未来高度，给所有人留足升级时间；若追求普遍采用，在此之上再叠加矿工投票是合理的，但阈值只设一档：100% 太严，一家小矿工即可挟持升级，原文建议 95%–99% 之间。紧急硬分叉则可能来不及咨询矿工、只能直接定高度；也可预先埋伏笔，例如先发一个中间版本软件，把“接受两倍大区块”写成未来的软分叉式规则，真需要时再走常规流程激活。原文 Code 一节还附了一个示范性的无争议硬分叉代码提案：修复 timewarp 攻击——选它正因为改动小、在山寨币中已被广泛部署测试，意在打破“比特币不可能硬分叉”的成见，并建议把激活放在很远的未来（如约四年区块量之后）。

五、谁必须动

普通持币人：本 BIP 本身不要求任何动作。它给的是一把尺子：日后遇到升级争论时，先判断它属于哪一型，再判断投票、高度与阈值的安排是否与该型相称。

全节点与矿工：无直接规则变化。但原文的立场应记牢：矿工投票只在“无争议升级”里是协调工具，在分裂硬分叉与单方面软分叉的语境里，投票既非授权、也非否决权。

开发者与实现维护者：替代实现的风险点在共识校验的重写，原生解法是共享 libbitcoinconsensus；提出共识变更时，应按本 BIP 的分类说明它是哪一型分叉、部署机制为何与之匹配。

共识层：本 BIP 是信息类文件，不改任何共识规则；它影响的是此后提案“怎么写清楚”的方式。

六、现在算不算数，以及一个常见误读

状态为 Closed（已关闭）：提案未获采用、已经关闭。它提出的分类语言——尤其是软/硬分叉定义与“无争议”这一限定——在后来的讨论中被广泛沿用，但文件本身不具规范效力；其附带的 timewarp 修复硬分叉示范也未在主网部署。后文 BIP-100 至 BIP-104 的扩容之争，恰可用它的框架复盘：它们都是硬分叉，且远非无争议。

常见误读：“硬分叉只要矿工投票过了 95% 就名正言顺。”不对。按 BIP-99，95% 上下的矿工投票只是无争议硬分叉在临近全员升级时的一道协调保险；若变更本身有争议，投票高低都不能替代全体用户升级这一前提，更不能把分裂硬分叉洗成常规升级。

七、延伸

• 阅读版：https://bips.dev/99
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki
• 相关：BIP-9 version bits、BIP-16 P2SH、BIP-50 2013 年 3 月分叉复盘、BIP-100 至 BIP-104 区块大小硬分叉组
• 仓库总目录：https://github.com/bitcoin/bips

本页内容整理自 bitcoin/bips 仓库与 bips.dev，事实已与仓库核对；解读仅供学习参考。