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

引言

现有的比特币交易使用 CheckMultiSig 验证 n-of-n 多重签名，导致需要在比特币区块链上发布与 de 交易中的签名者数量呈比例的签名和公钥。这种方法不仅揭示了交易参与者的总数，而且交易费会随着签名者数量的增加而增加。为解决该问题，在 2018 年，研究人员提出 Schnorr 多签协议：Musig。但是，该协议需要签名者之间进行三轮通信，用户体验相对较差，导致该协议未引起广泛关注与应用。

在 2020 年，随着 MuSig2 的推出，使得交互式签名取得了重大进展：将三轮通信**为两轮，为用户带来更好的体验。此外，MuSig2 允许一组用户共同生成单个签名和公钥来验证交易，提高了隐私性，并显著**了交易手续费。经过三年多的不断完善，Schnorr 多重签名（MuSig2）已经在钱包和设备上实现。

MuSig2 相关提案如下：

· 2022 年比特币 BIP-327: MuSig2 for BIP340-compatible Multi-Signatures

· 近期https://git**.com/achow101/bips/commits/musig2/，当前已合并到 Bitcoin BIP 库。

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、数字资产托管等应用需求，实现一鱼四吃。

MuSig2 原理与实现规范

MuSig2 原理

MuSig2 实现规范

近期，比特币核心贡献者 Andy Chow 提出几个 BIP 提案：

· BIP-328: Derivation Scheme for MuSig2 Aggregate Keys【应用层】：描述基于 BIP 327 MuSig2 aggregate public key，构建 BIP 32 extended public keys，并使用这些 BIP 32 extended public keys 进行密钥派生。

· BIP-373: MuSig2 PSBT Fields【应用层】：为 BIP174 Partially Signed Bitcoin Transaction (PSBT) 中的随机数、公钥和 partial 签名添加了字段。

· BIP-390: musig() Descriptor Key Expression【应用层】：提供一种由 MuSig2 钱包控制的交易输出的方法。

这是 MuSig2 被采纳和钱包集成的必要步骤。这些 BIP 和规范是集成 MuSig2 钱包所需要的**内容。此外，许多钱包开发者和协作托管解决方案（见Getting Taproot ready for multisig）长期以来一直要求对 MuSig2 协议进行标准化。现在，随着正式的 BIP 到位，社区可以自行审查、提供反馈并帮助提高认识。

MuSig2 一鱼四吃

铭文

铭文最典型的应用就是构造 BRC20，一种可以被看做为比特币上的 NFT 通证。其核心设计是通过 Ordinals 协议将数据刻录在每个聪上，并实现简单操作。总的来说，这里有三个步骤。

**步，追踪每个聪的**性。由于聪是比特币的**且不可分割的单位，且比特币总量为 2100 万，可用聪的上限为 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 **（即 tran**er 操作）需要两次交易。**个交易中，向发送者进行一次基本要求的链上刻录，这与铸造的操作非常相似。第二个交易中，另一笔交易完成了从发送者到接收者的转移。然后，链下索引器更新状态。如果条件满足，索引器会从发送者的余额中扣除相应金额，并记入接收者的余额。

我们可以观察到，Schnorr 签名已用于比特币的 Taproot 升级中，提升了比特币交易的隐私性和效率。升级版本的 Schnorr 多重签名（MuSig2）可以非常直观且自然的合并入 Taproot 升级的部分，并自然衔接如铭文和类似 BRC20 的创建过程中。新升级的铭文可以在现有基础上提高签名和验签速率，并且进一步减少在铸造过程中所需要的交易费。

另外一个应用来自于链下索引器部分。现行的索引器本质是链外验证者，不同的服务提供商提供各自的索引器更新服务。这里引起的风险来源于不可信，正如众多的侧链和 Rollup 服务提供商一样，用户无法对相对管理**化的服务提供商进行信任。即使这些索引器并不存贮用户的天然资金，但是错误报价或延迟报价将导致用户交易失败。MuSig2 提供了一种多签的思路。可以引入相对分散并且大量的验证者共同维护相同的索引器，每次在特定的节点进行共同验证打点签名，类似于 checkpoint 机制。用户起码可以信任在打点前的索引器诚实且可信地提交了链上铭文和交易流。这样，MuSig2 为链下索引器提供了必要的安全性，从而提升整体铭文生态的可靠性。

比特币质押

与以太坊等 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 中发挥更大的作用，从而为用户提供更多收益。

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 桥的安全性。

数字资产托管

聚合签名允许多个签名组合成一个签名，从而简化验证过程并提**率。如图 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 不出现。因此，实现门限签名与聚合签名耦合，同时满足多个应用需求。

参考资料

2021. MuSig2: Simple Two-Round Schnorr Multi-Signatures

2022. BIP-327: MuSig2 for BIP340-compatible Multi-Signatures

2020. BIP-340: Schnorr Signatures for secp256k1

2023. Forgery with a fake key in MuSig2

2023. BitVM whitepaper

2024. BitVM 2: Permissionless Verification on Bitcoin

2024. Chakra x Babylon Staking Testnet: Technical Overview & Security Analysis