如何保护您的智能合约？ （安全检查表）

代码审计和形式验证

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 模板是否安全？不。许多流行的模板包含有关编译器版本、缺少修饰符或不安全传输语义的过时假设。每行都需要上下文验证。

问：我应该部署具有自毁功能的合约吗？自毁会带来不可逆转的风险。如果需要进行测试，请在主网启动之前使用编译时标志或条件编译永久禁用它。

问：我应该多久轮换一次实时合同的管理密钥？管理密钥轮换在部署后不适用，因为私钥不直接管理智能合约。相反，轮换治理签名者并通过限时提案更新多重签名阈值。