BIP8、BIP9 与现代软分叉激活方法

作者：Aaron Van Wirdum

来源： https://bitcoinmagazine.com/technical/bip-8-bip-9-or-modern-soft-fork-activation-how-bitcoin-could-upgrade-next

原文网页记录的出版时间是 2020 年 7 月 20 日。但写作时间应当早得多，因其探讨的是 Taproot 升级可能采用的激活方法。

实际上，Taproot 升级采用 “Speedy Trial” 激活方法，从 2020 年 5 月开始收集区块信号，在 6 月 12 日就已达成信号比例目标。

Taproot 是一个可以提升比特币的隐私性和灵活的协议升级提议，目前已到了开发的最后阶段。Bitcoin Core 的贡献者们都认为这项升级有益于比特币，而且就目前来看，也受到广大比特币生态系统的广泛欢迎。因此，Tarpoot 可能会进入 Bitcoin Core 的发行版本，而其它比特币客户端实现可能也会跟进。

但还有一个问题：比特币网络自身该如何升级？Taproot 是一次共识协议变更，这意味着比特币的节点们必须有一部分从旧规则切换到新规则，但又不能让网络分裂成强制执行不同规则的部分。出于许多原因，这在过去已被证明是一件难事。

激活协议升级的更优策略已在酝酿中。

以往的软分叉和 BIP9

好消息是 Taproot 将是一次 “软分叉”。这种类型升级会添加，或者说收紧共识规则 —— 与之相对的 “硬分叉” 则会移除，或者说放松共识规则。添加或收紧规则的好处是，一个升级后的节点认为有效的任何东西，没升级的节点也会认为是有效的。（如果旧节点同时接受类型 A 和类型 B 的交易，但新规则只允许类型 A 的交易，那么旧节点在强制执行新规则的网络中也能保持兼容性。）

比特币的最早的一些软分叉是通过 “信号日（flag day）” 激活的。开发者们（尤其是 中本聪）在新的比特币客户端软件发行版的代码中嵌入一个未来的日期，从而指定升级后（使用新版软件）的节点开始强制执行新规则的时间点。矿工和用户被鼓励在该日期前使用更新的软件，已避免网络分叉。（顺便说一句，在那时候，矿工和用户通常是同一群人，与今天不同。）

因为没升级的节点也跟新规则兼容，软分叉的一个显著好处是，只要绝大部分的矿工强制执行新规则，整个比特币网络就能对应用新规则的区块链达成共识。这也意味着，在强制执行新规则时，不必迫使所有节点立即升级，用户可以保持一些灵活性。（虽然用户也被鼓励升级，因为他们是通过拒绝违反新规则的交易和区块来强制执行新规则的最终力量。）

自 2012 年以来，软分叉越来越多地利用哈希算力作为切换到新规则的一种协调机制。通过在自己挖出的区块中嵌入一个比特，矿工们可以向其他矿工以及网络中的其他人表明自己是否已经升级了软件，也即是否准备好了强制执行新规则。一旦有足够多的哈希算力表示支持，所有升级后的节点就会打开开关，强制执行新规则。

经过几次升级，这一策略形成了第 9 号比特币升级提议（ BIP 9）。比如说，BIP 9 也被用来激活比特币的最后一次软分叉升级 “隔离见证（ Segregated Witness）”。矿工有一年的窗口可以表态，需要在至少一个难度调整周期内有 95 % 的区块包含了就绪信号比特。如果在一年后，没有任何一个难度调整周期达成了这个目标，激活窗口就过期了，升级就会失败。（当然，可以再尝试一次。）

不过，在隔离见证升级中，BIP 9 的历程并不顺利。与之前的一些升级一样，一些矿工并没有积极升级，可能是因为不关心：通常没有非常大的激励让他们尽早升级。但更大的一个问题是，一些矿工开始以为，信号表决过程是一种对升级的投票 —— 他们不是在表示自己是否准备好了，而是在表示自己会（或者不会）支持它。更糟糕的是，一些矿工最终使用这种 “投票” 来阻挠升级，以期获得对比特币开发过程的政治影响力；并且/或者，他们可以 “投票” 反对升级，以便留下升级将要修复的比特币协议怪癖，并暗中从中获得持续的好处。

在长时间的紧张戏剧之后，隔离见证最终还是激活了，不过，是在另类的比特币客户端包含了一种新的激活方案之后。BIP 148 ，被包含在一些用户运行的 “BIP 148 客户端” 中，它被编程为从一个信号日开始，仅接受表态支持隔离见证升级的区块。与此同时，在 BIP148 信号日之前，矿工们运行了包含 BIP 91 的 “btc1 客户端”，实质上将激活的哈希算力要求从 95% 降低到 75% 。面对潜在的网络分裂风险和收入损失，阻挠的矿工让步了。但对大部分 Bitcoin Core 开发者来说，BIP 9 已经显露出并非最优的解决方案，他们也开始思考替代方案。

BIP 8

BIP 8 是 BIP9 的更早的替代方案，由 BIP 148 的作者 Shaolinfry 以及 Bitcoin Kntos、Bitcoin Core 的贡献者 Luke-jr 提出。它最初类似于 BIP 9 ，但有一处关键的区别：如果在一年的窗口期内没有足够多的哈希算力支持升级，它不会让升级失败，而是会做相反的事情：开始强制实施新规则。类似于信号日，所有升级的节点都会从此开始强制执行新规则。依然不升级的矿工将会承担所挖出的区块被升级后的矿工和用户拒绝的风险。

BIP 8 背后的主要观念是 —— 当然，假设用户们都升级了 —— 矿工不能阻碍软分叉，也不能凭此来获得好处。他们可以加速激活、帮助协调协议升级，但即使他们不激活，升级最终还是会发生。

后来的 BIP 8 加入了一些显著的变更。其一，BIP 8 允许节点配置两种不同的策略，在信号窗口即将过期的时候：强制激活，就像前面两段解释的那样；不强制激活，就像 BIP 9 。此外，除了激活升级自身，节点可以强制对升级 表示就绪（如果有所配置）。不表示已经升级的区块将会被拒绝，从而依然可以保证升级，至少对升级后的节点而言。这两项变更的组合带了了有趣的属性：如果绝大部分比特币的挖矿算力被迫表示升级就绪，那么即使 BIP8 节点没有配置为强制表态，最终也能升级。

反对 BIP 8 （尤其是其强制信号，或者说自动激活）的一种观点是，这可能有很大风险，尤其是在窗口较短的情况下。如果挖矿算力的大多数以及至少一些用户没有升级，那么这种激活程序会让网络分裂成升级后的网络和升级前的网络。假设绝大部分用户都支持升级，这种分裂最终可能会解决，以升级后的网络的胜利告终。但与此同时，没升级的用户就会承担丢失资金的风险，没升级的矿工也会浪费挖矿算力、使比特币的安全性受到损害。

也许对冲这种风险的最好手段就是足够长的时间。不幸的是，并不是每个人都对 “足够长” 有一致的看法；一些人会认为，强制信号可以在一年内开始，另一些人则认为，应该有几年时间的准备期。

BIP 8 的另一个复杂之处是设置强制信号的默认值。如果强制信号是默认关闭的，用户可能会发现彼此无法协调，也就增加了网络分裂的风险。相反，如果强制信号被某一个 Bitcoin Core 发行版作为默认值，那么一直以来的 Bitcoin Core 的广泛采用就保证升级一定会发生。一些人认为，这会给予 Bitcoin Core 开发者太大的影响力。BIP 8 的联合作者 Luke-jr 倾向于仅在特殊客户端种部署 BIP 8 ，就像 BIP 148 客户端一样。

其他人认为，Bitcoin Core 开发者总是根据自己的最佳判断来发行软件，同时满足用户需求和避免有争议的升级；设定 BIP 8 默认值与此并无不同。如果任何人不同意 Bitcoin Core 开发者作出的这个选择，可以直接选择不升级到新版本，甚至复刻 Bitcoin Core 的代码、启动一个相互竞争的客户端。

现代软分叉激活方法

虽然 Bitcoin Core 的开发者们确实会考虑用户的需求，并尝试避免有争议的升级，但也不是每个人都相信，每次都会皆大欢喜。也许，对提议中的升级的顾虑，只有当软件发行新版本时才会浮现。也许新版本中会出现全新的问题。又或者，Bitcoin Core 的开发者们也可能忽略了一些东西。

这也是 Bitcoin Core 的贡献者 Matt Corallo 提出一种叫做 “ 现代软分叉激活方法” 的策略的原因之一（ 中文译本）。现代软分叉激活方法包含 3 个步骤，本质上，它们实现了 BIP 9（或者说不设强制信号的 BIP 8）与带有信号日的 BIP 8 的组合（虽然强制信号依然是一个选项）。

作为第一步，BIP 9 将允许矿工通过哈希算力来激活软分叉。如果矿工们没有在（比如说）一年内激活，那么第一个激活窗口过期。然后，作为第二步，开发者们花一些时间来分析激活为何失败，如果找出了真实的担忧，那么要重新考虑提议。如果他们认为提议本身没有问题，那么，进入第三步，使用带有信号日的 BIP 8 ：矿工们获得了另一次机会来通过哈希算力激活软分叉，但如果他们再次失败，软分叉会在第二个信号窗口结束时直接激活。（在第二个信号窗口内，哈希算力的激活门槛可以随时间逐渐降低，如 Bitcoin Core 贡献者 AJ Towns 所 建议 的。）

Corallo 认为，如果提议本身没有问题，就显式地重新部署 BIP 8 ，这样做可以提供 BIP 9 的全部好处，而不会有缺点。代码在第一个信号窗口就发布，让每个人考虑，矿工们可以协调出一个平滑的升级，如果他们愿意的话；而且，因为没有强制激活，开发者们也有时间重新思考提议，如果初次尝试失败的话。与此同时，矿工们无故阻挠的动机也更小，因为，每个人都知道，如果提议本身没问题，那么它最终就会被激活。

反对现代软分叉激活方法的主要论点是，没有矿工的协调，整个过程会花费更长时间，而且一些人认为，第一步（BIP 9 步骤）会浪费时间。Corallo 的初版提议包含了为期一年的 BIP 9 信号窗口，然后是六个月的重新考虑期，最后是为期两年、带有自动激活机制的 BIP 8 步骤：总计是三年半的时间。虽然这里面的时间长度不是不可变更的，但过度缩短某一些步骤的时间长度，将让重新考虑 以及/或者 升级的窗口变短（增加网络分裂的风险）。

一些人也认为，因为强制激活到来之前会有很长一段时间，矿工最终还是能够尝试并获得一些政治影响力：他们毕竟能推迟升级，长达数年。

BIP 8 + BIP 91

另一种最近在比特币的技术频道中回荡的建议，也许可以恰当地描述为 BIP 8 和现代软分叉激活方法的综合，至少在精神上是这样。这个未命名的提议将部署一个很长的 BIP 8 信号窗口，可能会跟整个现代软分叉激活法的周期一样长（三年半），窗口期过好，就启动强制信号。不过，如果在（比方）一年之后，升级还是没有激活，开发者将花时间来重新考虑提议，就像在现代软分叉激活法中一样。

如果开发者没有发现问题，或者说，可以断定它没有激活知识因为矿工的漠不关心或其它无效理由，他们可以选择以 BIP 91 策略部署一次新的软分叉（隔离见证的激活就用到了 BIP 91）。这将实质性降低激活的哈希算力门槛，可能会加速整个流程。

相反，如果开发者们在提议中发现了问题，他们可以部署一次新的软分叉、修复这个问题，甚至取消原本的软分叉提议。假设在强制信号之前有跟现代软分叉激活方法同样长的周期（三年半），时间应该是足够长了。

反对这种想法的主要一件事，如果真的部署另一次软分叉来取消一次软分叉，可能并不是那么优雅。更具体地说，它要求矿工和用户在截止日期之间升级到新版本，否则就有分裂网络的风险。

Spork

最后 —— 我认为这个想法有些另类 —— Bitcoin Core 贡献者 Jeremy Rubin 提出了一个他发明的概念，称作 “概率性的比特币软分叉（ Sporks）”，可能比一般的哈希算力强制执行软分叉更加激励兼容。

Rubin 主张，BIP 9 的核心问题是，矿工可以拖延升级，而自己完全不需要付出任何代价。直接拒绝表态升级就绪是没有代价的，可能反而会获得政治影响力。

在 Spork 中，就绪信号不再是矿工包含在自己区块中的一个比特，而是从区块头哈希值中派生出来的：是他们投入时间和资源生产出来的随机工作量证明。升级后的节点会对一个小子集的有效区块头哈希值达成一致 —— 从统计学上来说，假设每六个月时间只会找出一个 —— 然后就启动升级。

因为哈希函数的随机性质，矿工无法控制自己生产的区块头哈希值是常规的，还是激活升级的；从统计学上看，TA 只是会偶尔得出后面一种。所以，如果他投入了资源、恰好生产了一个激活升级的区块头哈希值，他有两个选择。要么，发布到比特币网络中、获得区块奖励、激活软分叉。要么，扣住这个区块、拖延软分叉的激活，在我们这个假设的案例中，是拖延六个月时间 —— 但这样做的时候，也就放弃了区块奖励。拖延升级将面临巨大的代价。

当前，Sporks 的主要问题是，它是一种相对比较新的想法，还没有部署过 —— 还没有经历风霜。虽然一些人认为这个想法挺有趣，但它还没有成为 Taproot 激活方法的主要竞争者。

作者注：关于软分叉激活方法（具体来说就是 Taproot 的激活）的争论此起彼伏；本文不是对激活方法的全面描述，尤其因为，在使用不同参数和其它调整时，同一方案也会形成许多变种，各有优点和缺点。

更新

另一种想法，在本文写成（绝大部分）以来获得了一些关注，就是先开启相对较长的 BIP 8 信号窗口（假设是两年），在信号窗口结束时不设强制信号机制。这让矿工可以相对自然地激活软分叉，就像他们在过去完成过许多次的那样。不过，如果在一段时间（比如六个月）之后，软分叉还没激活，而且这样的拖延似乎没有很好的立候，那么可以发行一个新的客户端，配置为在现有的信号窗口结束之时（或更早之前）启动强制信号机制。假设绝大部分矿工都在这一强制信号期之前或期间升级，那么两组 BIP 8 节点（设有和未设强制信号机制的）都将激活软分叉、强制实施新规则。

（完）

• 本文转载自： btcstudy.org/2025/08/19/... , 如有侵权请联系管理员删除。