Enhancing Test Coverage: A Framework for Effective Protocol Security | Dmitry Zakharov (MixBytes)

在 Web3 安全審計的實踐中，簡單的代碼覆蓋率指標往往給人虛假的安全感。Mix Bites 的 Dimitri 基於多年 250+ 審計案例，提出了一個系統性的框架來解決這個問題。他強調，編寫全面的安全測試需要三種截然不同的思維方式，而不是單純地追求測試覆蓋的百分比。

黑客思維的本質是轉變視角：不再作為按規範設計的開發者思考，而是作為想要破壞協議的攻擊者思考。這要求開發者問出四個關鍵問題。首先，識別權限漏洞——某些函數是否真的應該只由特定角色（如授權的 RO 或鏈下服務）調用？其次，檢查調用序列和頻率限制，以捕獲重入攻擊（reentrancy）或過度使用的風險。第三，檢驗輸入參數的邊界——比如一個接受 256 位整數但內部轉換為 8 位的函數，如果沒有限制最大值就會被利用。最後，識別哪些參數不應該由用戶控制，而應該由常量或管理員白名單控制。

形式驗證思維則完全不同。它要求從詳細的規範開始，明確協議在任何狀態下必須滿足的不變性。例如，在 Uniswap V4 這樣的交換合約中，輸出代幣數必須不超過合約余額；在接受用戶存款的協議中，內部托管變量應該等於實際合約余額。通過 Fuzz 測試或正式驗證工具持續驗證這些不變性，即使代碼在演變，協議的核心承諾也始終被保護。

系統架構師思維則關注整個系統生態。它假設所有外部集成都會在某個時刻失敗：預言機可能停止更新價格（Luna 危機）、鏈下服務可能引入錯誤（時間單位混淆）、跨鏈橋可能中斷、集成的協議可能升級並改變獎勵分配。開發者應該提前為每個外部依賴編寫模擬失敗的測試場景，確保協議能夠優雅地降級或回復。

實踐層面，Dimitri 建議先實現 80-90% 的代碼覆蓋率，確保基本功能正確，然後應用這三種思維方式的問卷逐層深化安全層。建立一份可復用的測試清單特別有價值——每當開發新版本時，這份清單可以快速確保所有已知的攻擊向量都被重新覆蓋。需要注意的是，並非所有思維方式都必須應用；例如，沒有外部集成的協議可以跳過系統架構師思維。但根據 Dimitri 的經驗，幾乎所有生產級協議都有外部依賴，因此三種思維方式通常都是必需的。