合约审计：审计流程、静态工具、报告解读与竞赛生态

智能合约审计（Audit）是由独立安全专家在约定时间内，对冻结的代码进行系统性漏洞挖掘与架构评估，并输出报告的专业服务。必须建立正确预期： - 审计能做的：在投入时间内按行业方法论系统性寻找已知漏洞类别、评估架构与权限设计、指出与文档/规格不符的实现偏差。

• 审计不能保证的：不能证明「没有漏洞」。审计是时间受限的抽样深挖，审计后仍可能有未发现的问题；审计也通常不保证经济模型合理、预言机数据真实、团队不跑路、私钥不被盗。

因此正确的安全栈是：充分测试 → 静态分析 → 专业审计（甚至多家交叉审计）→ 公开审计报告并逐条修复 → 时间锁冻结期 → Bug Bounty → 持续监控，而不是「拿到审计报告就可以放心冲」。

正规审计的典型流程（你也可以用同一套来自审）： 1. 范围冻结（Code Freeze）：确定审计的精确 commit hash、合约清单、Solidity 版本与依赖版本。审计期间改代码会使结论失效。

2. 文档与规格：团队提供 NatSpec 注释、架构文档、预期不变量（如「总存款 == 总份额对应资产」）、信任假设（哪些外部协议/管理员被信任）。 3. 快速扫描：跑静态工具（Slither 等）、统计复杂度与外部调用面，建立全局地图。

3. 手动深度审查：逐函数数据流分析、状态机遍历、权限矩阵、经济逻辑推演、与已知攻击模式比对，这是最耗时的核心阶段。 5. 报告与修复：输出分级 findings；项目方修复，审计方复审（re-review）并在报告中记录每条的修复状态。

4. 交付与后续：最终报告公开；审计后任何代码变更都应重新审计，并建议设立冻结期与赏金。

Slither（Trail of Bits 出品）是 Solidity 最主流的静态分析框架，安装 pip install slither-analyzer 后，在项目目录执行 slither . 即可批量检测：重入隐患、未使用变量/死代码、危险的 delegatecall、任意外部调用、存储槽占用、继承链问题、弱可见性等几十个检测器，并能打印合约继承图（slither . --print inheritance-graph）与函数调用关系。

正确使用姿势： - 它是审计的起点不是终点：误报不少，每条结果需要人工判断是否真实可利用。 - 把它接进 CI，新增代码引入高危模式时自动报警。 - 配套工具：slither-read-storage 查代理存储槽布局；slither-check-upgradeability 专门检查可升级合约的存储碰撞、未使用初始化缝隙等问题。

同类还有基于 Python 的快速检测器、Solhint（lint，管风格与简单安全规则）。

除了模式匹配式的静态分析，还有更「数学化」的工具路线： - 符号执行（Symbolic Execution）：以 Mythril 为代表，把函数输入当作符号变量，沿每条执行路径建立约束，用求解器（SMT/SMT-like）判断「是否存在一组输入让攻击者获利/触发违规」。

它能发现一些人眼疏漏的路径组合，但面对循环、复杂数学和跨合约调用会遇到路径爆炸，运行几小时后超时是常态，误报与漏报并存。 - 模糊测试：上一章 Foundry/ Echidna 的路线，用执行换覆盖。

• 形式化验证（Formal Verification）：用数学证明「代码实现满足给定规约」，Certora、Scribble 等工具允许你写出不变量规则并让验证器穷举证明。它在高价值协议（稳定币、核心借贷库）中逐渐普及，但编写规约本身成本很高，且「规约写错」依然无济于事。

结论：工具是放大器不是替代品，最高价值的发现仍来自理解业务逻辑的人工审查。

专家级人工审查的三个核心视角： 1. 数据流分析（Taint Analysis）：从所有「污染源」（msg.sender、外部返回值、price、任意用户输入）出发，追踪数据如何流入「敏感汇点」（转账、delegatecall、mint、权限判断）。

路径上缺少校验就是漏洞候选。 2. 权限矩阵：画一张「角色 × 函数」的表——普通用户、owner、keeper、被授权合约分别能调哪些函数；再逐个检查越权路径。重点看 owner 权力是否过大、能否绕过经济规则、密钥被盗后的爆炸半径。

3. 状态机遍历：把协议画成状态图（如借贷仓位：无仓 → 有抵押 → 借款 → 部分偿还 → 清算 → 完全关闭），检查每个状态下能否到达不该到达的状态、能否跳过检查、能否重放、能否在边界条件（0、最大值、首次）打破会计守恒。

全程不断追问三个问题：钱在哪？谁能动？怎么证明会计恒等式成立？

一份审计报告的主体是 Findings 列表，每条通常含标题、严重程度、位置（文件:行）、代码片段、攻击场景描述与修复建议。行业通用五级分类： - Critical（严重）：可直接导致资金被盗/永久冻结、权限被完全接管。

• High（高危）：特定条件下造成重大资金损失或协议不可用（如预言机操纵、重入、会计错误）。 - Medium（中危）：损失有限、需特定前提的问题（精度损失、边界 DoS、部分中心化风险）。

• Low（低危）：基本不影响资金但违反最佳实践。 - Informational / Gas：建议项与 Gas 优化。

阅读要点：看每条 finding 的状态列（Resolved 已修复 / Acknowledged 已知晓不改 / Partially 部分修复）；Medium 以上 Acknowledged 的项目要警惕；报告日期与审计 commit 要能和上线版本对应。

专业审计供给主要有两种形态： 1. 审计公司：Trail of Bits、OpenZeppelin、Spearbit（现属 Macro）、Cyfrin、Consensys Diligence、慢雾（SlowMist，亚太项目覆盖多）、CertiK 等。

按人周报价、排期常需数周，大额协议还会做「多家交叉审计」。注意：公司名气不等于具体项目质量，看具体报告与参与人员。 2. 审计竞赛（Audit Contest / Crowdsourced Audit）：把冻结代码公开，成百上千名安全研究者在限定时间内独立找漏洞，按严重程度分配奖池。

代表平台：Code4rena（竞赛模式开创者）、Sherlock（竞赛 + 保险式保障）、CodeHawks（Cyfrin 旗下）、Cantina。

竞赛模式覆盖视角广、性价比高，已成为新项目标配，很多顶级审计师都从参赛成长起来。

对学习者而言：这些平台公开了海量历史竞赛的报告与代码，是最好的免费实战教材。

技术审计默认「代码按预期执行」，但大量真实损失发生在代码「正确执行」时： - 经济与机制风险：代币激励设计导致死亡螺旋、抵押品流动性枯竭、清算拍卖失效、跨链桥增发无约束、治理被低投票率的闪电贷/借贷票仓控制。

这些需要经济建模与博弈分析，普通代码审计不覆盖。 - 中心化密钥（Admin Key）风险：owner 若是单个 EOA，密钥被盗或团队作恶即可升级合约转走资金、暂停提现、修改费率。检查三件事：① 管理权限是否由多签（如 Gnosis Safe）持有及签名阈值（3/5、5/9）；② 敏感操作是否经 Timelock（时间锁）延迟执行，给用户留出撤离窗口；③ 是否设有紧急暂停且暂停权是否去中心化。

• 依赖风险：预言机停摆、抵押品被项目方冻结、跨链消息层被攻破。 读项目时把「权力清单」当审计报告的第二份必读文件。

审计通过不等于终点，上线日的标准清单： 1. 确认部署字节码与审计 commit 完全一致（验证源码 + 比对 bytecode）。 2. 初始化参数复核：地址、费率、预言机地址、上限——参数配错和代码漏洞一样致命。 3. 权限交接：owner 从部署 EOA 转移到多签；确认 Timelock 已连接；废弃未使用的私钥。

4. 灰度策略：先设存款上限/小 TVL 限制，观察一到两周再放开。 5. Bug Bounty：在 Immunefi 等平台开设赏金，白帽提交漏洞有合法奖励通道，Critical 赏金通常为资金量的 5%-10%。

5. 持续监控：链上监控服务（如 Forta、Tenderly Alerts、OpenZeppelin Defender Sentinel）监听大额转账、暂停事件、权限变更、异常函数调用，触发即告警到值班群，并与第 6 章的应急预案联动。

安全是持续过程，不是一次性交付物。