门限签名介绍

介绍

门限签名（Threshold Signature Scheme，TSS）是数字签名的一个重要分支，它是一种基于安全多方计算（Secure Multi-Party Computation，MPC）的密码学技术。

门限签名系统中，首先会生成一个私钥，但是这个私钥不会发送给任何签名者。每个签名者只能拿到私钥的一部分。达到一定数量的签名者，能够代替整个签名组，对某条消息进行签名。但是一小部分签名者是无法进行签名的。

门限签名流程

生成公私钥。这里需要先定义 n（所有签名者的数量）和 t（门限值），至少 t+1 个签名者需要参与到签名中。所有参与门限签名的签名者一起生成一份公私钥。每个签名者获得一份相同的公钥和自己的一部分私钥。
签名阶段：对于一条公共的待签名的消息，每个签名者把自己的签名结果发送给一个中间管理者，把所有签名汇集起来得到真正的签名
验证阶段：使用公钥对签名进行验证，因为公钥是公开的，所以验证阶段不必进行多方计算。

用例

准备工作

TSS 开源库：https://github.com/ZenGo-X/multi-party-ecdsa/

gg18_sm_manager 管理服务端

gg18_keygen_client 秘钥生成客户端

gg18_sign_client 签名客户端

主要步骤

启动管理服务端。这里会启动一个监听服务器，用来协调各个签名者，包括生成公私钥，分发各部分私钥，收集签名。

首先配置 params.json 文件，配置 n 和 t。在 parties 个签名者中间，只要有 threshold+1 个签名者签名，就可以成功对消息进行签名。

{"parties":"3", "threshold":"1"}

然后启动进程：

./gg18_sm_manager

客户端生成自己的部分私钥。

使用三个客户端分别执行生成操作：

./gg18_keygen_client http://127.0.0.1:8000 keys1.store

./gg18_keygen_client http://127.0.0.1:8000 keys2.store

./gg18_keygen_client http://127.0.0.1:8000 keys3.store

客户端执行签名。

需要 t+1 个客户端执行签名，在本次示例中也就是 2 个：

./gg18_sign_client http://127.0.0.1:8000 keys1.store "Hello"

./gg18_sign_client http://127.0.0.1:8000 keys2.store "Hello"

一旦 t+1 方参数执行签名，协议会输出最终签名 (R,s)，至此整个流程执行完毕。

原理说明

参考 Multiparty Threshold ECDSA.pdf

这里主要介绍了多个参与者如何共同完成 ECDSA 门限签名，使用的是 GG18 方案。

协议特点

门限签名的优势。

高容错性：门限签名不会产生单点故障，各个签名者拥有一部分私钥，需要多个签名者一起做恶才会成功。
灵活性：在不更改公私钥的前提下，可以增加或者减少签名者，能够更好的对各部分私钥进行管理。
共享和分享：各部分私钥由不同人保管，任何时候各部分私钥不会聚合在一起，有效的分散了风险。
高效率：当各个签名者对消息完成了签名，多方计算就已经结束了。网络上各个节点能够对消息进行验证，因为公钥是公开的。而且各个签名节点不会暴露出来，也提高了安全性。门限签名支持 RSA, ECDSA, EdDSA 和 Schnorr 等加密算法。

门限签名与多签的区别

TSS 技术使我们可以用分布式计算代替所有签名命令，从而使私钥不再是单点故障。

与传统的多签不同，TSS 使用链下分布式多方计算技术，而多重签名发生在链上，这可能会消耗更多资源，并且多重签名的参与者会暴露在区块链中，并成为潜在的攻击点，总结如下：

安全性高：私钥会分割成多个私钥碎片再分享给多个参与方，且在签署交易的过程中，私钥也不会被重构。
可快速安装和签署：它比多签方案更加高效，因为 TSS 只有 1 个签名，而不是 n 个签名。
可保证找回：特殊情况下，可通过“重新共享”流程来找回您的私钥，即重新共享私钥。之前的共享将失效。

使用场景

如果没有 MPC-TSS，私钥通常存储在一个地方；在热钱包（连接到互联网）或冷存储（离线）中。这会造成“单点故障”，这也是黑客无法抗拒的目标。

MPC-TSS 可以消除这个致命弱点。

使用门限签名方案，可以在私钥中创建和分发独立持有的份额，这样没有一个人可以完全控制私钥。

私钥材料中的这些份额分布在运行多方计算协议的节点之间。因此，我们可以说不存在完整的、单独的私钥——只有由不同人控制的分布式共享，分布在多个节点上。

当需要对交易进行签名时，不是调用单个私钥，而是触发 MPC 过程，每个独立节点以分布式方式合作签署交易。

这种集体的、去中心化的数字签名被呈现给底层区块链网络并验证交易——就像“传统”私钥所做的那样。

MPC 的问题

分发敏感的私钥碎片是不够的。

如果 MPC 节点是集中式的并且受单个组织的控制，则资产仍然容易受到内部勾结或外部黑客的攻击。如果确定资产治理的策略引擎在易受攻击的数据库中运行，并且私钥材料位于可破解的硬件中，则这种情况更有可能发生。

除非 MPC 节点是真正分布式的，否则分布式签名过程只是去中心化的剧院，所有信任都放在控制节点的集中式 MPC 提供商，并且可能会审查交易或屈服于内部勾结。

MPC 钱包、智能合约钱包与账户抽象

MPC 钱包，是通过对私钥进行多方计算在链下实现“多签“等复杂的验证方式。将一个私钥打碎成多片，将私钥碎片交与多方进行计算和加密。当需要私钥签名时，则将多方碎片再拼接起来形成一个完整的私钥。MPC的核心思路为分散控制权以达到分散风险或提高备灾的目的，有效避免了单点失败等安全问题。

智能合约钱包，是在智能合约中定义了验证逻辑，比如如果需要验证一笔交易，需要五个中至少三个私钥提交签名进行验证，这就是智能合约钱包的一种——多签钱包。

MPC 钱包“多方参与”的概念与“多签钱包”有些类似，但实际上，虽然都可以实现“多签”的功能，二者的实现途径是不一样的。

MPC 钱包，是将一个私钥分解成多个片段，验证过程只涉及到一个私钥。并且计算网络是链下的，与智能合约并无联系。

账户抽象，可以将外部账户和合约账户抽象，使外部账户与合约账户相“结合”，通过智能合约赋予外部账户更加复杂的逻辑。应用账户抽象的钱包也属于智能合约钱包。

之前我们所熟知的多签钱包，比如 Gnosis Safe 等等，属于智能合约钱包，但因为这些智能合约是自定义的，缺乏统一的行业标准，且存在合约漏洞以及与其他合约兼容性等等问题未获得广泛的应用。应用账户抽象的智能合约钱包一定程度上解决了这个问题，能够实现的功能也不止“多签”这一个场景。

MPC 钱包、智能合约钱包的对比

这两种解决方案哪一种更好呢？我们认为二者是互补的方案，因为 MPC 钱包和智能合约钱包本质上不在同一个层面解决问题。MPC 钱包是链下方案，既可以控制基于外部账户的普通钱包，也可以控制智能钱包。二者各有用例，并不冲突。

MPC钱包作为链下方案，并不涉及到以太坊共识层或合约层的改动，用户的使用成本更低，且在短期内更具可行性。此外，在一些特殊的使用场景比如跨链密钥等更具优势。智能合约钱包是以太坊的系统性升级，可以给用户带来更多全新的体验和用例。但账户抽象是一个需要“兴师动众”的大工程，要求其他智能合约、开发者、以及以太坊架构都配合升级。过大的实操难度使从2015年就提出的愿景到今天也没有完全落地。而智能合约钱包对于用户而言，最直接的问题就是钱包的使用成本将会提升，从创建钱包开始就需要支付费用。

我们认为，应用账户抽象的智能合约钱包是最终愿景，MPC是短期内的热点方案，且在一些特殊场景更具实施优势，且两种方案并不完全冲突，可以互补使用。智能钱包在以太坊主网实现的可行性和可能性都较低，可以更多关注 Layer2 上的账户抽象和智能钱包进展。

jinCN / tss-research