當多籤變成單點故障，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 攻擊場景中會如何發揮作用。

場景重現

攻擊步驟1：Safe 前端被注入惡意 JavaScript 代碼

• 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 天免費試用。希望它不僅可以保護你的資產，更能借助你的反饋不斷優化升級，讓安全體系更完善。

安全不是一次性投入，而是一個持續演進的過程。隨著威脅不斷升級，安全防護也必須持續迭代。唯有專注與堅持，才能真正應對不斷變化的風險環境。

如果你正管理大額加密資產，或是高淨值用戶，歡迎試用 Cobo Safe{Wallet} 協籤方案，並與我們分享你的使用體驗。在加密行業，安全永遠是最重要的事。