比特幣時間延遲鎖可防止橋接漏洞造成的總損失：Rootstock 共同創辦人

Rootstock 共同創辦人 Sergio Lerner 呼籲比特幣橋接採用強制提款延遲，因為約 4,000 BTC 通過未經授權的 peg-out 離開 Liquid Network 的聯盟錢包。
摘要

• 時間延遲鎖可以給橋接操作員幾個小時的時間來識別和阻止未經授權的提款。
• Rootstock 的 PowHSMs 在簽署 peg-out 之前會等待 4,000 個區塊，約 36 小時。
• Lerner 表示，受損的 Rootstock 功能人員可以停止 peg，但無法強迫提前提款。
• 草案比特幣提案 BIP-443 可以支持將提款控制放入共識規則的金庫設計。

Sergio Lerner，RootstockLabs 的首席科學家和共同創辦人，告訴 crypto.news，立即結算可能會將單一驗證錯誤轉變為損失，因為橋接操作員沒有時間做出反應。

"如果沒有時間延遲鎖，單一的驗證錯誤和總損失將成為完全相同的事件，因為資金在軟體說 '是' 的那一刻就會移動，"Lerner 說。

他的評論是在一次事件之後發表的，當時行為者創造了未擔保的 L-BTC，並使用 SideSwap 的 peg-out 服務從 Liquid Federation 錢包中提取了近 4,000 BTC。Liquid 將這些行為者描述為所謂的白帽駭客，而 SideSwap 則表示其服務處理了該請求，因為 L-BTC 看起來是有效的。

這些行為者在 Blockstream 確認受影響的橋接節點已經修補後，隨後歸還了 3,400 BTC。大約 598 BTC 仍未解決，而 Liquid 在 9 月 10 日恢復了區塊生產，但未恢復交易或 peg 操作。
你可能還喜歡：Liquid Network 在橋接漏洞後恢復 3,400 BTC

時間延遲鎖可以創造干預窗口

Lerner 表示，在創建未擔保的 L-BTC 和釋放真實 BTC 之間的強制延遲可以減少損害。

在這樣的系統下，軟體批准將開始一個等待期，而不是完成提款。自動監控工具可以比較請求的 peg-out 與支持 L-BTC 的 BTC，並在結算之前標記任何不平衡。

"如果 Liquid 擁有一個時間延遲鎖——在指定的時間內資金無法移動，無論軟體或操作員說什麼——那麼這個錯誤將導致一個可管理的事件，而不是立即的全面災難。"

根據 Lerner 的說法，這個延遲將給操作員在未擔保代幣創建後提供幾小時的反應窗口。全天候運行的監控系統可以檢測到 peg-out 通過了第一輪軟體檢查，儘管缺乏相應的擔保。

他補充說，功能人員可以在硬體簽署交易或從聯盟錢包釋放 BTC 之前暫停 peg。

Liquid 的系統並未報告被盜的 Peg-out 授權金鑰。SideSwap 表示，一位客戶將 4,000 L-BTC 發送到其 peg-out 服務，該服務根據其正常流程處理了請求，因為這些代幣無法與擔保的 L-BTC 區分。聯盟在大約 23 分鐘後向提供的比特幣地址支付了 3,996 BTC。

Lerner 的提案將在第一個驗證階段之後增加一個額外的控制。即使軟體錯誤地批准了提款，延遲也將防止相應的 BTC 立即離開。

Rootstock 強制執行 4,000 區塊的比特幣提款延遲

Rootstock 已經通過其雙向 peg 使用延遲機制進行 BTC 提款，儘管比特幣的共識規則並不強制執行等待期。

該系統依賴於稱為 PowHSM 的專用硬體安全模組。在簽署 peg-out 之前，這些設備獨立驗證已經通過了 4,000 個 Rootstock 區塊，這代表了約 36 小時的累積工作證明。

根據Lerner的說法，私鑰保留在設備內，功能人員無法指示硬體繞過所需的時間。Rootstock將HSM規則與合併挖礦結合，透過此方式，比特幣礦工為側鏈貢獻工作證明。

"即使是共謀的大多數簽署者也無法竊取資金，因為私鑰從未離開PowHSM，且HSM獨立驗證在簽署之前已經過了4,000個Rootstock區塊，"Lerner說。

Rootstock的模型假設參與合併挖礦的比特幣哈希率的大多數和聯盟功能人員不會合作來停止網絡。Lerner表示，受損的功能人員可能會中斷掛鉤操作，造成活躍性問題，但HSM規則將防止他們強迫未經授權的提前提款。

當監控工具識別出可疑活動時，功能人員可以關閉他們的HSM，以便待處理的掛鉤不會收到簽名。Lerner將這一暫停描述為保護基礎BTC的一種方式，同時操作員檢查問題並決定如何進行。

"共謀的大多數在最壞的情況下可以停止掛鉤，但他們無法強迫未經授權的提款，"他說。

分散的撤銷控制可能限制凍結權限

停止待處理的提款會引入另一種風險，因為同樣的權力可能被用來延遲合法用戶。Lerner表示，沒有任何單一公司、操作員或管理者應該控制撤銷機制。

相反，獨立的功能人員應該通過多方結構共享權限，並且硬體規則限制他們的行為。在他提出的模型中，功能人員可以暫停處理，但無法將BTC重定向到其他地址或沒收它。

"為了防止單點故障或集中審查，撤銷控制應該在獨立的多方功能人員之間分散，使用硬體強制的規則，而不是集中管理的密鑰。"

這些控制仍然允許一組功能人員在足夠的參與者共同行動的情況下中斷提款。Lerner的區分在於該權限的範圍：操作員可以在異常被審查時暫時保留簽名，但他們無法創建有效的交易將擔保轉移給自己。

時間延遲還需要考慮每筆交易的價值和目的。36小時的等待可能不適合例行支付，而持有大量BTC的橋樑則有不同的風險輪廓。

Lerner表示，高價值結算系統應將時間視為安全控制，類似於實體銀行金庫使用的延遲機制。提款期間可以根據交易大小而有所不同，或根據風險擔保要求不同的累積工作證明門檻。

較短的期間可以適用於較小的轉移，而較長的延遲則可以給自動系統和人類響應者更多時間檢查異常的大請求。Lerner並未為每個橋樑規定一個延遲，但引用Rootstock的4,000區塊要求作為保障大型BTC餘額的有效期間。

本地比特幣金庫可以在共識中設置保護措施

Rootstock目前的保護依賴於其HSM和聯盟，而不是比特幣網絡強制的規則。Lerner表示，本地比特幣金庫和撤銷密鑰可以將可比的控制移入基礎協議。

一個可能的構建塊是BIP-443，一個名為OP_CHECKCONTRACTVERIFY或OP_CCV的操作碼草案提案。該提案將允許比特幣輸出攜帶數據，並限制其資金如何通過未來的交易移動。

BIP-443 描述了 OP_CCV 作為一項需要軟分叉的共識變更。其列出的用途包括攜帶狀態的比特幣輸出、側鏈以及允許反應性安全的兩步提現結構。該提案仍處於草案狀態，其啟動過程尚未確定。

Lerner 引用了 OP_CCV 和 BIP-443 作為原生保險庫如何使用戶或指定方在檢測到被盜憑證、修改過的軟體或其他異常事件後，有時間取消提現的例子。

根據 Lerner 的說法，將該機制納入比特幣共識將減少對特定橋接 HSM 政策的依賴。礦工、職能人員或管理者必須遵循附加在比特幣輸出上的支出條件，而不是在資金已經移動後再進行任意暫停。

對於大型橋接提現，Lerner 表示，延遲應持續足夠長的時間，以便自動警報和人工操作人員能夠識別問題、停止處理並檢查受影響的軟體，然後再讓 BTC 成為收件人可永久支出的資金。
閱讀更多：CLARITY 法案面臨參議院對加密衝突規則的分歧