作者：Blue Matt
来源： https://bluematt.bitcoin.ninja/2020/01/10/modern-soft-fork-activation/
原文出版于 2020 年 1 月。时间上是 Taproot 升级的激活方法确定前夕。
本文最初发布在 bitcoin-dev 邮件组 中，那是一个瞄准技术读者的讨论空间。但重新发布在这里，因为广泛的人群都对这个话题感兴趣。软分叉激活方法的要求和目标格外吸引人。
最近，许多软分叉的提议在实现和吸引采用上取得了良好的进展。然而，出于许多理由，激活方法并没有得到很多讨论。我有意在这里重启讨论。
在开始之前，似乎值得重新回顾软分叉提议的目标以及它们的激活方法的目标。我也许会遗漏一些，但以下是基本的要求：
1）避免在面临重大、合理且直接的反对意见时激活。如果有一种得到广泛采用的、合理的比特币用法，在当前有效，而且没有理由认为即使不发生变更、它在未来也不会被继续使用，并且一项变更会让这种用法不再可用或者将显著增加使用难度，那么这项变更就不应发生。我很希望这一点不会引发反对（最后一点提出了一种重要警告，是每个人都会立即指出来的）。
2）避免在不可能实现较高比例的节点采用的时间框架内激活。就像所有关于“节点” 的论证，我要指出，在这里，“节点” 一词意味着 “经济适用” 的节点，而不是 Google Cloud 和 AWS 上的成千上万的侦测节点（spy node）。如果没有节点来强制执行，规则变更就没有意义，无论规则变更采取软分叉形式、硬分叉形式还是不软不硬分叉。所以，在一个不能实现大规模节点采用的时间框架内激活，是没有任何价值的，而且可能会导致意料之外的副作用。
3）不要（无必要地）让没有升级的矿工无法提供算力。因为比特币的部分安全性来自矿工，如果一项规则变更的副作用是减少网络的哈希率，那么这是无必要地削弱网络的一项关键安全参数。这也是为什么，在离我们最近的软分叉中，都要求 95% 的算力表示自己已经升级、有能力强制执行新规则。此外，这也是为什么近期的软分叉提议都不包含让标准的 Bitcoin Core 实例的挖矿功能失效的变更（也即，要求变更依赖于 Bitcoin Core 的标准化行为）。
4）只要有可能，就使用算力强制执行来消除升级过程的风险。作为上述各点的必然结果，我们使用软分叉的首要理由之一就是，基于算力的规则强制执行，是防止节点升级期间出现网络分裂的优雅方式。虽然在显著比例的 “经济节点” 开始强制执行新规则之前，在新规则所保护的系统中投入大量价值是不理智，算力还是让我们能够巧妙地弥合激活时间和大量采用之间的时间空档。通过让占据绝对多数的矿工强制执行新的规则，违反新规则的尝试不会导致限制的网络分裂，也不会干扰现有系统的用户。如果我们不准备利用这一点，我们就应该转而执行硬分叉，而时间步骤也必然会放慢。
5）遵循社区的意愿，不理会个人化的、不理性的反对意见，但不应否决合理的反对意见。近期也出现过一种形式的对软分叉的 “反对意见”：“这提议不好，因为它没有修复另一个我认为应该尽快修复的问题”。我不认为有谁会觉得这是一种合理的反对意见，而我们应该站在一起，作为社区（而不是作为开发者或某一个专门团体）忽略这样的意见、勇往直前。“捆绑” 无关的特性不会带来明智的工程决策，只会带来政治上的来回拖延和妥协。
我认为，BIP 9（加上一种精心制作的软分叉提议）可以非常有效地检查上述清单中的第 2 ~ 4 条；在出现大量的社区参与和谨慎考究时，就能有效地满足第 1 条。至于第 5 条，我确信每一个人都注意到了，这就是事情开始变得艰难的地方。
BIP8 被提议作为一种替代方案，很大程度上就是对第 5 条作出的反应。然而，它的一种幼稚的部署方法，很明显，会在第 1 条、第 3 条和第 4 条上完全失败；而且，在我看来，也无法满足第 5 条的要求，因为它既给了人们一种这样的印象、建立了这样一种先例，甚至在实践中也增加了开发者为系统决定共识规则的能力。一个基于 BIP 8 的部署流程，如果以更加准确地度量社区支持为前提，也许能够满足第 1 条和第 5 条，但我没看到有任何一个关于如何实现这种前提的提议。可以说，一个显著更长的激活时间窗口也能让 BIP 8 能够满足第 3 条和第 4 条，但必然在 “无必要” 和 “只要有可能” 两方面存在瑕疵。
你可能注意到了，从实现关键目标这一个角度看，BIP 8 与 “信号日（flag-day）激活” 的唯一区别在于，如果它在信号日之前就取得了 “融洽结果（happy-path）”，那么它看起来就像 BIP 9，但这是没有保证的。此外，它还有一种 “锦上添花” 的特性：如果矿工很快采用，那么激活在信号日之前就能发生，虽然这种有用性是有限的，因为还要考虑节点的采用。
（译者注：“信号日” 是比特币早期曾采用过的激活方法，新版本的软件会硬编码新规则的激活日期，到了日期就直接激活；相对而言更加激进、更少社会协商。）
因此，为了在 BIP 8 和 BIP 9 的缺点之间取得平衡，“共识清理（Great Consensus Cleanup）” 软分叉提议在讨论章节包含了以下这段文字（以及介绍 BIP 9 部署的规范）：
尽管有人建议采用其它激活方法，我们依然提议采用 BIP 9，以保证矿工已经升级到强制执行新规则、作为尽可能减少分裂的重要部分。虽然曾经有 BIP 9 软分叉导致了政治争议，但本提议 —— 一个相对不重要的软分叉 ，提供了一个很好的机会，尝试回到利用 BIP 9 来保证矿工在激活前升级的道路上；在本提议的作者来看，这是一个重要的目标。不过，如果在 BIP 9 到期时，激活新规则的广泛共识达成了，但矿工还没有表现出充分的准备，那么可以在日后再策划一个信号日激活。出于这个理由，软件实现可能会提供一个兼容选项，允许不更新软件就能执行新规则的信号日激活。
最终，经过显然是有限的讨论，我依然喜欢这种模式（虽然我不能说它是我自己提出来的，因为最初的提议来自 Greg Maxwell）。BIP 9 只会在出现不合理反对时崩溃，而给定我们必须要达成一定的共识（某意见在事实上是物理性的，或者说无关的），不合理反对是难以被忽视的。虽然我承认这是一种可能性，我依然认为：（1）发生这种情形的概率比以往的软分叉更小；（2）即使真的是这种情形，也只是拖慢进度，并不必然会让事情从此叫停。事实上，在 BIP 9 真的遭遇失败的情形中，整个过程会给我们提供一个很好的了解，了解社区的准备程度和对某一项变更的意愿。虽然我们可以（也应该，也确实）通过广泛接触和讨论来了解社区对一项变更的准备程度和接受度（可以了解到很多），有时间框架的变更会迫使人们更细致地思考它。
因此，把事情讲得更具体些，我认为，一种能够作为正确先例、妥当地兼顾上述目标的激活方法，应该是这样的：
1）一个标准的 BIP 9 部署流程，以一年的时间窗口准备激活，要求 95% 的矿工准备好；2）在一年内无法激活的情形中，设定一个长度为 6 个月的静默期，社区可以分析和讨论不激活的理由；3）在合理的情况下，在最早的部署软件发行版中提供一个简单的 命令行命令/配置文件参数，让用户可以选择一个 BIP 8 部署流程，以 24 个月的时间窗口促成信号日激活（同时，新的 Bitcoin Core 发行版自动启用这个标签）。
这给更加标准的激活方法提供一个非常长的时间窗口；虽然，在保证依然能够满足第 5 条目标的前提下，需要显著延长时间窗口来保证满足第 3 条目标。开发比特币不是一场赛跑。如果有必要，等待 42 个月可以保证我们不是在建立一个会在日后让我们后悔的负面先例。
（完）
