单签者 multisig：SSP 如何让两台设备感觉像一只钱包

如果你从 multisig 是什么 起就跟着这个系列，那么你了解协议：在钱可以动之前，需要有多于一把私钥签名。你看过 m-of-n 选择器、BIP48 线路图、Schnorr 聚合的地平线 和 社交恢复对比。这些都是机器。这一篇讲的是体验。

对 multisig 诚实的历史性批评是：它在使用上很不友好。多个钱包、手动来回 PSBT、协调器软件、签字派对——协议是稳的，但 UX 是惩罚。**单签者 multisig（single-signer multisig）**是修正这一点的产品想法：一只钱包在链上使用完整的 multisig 花费规则，但对使用它的人来说——它就像只有一个按钮的一只钱包。SSP 就是围绕这个想法构建的。

TL;DR

• "单签者"不等于一把密钥。 它的意思是协议仍然是 m of n 把密钥，但签名 UX被收拢成单一流程。用户在一个地方签字；钱包负责设备与设备之间的协调。
• SSP 的具体形态：一个浏览器扩展、一个手机应用（SSP Key）、一个钱包身份。你点 Send，在手机上确认，交易就被广播。两个签名都发生了；你体验到的是一个。
• 胜利在于门槛带来的好处（防被偷、不存在单点失败）被保留了，而协调成本降到了几乎和 single-sig UX 一样。
• 代价是这只在两台设备都可达的情况下成立。一旦 UX 不得不暴露"多签性"——恢复、设备更换、在第三方上还原——抽象就破了，按设计如此。
• 这种模式是最接近"无折中"答案的方案，适用于零售规模的单人 self-custody。这是 SSP 的赌注，也越来越是每一只现代 multisig 产品的赌注（Coinbase Wallet、Phantom 持续演化的托管故事、以及 Safe 在 Ethereum 上的 smart-account 流程）。

单签者理想：用户真正想要的是什么

如果你问一个 self-custody 用户他想要什么，你会得到一堆互相矛盾的答案：

• "我想我的币安全。" — 暗示 multisig、硬件、冗余。
• "我想 5 秒内签一笔交易。" — 暗示单一设备、一次点击。
• "我想在丢东西时可以恢复。" — 暗示 seed 备份、冗余。
• "我再也不想抄一遍 seed 了。" — 暗示平台托管密钥。
• "我想要它便宜。" — 暗示最少的链上印记。

这些目标无法同时全部对齐。Self-custody 钱包设计的历史，就是要尊重哪些目标、礼貌拒绝哪些目标的历史。硬件钱包以 UX 为代价尊重安全和恢复。Smart-contract 钱包以跨链覆盖为代价尊重 UX 和恢复。纯 hot wallet 则以安全为代价尊重 UX 和便宜。

单签者 multisig 是一种通过把协议语义和界面语义分开，部分地尊重全部五个目标的尝试。钱包仍然在链上跳完整支 multisig 的舞；用户只是不必每笔交易都参与那支舞超过一次。

SSP 是如何交付的

SSP 的具体实现，用大白话说：

1. 设置时，你安装浏览器扩展和手机应用（SSP Key）。每一个都生成自己的 seed，你分别备份它们（这是 前 1000 美元清单 里的一步）。两台设备互换公钥；从那一刻起，它们在协议层面共享同一个钱包身份。
2. 日常签名时，你在浏览器扩展里点 Send，审一下交易并批准。扩展构建一笔部分签名交易，并把通知推到你的手机。手机应用显示交易细节，你点批准，应用生成第二份签名。扩展把两份签名合并并广播。整个流程花费时间：当两台设备都在你面前时，大约 8 秒。
3. 收钱时，显示给你的地址，是从两个 xpubs 通过 BIP48 派生出的 multisig 地址。你扫码或复制；发送者那边看不到任何异常。从他的角度看，它就像任何其它加密地址。
4. 对账时，钱包给你显示余额、历史、手续费等等，跟单签钱包没有区别。没有单独的"multisig 界面"。在正常使用过程中，协议形态完全不可见。

关键的设计决定是：第二份签名是用户唯一需要去思考的"多签性"所在。设置阶段是两台设备，签名阶段是一次额外点击，这就是从用户视角看 multisig 协议的全部表面。

一个小但重要的细节：SSP 浏览器扩展和 SSP Key 并不在同一处。它们分别运行在不同的操作系统、不同的硬件、不同的攻击面上。这是让两份签名设置真正成为防盗屏障，而不是只是一个 UX 减速带的原因。（我们在 七种失败模式那篇文章 以及 What is 2-of-2 multisig 里把这一点展开过。）

用户永远看不到的部分

很多功夫都花在让用户不必去处理 multisig 的水管。具体说：

• **PSBT（Partially Signed Bitcoin Transactions）**就是那些在共同签名设备之间来回穿梭的大块数据结构。在传统的 multisig 配置中你需要手动复制粘贴它们。SSP 通过自己的协调通道做序列化和传输；用户看到的是一条通知，不是一段 base64 字符串。
• 共签者 xpub 的交换 是一次性的设置事件。在传统 multisig 中，你需要逐个明示地导入每个共签者的 xpub。SSP 把这件事包在配对流程里；你确认一个 QR 码或六位数字码，从来不接触底层的密钥材料。
• 手续费估算、找零处理、地址轮换 都由钱包按照单签钱包的方式来处理，尽管钱包在引擎盖底下是 multisig。
• 赎回脚本（redeem script）——用 BIP48 规范描述 multisig 规则的脚本——由钱包自动构建。用户看不到它，不需要逐行批准它，也不需要知道它存在。（如果他们愿意，可以在区块浏览器上看到它，这是 multisig 钱包最干净的"把工作过程给你看"的属性。）

所有这些抽象都是必要的工作，但同时也是风险——每一次协议被对用户隐藏，钱包就要为把那部分隐藏内容做对负责。SSP 的审计工作（Halborn）基本上就是围着这些"看不见的代码路径"在转。

它什么时候不再像单签者

抽象并不完美，而且知道它在哪里破裂很重要。单签者 UX 在两台设备都可用时成立。当其中一台不在时，裂缝就会显出来：

• 更换设备。 你换手机时，新设备必须重新配对。这是一个一次性的 multisig 协调步骤，它确实是可见的——钱包会引导你让两台设备相互再"看到"对方一次。
• 从 seed 恢复。 如果某台设备被摧毁，你要从它的 seed phrase 在一台新设备上恢复它，然后再配对。你拥有两个 seed（每台设备一个）这个事实，会在这个时刻以一种正常使用下并不存在的方式变得可见。
• 跨软件恢复。 如果你哪天把你的两个 SSP seed 装进一只第三方 multisig 钱包（Sparrow、Electrum 等），所有 multisig 管道都会变得可见——这不是 bug，是一个 feature，因为它正是证明你的钱包是可互操作的根据，但这不是 SSP 的 UX。
• 当一台设备离线时花费。 在两台设备都不在的情况下，钱包不能共签；那就是协议。你会看到一个"等待第二份签名"的状态，直到另一台设备上线。

前三种情况都足够少见，不真正让平均 UX 变差。第四种是最常见的摩擦点——也是正确的摩擦点。如果钱包允许你在没有第二台设备的情况下花钱，那它就不再是 2-of-2 钱包了。那点摩擦正是安全本身；你无法把它工程化掉，除非也把你为之付费的那个属性也去掉。

围绕单签者 UX 做设计

SSP——以及其他现代 multisig 产品——遵守三条设计原则，以保持这层抽象紧凑：

1. 两个共签者必须生活在不同的威胁面上。 把两把共签密钥放在同一个操作系统上的钱包，其实没有真的提供安全收益；它只是把一个攻击面摊到了两把锁上。SSP 在浏览器扩展和移动应用之间的分工，自然地强制执行了这一点。
2. 协调通道必须不可伪造。 浏览器扩展发送给手机应用的 PSBT，必须在密码学上绑到正确的钱包和正确的交易上；否则那层抽象就变成它自己的攻击面。SSP 在协议层面对这部分材料做签名和验证。
3. 对用户的承诺必须诚实地说出隐藏了什么。 那些宣传"完全无信任的单签者体验"但不解释恢复时会发生什么的钱包，是在为用户埋下一个不愉快的惊喜。SSP 的入门流程会显式地把两份 seed、两份备份、两种恢复场景全都走一遍——抽象在使用时是隐藏的，但在入门过程中是被亮出来的，这样它就不会以后埋伏你。

Ethereum 上的账户抽象钱包还多一件工具：智能合约层。借助 ERC-4337，一只钱包可以代为承担 gas 费、批处理交易，给出一个甚至更"像单签者"的 UX，同时在底下仍然实现 multisig。SSP 在 Bitcoin 上没有那一层（没有智能合约），所以它的抽象更多依赖 UX 工程，而不是链上吸收。两条路都合理；Ethereum 那条更灵活，但代价是有链特异性；SSP 那条更具可移植性，但代价是更多 UI 工作。

这对你意味着什么

三个要点：

1. "感觉像一只钱包"这种体验才是头条卖点，而不是 multisig 本身。 如果你的朋友问"SSP 是 multisig 钱包吗？"，技术上正确的答案是"是"，但有用的答案是"它是一只两台设备的钱包，在手机上点一下就完成一次花费"。这才抓住了人们真正感受到的东西。
2. 你看到的那点摩擦，是在做真实的工作。 每一次 SSP 让你在手机上确认，它都是在执行那个能阻止被攻陷的笔记本把你的资金搬空的协议。那点摩擦，正是你一开始选择 2-of-2 钱包而不是 hot wallet 的主要原因。
3. 把抽象当成合同，不要当成魔法。 本系列的收官文章，Multisig 失败模式和 SSP 如何应对，会走一遍当这层抽象的每一部分破裂时会发生什么——设备丢失、密钥被攻陷、签名服务器宕机。读一遍。这层抽象做得好，但理解它的失败模式，才是把你变成这一整个系列所面向的那种 self-custody 用户的方式。