如何保護您的智能合約？ （安全檢查表）

代碼審計和形式驗證

1. 在部署前聘請多個獨立安全公司進行手動代碼審查。

2. 應用 Certora 或 MythX 等形式驗證工具以數學方式證明關鍵不變量的正確性。

3. 使用檢查-效果-交互模式確保所有外部調用都針對重入向量進行驗證。

4. 審核所有導入的庫（包括 OpenZeppelin 合約）是否存在特定於版本的漏洞。

5. 維護一個不可變的審計跟踪，將每次提交鏈接到其相應的驗證報告和時間戳。

訪問控制和權限管理

1. 使用審計標準中的 Ownable 或 AccessControl 模式實施基於角色的訪問控制。

2. 嚴格區分管理功能和麵向用戶的邏輯——公共入口點不得進行特權操作。

3. 暫停、升級或提取資金等敏感操作需要多重簽名批准。

4. 定期輪換管理密鑰並使用硬件安全模塊將其離線存儲，而不是存儲在 GitHub 存儲庫或純文本文件中。

5. 在鏈上記錄每個權限更改，並提供完整的上下文：調用者、時間戳、目標角色和以前的所有者。

Gas 優化和運行時保障

1. 避免無界循環，因為無界循環可能會在執行過程中導致氣體耗盡故障——使用分頁或上限迭代。

2. 對外部調用插入明確的 Gas 限制，以防止通過無限後備循環進行 DoS。

3. 在處理數組或字符串之前驗證輸入長度和範圍，以避免堆棧溢出或靜默截斷。

4. 對涉及用戶提供的值的所有算術運算使用 SafeMath 或 Solidity 0.8+ 內置溢出檢查。

5. 部署時啟用恢復字符串以幫助調試，而不會在生產錯誤消息中暴露敏感邏輯。

可升級性和代理模式

1. 僅當升級邏輯必須與業務邏輯完全解耦時才首選透明代理。

2. 將代理管理地址存儲在單獨的、強化的合約中（而不是存儲在代理本身中），以防止未經授權的升級。

3. 主網啟動後凍結升級能力，除非受具有法定人數強制投票期的時間鎖定 DAO 管轄。

4. 在部署新邏輯之前，使用 slither 或 crytic-tool 驗證實現之間的存儲佈局兼容性。

5. 絕不允許自毀或委託調用任意地址（即使在升級功能中），除非明確列入白名單並記錄。

監控、警報和事件響應

1. 通過 Tenderly 或 BlockSec 集成實時事務跟踪以檢測異常狀態轉換。

2. 針對突然餘額下降、意外所有權轉移或重複恢復等關鍵情況設置鏈上事件觀察器。

3. 通過加密通道將警報發送給指定響應者，而不是公共 Slack 或 Discord 群組。

4. 維護預先簽署的緊急暫停交易，以便在確認洩露後幾秒鐘內廣播。

5. 使用由治理多重簽名簽名的 IPFS 支持的 Merkle 根，每週歸檔所有歷史狀態快照。

常見問題解答

問：我可以僅依靠 Slither 或 Mythril 等自動掃描儀嗎？自動化工具可以捕獲已知模式，但會錯過代幣經濟學或交互模型特有的邏輯缺陷。人工審查仍然至關重要。

問：不加修改地使用 GitHub 上的 ERC-20 模板是否安全？不。許多流行的模板包含有關編譯器版本、缺少修飾符或不安全傳輸語義的過時假設。每行都需要上下文驗證。

問：我應該部署具有自毀功能的合約嗎？自毀會帶來不可逆轉的風險。如果需要進行測試，請在主網啟動之前使用編譯時標誌或條件編譯永久禁用它。

問：我應該多久輪換一次實時合同的管理密鑰？管理密鑰輪換在部署後不適用，因為私鑰不直接管理智能合約。相反，輪換治理簽名者並通過限時提案更新多重簽名閾值。