作者：Janusz
來源：https://insider.btcpp.dev/p/bitvm-based-bridges-and-emergency
原文出版於 2025 年 8 月。
隨著基於 BitVM 的橋接合約接近於進入生產環境，我開始思考被稱為 “緊急更新” 路徑的課題。在 Citrea 團隊的幫助下，我能夠理解驗證 BitVM 橋接合約的花費路徑的不同方式，從而確定它是否帶有緊急更新機制。本文嘗試討論未來的項目會如何實現這些花費路徑。請注意，緊急更新路徑，以及花費合約的多簽名裝置，並不是 “BitVM 的專屬特性”，它們是廣泛用於由證明系統來保護的橋接合約的機制，而我認為，它也將在基於 BitVM 的橋接合約構造中得到利用。本文是解釋性的，希望能夠點燃關於我們應該如何披露這些花費路徑的類型的討論。
你是否遭遇過需要立即從銀行中取錢的困境？比如你的車子壞了，你要立即給修理工付錢。又或者，你的朋友在酒吧喝太多酒了，你要交一筆錢保他出來。
BitVM 橋接合約可能也想要同樣的保證。我們希望橋接合約的運營者被綁定在具體的 BitVM 初始設置的規則中。但是，要是哪裡出了問題呢？如果系統有一個漏洞、攻擊者可以憑空拿走其中所有的錢、或者導致其中的資金永久凍結呢？
即使是友好的人發現了 bug，可能也希望有一種方式能夠搶先將所有的錢從橋接合約中轉移出來，防止合約被爆破。
實現這種保證的方式是緊急多簽名裝置 —— 這是一條額外的花費路徑，可以在 BitVM 橋接合約中實現，讓一組（或一個）簽名人能夠完全繞過挑戰遊戲和樂觀的報銷機制、將資金從一個橋接合約中轉出。
BitVM 是一種新的技術，其對應的橋接程序也是新生事物。一些團隊不希望在沒有保險機制的情況下發布這些新的橋接合約構造。嚐鮮的橋接合約運營者和流動性供應商，可能也希望有緊急開關，這樣能保證他們的資金可以在發現 bug 時轉移出來。不可變更性並不總是跟商業上的激勵完全一致。
一些已經上線的 BitVM 橋接合約實現中可能已經有了用於緊急更新的多簽名裝置。更多的橋接合約構造即將上市，它們在啟動時可能會有安全理事會 —— 一組得到許可的、操作緊急多簽名裝置的簽名人。如果這些系統的安全模式最終迴歸到了一個需要許可的 M-of-N 多簽名裝置（哪怕是一次性的），用戶也有權利知情。
我花了兩週時間來研究建立這樣的安全理事會的方法，並且一直在思考驗證他們的存在的方法（當然，是在一些 BitVM 陣營的成員的幫助下）。
這些練習提出了一個有趣的 “問題”。我們無法（在區塊鏈內）驗證這些花費路徑，直到它們真的被使用。也就是說，如果內部人完全不披露，一些用戶甚至永遠不會知道，一個需要許可的 M-of-N 多簽名裝置是一個基於 BitVM 的橋接合約的最終信任假設。
BitVM 橋接合約回顧
“BitVM” 是由 Robin Linux 提出的一種方法，可以在比特幣區塊鏈內執行任意計算。它激發了比特幣開發的新浪潮，許多團隊都在使用這種技術來開發 layer 2 橋接合約。這些合約所支持的 layer 2 可以 設置多個運營者來保管比特幣，作為所在 layer 2 上的封裝的比特幣資產的背書。但是，更重要的是，它還額外啟用了一種樂觀的偵測其中的機制，可以用來質疑來自運營者的任何惡意的（或者不正確的）取款嘗試。
在啟動階段，一組簽名人要形成一個 N-of-N 多簽名裝置，以為一個橋接合約預先簽名交易圖。只要其中任何一個人銷燬了自己用在這個預簽名儀式中的私鑰，那麼鎖定在這個橋接合約中的 UTXO 就只能被預先定義的花費腳本花費。
在一些涉及中，運營者必須墊付資金（作為流動性），然後從橋接合約中請求報銷。在一段時間之後，運營者才能支付給自身。另一種設計是讓用戶能夠跟誠實運營者合作，後者會給前者釋放將資金轉移出橋接合約所需的私鑰。
不管是哪一種設計，都需要至少一個誠實運營者，才能處理取款。如果運營者是不誠實的，比如說，他們見證了一次取款、這一取款與所在系統的最先狀態有衝突，那麼一個觀察者（瞭望塔服務）可以挑戰他們。
這裡說的瞭望塔是一個實體（或者一個人），自己運行 BitVM 驗證器軟件，可以挑戰然後叫停來自 BitVM 橋接合約操作者的取款請求。
關於不正確的取款，舉個例子，一個運營者嘗試從所在的 BitVM 實例中取出超過他們應當具有的餘額的資金。這就是為什麼來自橋接合約的支出都包含了一個時間鎖。它讓瞭望塔有時間來提交挑戰。這個從取款合約被廣播到時間鎖解鎖的時間窗口，叫做 “挑戰窗口”。
僅在挑戰窗口結束斥候，運營者（或用戶）才能夠從橋接合約中取走資金。在基於 BitVM 的橋接合約中，盜竊需要所有運營者和瞭望塔合謀（可以把橋接合約洗劫一空）。只要其中一個是誠實的、定期檢查區塊鏈、TA 的驗證器也在線、願意提交挑戰，資金就不會被盜。這個 1-of-N 信任假設是好的，因為這意味著我們要信任的人的數量 少於 標準的聯盟，在後者中，只要不誠實的人佔到了多數，就足以盜竊資金。
上述機制，創造了一種比已經在比特幣網絡中服役的裝置更加信任最小化的橋接裝置。但在現實中，這種核心的信任假設，可能還是會回落到一個得到許可的多簽名裝置中（儘管只是臨時的）。（譯者注：回落後的情形與當前已經實現的裝置（用於側鏈的多簽名聯盟）是一樣的。）
緊急多簽名的引入
如引言所指出的，各開發團隊可以（也將會）在他們的 BitVM 實例中加入一個緊急花費路徑。他們應不應該這樣做，並不重要。更重要的是，你只需知道，幾乎所有進入生產環境的基於 BitVM 的橋接合約，在還未成熟的時候，都會包含一個緊急花費機制。我們應該期待的是這些開發團隊會妥當地披露這些緊急花費路徑的性質。
緊急多簽名裝置並不是 BitVM 的特性。它是廣泛用於由證明系統保護的橋接合約的機制，用於在發現 bug 時更新系統。其它生態系統中的 Rollup 實例已經在這方面建立了先例。
BitVM 橋接合約使用隔離見證 v1（Taproot）腳本來創建和預簽名橋接合約的花費路徑。Taproot 腳本使用了 MAST，使得大量花費條件可以存在於一個 UTXO 中。當使用一個葉子腳本來花費這個 UTXO 時，只有這一個葉子腳本才會公開（其它同時存在的葉子腳本不需要公開）。
BitVM2 論文正確地指出，預簽名的交易可以限制運營者在取款時僅能使用可以被挑戰的方式。但是，沒有什麼能阻止具體的一個 BitVM 實例的開發者在 Taproot 腳本樹上包含允許從橋接合約中取款的 額外花費路徑。
在 Taproot 腳本樹上，每一條花費路徑都叫做一個 “葉子” 腳本。為了解鎖和花費攜帶由這個腳本樹鎖定的 UTXO，只需要揭示其中一個有效的葉子（並提供滿足該葉子腳本的見證數據）。
我們來看一個例子：第一條路徑（或者說第一個葉子）是標準的取款路徑，帶有挑戰窗口。另一條路徑，則是緊急花費路徑，可以繞過挑戰窗口。
葉子 A：由 1-of-N 欺詐證明來保護的花費條件
OP_PUSHBYTES_2 <SomeDelay>OP_CSVOP_DROPOP_PUSHBYTES_32 <OperatorPubKey>OP_CHECKSIG葉子 B：2-of-3 緊急脫錨花費條件
OP_PUSHBYTES_32 <pubkey1>OP_CHECKSIGOP_PUSHBYTES_32 <pubkey2>OP_CHECKSIGADDOP_PUSHBYTES_32 <pubkey3>OP_CHECKSIGADDOP_PUSHNUM_2OP_NUMEQUAL“葉子 A” 是 BitVM 實例中的常規取款報銷條件。在經過一段挑戰期（<SomeDelay>）之後，一個預先指定的運營者可以從橋接合約中取款。如果花費在橋接合約中鎖定的 UTXO 的運營者是不誠實的，一個瞭望塔可以在挑戰期內（也就是花費 BitVM 合約之後，<SomeDelay> 時間鎖過期之前的這段時間裡）挑戰他們，阻止不誠實的取款請求。
葉子 A 可被 N-of-N 預先簽名委員會構造的一筆預簽名交易花費。
另一方面，“葉子 B”，則是一個馬上生效的花費路徑，一個 2-of-3 多簽名裝置可以立即轉移 BitVM 合約中的所有資金。如果開發團隊在合約中發現一個可被利用的 bug，或者他們決定捐款潛逃，就可以這樣做。
當我說 “合約” 的時候，我指的總是掌管一個比特幣 UTXO 的花費條件的 BitVM 合約。
這兩個花費條件可以同時存在於一個橋接合約的 taproot 腳本樹上。雖然增加一個能夠繞過 BitVM 挑戰-響應 遊戲的花費條件並不總是合理的，但客觀上沒有什麼能夠阻止開發者實現這樣的花費條件。
而且，腳本樹上的花費條件可以是非常靈活的。在上述例子中，我們只展示了兩種花費條件。然而，開發團隊可以創造出包含了多種多樣花費條件的腳本樹。上面的葉子 B 就是一個例子：這種緊急更新機制沒有時延，可被 2-of-3 簽名人集合花費，導致用戶資金被盜。而更廣泛的協議升級可以由 9-of-12 的安全理事會發起，並且帶有時間鎖。
具體的設計在各個實現上可能有所不同，重要的是，我們得能夠驗證這些花費條件。現代比特幣腳本的一個 “問題” 在於，在一個腳本被花費之前，你是無法公開驗證它的。這跟基於 BitVM 的橋接合約嚴格相關，它意味著我們無法驗證所有的花費路徑，直到一個具體的葉子腳本被用來花費一個 UTXO 。請記住，當一個葉子被花費的時候，只有這個葉子所表示的花費條件會揭曉。所以，如果在我們的實例中，只執行了常規取款，那麼我們無法驗證是否存在一個緊急花費路徑；反之亦然。
這可能會帶來一個問題。如果開發團隊向腳本樹插入了一個緊急花費機制，但從不公開它，用戶可能永遠無法確定那裡沒有受許可的多簽名裝置（或者受許可的某一個人）可以花費鎖定在橋接合約中的所有資金。
想了一個星期以後，我得出了一些開發團隊可以揭曉橋接合約花費路徑的方法。
披露方法
直接在說明書中披露花費路徑
對於開發團隊來說，最簡單的辦法就是在說明書中公開具有特權的角色。開發團隊可以直接公開橋接合約的運營者、誰是參與預簽名儀式的人、誰是運行輕客戶端的人，以及誰是瞭望塔。
有一些披露，總好過沒有，但我們還是無法單純基於說明書網站上的生命來驗證橋接合約的花費路徑。如果能直接驗證腳本，那就更好了。
在存入資金之前先測試
開發團隊可以為不同的花費路徑發送測試交易。他們可以從一個給定的實例中花費一些資金，最終揭曉所有的花費路徑，而用戶也可以自己驗證花費路徑。
這要求開發團隊花費腳本樹上的每一個葉子。但即使如此，我們還是永遠無法確定他們不會插入從未揭曉過的額外花費條件。開發團隊總是可以選擇性不花費某個葉子、不揭曉器花費條件。這通常被當成 Taproot MAST 的一個特性，但在橋接合約的語境下，這會降低用戶對開發團隊事實上揭曉了所有花費腳本的信心。
不幸的是，測試交易不能提供我們期待的透明性。
利用大規模的限制條款模擬委員會
另一種辦法是，開發團隊利用一個足夠大的限制條款模擬委員會，並給予獨立參與者參與預簽名橋接合約交易圖內的所有交易的機會。這將給予獨立參與者驗證緊急多簽名存在性、其中有多少簽名人的機會。
但是，這依然要求用戶信任限制條款委員會的參與者，而不是讓他們直接驗證腳本。我會說，前進的道路在於，我們能夠給予任何用戶驗證橋接合約的花費路徑的機會。
創造一種標準化的披露方法
以我個人來看，我們應該期待開發團隊會公開他們為自己的 BitVM 實例創建的完整的腳本樹。
如果開發團隊提供了創建 tapscript 的內部密鑰、葉子腳本的完整集合以及對應的橋接合約地址，我們就可以自己動手了。
使用這些信息 —— 用來生成花費路徑的內部公鑰、從 taproot 腳本樹推導出來的默克爾根 —— 我們就能將他們相加、得出一個調整後的公鑰。如果這個調整後的公鑰跟 BitVM 橋接合約的地址相匹配，我們就驗證了該地址事實上只包含了這些花費腳本。
看！我們有了一種可以驗證的披露方法。如果一個開發團隊公開了不正確的 taproot 腳本樹，那麼調整後的公鑰就不會跟橋接合約的地址匹配。
這種披露方法讓我們能夠真正驗證跟一個 BitVM 橋接合約實例的關鍵信任假設。但是，它 需要 開發團隊公開整棵腳本樹以及相關的內部公鑰。
透明性的重要性
即使我們不披露簽名人的身份，我們依然需要腳本來理解真正的信任假設。這些系統被設計成帶有 1-of-N 誠實參與者信任假設。但如果信任假設最終會回落到一個受許可的多簽名裝置，把資金存進這些合約的用戶有權利知情。
我預計絕大部分基於 BitVM 的橋接合約都會包含這類緊急更新花費路徑。我希望這些橋接合約不會永遠帶有這樣的花費路徑，我們可以升級到更加信任最小化的設計。但是，我們不能當它們不存在，或者藉口說它們不是唯一的信任模式。
只要緊急花費路徑存在，它不折不扣就是信任模式本身。
（完）
