MPC 钱包与多签的对比
MPC 钱包与多签钱包给出的标题是同一个：没有单点可攻破。两者都做到了。但它们走的是不同的路，而不同的路在事情出错时会带来不同的后果——而那正是一个安全模型唯一真正要紧的时刻。
本文是技术上的正面对照。若你想先看自我保管选择的全景，自我保管方案对比覆盖了整个领域，包括硬件钱包与单纯的助记词。
对同一个问题的两种不同答案
两者对问题的陈述完全一样：一个秘密掌控一切是不可接受的，因此要把权限分散开。
MPC 把密钥拆开。 概念上仍只有一把私钥，但它从不在任何地方被拼合起来。取而代之的是，它的分片分散在不同地方，而一套密码学协议让这些分片协作产出一个签名，且没有任何一方得知完整密钥。
多签要求多把密钥。 这里确实存在若干把彼此独立的私钥。地址编码了一条规则——这些密钥中的若干把必须签名——而区块链在验证交易时强制执行该规则。
这个区别听上去很学术。其实不然。一个是关于密码学的事实，另一个是关于区块链的事实。链上知道什么，决定了系统某个部件失效时会发生什么。
MPC 实际上如何运作
MPC——多方计算，在此语境下通常指门限签名方案——让多方在各自只持有签名密钥的一个分片的前提下，共同就一条消息计算出签名。若你想要形式化的处理，NIST 维护着一个门限密码学项目。
其输出是一个单一而普通的签名。在链上，MPC 钱包的交易与某个人用一把密钥签出的交易毫无二致。这有真实的好处：它在每条链上都能用，成本与单签交易相同，而且不会向任何观察链上的人透露你的安全安排。
同一性质带来的后果，正是需要小心的地方。因为链看到的是一个普通签名，链对你的策略也就什么都不强制。存在几个分片、由谁持有、需要几个协作，这些都是关于软件与服务器的事实，而不是关于账本的事实。改动软件，你就改动了策略。
第二件要看的事是分片的保管。许多消费级 MPC 钱包会把一个分片放在提供方的基础设施上。这往往正是顺滑恢复体验得以成立的原因——同时也意味着提供方的持续存在与配合，是你这套配置的承重部件。有些设计把这一点缓解得很好，比如可导出的分片或独立的备份路径。问题不在于 MPC 能否做好，而在于你正在考虑的那个具体产品，是否以你能够验证的方式做好了。
多签实际上如何运作
在多签里，策略是地址的一部分。在 Bitcoin 与其他 UTXO 链上，地址由一段列明公钥与阈值的脚本派生而来；一笔没有携带足够有效签名的花费根本就是无效的，网络上的每个节点都会拒绝它。在带智能合约的链上，对应物是一个没有拿到所需批准就不会动作的账户代码。
不需要信任任何人去应用这条规则，因为应用规则正是网络在做的事。若明天所有相关的钱包软件都消失，规则依然成立，而任何持有密钥并拥有任一兼容工具的人仍然可以花钱。
代价也是实打实的。你要管理多把密钥而非一把，备份变得更复杂，交易也更大——在 Bitcoin 上，更多签名意味着更多字节和略高的手续费。你的策略同样在链上可见，这是一个隐私上的考量：观察者能看出某个地址是 2-of-3，即便看不出谁持有哪一把。
什么是多签，以及它为何重要对模型讲得更深。
SSP 精确地处在什么位置
SSP 是 2-of-2 多签，但此处诚实要求补一个细节，因为在每条链上的实现并不完全相同。
在 Bitcoin 与其他 UTXO 链上，它是通过 BIP-48 实现的脚本层面原生多签。两把密钥、一段脚本，由共识强制执行。
在 Ethereum 与其他 EVM 链上并没有等价的原生脚本，因此 SSP 使用一个智能账户来验证由两把密钥共同产出的聚合 Schnorr 签名。你的两台设备运行一套 MuSig2 风格的协议，而链上只看到一个签名——就机制的形状而言，这更接近 MPC 而非 Bitcoin 的多签脚本。
真正要紧的区别不是「聚合与否」。而是以下两个在 SSP 所支持的每条链上都成立的事实：
- 两把密钥都在你的设备上生成，也只由你持有。 SSP 不持有任何分片、任何密钥、任何部分秘密。我们的服务器上没有任何可以丢失、被传唤或被扣作人质的分片。
- 这项要求在链上。 在 EVM 上，智能账户的代码在没有一个只有你两把密钥才能产出的签名时，不会授权任何交易。那段代码已部署、公开且经过审计——它不是我们的软件选择去执行的一条策略。
在 Solana 上，它是一个没有创建者也没有管理员密钥的链上程序，其中金库地址本身就是成员集合与阈值的指纹。机制不同，保证相同。
若你对聚合的密码学感兴趣，Schnorr 签名与多签聚合讲的正是一个签名何以能够要求两把密钥。
失效模式并排比较
比较安全模型的最好方式，是问「什么会坏掉」。
一台设备被攻破。 两种模型都挺得住。攻击者拿到一个分片或一把密钥，无法独自签名。
提供方消失。 多签挺得住——密钥与链上规则就是全部所需。MPC 只有在你能够脱离提供方的软件取得并使用自己的分片时才挺得住，而这完全取决于其设计。
提供方被迫行动。 若提供方持有一个分片，该分片有可能在法律强制下被交出，而依方案不同，它与另一个分片相加或许就足以转移资金。若提供方什么都不持有——如同 SSP，两把密钥都是你的——那就没有什么可被强制的。
你丢了一把密钥或一个分片。 这取决于阈值，而不取决于技术。任一类型的 2-of-3 配置都能容忍一次丢失；任一类型的 2-of-2 配置都不能。如果你的一把密钥被攻破会怎样专门走过 SSP 的情形。
钱包软件就你所签之物对你撒谎。 在这里两种模型都帮不上忙，而这一点值得直说。分散权限防的是密钥被偷；它防不住你批准了错误的交易。正因如此，对两种模型而言真正有意思的问题都是：你的设备在签名前独立验证了什么——是解码原始交易，还是相信服务器给出的描述。
各自在哪里胜出
MPC 在缺乏良好多签原语的链上胜出，在交易体积与手续费上胜出，在安排本身的隐私上胜出，往往在使用体验上也胜出——尤其是恢复环节，一个设计良好的 MPC 产品可以比同时照看多份助记词备份友好得多。
多签在可验证性上胜出。 规则就在账本里。你不必去相信对安全模型的某种描述；你可以读地址或读合约，直接看到策略。它在独立性上也胜出：一套密钥由你自己持有的多签配置，其信任模型里根本没有任何公司。
为不同用途偏好不同答案，并不构成矛盾。日常小额放在一个做得扎实的 MPC 钱包里，长期持仓放在一套密钥分开存放的多签里，是完全自洽的安排。
在你把身家托付出去之前该问什么
无论你偏向哪一边，下面四个问题能把强实现与弱实现区分开来。
- 每一把密钥或每一个分片由谁持有，我能否全部取得？ 如果诚实的答案里包含「提供方，而且不能」，那你选的是一个带对手方的模型。
- 如果提供方明天就消失了会怎样？ 应当存在一条不经过他们的、有文档的路径。在你需要它之前先试一遍。
- 策略住在哪里？ 在链上的脚本或合约里，还是在软件里？两者都可能没问题，但只有一种能在软件变更之后依然存续。
- 每台设备在签名前验证了什么？ 如果两台设备都对服务器发来的东西盲签，那么第二把密钥什么也没添上。多签的失效模式以及 SSP 如何缓解走过了这一点，以及一套多密钥配置在实践中被架空的其他方式。
若你想从头理解 SSP 所构建于其上的模型，请从什么是 2-of-2 多签开始。而如果把你带到这里的顾虑是丢失一把密钥、而非失去对它的控制，社交恢复与多签讲的是另一族答案。
