慢霧：Safe困局，Guard能否重構契約巴別塔？

原文標題：《慢霧解析｜Safe 困局，Guard 能否重建契約巴別塔？ 》

原文作者：flush & kong，慢霧科技

背景

2025 年 2 月 21 日，加密貨幣產業遭遇最嚴重的資產管理危機。交易平台 Bybit 的鏈上多簽錢包遭定向攻破，近 15 億美元資產透過一筆「合法簽署」的交易悄悄流失。事後鏈上分析顯示，攻擊者透過精密的社會工程攻擊取得了多簽權限，利用 Safe 合約的 delegatecall 功能植入惡意邏輯，最終繞過多重簽名驗證機制，將資金轉移至匿名地址。

這次事件暴露出一個殘酷現實：「多重簽名」不等於「絕對安全」，即便是 Safe 多簽錢包這樣的安全機制，如果缺乏額外的防護措施，仍然存在被攻破的風險。這也並非首個針對 Safe 多簽錢包的攻擊案例。去年 WazirX（損失 2.3 億美元）和 Radiant Capital（損失 5,000 萬美元）都遭遇了類似的攻擊手法。正如慢霧：Bybit 近 15 億美元被盜背後的黑客手法與疑問一文中的分析，Safe 多簽錢包攻擊事件呈現出以下技術同源性：

過度依賴簽名機制：將安全責任都交給私鑰保管。

動態防禦缺失：缺乏交易執行前的即時風險掃描。

權限控制粗粒度：未對 delegatecall 等高風險操作建立白名單機制。

(Bybit 被盜流程：使用 Safe v1.1.1)

這一系列事件的核心問題不在於 Safe 合約本身，而是在於整個系統的集成過程中的安全隱患，特別是在前端驗證環節。這促使我們需要思考：如何透過 Safe 的額外安全措施機制來強化多簽錢包的防護能力？

Safe

Safe 是一款多重簽名 (Multi-Sig) 錢包，主要用於管理高價值資產和數位貨幣的安全儲存與轉移。作為去中心化資產管理的基礎設施，它透過多方協同驗證機制確保資金操作的安全性，防止單一管理員或駭客利用單點故障進行惡意操作，廣泛應用於 DAO 治理、企業資金託管、去中心化基金池等場景。該合約由 Safe（原 Gnosis Safe）團隊開發，是當前業界標準的鏈上資產管理解決方案。合約採用 EIP-712 標準實現結構化資料簽名，從而提高交易資料的安全性和可驗證性。

核心用途

資金安全管理：合約要求多個預先設定的所有者 (Owners) 共同確認交易才能執行，從而有效防止單點失誤或惡意操作，確保資金安全。

交易執行與管理：透過內建的多簽驗證機制，合約能夠在滿足簽章門檻條件的情況下，執行對外轉帳、呼叫其他合約或處理複雜的業務邏輯，支援代幣和原生幣的支付和費用補償。

模組化擴充：合約採用模組化設計，透過繼承和組合多個管理模組（如 OwnerManager、ModuleManager、GuardManager、FallbackManager 等），使其功能靈活且易於擴展，為不同應用情境提供客製化支援。

函數解析

execTransaction 函數執行經過多重簽章驗證的交易：

· 計算交易的唯一雜湊值（結合交易參數、nonce 等）；

p>

· 呼叫目標位址的業務邏輯，並在交易執行後透過事件記錄成功或失敗狀態；

· 支援靈活的 gas 費用處理，確保在支付補償時準確計算交易成本。

checkContractSignatures & checkNSignatures 函數驗證交易或訊息的簽章資料：

· 分別處理 EOA 帳戶簽章、合約簽章 (EIP-1271)、以及預先核准的雜湊；

· 確保簽章依照擁有者順序排列，且每個簽章都來自有效位址，防止重播攻擊和簽章竄改。

getTransactionHash 函數產生交易哈希，用於簽章驗證和防止重播攻擊：

· 利用 EIP-712 標準對交易資料進行結構化雜湊；

使用內聯式確保每筆交易的唯一性。

handlePayment 函數處理執行交易過程中的 gas 補償支付：

· 根據實際消耗的 gas 費用和基礎費用計算支付金額；

· 支持 ETH 費用以及補償代幣的準確支付。

onBeforeExecTransaction 為內部虛擬鉤子函數，在 execTransaction 函數執行之前被呼叫。此函數的設計目的是允許繼承 Safe 合約的子合約在交易執行前進行自訂邏輯處理。接收的參數集包括：

· to：目標地址 - 交易要調用的合約或帳戶地址

· value：以太幣值 - 隨交易發送的以太幣數量

· data:>決定是 CALL 或 DELEGATECALL

· safeTxGas：交易 gas 限制 - 為交易執行預留的 gas 數量

· baseGas： 價格 - 獨立於交易執行的 gas 成本

· gasToken：gas 代幣 - 用於支付交易費用的代幣地址

· refundReceiver：退款接收者 - 接收交易費用補償的地址

· signatures：為數位資產管理提供了高效且安全的解決方案，實現了從交易初始化到最終執行的全流程安全管控，並成為區塊鏈安全管理的重要工具，但同樣需要注意的是，受害者大多依賴硬體錢包進行簽名，而部分硬體設備對結構化資料簽名的顯示效果欠佳，容易導致用戶在短時間內無法識別交易資料，從而有「盲簽」風險。針對此現象，除了優化硬體及其資料展示效果之外，還可以探索增加多重確認、智慧提示以及增強簽章驗證工具等措施，以進一步降低盲簽帶來的安全隱患。

Safe Guard

Safe 合約在 1.3.0 版本中引入的重要安全功能－Safe Guard 機制。此機制旨在為標準的 n-out-of-m 多簽方案提供額外的限制條件，進一步增強交易安全性。 Safe Guard 的核心價值在於能夠在交易執行的不同階段進行安全檢查：

· 交易前檢查 (checkTransaction)：Guard 機制可以在交易執行前，對交易的所有參數進行程序化檢查，確保交易符合預設的安全規則。

· 交易後檢查 (checkAfterExecution)：在交易執行完成後，Guard 還會進行額外的安全驗證，檢查交易執行後 Safe 錢包的最終狀態是否符合預期。

架構分析

在 Safe 中，多簽交易一般透過 execTransaction 函數進行執行。在 Safe Guard 啟用的情況下，當使用者執行多簽交易時，Safe 合約將呼叫 Guard 合約的 checkTransaction 函數執行交易前檢查，而當多簽交易執行完成後，Safe 合約將呼叫 Guard 合約的 checkAfterExecution 函數對交易的執行結果進行檢查。具體實現如下：

當 Safe 合約透過 Guard 機制執行多簽交易預檢時，其 checkTransaction 函數將接收完整的交易上下文數據，包括目標合約位址、調用方式、執行資訊資料（如 delowner）、資訊資料如資訊。

該機制使開發者能夠實現多維度的風控策略，例如合約白名單管控（限制可交互地址）、函數級權限管理（禁用高危險函數選擇器）、交易頻率限制以及基於資金流向的動態規則等。透過合理配置 Guard 策略，可有效阻斷攻擊者利用非合約層面進行攻擊。

在近期不斷曝出安全事件的背景下，各方對多簽錢包合約的安全性日益關注，硬體錢包提供者如 KeyStone 、OneKey、RigSec 等紛紛呼籲增強 Safe 合約的解析和防護能力，以預防類似風險的再次發生。在 Bybit 事件後，許多專案方開始聚焦 Safe 合約，並探索基於 Guard 機制的升級與擴充方案。

其中，不乏有基於 Guard 機制的創新應用，建構一種建立在 Safe 多簽錢包之上的中間層安全解決方案，為底層資產與用戶資產之間提供了額外的安全保障。其核心作用在於，透過將 Safe 多簽交易涉及的目標合約、呼叫方式、執行資料、owner 簽名資訊、付款資訊以及 gas 資訊傳入 checkTransaction 函數，實現對交易的極細粒度檢查，包括白名單合約呼叫、白名單函數操作、白名單轉帳目標、交易頻次等權限控制。

值得注意的是，Safe 本身只提供 Guard 管理和回呼功能，實際的多簽交易檢查邏輯由使用者自行實現，其安全性取決於 Guard 實現的品質。如：Solv Guardian 拓展了這一思路，在每個 Vault 配置專門的 Guardian 來指定允許的目標位址和操作權限，實現了指定允許合約、定義允許函數操作和 ACL 驗證需求三大權限控制要素。

同時，採用分離的治理機制，由 Vault Guardian 負責執行，而 Governor 控制治理權限，確保即便 Guardian 出現問題，也能及時採取補救措施保護用戶資產。類似的設計理念也在 Elytro 的 SecurityControlModule 中得到應用，該模組透過 preExecute 函數攔截關鍵操作，並藉助白名單機制對模組安裝、鉤子設定和驗證器管理等高風險操作進行精細管控，從而確保只有經過信任的合約才能被添加到系統中，為錢包提供了持久的安全保障。

在 Bybit 事件攻擊鏈中，若 Safe 合約部署了合理配置的 Guard 機制，攻擊者透過 execTransaction 發起的惡意 delegatecall 將在預檢階段被多重策略攔截：Guard 的 checkTransaction 函數首先識別到 delegatecall 操作隨後被定義為 0972072072172 月20 月 20707232 平底地址代碼的規則。 7242）及高危險函數選擇器，透過預設的合約白名單與函數黑名單策略直接回溯交易，最終形成「策略攔截 → 邏輯阻斷」的防禦體系，徹底阻斷儲存竄改與資金轉移路徑。

(當使用 Safe 版本 ≥ v1.3.0  Safe Guard 模組的驗證操作 https://excalidraw.com/#room=fd1df6709b380 te>

總的來說，Safe 僅在 1.3.0 版本之後才提供 Guard 功能，儘管 Guard 可以提供極為細粒度的多簽交易檢查，但用戶在使用 Guard 功能時有較大的門檻。他們需要自行實現 Guard 檢查邏輯，粗略的或有缺陷的 Guard 實作可能無法幫助用戶提升其 Safe 錢包的安全性，因此對 Guard 實作進行安全審計是必要的。毫無疑問的是，安全且適當的 Guard 實現可以極大提升 Safe 錢包的安全性。

結論與展望

Bybit 被攻擊事件凸顯了及時更新安全基礎設施的重要性，Bybit 使用的是 v1.1.1 (<1.3.0) 版本的 Safe 合約，這意味著他們無法使用 Guard 安全特性。如果 Bybit 升級到 1.3.0 或更高版本的 Safe 合約，並實現了合適的 Guard 機制，例如指定唯一接收資金的白名單地址，並進行嚴格的合約函數 ACL 驗證，可能就能避免這次的損失。儘管這只是假設，但它為未來的資產安全管理提供了重要思路。

Safe Guard 機制就像是為數位資產保險箱加裝的智慧安檢系統，其效能取決於規則設計的嚴謹性和實施品質。面對日益精密的攻擊手段，我們需要：

· 自動化驗證：建立自動化的交易驗證機制

· 動態策略調整：根據威脅情報即時調整安全策略

· 對常規稽核：根據威脅情報即時調整安全策略

· 對常規稽核防禦：1

p>

未來的數位資產管理，將是智慧合約安全機制與持續攻防演進的共同演化過程。將安全理念融入每一個環節，才能在駭客的「矛」與守護者的「盾」的賽局中建構真正的安全壁壘。

參考資料

[1] https://github.com/safe-global/safe-smart-account/blob/v1.3.0/CHANGEsam.

blockquote>

[3] https://docs.solv.finance/security/solv-guard

[4] https://github.com/safe-global/safe-smart-account/tree/main/contracts/examples/guardsquoblock/dlock; https://github.com/Elytro-eth/soul-wallet-contract/blob/v0.6/contracts/modules/securityControlModule/SecurityControlModule.sol