MuSig2：Schnorr 的多签名

作者：Popeller

来源：https://popeller.io/schnorr-musig2

比特币以往的多签名合约，（在使用时）都要求在交易的一个输入中使用多个签名。有了 Schnorr 签名之后，事情就不同了。得益于 Schnorr 签名的线性数据，我们可以将来自多个参与者的签名碎片组合起来，成为一个签名，然后放到交易的输入中。因此，交易的输入将只包含一个签名，而且验证者也无法分辨这到底是一个普通的单签名，还是多个签名聚合而成的签名，又或者是别的。这可以降低交易的体积并提高验证效率，（长期来看）也能提升隐私性，因为越来越多用户会开始使用 taproot。

近年来，最有前景的 Schnorr 多签名协议就是 MuSig2，由 Jonas Nick、Tim Ruffing 和 Yannick Seurin 在这篇论文中提出。所以我们就来看看这篇论文。我假定读者都熟悉 Schnorr 签名，如不熟悉，我前一篇文章有述。

多签名 vs 门限签名

MuSig2 是一个 多签名 协议，也就是 n 个参与者要集体参与（n-n）的协议。要花费一个输出的时候，n 个参与者都必须提供自己的签名。不应将它与 门限签名 协议相混淆，因为门限签名是 t-n 的，n 个潜在的签名者中只要任意 t 个签名者提供了自己的签名，即可产生有效的签名。

“多签名（multisig 或 multi-signature）” 一词在比特币世界中通常包含了门限签名和多签名两者，这可能是因为原来，这两种签名（在比特币中的实现）都使用了同一个 OP_CHECKMULTISIG[VERIFY] 脚本代码 1。不过，有了 Taproot，我们可以用新的方法来实现多签名（MuSig2）和门限签名（FROST），所以区别它们并使用正确的术语就变得更重要了。

MuSig2 一瞥

假设 Alice 和 Bob 想要在一个共同控制的比特币地址中接收比特币，他们可以使用 MuSig2 来生成一个地址，流程如下：

他们各自生成三个随机数：一个私钥和两个 nonce。他们各自计算出这三个随机数对应的椭圆曲线点，结果就是一个公钥和两个 nonce 承诺。他们都把这三个点分享给对方。

使用在彼此间公开的公钥数据，他们可以计算出一个共有的公钥 P，这个公钥就同时表示了他们俩的公钥。公钥 P 即可用来生成一个 Taproot 地址，可用来接收任何想发给 Alice 和 Bob 的资金。假设某人发送了 1 BTC 到该地址中：

现在，假设 Alice 和 Bob 想要花费这个输出，把这 1 BTC 发给地址 Q。Alice 或 Bob 可以创建一个未签名的交易来花费前面提到的那笔交易：

然后，他们需要集体签名这笔交易。流程大略如下：

他们计算出一个共同的 nonce 承诺值 R以及各自的响应值（签名碎片） s1和 s2，最终的签名就是 (R,s)=(R,s1+s2)。我们来仔细看看这里的两个步骤：公钥生成和交易签名。

$$创建共有公钥

上一节介绍的第一步是创建一个共有的公钥，并以此生成一个 taproot 地址。我们详细分解一下 Alice 要做什么（Bob 也做一模一样的事）：

Alice 生成了自己的公钥 P1和两个 nonce 承诺值 R′1和 R′′1，她也收到了来自 Bob 的对应的三个值 P2,R′2,R′′2。然后，她就能创建共有公钥 P：

共有公钥 P是 P1和 P2的线性结合。注意，两项的系数 ai是不同的 2，因为被哈希的数值中使用了不同的 Pi。这些系数是用来缓解 密钥取消攻击（Key Cancellation Attack）（常用名 “Rogue Key Attack”）的，这种攻击是说，Alice（先收到对方公钥的一方）可通过选择自己的公钥，使得日后无需 Bbo（对方）的参与就能创建有效的签名。我可能会写一篇文章来讲解这个题目，但现在我建议你阅读 Pieter Wuille关于这个主题的文章。

虽然 Alice 和 Bbo 交换了 nonce 承诺，这个阶段他们用不上它。nonce 承诺是日后需要签名交易的时候使用的。提前交换这些 nonce 承诺值，是为了在日后节省一轮通信。我们是在交换公钥时附带交换了 nonce 承诺。你也可以后面再交换 nonce 承诺（而且有些人认为正应该这么做 3 ）。Alice 使用公钥 P生成了地址 4，接下来这个地址就可以交给支付者、用来接收资金了。

签名花费交易

再来看看 Alice 和 Bob 要如何合作来花费这个输出。我们照样从 Alice 的角度来理解：

基于他们所有的 4 个承诺（以及公钥 P和待签名消息 m），他们都计算一个标量 b以及一个共用的 nonce 承诺值 R，以及一个挑战哈希值 e：

这个过程里面发生了很多事。我们的目标是让 Alice 和 Bob 能够一致使用同一个 nonce 承诺值 R，并创建他们各自的响应值 s1和 s2，最终产生一个共同的签名。为了实现这个目标，我们需要 b和 e。

他们先是用双方的 nonce 承诺值计算出标量 b，然后又使用这个标量来生成 Alice 两个 nonce 承诺值得线性和 R1=R′1+bR′′1（对 Bob 的两个 nonce 承诺值也作如此处理）。然后，这两个结果被加在一起，形成共同的 nonce 承诺值 R。这个 nonce 承诺值后面将用来生成最终的签名。

现在，轮到 Alice 来创建她的响应值 s1了（Bob 会以类似的方式生成 s2）：

注意，Alice 的最终 nonce 值 r1是其初始 nonce 值 r′1和r′′1的线性和，这个线性和反映了上面 R1的计算方式。

Alice 和 Bob 交换 s1和 s2，然后他们各自都可以生成一个有效的签名 (R,s)=(R,s1+s2)。这个签名可以放到交易的见证数据中，然后这个交易就可以广播出去了。

但这一套真的行得通吗？

Alice 和 Bob 做了许多花里胡哨的操作来生成这个签名。我们来看看这个签名是不是真的有限。Schnorr 签名的验证函数是：

那我们就来推导一下等式是否成立：

看起来这个签名对正确的私钥集合（ p1和 p2）是有效的。但，我们怎么知道错误的私钥组合无论如何都只能生成出无效的签名、以及签名不可能以其它的方式伪造呢？所有这些问题都在 MuSig2 论文里面有证明，但我不能说完全理解了他们给出的证明，所以我无法验证这个方案的安全性。所以一定程度上，我得信任他们。

结论

MuSig2 比传统的、使用 OP_CHECKMULTISIG[VERIFY] 实现的多签名方案更复杂，但从验证效率、隐私性和交易的体积角度来看，这些额外的复杂性是值得的。我预计还要很长的时间才能看到它在比特币钱包中的实际实现，甚至我也不确定 MuSig2 会成为大家首选的协议。迄今为止，MuSig2 没有什么竞争者，但可能 FROST（一种用于门限签名的协议）可能会用作多签名设定。我还不知道那是不是做得到，但我会在后续的文章中探讨。

（完）