深度解析Safe困局：Guard 能否重構契約巴別塔？

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

此次事件暴露出一個殘酷現實："多重籤名"不等於"絕對安全"，即便是Safe多簽錢包這樣的安全機制，如果缺乏額外的防護措施，仍然存在被攻破的風險。這也並非首個針對Safe多簽錢包的攻擊案例。去年兩家知名交易所分別損失2.3億美元和5,000萬美元，都遭遇了類似的攻擊手法。Safe多簽錢包攻擊事件呈現出以下技術同源性：

• 過度依賴籤名機制：將安全責任都交給私鑰保管。
• 動態防御缺失：缺乏交易執行前的實時風險掃描。
• 權限控制粗粒度：未對delegatecall等高風險操作建立白名單機制。

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

Safe

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

核心用途

• 資金安全管理：合約要求多個預先設定的所有者(Owners)共同確認交易才能執行，從而有效防止單點失誤或惡意操作，確保資金安全。
• 交易執行與管理：通過內置的多籤驗證機制，合約能夠在滿足籤名閾值條件的情況下，執行對外轉帳、調用其他合約或處理復雜的業務邏輯，支持代幣和原生幣的支付和費用補償。
• 模塊化擴展：合約採用模塊化設計，通過繼承和組合多個管理模塊（如OwnerManager、ModuleManager、GuardManager、FallbackManager等），使其功能靈活且易於擴展，爲不同應用場景提供定制化支持。

函數解析

execTransaction函數執行經過多重籤名驗證的交易：

• 計算交易的唯一哈希值（結合交易參數、nonce等）；
• 驗證所有籤名的有效性，確保每個籤名均來自合法的所有者或預先批準的地址；
• 調用目標地址的業務邏輯，並在交易執行後通過事件記錄成功或失敗狀態；
• 支持靈活的gas費用處理，確保在支付補償時準確計算交易成本。

checkContractSignatures & checkNSignatures函數驗證交易或消息的籤名數據：

• 分別處理EOA帳戶籤名、合約籤名(EIP-1271)、以及預批準的哈希；
• 確保籤名按照所有者順序排列，並且每個籤名都來自有效地址，防止重放攻擊和籤名篡改。

getTransactionHash函數生成交易哈希，用於籤名驗證和防止重放攻擊：

• 利用EIP-712標準對交易數據進行結構化哈希；
• 使用內聯匯編優化內存操作，提高計算效率；
• 結合當前的nonce值，確保每筆交易的唯一性。

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

• 根據實際消耗的gas費用和基礎費用計算支付金額；
• 支持ETH以及其他代幣的支付，確保費用補償準確無誤。

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

• to：目標地址 - 交易要調用的合約或帳戶地址
• value：以太幣值 - 隨交易發送的以太幣數量
• data：數據載荷 - 包含函數選擇器和參數的調用數據
• operation：操作類型 - 確定是CALL還是DELEGATECALL
• safeTxGas：交易gas限制 - 爲交易執行預留的gas數量
• baseGas：基礎gas - 獨立於交易執行的gas成本
• gasPrice：gas價格 - 用於計算交易費用補償的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函數將接收完整的交易上下文數據，包括目標合約地址、調用方式、執行數據（如delegatecall）、owner籤名信息、Gas配置及支付信息。該機制使開發者能夠實現多維度的風控策略，例如合約白名單管控（限制可交互地址）、函數級權限管理（禁用高危函數選擇器）、交易頻率限制以及基於資金流向的動態規則等。通過合理配置Guard策略，可有效阻斷攻擊者利用非合約層面進行攻擊。

在近期不斷曝出安全事件的背景下，各方對多簽錢包合約的安全性日益關注，硬體錢包提供商紛紛呼籲增強Safe合約的解析和防護能力，以預防類似風險的再次發生。在某交易平台事件後，許多項目方開始聚焦Safe合約，並探索基於Guard機制的升級與擴展方案。其中，不乏有基於Guard機制的創新應用，構建一種建立在Safe多簽錢包之上的中間層安全解決方案，爲底層資產與用戶資產之間提供了額外的安全保障。其核心作用在於，通過將Safe多籤交易涉及的目標合約、調用方式、執行數據、owner籤名信息、付款信息以及gas信息傳入checkTransaction函數，實現對交易的極細粒度檢查，包括白名單合約調用、白名單函數操作、白名單轉帳目標、交易頻次等權限控制。

值得注意的是，Safe本身只提供Guard管理和回調功能，實際的多籤交易檢查邏輯由用戶自行實現，其安全性取決於Guard實現的質量。如：某安全解決方案拓展了這一思路，在每個Vault配置專門的Guardian來指定允許的目標地址和操作權限，實現了指定允許合約、定義允許函數操作和ACL驗證需求三大權限控制要素。同時，採用分離的治理機制，由Vault Guardian負責執行，而Governor控制治理權限，確保即便Guardian出現問題，也能及時採取補救措施保護用戶資產。類似的設計理念也在另一個安全模塊中得到應用，該模塊通過preExecute函數攔截關鍵操作，並借助白名單機制對模塊安裝、鉤子設置和驗證器管理等高風險操作進行精細管控，從而確保只有經過信任的合約才能被添加到系統中，爲錢包提供了持久的安全保障。

在某交易平台事件攻擊鏈中，若Safe合約部署了合理配置的Guard機制，攻擊者通過execTransaction發起的惡意delegatecall將在預檢階段被多重策略攔截：Guard的checkTransaction函數首先識別到delegatecall操作類型並觸發禁用規則（如強制限定operation僅爲普通調用），隨後解析data字段檢測到非常規合約地址及高危函數選擇器，通過預設的合約白名單與函數黑名單策略直接回滾交易，最終形成「策略攔截 → 邏輯阻斷」的防御體系，徹底阻斷存儲篡改與資金轉移路徑。

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

結論與展望

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

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

• 自動化驗證：建立自動化的交易驗證機制
• 動態策略調整：根據威脅情報實時調整安全策略
• 多層防御：結合多種安全機制構建深度防御體系
• 持續審計：對Guard實現進行定