本文介紹了 BIP-327 MuSig2 多簽協議在當下最火四領域（Inscription, Restaking, BitVM co-sign, Custody）的應用。

原文：BIP-327 MuSig2 in Four Applications: Inscription, Bitcoin Restaking, BitVM Co-sign, and Digital Asset Custody

作者： Qin Wang (CSIRO), Cynic (Chakra), mutourend (Bitlayer), lynndell (Bitlayer)

出品：Bitlayer 研究小組

1. 引言

現有的比特幣交易使用 CheckMultiSig 驗證 n-of-n 多重簽名，導致需要在比特幣區塊鏈上發布與 de 交易中的簽名者數量呈比例的簽名和公鑰。這種方法不僅揭示了交易參與者的總數，而且交易費會隨著簽名者數量的增加而增加。為解決此問題，在 2018 年，研究人員提出 Schnorr 多簽協議：Musig。但是，該協議需要簽名者之間進行三輪通信，用戶體驗相對較差，導致該協議未引起廣泛關注與應用。

在 2020 年，隨著 MuSig2 的推出，使得互動式簽名取得了重大進展：將三輪通訊降低到兩輪，為用戶帶來更好的體驗。此外，MuSig2 允許一組用戶共同產生單一簽名和公鑰來驗證交易，提高了隱私性，​​並顯著降低了交易手續費。經過三年多的不斷完善，Schnorr 多重簽名（MuSig2）已經在錢包和設備上實現。

MuSig2 相關提案如下：

Bitlayer 與 Chakra 研究小組發現，隨著銘文、比特幣質押、BitVM 和數位資產託管的繁榮，BIP-327 MuSig2 極具應用潛力，理論上支持無限數量的簽署者參與交易，可節省鏈上空間、降低手續費、提高安全性、隱私性和可操作性等。

銘文：銘文是將客製化內容寫入比特幣的聰（satoshi）進行銘刻。由於其能夠直接在區塊鏈上創建不可篡改和可驗證的資訊記錄，使得這一概念得到了廣泛關注。銘文可以從簡單的文字到複雜的資料結構，提供了一種可靠的方法來認證數位資產的真實性和來源。區塊鏈銘文的永久性和安全性使其在數位身份驗證、所有權證明和關鍵資訊的時間戳等應用中有較高的應用價值。對於銘文，MuSig2 能夠提高簽名和驗簽速率，減少在鑄造過程中所需的交易費，並為鏈下索引器提供了必要的安全性，從而提升整體銘文生態的可靠性。

比特幣質押：比特幣持有者重新分配其質押資產，從而支援各種區塊鏈協議或去中心化金融（DeFi）應用的機制。這個過程允許比特幣在區塊鏈生態系統中發揮多種作用，增強其實用性和收益潛力。透過參與重質押，用戶可以為其他網路的安全性和功能做出貢獻，同時保持其比特幣持有量。這種創新方法利用了比特幣的流動性和安全性，推動了更整合和高效的區塊鏈經濟。由於比特幣缺乏實現流動性質押所需的合約能力，且 UTXO 架構也無法較好地相容於質押代幣任意麵額提款功能。因此，需要 MuSig2 實現比特幣的流動性質押。

BitVM：在比特幣網路上實現智慧合約功能的框架。與原生支援複雜智能合約的以太坊虛擬機器（EVM）不同，BitVM 旨在擴展比特幣的腳本功能，以便進行更複雜的可編程交易。這項發展為比特幣的去中心化應用（dApps）和複雜金融應用程式開闢了新的道路，突破了其簡單腳本語言的限制。 BitVM 的引入，標誌著比特幣實用性的重要進化，在比特幣和其他更靈活的智慧合約平台之間架起橋樑。在不需要軟分叉的情況下，BitVM 需要預簽，從而實現 1-of-n 信任假設以及 permissionless 挑戰功能。為讓信任假設盡可能小，需讓 n 值盡可能大。但是，現有 CheckMultiSig 腳本驗證大規模多簽，需要極高的交易費，導致不可行。 MuSig2 可讓 n 值盡可能大，使得 n 的取值不受限於比特幣區塊以及 stack size 限制，而取決於實際可協調的 cosigner 數量限制，且費用低。

數位資產託管：使用區塊鏈安全儲存和管理數位資產，如加密貨幣、NFT（非同質化代幣）和其他代幣化資產。這涉及保護私鑰、確保存取控制以及提供網路威脅的防護。門限簽章在數位資產安全管理中起著關鍵作用，它透過分散式的方式實現加密金鑰的管理。這種技術將私鑰分成多個份額，並分發給不同的參與者。要簽署交易或存取數位資產，必須將預定門限數量的份額結合起來，確保沒有單一一方可以單方面控製或濫用資產。這透過減輕金鑰外洩、內部威脅和單點故障的風險來增強安全性。此外，門限簽章為數位資產管理提供了更穩健和靈活的治理模型，允許在去中心化組織和多方系統中進行安全的協作和決策。將門限簽名與 MuSig2 結合，能夠同時滿足銘文、比特幣質押、BitVM co-sign、數位資產託管等應用需求，實現一魚四吃。

2. MuSig2 原理與實作規範

2.1 MuSig2 原理

2.2 MuSig2 實作規範

近期，比特幣核心貢獻者 Andy Chow 提出幾個 BIP 提案：

這是 MuSig2 被採納和錢包整合的必要步驟。這些 BIP 和規格是整合 MuSig2 錢包所需的全部內容。此外，許多錢包開發者和協作託管解決方案（請參閱 Getting Taproot ready for multisig）長期以來一直要求對 MuSig2 協定進行標準化。現在，隨著正式的 BIP 到位，社群可以自行審查、提供回饋並幫助提高意識。

3. MuSig2 一魚四吃

3.1 銘文

銘文最典型的應用就是構造 BRC20，一種可以被看做成比特幣上的 NFT 通證。其核心設計是透過 Ordinals 協定將資料刻錄在每個聰上，並實現簡單操作。總的來說，這裡有三個步驟。

第一步，追蹤每個聰的唯一性。由於聰是比特幣的最小且不可分割的單位，且比特幣總量為 2,100 萬，可用聰的上限為 2.1 千萬億。在比特幣中的每個聰都是一個獨特的存在，具備唯一性，這正是在比特幣上建立 NFT 的底層邏輯。這裡每個聰都將被賦予一個順從序號（透過 Ordinals 協定），並以先進先出的方式管理，以確保精確追蹤和有序處理。 如圖，我們看到每個聰都是完整順序序列的一部分，範例中顯示的是聰 #1、#11 和 #31。

第二步，利用 JSON 格式和 Taproot 腳本將訊息​​嵌入聰中。這些訊息儲存在 SegWit 欄位中，使得流程高效且安全。腳本將 JSON 嵌入聰中，即 OP 欄位內。 OP_IF 開始條件判斷，而嵌入的內容將安排在 OP_FALSE 欄位後，條件確保後續內容不會被執行，僅作儲存。因此，剛嵌入的 JSON 完整的保存在了這枚聰上。圖 1 所示的 JSON 嵌入內容包含部署 BRC20 代幣的關鍵參數。它指定了協議為 “brc-20”，操作類型為 “部署”，代幣符號為 “ordi”，最大供應量定為 2100 萬，鑄造限額為 1000。這裡，支援此流程的關鍵 BIP 包括 Schnorr Signature (BIP340)、Taproot (BIP314) 和 Tapscript (BIP342) 以及 SegWit (BIP141)。

第三步，識別 BRC20 代幣涉及由索引器管理的鏈下狀態。這些索引器根據歷史交易解析並解釋 BRC20 代幣的狀態。它們解析鏈上數據，檢查代幣狀態，並更新餘額，確保資訊是最新的。此外，輕客戶端整合了這些訊息，使用戶能夠無縫識別和管理他們的 BRC20 代幣。

圖 1. BRC20 代幣的關鍵步驟

這裡，部署和鑄造操作只需要一次交易，而轉移 BRC20 代幣（即 transfer 操作）需要兩次交易。在第一筆交易中，向發送者進行一次基本要求的鏈上刻錄，這與鑄造的操作非常相似。在第二筆交易中，另一筆交易完成了從發送者到接收者的轉移。然後，鏈下索引器更新狀態。如果條件滿足，索引器會從發送者的餘額中扣除相應金額，並記入接收者的餘額。

我們可以觀察到，Schnorr 簽章已用於比特幣的 Taproot 升級中，提升了比特幣交易的隱私性和效率。升級版的 Schnorr 多重簽章（MuSig2）可以非常直觀且自然的合併入 Taproot 升級的部分，自然銜接如銘文和類似 BRC20 的創建過程中。新升級的銘文可以在現有基礎上提高簽名和驗簽速率，並且進一步減少在鑄造過程中所需的交易費用。

另外一個應用來自於鏈下索引器部分。現行的索引器本質是鏈外驗證者，不同的服務提供者提供各自的索引器更新服務。這裡引起的風險來自於不可信，正如眾多的側鍊和 Rollup 服務提供者一樣，使用者無法對相對管理中心化的服務提供者進行信任。即使這些索引器不會存貯用戶的天然資金，但錯誤報價或延遲報價將導致用戶交易失敗。 MuSig2 提供了多籤的想法。可以引入相對分散且大量的驗證者共同維護相同的索引器，每次在特定的節點進行共同驗證打點簽名，類似於 checkpoint 機制。用戶起碼可以信任在打點前的索引器誠實且可信地提交了鏈上銘文和交易流。這樣，MuSig2 為鏈下索引器提供了必要的安全性，從而提升整體銘文生態的可靠性。

3.2 比特幣質押

與以太坊等 PoS 鏈有原生的質押機制不同，比特幣是由 PoW 共識機制維護的區塊鏈，需要透過額外的機制實現質押功能。目前，最廣為人知的是 Babylon 提出的比特幣質押方案。

在 Babylon 質押機制中，使用者透過 Babylon 定義的 BTC 質押腳本完成質押，稱為質押交易，產生質押輸出。質押輸出是一個 Taproot 輸出，內部金鑰透過設定為 NUMS 點停用，有三個可用的腳本路徑，實現質押功能。分別是：

  • 時間鎖路徑：實現質押的鎖倉功能；
  • 解質押路徑：實現提前結束質押功能；
  • 罰沒路徑：實現作惡時系統的懲罰功能。

比特幣質押機制為比特幣持有者提供了一個較安全的生息方案，提升了比特幣資產的效用。但是，這種質押在一定程度上損害了比特幣的流動性。但是，以太坊質押機制的多年探索為比特幣質押探明了道路，可以使用流動性質押解決該問題。

流動性質押引入了新的角色，即資產的託管方。用戶將資產存入流動性質押項目的託管地址，以獲得對應比例的流動性質押代幣（Liquid Staking Token, LST）。流動性質押專案將收集到的資產進行原生質押，LST 的持有者自動分享質押收益。此外，LST 持有者可以直接在二級市場交易 LST，或燃燒 LST 以換回原生的質押資產。

以太坊上的流動性質押可以透過智能合約來實現。但是，比特幣缺乏實現流動性質押所需的合約能力，且 UTXO 架構也無法較好地相容於 LST 任意麵額提款功能。目前，由於 OP_CAT 等契約操作碼未上線，因此無法有效地對比特幣交易輸出的未來花費方式實施限制。因此，需要 MuSig2 來實現比特幣的流動性質押。

如圖 2 所示，在 Chakra 流動性質押中，用戶首先將比特幣轉入由 MuSig2 支援的多簽地址。該事件被索引器捕獲，並調用鏈上合約，為用戶鑄造 ckrBTC。多簽地址中的比特幣會質押入 Babylon。用戶在持有 ckrBTC 的同時，也能夠持續獲得 Babylon 質押的收益。當用戶想要結束質押，可以銷毀 ckrBTC，索引器偵測到銷毀事件後，進行解質押操作，將比特幣回饋給用戶。此外，用戶也可以直接在二級市場交易，將 ckrBTC 換成比特幣。

圖 2. Chakra 流動性質押流程

與自託管質押相比，MuSig2 支援的流動性質押，引入多個參與者維護數位資產託管的安全性，且同時釋放了質押比特幣的流動性，讓 LST 能夠在 BTCFi 中發揮更大的作用，從而為用戶提供更多收益。

3.3 BitVM Cosign

Robin Linus 2023 年 10 月發布 BitVM: Compute Anything on Bitcoin 白皮書，使用 Lamport 一次性簽名實現了有狀態的比特幣腳本。該系統可在不引入新操作碼等軟分叉的情況下，透過樂觀挑戰機制實現圖靈完備的比特幣合約。該系統僅使用 OP_BOOLAND 和 OP_NOT 操作碼構建的 NAND 閘二進位電路，展示了在比特幣上驗證任意計算的挑戰機制，但是程式編譯出的電路規模龐大，幾乎不可實際應用。隨後，BitVM1 使用 RISC-V 指令表達程序，充分利用比特幣系統中所有的操作碼，以提高效率。

BitVM2 對 BitVM1 進行了兩方面擴充。（1）BitVM1 中的挑戰者是參與初始設定的聯盟成員，而 BitVM2 中的挑戰者是任意參與者。因此，BitVM1 中聯盟成員有串謀作惡的風險，而 BitVM2 的挑戰者是 Permissionless 的，聯盟成員無法串謀作惡。（2）BitVM1 需要多輪挑戰，週期較長，而 BitVM2 充分利用了 ZK Proof 的簡潔性以及 Taptree 的腳本表達能力，挑戰週期僅 2 輪，將 peg-in 時所需預籤的交易數由約 100 筆降低到了約 10 筆。具體而言，BitVM1 需要使用二分法，經過多輪交互，找到程式中錯誤執行的 RISC-V 指令；而 BitVM2 驗證的不再是程式自身，而是驗證程式執行正確的 ZK proof，BitVM2 會把 ZK 驗證演算法切成多個子函數，每個子函數對應一個 Tapleaf。當被挑戰時，Operator 需揭露各個子函數的值，若有不一致之處，任何人都可發起 Disprove 交易對其進行懲罰。

如圖 3 所示，BitVM2 需要大量的 n-of-n 預簽。由於用戶不知道哪個 Operator 會為其墊付，所以在發起 Peg-in 交易之前，需要 BitVM 聯盟對 Take1, Take2, Assert, Disprove 和 Burn 這 5 個交易進行 n-of-n 預簽。用戶只有確認各子孫交易預簽完畢後，才會將資金真正透過 Peg-in 交易存入 n-of-n 多簽控制地址。當用戶想要出金時，可發起 Peg-out 交易，其中一個 Operator 為其墊付，則能完成出金。

Operator 需要質押 2 個 BTC，才可以報銷墊付的比特幣。如果無人挑戰，則 Operator 可透過 Take1 交易成功報銷。如果 Operator 作惡，任何人眾籌 1BTC 後即可發起挑戰。面對挑戰，如果 Operator 不回應，則執行 Burn 交易，即銷毀 1.9BTC，且剩餘的 0.1BTC 給發起 Burn 交易中的接收位址；如果 Operator 回應，即執行 Assert 交易。

  • 情況 1：某子函數值揭露不一致，則任何人可發起 Disprove 交易，即銷毀 1BTC，且 1BTC 給發起 Disprove 交易中的接收地址。
  • 情況 2：子函數值揭露一致，則 2 週後，Operator 可透過 Take2 交易成功報銷。
圖 3. BitVM 2 流程

在 BitVM2 系統中，需要 BitVM 聯盟對 Take1, Take2, Assert, Disprove 和 Burn 這 5 個交易進行 n-of-n 預簽。 BitVM 信任假設為 1-of-n，其中 n 值越大，則信任假設越低。但是，如此龐大規模的多簽需要極高的手續費，導致在比特幣上幾乎不可行。 MuSig2 能夠將大量的多簽聚合為一個簽名，將手續費降到最低，且理論上支持的 n 值無限大，具體取決於實際可協調的 cosigners 數量，如 n 值為 1000 甚至更大。

BitVM 部署時，為防止 BitVM 聯盟透過 n-of-n 多簽共謀花費，在 Peg-in 設定完成之後，要求 n 個 cosigners 中至少有一個 cosigner 刪除私鑰。這使得 BitVM 橋中的資金只能透過 Operator 誠實墊付後，使用報銷交易進行花費。因此，提高了 BitVM 橋的安全性。

3.4 數位資產託管

聚合簽名允許多個簽名組合成一個簽名，從而簡化驗證過程並提高效率。如圖 4 所示，Alice 使用完整私鑰 KeyA 產生簽署 SigA，Bob 使用完整私鑰 KeyB 產生完整簽章 SigB。然後將 SigA 與 SigB 聚合，產生聚合簽章 AggSig。這種方式不僅確保了每個參與者的獨立性和責任，還增強了整體系統的安全性，因為需要雙方的參與才能進行任何授權操作。透過這種協作，Alice 和 Bob 能夠實現更安全、更有效率的數位資產管理，防止單點故障和惡意操作，同時簡化了交易的複雜性和驗證成本。

另一方面，Alice 使用門限簽名，使用分散式設備產生和管理數位簽名，而任何單一設備無法擁有完全的簽名能力。具體而言，門限簽章方案將私鑰分割成若干片，每個裝置都儲存一片私鑰。當且僅當一定數量的設備（即達到門限值）合作時，才能產生有效的簽章。該機制極大地提升了數位資產的安全性，因為即使部分私鑰分片洩露，攻擊者仍然無法產生有效的簽名。此外，門限簽章還能防止單點故障，確保系統的穩健性和持續性。因此，門限簽名為分散式管理數位資產提供了高效、安全的解決方案。

圖 4. 聚合簽名，門限簽名

當 Alice 與 Bob 均使用門限簽名進行各自的數位資產進行管控，且需要使用聚合簽名（MuSig2）對某筆交易進行多重簽名，如上述銘文、比特幣質押、BitVM co-sign 等應用。此情況下，需要將聚合簽名與門限簽名結合，實現一魚多吃。

圖 5. 聚合簽章與閘限簽章耦合

如圖 5 所示，當 Alice 與 Bob 使用門限簽章進行數位資產託管，則完整私鑰 KeyA 與 KeyB 均不出現，而僅出現對應的私鑰分片，分別為 (ShareA1, ShareA2, ShareA3) 和 ( ShareB1, ShareB2, ShareB3)。此時，基於私鑰分片 (ShareA1, ShareA2, ShareA3) 和 (ShareB1, ShareB2, ShareB3) 分別執行門限簽名，分別產生簽章 SigA 和簽章 SigB。然後將簽章 SigA 與簽章 SigB 聚合，產生聚合簽章 AggSig。整個過程中，完整私鑰 KeyA 和 KeyB 不出現。因此，實現門限簽章與聚合簽章耦合，同時滿足多個應用需求。

參考資料

  1. 2021. MuSig2: Simple Two-Round Schnorr Multi-Signatures
  2. 2022. BIP-327: MuSig2 for BIP340-compatible Multi-Signatures
  3. 2020. BIP-340: Schnorr Signatures for secp256k1
  4. 2023. Forgery with a fake key in MuSig2
  5. 2023. BitVM whitepaper
  6. 2024. BitVM 2: Permissionless Verification on Bitcoin
  7. 2024. Chakra x Babylon Staking Testnet: Technical Overview & Security Analysis

免責聲明：作為區塊鏈資訊平台，本站所發布文章僅代表作者及來賓個人觀點，與 Web3Caff 立場無關。文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。

欢迎加入 Web3Caff 官方社群：X(Twitter)账号丨微信读者群丨微信公众号丨Telegram订阅群丨Telegram交流群