审计目标

一次 Solana 隐私池（privacy pool）协议审计。协议核心：用户提交零知识证明， 验证通过后由池子代为执行转账，实现「谁花的钱不可追踪」。审计要回答： 这个系统有没有办法被绕过或滥用？

审计框架：五个核查面

1. 零知识证明路径

ZK 电路是否真正验证了必要的约束？常见问题：电路只验证了一部分 witness， 或者验证了无关变量。对 Circom/Arkworks 电路，逐条对照约束方程与业务规则， 确认「验证通过 => 满足全部条件」成立。

2. nullifier 一致性

隐私池防双花的核心是 nullifier：同一笔承诺只能被花费一次。 审计重点：nullifier 是否在链上正确记录？是否有路径可以构造出相同的 nullifier 而不被发现？哈希输入顺序、域分隔符（domain separator）错位都会导致碰撞。

3. 费率与金额边界

金额计算是否可能溢出/下溢？费率取整是否导致「少扣费」或「多扣费」？ Solana 的 u64 算术要逐处检查溢出场景，费率计算要验证极端输入 （零金额、最大金额、频繁小额）。

4. 权限模型

谁可以调用管理函数？参数是否可被任意用户控制？Anchor 的 signer 检查、 program upgrade authority、close account 权限都要过一遍。

5. 状态一致性

池子的累计状态（总锁定、总花费）与成员账户状态是否可能不一致？ 异常路径（证明失败、重复花费、部分执行）后状态是否回滚干净？

报告标准：让修复者不猜

审计报告的每个发现都包含四要素，缺一不可：

• 严重度：Critical / High / Medium / Low，附带判定理由。
• 位置：文件 + 行号 + 代码片段。
• 根因：为什么这里是 bug，攻击者如何利用。
• 利用路径：从攻击者视角的完整调用序列，验证可达性。

工具与验证

• Anchor 测试框架：写 PoC 测试复现每个 High 以上问题，用真实执行证明可达。
• 静态扫描：grep 常见危险模式（unwrap、unchecked、裸 transfer）。
• 交叉复核：两个视角（开发者视角找遗漏，攻击者视角找路径）独立过一遍。

教训

审计的价值不在「找出多少行问题」，而在「让修复者拿到报告就能动手」。 严重度判断要保守——宁可把可疑的标 High 并说明依据，也不要漏报。 输出一份「带利用路径」的报告，比十页泛泛而谈的安全建议有用得多。