乾貨 | 比特幣軟分叉激活史（下）

作者:Bitcoin Optech

上文我們講了《乾貨 | 比特幣軟分叉激活史（上）》，後續如下：

[2016] BIP9 versionbits：BIP68/112/113 相對鎖定時間激活

BIP9 提出了一種新的激活機制來解決 ISM 的幾個問題：

• 沒必要地懲罰礦工：ISM 激活會導致區塊版本號遞增，沒有遞增版本號的礦工所生產的區塊就會被當成無效的，即使這個區塊並沒有違反軟分叉的其它規則。舉個例子，在 2015 年7 月 4 日的鏈分裂中，所有的交易都遵守軟分叉規則 —— 這些礦工損失 50 萬美元的唯一理由就是升級要求區塊頭裡應該包含一個 3 而沒升級的礦工使用了 2 。
• 很難并行化：使用 ISM，即使開發者認為有必要，也必須等待一個分叉結束，另一個分叉才能開始收集信號。
• 不允許失敗：ISM 不設過期時間。等待激活信號的節點軟件一旦放出，運行了新軟件的節點就會一直監控信號，直到激活完成。沒有辦法確定人們是不是完全不需要這個軟分叉。
• 不可預期的激活時間：無法提前知道確切的激活時間，意味着協議開發者、商戶系統管理員以及礦池運營者，都很難在激活之後短時間內立即投入使用，即使出現了需要快速反應的問題。

BIP9 versionbits 嘗試解決這些問題。它將區塊頭內的 vision 字段用作 bit 字段。這個字段裡面的數據只用來表示信號 —— 不會被當成無效區塊的依據 —— 並且可以并行地設置。測量每 2016 個區塊運行一次，以壓縮某一小部分算力足夠幸運便能冒充 95% 支持的可能性。最後，當達到了 95% 的信號門檻，激活之前會有額外的 2016 個區塊（約兩周）的 “鎖定期”，以便各方準備升級。如果過期時間之前未能達到激活的門檻，整個軟分叉的嘗試就結束，沒有用上的代碼可以在後來的軟件版本中刪除。

這個激活方法第一次使用是在 BIP68 共識強制的序列號、BIP112 OP_CHECKSEQUENCEVERIFY 以及 BIP113 中位時間定義的 nLockTime 的軟分叉中。這個分叉很快進入了鎖定階段，然後自動進入了激活階段。

[2016-7] BIP9、BIP148 以及 BIP91：BIP141/143 隔離見證激活

隔離見證軟分叉是用 BIP9 激活參數發布的。少數礦工很快地表示了支持，但支持率遠低於 95% 的門檻。一些比特幣用戶認為礦工是在不合理地拖延一個有用的新特性，所以開發出了自願的激活措施，就是 BIP148。BIP148 的最終形式指定，從某個日期開始，拒絕一切不支持 segwit 的區塊，

實現 BIP148 的軟件出現后，網絡中就有了三類節點 —— 不升級的節點，BIP9/141 節點，以及 BIP148/141 節點 —— 陷入共識錯誤的幾率更大了。如果礦工沒有支持隔離見證，而大部分用戶都繼續把這些區塊當成有效的，BIP148 的用戶可能就會收到在其他用戶看來無效的比特幣。此外，如果大部分用戶都支持 BIP148，但礦工繼續生產許多在 BIP148 看來無效的區塊，那些不實行 BIP148 的用戶就會接受 BIP148 用戶認為無效的比特幣。只有用戶都遵守同樣的規則，且大部分算力都支持 BIP148 規則，升級才是安全的。

一種降低風險的辦法是，給出足夠的時間，讓用戶可以升級到強制激活隔離見證的節點，但 BIP148 無法做到這一點，因為它的目標是觸發現有的 BIP9 流程，也就意味着，它要在 BIP9 到期日很久以前就強迫礦工發信號表示支持。作為 BIP148 可能不得人心的替代方案，BIP149 提議給用戶多一年的時間來升級。BIP149 從未獲得足夠多的公開支持，但它是第一個使用 BIP8 的提案，而 BIP8 在未來幾年裡引發了更多的討論。

在 BIP148 開始獲得重大的公開支持時，多個礦工、交易所和業界人士表示支持一個兩步驟的提議，在激活隔離見證的同時會與支持 BIP148 的節點保持共識。第一個步驟寫在 BIP91 中，它改進了 BIP9 的規則。礦工可以使用 BIP9 的位字段來表示他們是否會實行一個暫時的規則：拒絕一切不發信號支持 BIP141/143 隔離見證的區塊。與 BIP9 不同，BIP91 的閾值從 95% 降到了 80%，而其監控和鎖定期的長度從 2016 個區塊降低到了 336 個區塊。

BIP91 鎖定並且激活了。隨後，BIP141/143 鎖定並激活。在它們鎖定時，BIP148 的強制支持措施過期。

這個來自礦工、交易所和業界人士的提議的第二個階段需要一個硬分叉，在遭到大量個人用戶和企業的激烈反對之後，提案的簽名人撤回了這個提議。

至今，人們仍然在爭論，這些事件以及同期發生的其他事件，到底為隔離見證激活造成了多大的影響。

緊急激活

不止一次，人們在共識代碼中發現了嚴重的漏洞，開發者沒有經過激活的流程就放出了補丁。這樣做可能導致共識失敗，但也為升級的節點立即消除了漏洞。重大的事件包括：

• 使用 chainwork 來替換高度（2010 年 7 月）：比特幣一開始認定最多區塊的鏈（“最長鏈”）為有效的鏈。如果每個區塊都有同樣的難度，那這樣的最長鏈同時也會是積累了最多工作量證明的鏈。但是不同的區塊有不一樣的難度，所以 chainwork 軟分叉在 Bitcoin 0.3.3 中放出，將累積最多工作量證明的鏈視為有效鏈。
• 消除繞過腳本的 bug（2010 年 7 月）：比特幣一開始將花費 UTXO 的腳本（scriptSig）和保護 UTXO 的腳本（scriptPubKey）結合起來、同時求值。這種設計使得人們可以在鎖定機制計算之前就終止腳本，以成功狀態退出，例如，在運行 OP_CHECKSIG 以檢查簽名之前就終止腳本。這個 bug 最初被報告為 使用 OP_TRUE OP_RETURN 的 scriptSig 可以花費任何人的比特幣。這個漏洞在 Bitcoin 0.3.6 中第一次修復，辦法是讓 OP_RETURN 必定以失敗收場，而且為腳本的其它顯示安排了數字。雖然所有這些變更都是軟分叉，但相同代碼的修改（後來移除某些限制）也會造成硬分叉式的更改。即使是這麼重大的變更，scriptSig 可以篡改 scriptPubKeys 運行的底層問題仍然存在，所以第二次軟分叉在 Bitcoin 0.3.8 中實現，它讓兩者獨立執行。
• 修復溢出漏洞（2010 年 8 月）：某人創建了一筆交易來花費 0.5 btc 並創建了兩個價值 92,233,720,368.54277039 BTC 的輸出。比特幣的確要求輸出的數值不能大於輸入的數值，但檢測方法是把輸出的數值加入到一個最多能表示 9,223,372,036,854,776 聰（約 9200 萬 btc）的 64 位整數中，這個整數溢出后就會從 -9,223,372,036,854,776 聰開始。這就意味着，這個交易似乎只花費了總計 -0.1 btc。這還繞過了另一條規則，就是禁止單個為負的輸出，但是不禁止總計為負的數值 —— 因為它假設了任何正值的總和都仍會是正的。這使得某人創造出了 1840 億 btc，而且這樣的把戲可以不斷重複，沒有任何代價，產生無數的比特幣。幾個小時內，Bitcoin 0.3.10 放出了一個軟分叉補丁，限制輸出為 2100 萬 btc。它還要求放棄帶有溢出交易的鏈 —— 這是有意製造的共識失敗，但為了比特幣仍然有意義就必須這麼做。
• 臨時修復 BDB 鎖定問題（2013 年 3 月）：2012 年初，比特幣開發者意識到，如果同時對 UTXO 數據庫（鏈狀態）做太多更改，可能會超出鏈狀態數據的默認容量限制之一。因為當時的比特幣區塊比較小，只有在區塊鏈重組、需要同時處理來自多個區塊的交易時才會觀察到這個情形。當時人們實現了一個簡單的解決方案：在重組期間，一次只處理來自一個區塊的交易。後來，一些人開始請求礦工把可選的默認區塊大小從 250 KB 提高。在 2013 年3 月 12 日，某個礦工生產了一個約 1 MB 的區塊，包含了超過 1700 筆交易 —— 也是截至當時最大的比特幣區塊 —— 在許多節點上都超過了數據庫的容量，導致它們認為這個區塊時無效的，即使它完全符合比特幣的明示的共識規則。把水攪得更渾的是，一個新版 Bitcoin Core 已經發布，它用上了不一樣的數據庫引擎，沒有這種限制，因此也能安然地接收這個更大的區塊 —— 所以不同版本的節點之間出現了共識錯誤。在快速分析了情況之後，開發者鼓勵用戶暫時降級到舊版本（會拒絕掉這個大區塊的版本），然後更新到一個緊急版本，以軟分叉暫時將區塊大小的上限降到 500 KB，好留出時間讓每個用戶都能升級新的數據庫引擎，而這種暫時的下調會在幾個月之後自動過期。

未來的激活

Segwit 激活幾個月出現問題之後，一些人開始考慮 BIP8。BIP8 的支持者們認為它能解決 BIP9 的一些問題：

• 允許強制激活：BIP8 是 BIP148 的一般化，礦工可以在等待激活的時間段里自願發信號表示支持，但它還設了一個最後通牒時間段，礦工在這段時間裡必須發信號表示支持，否則所生產的區塊就有可能變作無效的。後來，人們設計了一個參數 LockinOnTimeout （LOT）來觸發這種動作：使用 LOT=true 的節點，會要求礦工在激活即將超時的最後一段時間裡發出信號；使用 LOT=false 的節點，不會這麼要求，但如果有足夠多的區塊帶有信號，仍然會實行新規則。
• 使用高度而非時間：BIP9 開始和停止監控激活信號的時間都基於礦工寫入區塊的時間的平均值。所以礦工是有可能操控這個時間的，這會阻礙 LOT=true 的功能，所以 BIP8 提議使用區塊高度而非時間。

BIP8 的靈活性使其成為了 taproot 軟分叉的多種候選激活提案之一，雖然批評者也批評了它的某些方面，比如某些設置允許礦工拒絕激活得到廣泛社區支持的提議、鼓勵一個團體 “俘虜” 另一個團體所用的信號機制、要求礦工對所生產的區塊作沒有實質意義的更改、看起來給了開發者凌駕於共識規則的權威以及提高了共識失敗的風險。截至本文撰寫之時，taproot 激活方法的討論仍在進行。

其它想法也一直在討論，包括 “概率性的軟分叉激活（sporks）”、“多階段軟分叉激活（MSFA）”、“閾值遞減型激活（decthresh）”、“返回硬編碼高度或時間的激活（flag days）”，以及 “激活推遲后使用更短信號期的方法（speedy trial）”。