作者：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 個月可以保證我們不是在建立一個會在日後讓我們後悔的負面先例。
（完）
