作者：Antoine Poinsot
來源：https://bitcoinmagazine.com/print/the-core-issue-consensus-cleanup
關於比特幣的未來，比特幣的協議開發者們通常比絕大部分比特幣人更加悲觀。每天都接觸比特幣的不完美之處，當然會帶給他們更加清醒的視角，但這也映照出比特幣的成就。世界上的任何一個人，不論其種族、年齡、性別、國籍乃至其它任何標準，都可以在一箇中立的貨幣網絡上保存和轉移價值，並且這個網絡還在日復一日壯大。雖說如此，比特幣還是有一些許多比特幣人都沒有注意到的問題，如果不妥善解決，可能威脅比特幣的前景。由 “共識規則清理（Consensus Cleanup）” 修復的漏洞，就是這樣的例子。
“共識規則清理”（BIP 54 1）是一個軟分叉提議，意圖修補比特幣共識協議中長期存在的幾個漏洞。與本期刊（Bitcoin Magazine 的 “The Core Issue”期刊）提到的絕大部分 Bitcoin Core 開發工作性質不同，它是一個軟分叉提議。雖然這個提議在歷史上曾由多位參與 Bitcoin Core 項目的開發者領銜， 實際上，它屬於 “比特幣協議開發” 這一廣義類別。
本文將介紹這項提議中的全部四項措施，介紹它們意圖解決的問題所造成的影響以及修補措施的發現。我們將說明，這些緩解措施是如何在吸收反饋意見、解決新發現的漏洞中提煉的，最後，我們會概要介紹這個軟分叉提議的現狀。
比特幣工作量證明機制中的一個漏洞
比特幣網絡通過調節其挖礦難度來保持平均每 10 分鐘挖出一個新區塊的速度。但是，在這個難度調整機制的實現中，有一個 “差一錯誤”（編程中的常見錯誤），讓一種叫做 “時間扭曲” 的攻擊有機可趁：佔據大部分挖礦算力的礦工可以通過調降難度、任意地加快區塊生產的速度。
幸運的是，這種攻擊需要控制 51% 以上的挖礦算力，但是，任意加快區塊生產的速度是致命問題。它意味著，全節點將不再能控制資源的使用量，而攻擊者可以顯著加快比特幣區塊補貼（新貨幣）的發放速度。
雖然這種攻擊需要 “51% 的礦工”，它還是跟比特幣所面臨的標準威脅模型顯著不同。傳統意義上的“51% 攻擊” 然一個礦工可以阻止一筆交易的確認（只要 TA 能保持自己的算力優勢）。但這個漏洞卻讓攻擊者可以通過迅速降低挖礦的難度，在 38 天以內癱瘓整個網絡。
但是，攻擊者有可能不會癱瘓整個網絡，而是小幅度地利用這個 bug 。當前的礦工們可以串通起來讓區塊生產速度變成 4 倍（也就是每 2.5 分鐘挖出一個區塊），同時讓比特幣網絡保持看起來正常的狀態，實質上，就是讓可用的區塊空間變成 4 倍、從未來的礦工手上盜竊區塊補貼。短時的用戶可能會被激勵去支持這種攻擊，因為更多可用的區塊空間意味著在區塊鏈內確認交易的手續費會更低（暫時假設其它條件不變）。當然，這是以全節點運營者的開銷為代價的，而且會降低網絡的長期穩定性。
時間扭曲攻擊利用的事實是：難度調整週期並不重疊，所以，新週期中的區塊的時間戳，可以設為比剛剛結束的上一週期中的最後一個區塊更早。因為讓難度調整週期重疊將變成一雌硬分叉，所以退而求其次的最好辦法，就是難度調整週期邊界上區塊的時間戳關聯起來。BIP 54 規定了，一個難度調整週期的第一個區塊的時間戳，不得比上一週期的最後一個區塊早兩個小時以上。
此外，BIP 54 還規定了，一個難度調整週期必須花去正數時間。也就是說，在一個難度調整週期中，最後一個區塊的時間戳不能比第一個區塊的時間戳還要早。你是不是很驚訝，怎麼比特幣一直沒有這個規定？我們也曾驚訝，這居然是必要的。現實表明，這是對一種聰明的的攻擊的簡單修復措施；這種攻擊跟時間扭曲有關，由化名為 “Zawy” 的開發者和 Mark “Murch” Erhardt 在審核共識規則清理提議時發現。
需要幾個小時來驗證的區塊
任何礦工都能利用一些驗證起來很費勁的操作，創建出需要很長時間來驗證的區塊。雖然一個普通的比特幣區塊只需要 100 毫秒這個量級就能驗證，但這些 “用來攻擊的區塊” 的驗證時間可以長到在高端的計算機上超過 10 分鐘、在樹莓派上超過 10 小時（後者是常見的用於運行全節點的硬件）。
一個別有用心的攻擊者，可能會利用這種攻擊來摧毀整個網絡；而在這種攻擊的一種更能帶來經濟利益的變種中，一個礦工可以用這種攻擊來拖延自己的競爭對手、提升自己的收益，而不讓崩潰在網絡中蔓延。
歷史上，為解決這個問題而作出的嘗試都充滿波折，因為解決措施需要在比特幣的腳本編程能力上施加限制。這樣的限制有可能造成 “沒收”，在任何嚴肅的軟分叉設計中都應絕對避免。
（譯者注：此處說的 “沒收”，指的是因為禁用腳本的一些用法，而讓腳本中包含了這些用法的錢幣無法再花費。）
Matt Corallo 最早在 2019 年提出的 “Great Consensus Cleanup”，提議在非隔離見證腳本（常常被稱為 “老式腳本（legacy script）”）中禁用一些罕見的操作，來解決這個長驗證時間問題。一些人就擔心，雖然使用這些操作的交易，已經多年不被默認配置下的 Bitcoin Core 轉發和挖出，也許還是有一些人、在某些地方使用它們，只是不為人知而已。當然，這種風險也必須跟一個利用這個漏洞的礦工就能給所有比特幣用戶帶來的風險相權衡。
雖然這種對沒收的擔憂幾乎只是理論上的，這也是一個哲學問題：在比特幣協議開發中，如何設計出既能解決漏洞、造成沒收的可能性又最小的妥善緩解措施。後來，我對共識規則清理提議的改進，通過加入一個能夠精確界定有害行為的限制、不禁用任何具體的比特幣腳本操作，解決了這種顧慮。
偽造支付證據
比特幣區塊頭包含了一個默克爾根，它承諾了該區塊內所有交易。這使我們可以製作出一種緊湊的證據，證明某一筆交易已被一條具備一定工作量證明的區塊鏈確認。 這就是我們常說的 “SPV 證據”。
但是，因為這棵默克爾樹在設計上的弱點，如果區塊中包含了一筆精心定製的長為 64 字節的交易，攻擊者就有可能為一筆虛假的（不存在的）交易偽造出 SPV 證據。這可能會被用來欺騙 SPV 驗證器（通常來說，它會被用來驗證入賬支付或進入一個子系統的存款）。已經有緩解措施，能讓驗證者拒絕這樣的無效證據；不過 ，它們常常被忽視 —— 哪怕密碼學家也不例外 —— 而且在某些情況下可能很麻煩。
共識規則清理提議通過（在共識規則中）禁用序列化體積恰好為 64 字節的交易，來解決這個問題。這樣的交易首先無法具備安全性（只能用來燒掉資金，或是讓任何人都能花費），而且從 2019 年開始，默認配置的 Bitcoin Core 就不再轉發和挖出這樣的交易。其它方法也得到了討論，比如提升現有緩解措施的迂迴方式 a，但是提議的作者們選擇修復問題的根源，既消除軟件開發者們應用緩解措施的炫耀，也消除他們知曉這種漏洞的需要。
註釋 a：在區塊頭的版本號字段中承諾默克爾樹的深度。
UTXO 分身：重合交易
“小型…中型…大型通貨膨脹 —— 經濟過熱” 是 Russell O’Connor 發佈於 2012 年 2 月的博客的標題。在這篇文章中，他介紹了比特幣交易重合的可能性。這曾經是比特幣的一個致命缺陷，會打破交易標識符（哈希值）獨一無二的基礎假設。問題的源頭在於，礦工的 coinbase 交易只有一個空的輸入，也就是任何帶有相同輸出的 coinbase 交易都有一摸一樣的交易標識符。
（譯者注：coinbase 交易是一個區塊中的第一筆交易，用於讓出塊的礦工獲取交易手續費和區塊獎勵，它可以不花費任何 UTXO。）
當時，Bitcoin Core（那時候還叫 “Bitcoin”） 的開發者們用 BIP 30 2 修復了這個漏洞，該 BIP 要求全節點在收到區塊時執行額外的驗證。這種額外的驗證並不是絕對必要的，在同年實施的BIP 34 3 中就被繞過了。不幸的是，BIP 34 中的修復措施並不完美，20 年之後我們將需要重新引入 BIP 30 驗證。除了並非絕對必要之外，這種驗證措施也無法被另類的比特幣客戶端（比如 Utreexo）執行，而且實際上會阻止它們完全驗證區塊鏈。
共識規則清理提議加入了一種更加可靠、更經得起時間考驗的修復措施。所有比特幣交易，也包括 coinbase 交易，都包含一個用來決定該交易的 “生效日期” 的字段。這個字段的數值代表的是該交易尚屬無效交易的最後一個區塊高度。BIP 54 規定所有 coinbase 交易都必須將該字段設為其區塊高度（減一）。
結合來自 Anthony Towns 的一個明智的建議、確保時間鎖驗證總是運行，就能確保以往區塊的 coinabse 交易不可能使用相同時間鎖數值。反過來，這就確保了不會有兩筆 coinbase 交易擁有相同的交易標識符（哈希值），而且不再需要 BIP 30 驗證。
預防勝過治療
由共識規則清理（BIP 54）解決的漏洞，並非比特幣迫在眉睫的生存威脅。雖然其中有些有可能癱瘓整個網絡，至少目前不太可能被利用。雖說如此，情況可能會變化，我們主動緩解比特幣網絡的長期風險，是絕對必要的，即便為此必須承擔協調軟分叉的短期負擔。
共識規則清理提議上的工作起源於 Matt Corallo 在 2019 提出的原創提議。6 年以後，隨著我發佈 BIP 54 以及 Bitcoin Inquisition（一個比特幣共識變更的測試網）的相應軟分叉實現，這個提議終於結出果實。在這段時間裡，這項提議收到了大量反饋，我們討論了許多替代方案並加入了對其它弱點的緩解措施。我認為，現在它已準備好分享給比特幣的用戶了。
共識規則清理是一個軟分叉。比特幣協議開發者們選擇優先實現哪些提升，並公之於眾。 但是否採用一項對比特幣共識規則的變更，最終決定權在用戶。選擇權在你手上。
（完）
參考文獻
1. https://github.com/bitcoin/bips/blob/master/bip-0054.md ↩
2. https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki ↩
3. https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki ↩
