DeFi Security 101 - 2023 - 02 - Nat Chin

Nat 用攀岩作為貫穿全場的類比——攀岩需要繩索、快掛、登山扣來保護登山者，智能合約也需要多層工具來確保代碼安全。不同的是，攀岩的保護機制是物理的，而合約安全的保護機制是流程與工具。

規範（Specification）是整個防禦體系的基礎。開發者在寫代碼時往往會做出隱含假設——函數只能由所有者調用、入參必須在某個範圍內、某些數學計算應該成立。這些假設若只存在於腦中，會造成維護困難和漏洞。將假設明確文檔化的好處在於，未來當代碼庫增長時，規範能清楚地指出各個函數如何協同、何時應該回滾、邊界在哪裡。規範不是一成不變的；每次代碼變更都應該同步更新，就像添加新函數時應該寫單元測試一樣。若文檔過時而代碼更新了，就會出現「代碼是唯一真理來源」的混亂局面，難以判定新行為是否符合預期。

有了清晰的規範，單元測試的作用就是驗證實現是否真正遵循規範。單元測試應該涵蓋三類輸入：預期的正常輸入、邊界值（如 uint256 的 0 和 2^256-1）、以及意外或格式錯誤的輸入。目標是達到 100% 的語句和分支覆蓋率——這不只是數字遊戲，而是確保代碼在各種輸入下的行為都被檢驗過。單元測試最重要的優勢是防止未來的重構意外引入舊 bug；一旦測試失敗，系統會立即告訴你。

靜態分析工具 Slither 的角色是自動化掃描常見漏洞模式。Slither 內建 87 個檢測器，可以在數秒內掃描整個代碼庫，識別重入漏洞、危險的外部呼叫等問題。它的優勢在於速度快、可集成到 CI/CD 流程，缺點是無法判定「這個漏洞是否真的可利用」——它只能說「這裡違反了最佳實踐」。安全研究人員需要人工分類，決定是立即修復還是在文檔中註記「未來如果增加新功能，這裡會有問題」。

最具挑戰性的工具是模糊測試，代表深層的安全驗證。Echidna 根據開發者預先定義的不變性（例如「代幣總供應量永遠不變」或「用戶餘額不能為負」）自動生成隨機輸入，就像讓機器人來敲鍵盤測試。模糊測試比單元測試更全面，因為它不受開發者想像力限制，能發現邊界組合、組件交互中的微妙 bug。但代價是設置更複雜，故障排查也更難。

整個流程體現了一個核心理念：安全不是上線前的檢查清單，而是開發的每一步都要做的事。在寫規範時考慮邊界，在添加函數時寫測試，在提交前跑 Slither，在構建複雜模組時跑 Echidna。多層防禦各司其職，才能有效阻止漏洞。