Chainfeeds 導讀：
我們必須使用和攻擊者一樣的工具，對協議進行紅隊測試（Red Teaming），持續監控，並對潛在損失設定硬性上限，才能在最糟糕的情況下生存下來。
文章來源：
https://x.com/systematicls/status/2048756004972855667
文章作者：
sysls
觀點：
sysls：一旦你識別了不變量，將它們提升為運行時檢查。仔細思考哪些不變量實際上是可執行的。這就是 FREI-PI（Function Requirements、Effects、Interactions、Protocol Invariants）模式：在每一個涉及價值的函數末尾，重新驗證該函數承諾維護的核心不變量。許多能夠通過 CEI（Checks-Effects-Interactions）的攻擊（例如閃電貸夾擊、預言機輔助清算攻擊、跨函數償付能力抽乾），都會在函數末尾的不變量檢查中被捕獲。狀態化模糊測試（stateful fuzzing）會對協議的完整公開接口構建隨機調用序列，並在每一步斷言不變量。大多數生產環境中的攻擊都是多交易的，而狀態化模糊測試幾乎是唯一能在攻擊者之前發現這些路徑的可靠方法。使用不變量測試，驗證對於模糊測試生成的任何調用序列，某個性質都成立。同時配合形式化驗證，它可以證明該性質在所有可達狀態中成立。你的核心不變量絕對應該接受這種級別的驗證。複雜性是安全的敵人。每一個外部依賴都會擴大攻擊面。如果你在設計基礎設施，應該把「信任誰」的選擇交給用戶。如果無法移除依賴，就要多元化它們，避免單點失敗毀掉協議。將你的審計範圍擴展到模擬這些依賴如何失敗，並對其失敗情況下的最大損害設置限速。最新的 KelpDAO 攻擊就是一個例子：他們繼承了 LayerZero 的默認配置 requiredDVNCount=1，而這個配置存在於審計範圍之外。最終被攻破的是審計範圍之外的鏈下基礎設施。DeFi 中的大多數攻擊面其實已經被枚舉出來。逐一檢查每一個類別，問自己是否適用於你的協議，並實現對應的控制措施。構建紅隊能力，讓你的 AI agent 主動尋找協議中的漏洞 —— 這在當前階段已經是基礎要求。在基於投票的治理中，權力最初集中在團隊多籤中，並需要時間分散。即便代幣分佈廣泛，委託通常仍集中在少數幾個錢包（有時甚至是一個）。一旦這些被攻破，就結束了。部署「守護者錢包（guardian wallets）」，賦予其嚴格受限的權限：它們只能暫停協議，並且在 ≥4/7 的閾值下，在極端情況下將被攻陷的委託替換為預定義的錢包。守護者永遠不能執行治理提案。這樣，你就有一個救援層，可以在不推翻治理的情況下恢復系統穩定。當治理成熟且分散後，這一層可以被逐步移除。【原文為英文】
內容來源
