MuSig2 与 FROST：链上看不见的多方比特币保管

两种”多签”根本不同

比特币里常被统称为”多签”的东西其实是两种协议。第一种把规则写进脚本：2-of-3 这类门槛以 OP_CHECKSIGADD 或老 OP_CHECKMULTISIG 的形式公开在链上，花费时链上能看到三个公钥和逐个补齐的签名。第二种把规则藏进密钥聚合：以 MuSig2（BIP-327）为代表，参与方先把各自公钥聚合成一个普通公钥，链上只有一个密钥、最后只出现一个签名字节数的联合签名。第一种叫门限/多重签名，第二种叫多方联合签名，隐私与体积差别都从这里来。

MuSig2 怎么运作

MuSig2 是 n-of-n 方案：所有人必须到场，没有缺席路径。流程分两段——第一段各签名者广播自己的临时承诺（每个签名者两个椭圆曲线点），聚合后得到联合承诺；第二段各自基于聚合公钥、联合承诺与消息计算部分签名，收齐后拼成一个对外的 BIP-340 签名。对外界来说，这个签名和单人 Schnorr 签名在字节层面无法区分。聚合环节有个不能跳的技术细节：每个参与公钥要先乘一个基于上下文（公钥集合与聚合者公钥）哈希出的系数，再做加法。这一步针对的是”恶意公钥攻击”——不加系数扰动，攻击者提交精心构造的公钥即可在协议交互中偷学私钥信息。规范与 libsecp256k1 的 musig 模块把这套扰动顺序、密钥排序、会话状态机都写死了，实现者不应自行”优化”。

与 FROST 的边界

常被并列提起的 FROST 是 t-of-n 门限方案：任何 t 人凑齐即可出签名，其余人永久缺席也不锁死资金。差别不在加密强度，在信任模型。MuSig2 没有”策略层”：少一个人到场，资产就花不动，必须所有密钥持有者协作，或者事先用 Taproot 脚本路径补一条备用出口。FROST 的代价是更复杂的两轮签名协议、签名者集合变化时的密钥resharing流程，以及”每 t 人一个小圈子”这个策略在链上不可见带来的验证盲区——链不知道也不关心你们约定的 t 是多少，出事只能对内部。工程上两者并不互斥：MuSig2 因为只出现在链上密钥层面、审计面小，常被优先用于 2-of-2 这类结构（例如一方是客户一方是服务商的联合保管），t-of-n 需求更重的机构则更多评估 FROST 路线。

链上形态决定谁在看门

回到链这一侧：MuSig2 输出的链上足迹”本质上就是一个 BIP-340 公钥加一个协同签名”，BIP-327 明确用它替代 OP_CHECKSIGADD 实现的 n-of-n，因此签名者数量 n 不受共识规则限制。这带来一个反直觉的好处：将来加人、减人（只要配合 Taproot 的密钥调整或脚本路径迁移），链上历史看起来仍是”单密钥进、单签名出”，与任何普通用户的花费不可区分。而脚本式多签在链上永远是自报家门的：扫到脚本就能看到你们的人数和门槛——这本身就是一种隐私泄露，也是聚类分析的抓手。

落地清单

自托管读者核对四条：其一，任何声称 MuSig2 的钱包/服务必须能出示其使用的 secp256k1 musig 实现与版本，没有公开实现的”多方签名”不轻信；其二，n-of-n 方案必须有可演练的恢复路径（每把密钥的备份、以及至少一名参与方失联多年后的处置预案），因为协议层没有兜底；其三，把密钥聚合与脚本门限混着宣传的服务值得追问”链上到底看到什么”，答案应当能用一句字节结构描述；其四，任何涉及真实资产的方案先在小额上跑一次完整的”参与方各到场一次签名”演练。本文只做机制说明，不构成任何投资建议。