摘要：比特币的 Taproot 软分叉升级看起来已经准备就绪，比特币社区已经开始认真讨论潜在的激活方法。在本文中，我们总结了有关激活的主要选择，并讨论了最重要的争议点。最后，我们假设没有完美的激活方法。任何激活方法都可能开创一个不好的先例，在未来的某一天被人利用。但是，尽管发生了很多 “bikeshedding ” 的情况，但由于缺乏关于此特定升级的争论，此时采取的具体激活路径可能并不是特别关键。对于目前存在的一些困境和可能的发展方向，潜在的部分解决方案可能是由 Bitcoin Core 发布一个具有相对被动激活逻辑的客户端，并让其他社区成员在此基础上发布客户端，以稍微更强硬的方式强制激活相同的功能。
总览
正如我们在 2019 年 5 月提到的那样，Taproot 比特币软分叉提案在开发者社区中获得了广泛的关注，现在，在2020年夏季，焦点已转移至辩论如何在比特币网络上激活软分叉。
比特币软分叉激活历史
在决定最好的前进方向之前，回顾一下比特币软分叉的历史可能是个好主意。据我们所知，根据我们 2017 年 12 月 “比特币共识分叉的完整历史” 的文章，比特币的历史上有 16 次软分叉。大部分的升级，准确的说是 9 次，主要是在 2010 年初到 2012 年期间，以 flag day 软分叉的方式进行。另一方面，其中有 7 次软分叉是使用矿工信号门槛（从 55％ 到 95％）激活的。
| 平稳升级 | 重大事件 | 总和 | |
| Flag Day 或立即生效 | 8* | 1 | 9 |
| 矿工门槛激活 | |||
| 55% 矿工门槛 | 1 | 1 | |
| 80% 矿工门槛 | 1* | 1 | |
| 95% 矿工门槛 | 4 | 1 | 5 |
| 矿工门槛总和 | 5 | 2 | 7 |
| 总计 | 13 | 3 | 16 |
(来源: BitMEX Research)
（注：*据我们所知，有一个带有强制性矿工信号（BIP148）的 flag day 软分叉和一个带有强制性矿工信号（BIP 91）的矿工门槛软分叉）
尽管基于上述数据，flag day 升级方法可能看起来更可靠，但我们不建议您使用此数据来支持声称 flag day 方法更优异的说法。上述软分叉中的大多数问题是由与激活方法无关的特性引起的，同时在此期间生态系统已经发生了显着的变化。以上数据仅出于历史时空背景提供，关联性未必那么强。
区块容量战
另一个历史背景（也许同样不那么重要）是 2015 年至 2017 年间爆发的 “区块容量战” 。当时有一项名为 “隔离见证（Segregated Witness）” 的软分叉提案，旨在提高区块容量限制，然而由于区块容量战争冲突，此软分叉的激活有些危险，因此社区中的许多人都渴望尝试改进激活方法。
Bitcoin Core 中包含用于隔离见证升级的激活逻辑，基于 95％ 的矿工门槛，时间为一年，最后没有 flag day 激活。最终，在软分叉窗口期尾声，两个不同的软分叉，flag day 软分叉（BIP148）和 80％ 矿工门槛的软分叉（BIP91）强制发出隔离见证信号，因此最终被激活。这两个软分叉（BIP148 或 BIP91）都没有被纳入Bitcoin Core 中。
基于上述乱象，许多人总结，没有强制信号的 95％ 门槛系统有些失败。但是，我们认为，这种混乱主要是由于区块容量战中的紧张局势造成的，而不是激活逻辑固有的内在弱点。
激活争论
据我们所知，除了时序参数这一棘手问题以及假设将在某些地方使用矿工门槛信号外，争论似乎集中在三个相互关联的领域：
- 矿工门槛信号周期之后是否应该有一个 flag day 激活？
- 激活逻辑的哪些部分（如果有）应纳入 Bitcoin Core ？
- 矿工信号最终是否应该成为强制性的？
我们试图在下列的决策树图解中总结这些主要争论点之间的相互关系。根据我们的图示，我们认为在现代软分叉激活方面，基本上有六种合理的可能选择。
软分叉激活方法决策树（假设某种形式的矿工门槛信号）
(来源: BitMEX Research)
（注：带有强制性矿工信号的树的右侧与 BIP 8 一致，而树的左侧与 BIP 9 一致）
在下表中，我们旨在总结支持和反对上述三个挑战性问题的主要争论点，要确定软分叉激活方法，可能需要回答这些问题。
信号周期结束时的 Flag day
| 支持 flag day | 反对 flag day |
| · 最初的隔离见证激活没有 flag day 而导致了问题，这是因为矿工在早期并未激活它，以及基于升级可能不会发生的考量。 · 没有 flag day 的矿工信号给人一种矿工控制协议规则的错误印象，而实际上门槛投票只是矿工发信号表示他们已经准备好进行社区决定的软分叉的信号机制。 · 如果矿工选择不提早激活软分叉，可以之后安全地在未来某一天激活。最终将控制协议规则的是终端用戶，而不是矿工。门槛投票机制仅仅是安全地早期激活软分叉的一种方式。 | · 目前使用 flag day 过于激进。相反地，应该采取一种更友好的方法，并且只有在特殊情况下才考虑 flag day，如果参与者开始表现出敌对意思。 · 对于协议规则，尽可能保持耐心和友好是至关重要的。如果矿工对升级不满意，则应维持现状共识规则，并且不应发生软分叉，这确保比特币的规则保持稳健。 · 由于没有争议，矿工很可能会自主激活软分叉，如此一来为什么要在不必要时使用具有侵略性和风险的 flag day 系统？ · 增加 flag day 会带来一系列新问题。例如，谁有权发起 flag day？社区如何在日期达成协议？任何人都可以随时创建 flag day 软分叉，新规则可能会引起争议。 |
将激活逻辑纳入 Bitcoin Core
| 支持将激活逻辑纳入 Bitcoin Core | 反对将激活逻辑纳入 Bitcoin Core |
| · 如果激活方法未在 Bitcoin Core 中实现，则存在对激活参数进行协调的问题。 · 同时，如果其他社区成员发布带有激活逻辑的客户端，那么这将成为危险的先例。很多用户在共识不足的情况下，可能会发布各种软分叉的客户端，，增加将来发生危险的链分裂的风险。 · 包含激活方法的 Bitcoin Core 是最差的选择。 · Bitcoin Core 会发布一个包含激活逻辑的客户端，但是不会与其他错误修复捆绑在一起。同时，Bitcoin Core 没有自动更新功能。因此，升级完全是选择性的，Bitcoin Core 不会强制更改协议，只有选择运行新软件的用户才能更改协议规则。 | · 区块容量战争的最大问题之一是，现在许多人高估了 Bitcoin Core 项目对比特币共识规则的控制权。现在这是一个重要的问题，因此社区应该确保 Bitcoin Core 没有能力自行更改共识规则。 · 共识规则的更改必须来自比软件开发者更大的群体，并且必须由基层用户行动推动 · Bitcoin Core 项目实施 flag day 升级太具争议性和激进性，这是一种不恰当的权力掌握。用户和/或矿工必须在Core 纳入 flag day 之前展现对软分叉建议的支持。 |
flag day 激活点的强制矿工信号
| 支持强制性矿工信号 | 反对强制性矿工信号 |
| · 强制性矿工信令发送提供了确定性，因为社区知道激活是否有效。如果没有强制标记，则 flag day 激活可能已经过去，而用户将不知道软叉是否已激活。 · 例如，在 flag day过去之后，用户将不得不等待几个月（或更长时间），以查看是否生产一个违反新软分叉规则的区块，建立并被更广泛的经济体所接受，这可能会发生在任何时间点。 · 一个敌对的攻击矿工可以在任何时候产生一个违反软叉规则的区块，例如设计一个时间来造成最大的混乱。 · 因此，尽管强制性信号发动会迫使矿工升级并增加发生链分裂的风险，另一种选择要好，因为后者允许攻击者制造类似的链分裂风险，只是时间适合敌对行为者。 | · 现代软分叉仅限制非标准比特币规则。这使得激活非常安全，因为只有升级到反软分叉客户端的恶意矿工才能造成链分裂。即使矿工不为软分叉升级，他们也会一直生产有效的区块。强制性信号发送破坏了这种非常安全的升级方法，并带来了额外的风险。不升级也不采取行动的矿工会产生无效的区块。 · 因此，强制性信号发送过于激进。矿工应该可以自由地选择不升级，继续像分叉前那样运作。 · 强制性矿工信号发送只会鼓励虚假标记，在这种情况下，即矿工声称已经升级以支持协议变更，然而实际上只是在操纵标记。我们已经知道虚假标记很普遍，例如，在过去，大型矿工生产的区块带有多个相互矛盾的标记。因此，强制性信号发送无法提供任何确定性。 |
结论
可以说关于激活逻辑有许多 “bikeshedding”。由于缺乏有关此特定升级的争论，此时采取的具体激活路径可能并不特别重要。但是，从上面的讨论可以看出，没有完美的激活方法，每种方法都存在问题或者暴露出比特币协议规则稳固性方面有关的潜在弱点或矛盾。为解决问题所采取的任何方法都可能开创一个先例，从而在未来的某一天被其他协议变更所利用。
也许可以就目前明显的激活方法困境达成某些折衷方案：
- 比特币核心可以在 BIP 9 的基础上加入激活逻辑，选择 95％ 矿工门槛的激活逻辑，在激活期结束时不设 flag day，也不强制矿工信号。因此，由于需要矿工的合作才能激活软叉，Bitcoin Core 不会以明显的激进方式行事。这也有先例，因为比特币核心过去曾多次使用这种激活逻辑发布客户端。
- 然后就可以发布该软件的其他社区驱动版本（不是 Bitcoin Core ）。这些其他的客户端可能包含 flag day 激活逻辑，强制矿工发出 Bitcoin Core 软分叉的信号，时间上与 Bitcoin Core选择的激活窗口结束一致。因此，该社区驱动的软分叉将激活 Bitcoin Core 的软分叉。
这在某种程度上解决了社区协调的时间问题，因为社区成员可以直接选择将 Bitcoin Core 激活窗口的结束作为强制信号发送期间。这也不会开创一个关于使任何客户端作为激活任何软分叉的危险先例，因为它被用来激活 Bitcoin Core 中已经存在逻辑的软分叉。这种激活方法与隔离见证最终的激活方式相当相似，只是这次可以从一开始就计划好，至少在某种程度上是这样。当然，这并不能解决所有问题，也不能说这是一个好的结果，但是对我们来说，这似乎是一个可能的前进路径。
进阶阅读/材料