DSS Webinar | Automation Security with Brahma, CoW Swap & Mimic

本次 D5 安全峰會（DeFi Security Summit）網絡研討會聚焦於自動化在 DeFi 生態中的關鍵角色，以及如何在安全與易用性之間取得平衡。

DeFi 自動化的現實困境源於信任問題。用戶需要自動執行 DCA 投資、清算風險頭寸、收益優化等重複任務，但現有解決方案極不完善。大多數開發者手寫自定義腳本來調用智能合約，但這些腳本通常只有編寫者和少數高級開發者能夠理解，代際傳承時難以維護，且每個人對實現方式的理解都不同。更嚴重的是，這些腳本需要將私鑰存儲在服務器上（偶爾使用 AWS KMS 或 Hashicorp 這樣的密鑰管理系統），但實際上大多數仍直接存儲在服務器，一旦洩露就會導致資產盜竊。此外，鏈下數據來源（如資產價格）和鏈上數據（如 RPC 查詢）都不可靠，RPC 經常返回過時或未確認的數據，導致自動化執行失敗。

Mimic 的解決方案是一個三層無需信任自動化協議，其核心理念是完全消除用戶對服務商的信任依賴。在規劃層，開發者使用 Rust 語言和 Mimic 提供的庫編寫任務邏輯，編譯成 WebAssembly，然後發佈到註冊表。任務支持多種觸發條件：基於時間（每天、每周、自定義頻率）、基於鏈上事件（監聽特定合約事件）、基於資產價格變動、基於賬户餘額閾值。在執行層，Mimic 運營著一個中繼器網絡，這些中繼器根據設定的觸發條件競爭執行任務。任務執行時可以訪問 Mimic 的預言機網絡（聚合多個獨立預言機的數據源）和各種預定義意圖（互換意圖、跨鏈交換意圖、通用調用意圖、轉賬意圖等）。預言機允許開發者靈活地應用聚合邏輯，比如計算中位數、平均值或最大值。執行層還包含驗證器網絡，驗證器也運行相同的任務來確保中繼器的執行符合用戶預期。驗證器無需查詢用戶賬户，只需驗證時間觸發、數據完整性等基本條件。一旦獲得足夠的驗證結果，中繼器生成的「意圖」（Intent，即交易意願的抽象表達）就被拍賣給求解器網絡。求解器相互競爭為用戶爭取最優價格：互換時滑點更低、轉賬時手續費更少。最終意圖進入安全層執行，這是整個架構最關鍵的部分。結算智能合約驗證求解器能否實現意圖所述的一切，確保所有餘額變化符合預期。更重要的是，開發者可以定義安全保障措施——本質上是鏈上規則，限制單次交易金額、禁止調用某些函數、只允許調用特定選擇器。這些限制在鏈上強制執行，任何人都無法繞過。用戶可以用 TypeScript、Rust 或任何支持編譯成 WASM 的語言編寫代碼，然後安心將資產交給自動化流程，因為安全保障措施保證了只有授權操作才能執行。

Brahma 的方案則著眼於實際生產環境中自動化的複雜性。他們在過去四年裡反覆遇到三大難題。第一是密鑰管理。如果服務直接持有用戶的私鑰，那麼服務的任何漏洞都會導致大規模資產盜竊。Brahma 為此開發了 Hashicorp 密鑰管理系統的以太坊專用插件：服務不再請求私鑰，而是向 Hashicorp 發送簽名請求，由 Hashicorp 在其安全環境中生成簽名，然後返回給服務。這樣服務完全無法接觸私鑰，大幅提升了安全模型。第二是高吞吐量下的交易並行化。在單個密鑰對的情況下，每次交易都需要遞增 Nonce，但 RPC 經常返回過時的數據。例如第一筆交易已提交但仍在 Mempool 中等待確認，RPC 卻仍報告舊的 Nonce，導致第二筆交易簽署時 Nonce 衝突，最終交易失敗。Brahma 的解決方案是使用多個守門員（密鑰對），採用輪詢方式：key 1 發送 nonce 1、key 2 發送 nonce 2，以此類推，每個密鑰對可以並行執行。但這帶來了新問題：用戶原本的委託權限分散在多個密鑰對上，難以管理和輪換。因此 Brahma 在中間設置了一個執行合約（基於 Safe 多簽），用戶只需向執行合約一次性授予委託權限，而不管背後有多少個守門員。這創造了 1 對 N 的架構：一個執行合約持有所有授權和委託，多個守門員可以與之並行交互，既保持靈活性又簡化了用戶體驗。

第三個難題是交易驗證。為了進一步提升安全性，Brahma 使用智能合約錢包代替 EOA（外部賬户）。在這個模型中，用戶的資產由一個 Safe 多簽錢包（或其他兼容 ERC-4337 的智能合約錢包）管理。Brahma 為 Safe 開發了交易卡（Transaction Guard）插件，可以在交易執行前後進行檢查。簽署前，用戶可以掃描驗證碼確認交易內容（如批準哪個代幣、數額多少）。執行後，交易卡檢查 EVM 狀態變化：賬户餘額是否減少預期金額、是否獲得了預期的代幣、總資產是否按預期減少。此外，所有交易在後端進行完整模擬，確保符合既定政策（如支出限額、白名單地址等）後才生成簽名。這套防護機制完全在鏈上強制執行，確保即使服務端出現故障或被攻擊，用戶資產也不會被意外轉賬或批準到非預期地址。

Brahma 最新的 Swipe 產品展示了這套架構如何應用於實際場景。用戶在 Swipe 上註冊後，可以申領一張 Visa 卡，並委派一定金額的資產給 Swipe（可以是 USDC、借出資產換取的 USDC 等）。當用戶在咖啡店或其他銷售點用 Apple Pay 付款時，Swipe 收到交易通知，在 800 毫秒內完成一系列檢查：驗證交易金額是否在用戶委派的範圍內，檢查錢包是否有足夠的資金（若資金來自借貸頭寸，將其兌換為 USDC），最後與 Visa 結算。整個過程對用戶來說完全透明，體驗如同使用傳統信用卡，但資金實際上來自鏈上資產。

談及 AI 代理時，兩個項目都認為直接給 AI 無限權限是危險的。Mimic 的做法是讓 AI 在預定義的任務中選擇和執行，而不是讓 AI 自由編寫任務代碼；Brahma 的做法是通過執行合約的嚴格限制和安全保障措施（如金額上限、地址白名單）約束 AI 的行為。共同點是，AI 代理在既定護欄內工作，無法超越用戶預先定義的邊界。