当多签变成单点故障，Safe钱包用户该何去何从？

2025 年 2 月 21 日，加密货币交易所 Bybit 遭遇了一起黑客攻击，导致约 15 亿美元资产被盗。这一事件不仅刷新了加密货币被盗记录，更震惊整个行业的是：这起攻击绕过了被视为行业标准的多签安全机制。

事后分析显示，黑客攻破了 Safe 开发者设备，修改了 Safe{Wallet} 服务器上的前端 JavaScript 代码。当 Bybit 多签持有者登录时，界面显示正常交易，但实际签署的是完全不同的内容，导致资金被盗。

这一事件引发了深刻的思考：多签钱包真的是问题所在吗？还是我们使用它的方式出了问题？

安全的盲点：看不见的单点故障 

Bybit 事件后，一个问题浮出水面：Safe 真的安全吗？

必须承认的是，Safe 合约本身是安全的。它完全开源，经多家安全公司审核，历史运行中未出现重大合约漏洞。但安全不仅仅是合约代码的问题。

事实上，安全风险涉及一条很长的信任链。使用 Safe 钱包时，签名者依赖诸多环节：签名设备、操作系统、浏览器、钱包插件、Safe UI、RPC 节点、区块链浏览器、硬件钱包及其软件。这条链太长，黑客往往只需攻破其中一环就能获得巨额收益。 

在 Bybit 事件中，攻击者选择了一个看似不起眼的环节：Web 前端。黑客攻击了 Safe{Wallet} 的服务器，替换了 JavaScript。用户以为在签正常交易，实际上签的是恶意升级（将 CALL 改为 DELEGATE_CALL）。

进一步分析，我们发现这类安全漏洞的根源在于「信任链中的交叉点」。多签钱包本应创建一条由多人共同验证的安全链，每个环节都由独立个体把关。理想情况下，每个签名者都应使用独立的工具和方法验证交易。但现实中，签名者往往共享同一个 Web 界面、同一组 RPC 节点、同类型的硬件钱包和相似的验证流程。 

这凸显了一个关键安全漏洞：当所有签名者都依赖同一个 Web 界面，攻击者只需控制这个共享单点，就能同时欺骗所有签名者。值得注意的是，这并非 Safe 特有的问题，而是多签实践中普遍存在但常被忽视的盲区。

这些共享点就是安全链中的弱点。黑客只需攻破一个交叉点，就能同时影响所有人。

这一深刻教训告诉我们，安全不是一个工具，而是一套系统化的实践。拥有顶级的多签工具并不足以保证安全，关键在于如何用它们构建完整的安全流程。

对机构和交易所而言，这一认识尤为紧迫。2024 年数据显示，加密盗窃损失增长 67% ，达到 4.94 亿美元，但受害地址仅增加 3.7% 。攻击者已明确转向「精准狙击」高价值目标，最大单笔被盗金额高达 5548 万美元。当你的资产规模达到机构级别，你就成了黑客追逐的首选目标，任何安全妥协都可能带来灾难。

Bybit 的损失正是最深刻的教训，给整个行业敲响了警钟：真正的多签安全需要多条独立验证路径，而不仅是多个签名者。如果所有人依赖同一信息源，再多签名者也无法提供真正安全。

换句话说，Safe 本身可以很安全，但前提是你以正确的方式使用它，并理解整个安全链条中的每一个环节。这对高净值用户尤其重要。

MPC Safe：更强大的安全组合？

如果说损失 15 亿美元的 Bybit 黑客事件让我们学到了什么，那就是让我们重新思考安全的本质：多签钱包的安全不在于签名者的数量，而在于验证路径的独立性。

当所有人都看同一个 Web 界面，就创造了完美的单点故障。黑客只需攻破这一点，就能欺骗所有人。这就是 Bybit 事件的真相。

那么，我们如何在保持多签权限分散优势的同时，强化验证路径的独立性呢？ 

MPC 和 Safe 的结合或许是答案。这种组合不仅继承了两者的优势，还可能开创全新的安全范式，从根本上解决当前多签实践中的「共享信任点」问题。

Cobo Portal 的 MPC Safe 组合安全设计基于两个核心原则： 

解耦验证链路

传统多签方案中，所有签名者共享同一个界面、RPC 节点和解析逻辑，形成危险的「集中信任点」。更安全的方案应打破这种模式，建立分离的验证系统：

• 分离的签名基础设施（如 MPC 或 HSM）

• 自主维护的 RPC 节点网络（不依赖 Safe 提供的节点）

• 独立解析交易内容的服务层（确保每个签名者看到真实交易内容）

• 专用的审批界面，与主 Web UI 完全隔离

Cobo 推出的「Safe{Wallet} 协签」解决方案正是基于这一理念开发，可以作为 Safe 多签钱包中的一个签名者，但与其他签名者完全独立。

其工作原理是：Cobo Portal 从 Safe 服务中拉取待签名交易，通过独立的风控系统进行审核，然后使用 MPC 钱包或全托管 HSM 钱包完成签名，并将签名结果推回系统。 

以 Bybit 事件为例，即使黑客劫持了 Safe 界面，Cobo 独立验证系统仍能显示真实交易内容和风险警告。

最小权限原则

作为 Cobo 的一款安全产品，Cobo Safe 权限分离模块实现了一个简单但强大的理念：冷钱包永远不需要全部权限。

以交易所为例，冷钱包的主要工作是向热钱包转入资金。但每次热钱包需要资金时，管理员必须动用冷钱包的完整控制权进行转账，这增加了不必要的风险暴露。

Cobo Safe 方案很直接，允许创建一个特殊的「受限操作员」角色，这个角色只有一种权限：向预先设定的热钱包地址转特定白名单币种。日常运营只需通过这个低权限地址操作，主 Safe 无需频繁动用。用户还可以自行配置 Safe 的黑白名单，包括可调用的目标合约限制，进一步强化权限控制。

这意味着，即使黑客完全控制了这个操作员账户，他们能做的唯一事情就是向交易所自己的热钱包转账——没有权限修改钱包设置，没有权限转向其他地址，没有权限动用非白名单币种。

如果使用了 Cobo Portal， 15 亿美金被盗事故还会发生吗？

一旦理解了攻击者如何行动，就能设计出有效的防线。让我们模拟一下攻击者的行动路径，看看 Cobo Portal 的防护在 Bybit 攻击场景中会如何发挥作用。

Safe 多签方案下：所有签名者都使用同一个被攻击的界面，看到被伪装的交易内容；

Cobo Safe{Wallet} 协签方案下：虽然 Safe 界面被攻击，但 Cobo 的独立审批 App 不受影响，显示真实交易内容。

攻击步骤 2 ：伪装交易请求签名

• Safe 多签方案下：签名者看到的是「向热钱包转账」，实际在授权升级；

• Cobo Safe{Wallet} 协签方案下：独立验证链路解析出真实交易是 Delegate Call 操作，App 上显示风险警告。

攻击步骤 3 ：收集签名执行攻击

• Safe 多签方案下：收集足够签名后，合约控制权被攻击者获取；

• Cobo Safe{Wallet} 协签方案下：显示真实交易内容与风险提示，让签名者识别攻击行为。

攻击步骤 4 ：绕过多签防线

• Safe 多签方案下：攻击者获得合约控制权后，可转移所有资产；

• 配合使用 Cobo Safe 方案：即使前面的所有防线被突破，Cobo Safe 的权限分离确保攻击者只能执行预授权操作（比如向白名单热钱包转账）。

在 Cobo Portal 的独立验证防护下，Bybit 的攻击者将在多个环节被拦截。值得强调的是，虽然 Cobo Safe{Wallet} 协签 和 Cobo Safe 是两款独立产品，但将两者结合使用会提供更高的安全级别。如果突破了独立验证这一防线，权限分离系统仍能有效限制可能的损失范围。通过这种深度防御策略，这 15 亿美元的资产损失可完全避免。

安全就像保险。人们总是在灾难发生后才意识到它的重要性。

不幸的是，这个行业已经付出了天文数字的学费，但这也为我们重新思考加密安全提供了契机，即安全是不对称游戏。攻击者只需找到一个漏洞，防守者却必须守住所有。当数十亿美元的资产在那里，顶尖黑客甚至拥有无限资源的国家级攻击者会花月甚至年来研究你的系统，寻找那个唯一的弱点。

这正是 Cobo 开发 Safe{Wallet} 协签方案的原因。我们想解决一个核心问题：如何消除单点故障？答案是重构整个验证流程，实现多重安全保障。对于管理大额资产的机构来说，安全从来不是效率的对立面，而是前提。如果没有安全，效率根本无从谈起。

Cobo 内部一直在使用这套系统，安全事件频发后，我们意识到，这些安全实践不应该只属于我们自己，而应该惠及更多用户。因此，我们将其产品化，并推出 30 天免费试用。希望它不仅可以保护你的资产，更能借助你的反馈不断优化升级，让安全体系更完善。

安全不是一次性投入，而是一个持续演进的过程。随着威胁不断升级，安全防护也必须持续迭代。唯有专注与坚持，才能真正应对不断变化的风险环境。