多签钱包真的能提升安全性吗？从威胁模型视角看

多重签名钱包（Multisignature wallets，即在交易生效前必须有 N 个密钥中的 M 个进行签名的钱包）通常被视为单密钥热钱包理所当然的升级版。在 DAO（去中心化自治组织）、交易所和成熟的加密原生公司中，大多数资金库设置都采用了某种形式的多签方案（如 Safe、Squads、Multisig.js 或门限签名变体）。

这种声誉是实至名归的，但仅仅是针对特定的威胁模型而言。多签能防范一些最常见的资金被盗方式，但对其他一些方式却几乎无能为力。以下是关于多签的真实情况：它究竟擅长什么，不足之处在哪，以及在哪些情况下采用多签反而会让系统变得更不安全。

简述什么是多签

在 3 选 2 (2-of-3) 的多签中，存在三个私钥；其中任意两个私钥必须对交易进行签名，交易才能在链上执行。钱包本身是一个智能合约（在以太坊 / EVM 生态中）或一种原生的多签输出类型（在比特币中通过 P2SH/P2WSH 实现）。合约会验证签名，然后转发交易。

在 EVM 生态系统中最广泛使用的实现是 Safe（前身为 Gnosis Safe）。在 Solana 上，Squads 扮演着同样的角色。比特币有着悠久的原生多签支持历史，通常通过 PSBT 工作流与硬件钱包结合使用。

门限签名方案（TSS、FROST、MPC）通过单一的链上密钥实现了类似的结果——每个签名者持有私钥的一个份额（share），他们共同签名，而无需重构出完整的私钥。从威胁模型的角度来看，以下大多数观点对这两者同样适用，稍后会提到一些需要注意的特殊情况。

多签能防范什么（好消息）

单一密钥泄露

这是最显著的优势。如果某个签名者的硬件钱包被盗，或者手机感染了恶意软件，抑或是助记词泄露，持有这单一密钥的攻击者也无法转移资金。他们需要同时攻破至少 M-1 个其他密钥。

对于 2/3 的多签设置，这意味着攻击者必须攻破两个独立的终端，理想情况下，这些终端由不同的人在不同的物理位置、使用不同的硬件持有。在同一时间窗口内发生两次独立安全漏洞的概率，通常比发生一次的概率要低几个数量级。

内部人员风险

拥有完全托管权的单个人可能会愤怒退出、叛变、受到胁迫，或者仅仅是犯下灾难性的错误。多签则要求必须经过共谋（多方同意）才能行动。对于 DAO 和公司来说，这通常是首要的动机——防范任何单个内部人员的治理效益，甚至要高于防范外部攻击者的安全效益。

丢失密钥恢复

在 N > M 的 M/N 设置中，丢失一个密钥并不是灾难性的。剩余的签名者可以将资金转移到一个新的多签钱包中，并替换掉丢失的密钥。相比于丢失一个助记词就意味着永久损失的单密钥托管，这是一个非常有意义的改进。

用户钓鱼

许多钱包钓鱼攻击（虚假空投网站、恶意代币授权、钱包盗币合约等）都依赖于用户在单个浏览器会话中签署恶意交易。多签在不同的层面（例如 Safe 的协调 UI，或多台设备上的硬件授权）增加了一个确认步骤，这给了用户另一个缓冲时刻，去察觉他们正在签署非预期的交易。

多签不能防范什么（令人不安的部分）

这一部分是大多数快餐式科普文章常常跳过的内容。

多签本身的智能合约漏洞

多签本质上是一个智能合约。如果合约存在漏洞，世界上再谨慎的密钥管理也无济于事。历史上损失最惨重的多签事件——2017 年 11 月的 Parity 多签冻结事件——就是一个合约漏洞，而不是密钥泄露。价值约 1.5 亿美元的 ETH 因为一笔交易而变得永久无法被访问。

现代的 Safe 是以太坊上经过最多审计的合约之一，并且表现非常稳定，但这个道理依然成立：你实际上是在将“保护一个私钥”换成“信任一个智能合约”。这种信任必须通过反复的审计和时间的考验来赢得。

签名 UI 的安全隐患

几乎每一次多签授权都是通过某种前端界面进行的——Safe 的 Web UI、钱包插件或自定义仪表板。如果该界面被攻破（如 DNS 劫持、依赖项的供应链攻击、恶意浏览器扩展），攻击者可以向签名者 A 显示“发送 1 ETH 给 alice.eth”，但实际发送给硬件钱包进行签名的却是“发送 1000 ETH 给 attacker.eth”。

大多数硬件钱包确实会显示实际的目标地址，但签名者通常只是草草掠过。2025 年初的 Bybit 遇袭事件就是由 Safe UI 漏洞引起的；所有的签名者都批准了他们以为的一笔日常交易，而实际上代理合约正在被恶意篡改。

多签能够保护你免受仅仅掌握了一个密钥的攻击者的侵害。但如果攻击者能够把错误的交易伪装好放在你所有签名者的面前，多签则无能为力。

针对多个签名者的协同钓鱼攻击

如果签名者的身份是公开且可触达的——对于任何公布了 Safe 地址的资金库来说通常都是如此——攻击者就可以将他们全部作为目标。对每个签名者发起相同的钓鱼攻击。然后等待。如果三个人中有两个在同一天感到疲惫、分心或防备松懈，签名的门限（Threshold）就被凑齐了。

在实际运作良好的多签库中，这是最真实的攻击手段。而针对这种攻击的防御手段主要取决于流程，而非技术：在独立通信渠道（如 Signal、其他聊天软件或电话）中对每笔交易进行带外（out-of-band）确认，并制定严格的策略，规定任何超过 X 美元的交易都必须在签名前进行实时讨论。

链下密钥存储被攻破

如果所谓的“签名密钥”实际上是分配在两名工程师的 MetaMask 助记词和办公室保险箱里的一个硬件钱包之间，这其实是一个披着多签外衣的操作安全（OPSEC）问题。虽然在技术上满足了门限，但密钥分布的多样性是虚假的。只要两名工程师的笔记本电脑感染了恶意软件，或者办公室发生一次入室盗窃，门限就会被攻破。

真正的多样性需要：

不同的硬件型号。（比如一台 Ledger，一台 Trezor，一台 Keystone。）
用于任何软件签名的操作系统需互不相同。
任何持久化存储设备需位于不同的物理位置。
在适用的情况下，由面临不同威胁模型的不同人员来操作。

超过门限值的丢失

恢复能力的另一面是：在 2/3 多签中，丢失两个密钥就意味着永久损失。在 3/5 多签中，丢失三个密钥即为永久损失。M 和 N 之间的差距越大，应对单一密钥丢失的安全性就越高——但这同时也意味着攻击者更容易找到 M 个签名者进行钓鱼。

这是不可避免的矛盾。较高的 M 值对外部攻击更安全，但恢复难度更大。较低的 M 值更容易恢复，但也更容易受到攻击。没有任何一种设置可以同时兼顾优化这两者。

在哪些情况下多签会让事情变得更糟

以下是一些真实的案例：

对于极小额余额，多签的运维成本（交易协调、EVM 上的 Gas 费用、学习曲线）可能会导致单密钥托管所不会犯的错误。对于仅值 200 美元的“零花钱”级别加密资产而言，由硬件钱包支持的单密钥才是合适的工具。
对于将多签作为恢复方案的单人用户，如果实际上他们把三个密钥都存放在自己独自控制的设备上，那么多签不仅增加了复杂性，却并没有改变威胁模型——如果一名攻击者今天能攻破其中一台设备，那么他们也很可能攻破所有设备。
对于实际上并不具备签名者多样性的组织——所有人在同一个办公室、使用同一个 VPN 和相同的单点登录（SSO）系统——多签的门槛就会流于形式。

在这三种情况下，解决办法并不是“使用单密钥托管”，而是“正确使用多签，或者使用合规的托管机构”。但是，无视实际的运维操作，仅凭采用多签合约就认为高枕无忧，这往往是重大安全损失发生的根本原因。

什么样的多签才是优秀的设置

只有当以下所有条件均满足时，2/3 或 3/5 多签才能作为优秀的资金库控制方案发挥作用：

签名者必须是不同的人，如果可能的话，应位于不同的司法管辖区。
签名设备应使用不同硬件品牌，并运行在不同的操作系统上。
使用独立于签名界面的额外通信渠道进行交易确认。
拥有记录在案的操作流程，确保任何签名者在批准之前，都会根据预期的变更（如 calldata、目标地址、交易金额）核对交易负载（payload）。
多签合约本身必须经过了充分的审计（Safe 是 2026 年保守派的默认选择），且合约版本已固定并被所有签名者知悉。
必须存在签名者替换的应急预案，并且经过了实战演练。

这需要比大多数团队一开始所意识到的更强的纪律性。好消息是，这种纪律性是一次性的投入；坏消息是，这种纪律性比智能合约本身更为重要。

这与域名有何关联

域名命名体系是链下世界中与多签最契合的类比之一。一个仅由单一密码下的单一注册商账户控制的域名，就相当于一个单密钥钱包。而受到注册商锁定 + 注册局锁定 + DNS 提供商 2FA 防护 + 多个权威 DNS 解析提供商共同保护的域名，从结构上看就是一个多签架构：必须攻破多个独立的安全要素，域名才会被转移。

Namefi 更进了一步，将域名所有权以链上记录的形式呈现，让其可以直接保存在多签钱包中。如今，保护资金库的门限方案同样可以用来保护 DNS 控制平面——因此，就算单个成员遭到了钓鱼攻击，他也不能独自弄丢公司的域名，就像他无法单枪匹马掏空资金库一样。这两个世界中的威胁模型升级原理如出一辙：将“信任单一凭据”替换为“攻破 N 个独立要素中的 M 个”。

参考资料与延伸阅读

Safe — 智能账户合约及审计.
IETF FROST — RFC 9591，灵活轮次优化的 Schnorr 门限协议.
比特币 — BIP-174 PSBT（部分签名的比特币交易）.
Parity — 多签冻结事件事后分析.
a16z crypto — 运行 Safe 多签的实用指南.