如何界定智能合约审计范围：审计师需要的资料

你已完成了构建。你向三家审计公司询价。第一家报价 25,000 美元，两周内完成。第二家报价 90,000 美元，六周以上完成。第三家要求先开启动会，然后才肯报价。

报价差异并不是因为其中两家收费过高，而是因为三家公司都在猜测——其中一家猜得比另外两家更仔细。

审计的价格和时间表并不是在你签署委托书时确定的，而是在审计师在你的代码仓库中花第一个小时时确定的。如果他们把那一小时花在反向工程你的意图上，那你就是在支付高级安全研究员的费用让他们去读你的心思。如果他们把它花在攻击你的信任边界上，那你就物有所值。

这是一份确保结果是后一种情况的指南。

范围界定实际上决定了什么

范围界定是审计公司在报价前用来回答三个问题的过程：

• 我们审查哪些合约，在哪个确切版本的代码上？
• 这个代码面需要多少审计师-天？
• 团队已经知道什么我们不必重新发现？

输出是一份范围文档、一份报价和一个时间表。输入是在第一次通话前你提交的所有内容。Sherlock 发布的指南给出了一个数字：当团队带着清晰的范围到来时，他们的审阅者可以节省一到两天的注意力用于处理更深层的问题，而不是基本的定位。在整个行业中，清晰的准备可以将最终成本降低 15–30%。

这不是营销宣传。这是审计师发现你清算逻辑中的经济漏洞与审计师仍在弄清楚哪个合约包含清算逻辑之间的区别。

每位审计师都需要你提供的七项内容

这些是 Hacken、ConsenSys Diligence、OpenZeppelin、Quantstamp、Trail of Bits 和 Nascent 发布的准备就绪检查清单中一致出现的交付物。当这七项全部具备时，审计公司报价更快、收费更低、报告质量更高。

1. 冻结的提交哈希和明确的范围边界

每家主要公司都要求这一点。没有例外。

Quantstamp 明确声明：智能合约审计始终在冻结的代码库上进行，这是特定提交哈希上的一个时间快照。在审查期间或之后所做的任何更改都可能引入审计从未检查过的攻击向量。ConsenSys Diligence 一旦审计开始就不允许更改范围。Sherlock 称提交固定是“不可协商的”。

原因是机械性的。如果你的代码在审查过程中发生变化，审计师将失去对整个系统进行推理的能力，并且随着他们重新追溯每次修改的影响，时间表会延长。上周针对 main 分支编写的发现可能不适用于下周的 main 分支。

你需要提交的内容：

• 完整仓库 URL
• 分支名称
• 确切的提交哈希
• 范围内的文件路径（每个 .sol 文件、每个库、每个接口）
• 明确不在范围内的文件路径（前端、链下索引器、你未修改的第三方依赖）
• 范围内提交中的部署脚本和升级脚本——Nascent 的检查清单明确指出部署和升级与运行时代码同样重要，需要同样的安全关注

如果某些模块必须并行开发，请将它们推送到单独的分支并从范围内提交中排除。不要要求审计师审计 main 分支并“忽略新内容”。我们的审计前检查清单详细介绍了我们推荐的精确标记和冻结命令。

2. 一条命令即可运行的可重现构建

Hacken 的方法直接阐明了目标：提供一个新工程师可以克隆、设置并运行而无需手动猜测或本地变通的仓库。

Cyfrin 的审计实践也确认了同样的观点——审计师做的第一件事是本地构建项目并运行测试套件。如果由于未记录的私有依赖、未指定的 Node 版本或缺失的 .env 模板而需要两天时间，那么这两天的资深研究时间将由你为 DevOps 工作买单。

具体的交付物：

• 一个 README，包含一条命令安装和构建步骤
• 已记录的 Solidity / Rust / 框架版本
• 已提交的 Foundry、Hardhat 或 Anchor 配置
• 任何所需密钥的 .env.example（RPC 端点、分叉 URL、API 密钥）
• 关于测试网、主网分叉和任何 RPC 需求的说明
• 明确记录任何私有依赖的设置步骤

如果 forge build 在新克隆的仓库上无法成功，说明你还没有准备好进行审计。

3. 具有可见覆盖率的测试套件

Quantstamp 发布的目标是 100% 的行覆盖率。这对大多数团队来说是理想目标，但原则不是：编写良好的测试可以降低审计的时间和成本，因为审阅者可以看到开发者认为关键的内容以及存在差距的地方。

在实践中，Cyfrin 的框架更有用：测试是协议的心跳。它们揭示了开发者重视什么，并且检查测试覆盖率通过显示哪些角落未被覆盖来暴露代码库中更脆弱的部分。

审计师期望看到的内容：

• 覆盖正常路径和回退路径的单元测试。所有测试通过。
• 生成并可见的覆盖率报告。不要隐藏差距——审计师无论如何都会发现它们，可见的差距比隐藏的差距处理起来更快。
• 模糊测试。Foundry 不变性测试或 Echidna 有状态模糊测试。Nascent 的检查清单将其视为基线，而非加分项。
• 针对协议依赖的外部活动合约，进行针对主网状态的集成 / 分叉测试。
• 针对本地节点或测试网进行端到端测试的部署脚本。

一个提交了已经在模糊测试下测试其不变量的测试套件的协议，要求审计师进行更高级别的审查，而不是只提交五个单元测试和一个 TODO 文件的协议。如果你对模糊测试不太熟悉，我们的指南模糊测试如何增强 Web3 安全性涵盖了“基线模糊测试”的实际样子。

4. 三层文档

文档不是一项交付物。它是三项，审计师期望全部三项。

第一层——高层规范。协议应该做什么？Hacken 的方法将其分为功能需求（用于评估正确性的基线，以清晰的、可测试的形式编写）和技术描述（系统内部如何工作，为安全分析提供上下文）。Dedaub 向客户明确表示，如果你没有清楚地传达，审计师将不知道你的规范——你的数学公式、你的期望行为。当正确计算的定义没有给出时，审计很可能会遗漏对功能正确性的违反。

第二层——架构图。继承层次结构。合约互连。状态转换。系统中的价值流动。外部调用跨越信任边界的位置。OpenZeppelin 的准备指南期望这些。每个认真对待架构审查的检查清单也是如此，因为生产环境中 DeFi 系统中影响最大的漏洞很少是孤立的 Solidity 陷阱——它们是关于各部分如何组合在一起的假设的失败。

第三层——代码级文档。每个公共和外部函数上的 NatSpec。Solidity 编译器只解析 public 和 external 接口上的 NatSpec 标签，但 Nascent 和 OpenZeppelin 都建议记录实现敏感逻辑的内部函数。在风险集中点的内联注释——不受信任的外部调用、敏感计算、任何出现 unchecked 或 assembly 的地方。

ConsenSys Diligence 用直白的话说明了跳过这一点的成本：未能澄清代码注释中的意图迫使审计师花更多时间尝试理解。这增加了范围并推高了成本。

5. 角色和权限表

这是最高杠杆的审计前交付物之一，也是最常缺失的之一。

Rekt 测试的第一个问题是，你是否记录了所有参与者、角色和权限。Trail of Bits 的指导直接指出：通过回答这个问题并编写文档，团队可以发现表面上容易实现的目标——不一致的假设、实际负责哪些函数的角色之间的差距，以及谁应该和不应该访问什么。

一张角色表就是一页纸。列包括：

• 角色名称（所有者、管理员、暂停者、财务主管、守护者、用户）
• 地址类型（多签阈值、EOA、合约）
• 该角色可调用的函数
• 信任假设（例如“假定非恶意”、“假定在时间锁内行动”）
• 如果被攻破的连锁反应（例如“可以铸造无限供应”、“可以暂停提款 24 小时”）

Trail of Bits 自己发表的关于访问控制成熟度的研究表明，由区块链原生公司进行的审计很少将架构访问控制问题作为正式发现上报——这意味着如果你自己不提出特权函数，即使审计师发现了它们，也可能不会写下来。角色表迫使对话摆在桌面上。

6. 不变量列表

不变量是系统必须始终为真的陈述，无论调用哪些函数或以什么顺序调用。总存款应等于总份额乘以份额价格。没有用户应提取超过他们存入的金额加上应计收益。协议永远不应进入欠款超过持有量的状态。

ConsenSys Diligence 的框架：识别这些不变量有助于审计师头脑风暴可能违反安全属性并导致漏洞的用户操作。Sherlock 的建议相同——给审计师一个清晰的规范，包括不变量陈述（“这必须始终为真”），并记录信任角色和升级路径。

Rekt 测试的第 9 个问题是，你是否为系统定义了关键不变量并在每次提交时测试它们。如果答案是肯定的，提交不变量套件。如果答案是否定的，即使你还没有测试它们，也要写下不变量——列表本身就有价值。

Nascent 推荐使用 FREI-PI 模式（功能需求-效果-交互-协议不变量）来实现这一点：将所有代币和 ETH 转移视为交互，然后验证你的系统级不变量在每次交互结束时仍然成立。无论你是否采用了这种模式，不变量列表都是审计师用来设计对抗性测试用例的工具。要更深入地了解不变量和形式化方法如何交互，请参阅我们关于区块链安全中的模糊测试和形式化验证的文章。

7. “已知可接受问题”列表

这是防止浪费发现的交付物。

Nascent 的检查清单给出了模型：写下无关的安全假设。他们的示例涵盖了从预言机行为到链重组深度的所有内容：我们假设所有者不是恶意的，Chainlink 预言机不会对价格撒谎，Chainlink 预言机会在每 24 小时内至少报告一次，所有者批准的所有代币均符合 ERC20 标准且没有转账Hook，以及永远不会有超过 30 个区块的链重组。

Sherlock 的立场：列出公开的担忧给审计师一个更清晰的目标，并常常导致更强的发现。隐藏它们会拖慢一切，迫使审阅者重新发现你已经怀疑的事情。

没有这个列表，审计报告将包含团队三个月前已经评估并接受的中等严重性发现。每个发现都消耗审计师编写的时间、团队响应的时间，以及本可以用于真正的漏洞路径的报告空间。有了这个列表，审计师第一天就知道你的信任边界，并将审查时间花在压力测试假设是否实际成立上。

什么决定了价格

一旦范围确定，报价主要是五个变量的函数。

1. 代码库大小，以 nSLOC 衡量。非注释源代码行数是各家主要公司的主要定价驱动因素。Sherlock 发布的时间指南直接映射了这一点：

超过 6,000 nSLOC，持续时间不再线性增长——复杂性呈指数增长，Sherlock 会建议拆分范围或顺序审查。Sherlock 使用 Solidity Metrics 工具来计算 nSLOC；如果你想预测自己的报价，请在请求报价抢跑它。

2. 逻辑密度。一个 500 行的 ERC-20 不等同于一个 500 行的跨链桥。样板代币逻辑是一个已解决的问题，定价为 5K-15K 美元。同样行数处理跨链状态同步、ZK 证明验证或自定义 AMM 数学的代码，价格可以翻三倍。审计师对代码的难度定价，而不仅仅是长度。

3. 语言和链。Solidity 拥有最深的审计师池，这稳定了价格。Solana 上的 Rust 需要 25–40% 的溢价，因为合格的审阅者更稀缺。Cairo 和 Move 的定价比 EVM 等价物高 30–45%。ZK 电路——circom、Halo2、Plonky2——比 Solidity 基线高 80–120%，因为密码学专业知识很稀有。

4. 外部集成。你的合约触及的每个预言机、桥梁或外部协议都会扩展审计师需要内化的威胁模型。一个 600 nSLOC 的 Uniswap v4 hook 不是一个 600 nSLOC 的范围，如果 hook 的行为依赖于 PoolManager 内部细节。Sherlock 的框架：表面上看起来很小的范围，在计算集成依赖关系后往往会扩大。

5. 时间紧迫性。要求两周完成原本需要六周的范围，意味着要从其他项目中抽调高级工程师。Sherlock 对此加收 20–40% 的基础费用。其他公司报价 10–30%。如果你已经规划了安全预算但没有规划安全日历，那么日历上的延误会让你付出代价。

一个 2026 年市场的参考表，交叉参考了 Sherlock、Zealynx 自己的定价数据以及 Hacken 和 Hashlock 的公开报价：

重新审计这一行是最常被遗忘的预算项目。至少计划一次修复；复杂协议通常需要两次。我们的文章智能合约审计实际成本是多少更详细地分解了重新审计这一项。

在请求报价抢跑 Rekt 测试

在填写任何范围文档之前，先在内部运行 Rekt 测试。

Rekt 测试是 Trail of Bits、Fireblocks、Immunefi、Anchorage Digital、Solana Foundation 和 Euler Labs 发布的十二个是/否问题。它是事实上的行业门槛，用于判断一个项目是否真正准备好接受外部审查。几家审计公司——Cyfrin 和 Nascent 都公开表示——建议那些对大多数问题无法回答“是”的团队推迟审计，直到他们能够回答为止。

十二个问题：

1. 你是否记录了所有参与者、角色和权限？
2. 你是否保留了所有依赖的外部服务、合约和预言机的文档？
3. 你是否拥有经过编写和测试的事件响应计划？
4. 你是否记录了攻击系统的最佳方法？
5. 你是否对所有员工进行身份验证和背景调查？
6. 你是否有一个团队成员在其角色中明确包含了安全职责？
7. 你是否为生产系统要求硬件安全密钥？
8. 你的密钥管理系统是否需要多个人员参与和物理步骤？
9. 你是否为系统定义了关键不变量并在每次提交时测试它们？
10. 你是否使用最好的自动化工具来发现代码中的安全问题？
11. 你是否接受外部审计并维护漏洞披露或漏洞赏金计划？
12. 你是否考虑并减轻了滥用你系统用户的途径？

问题 1、2、4、9 和 10 直接映射到本指南中的范围界定交付物。其他问题涉及操作成熟度，审计师越来越多地将其纳入对团队是否能胜任修复反应的评估。

对其中任何一个问题回答“否”都不是不进行审计的理由。而是要知道你带着什么进入审计。

审计师实际想要的范围文档

业界最接近标准化范围文档的是 Code4rena 用于其竞争性审计准备的表格，Nascent 将其发布为其审计准备检查清单的第二部分。在第一次销售通话前填写这个表格，大约完成了审计公司在范围界定期间本需要做的 60% 的工作。

字段包括：

• 公共代码仓库 URL
• 范围内的合约数量
• 这些合约的总 SLoC
• 外部导入的数量
• 独立接口和结构体定义的数量
• 组合 vs 继承（哪个占主导）
• 外部调用的数量
• 测试的总体行覆盖率百分比
• 是否需要理解代码库的单独部分以提供上下文，如果是，是什么
• 预言机使用情况（哪个提供商、备用行为、陈旧性处理）
• ERC20 标准合规性（是/否/哪些偏差）
• 与非标准 ERC（ERC721、ERC777、收费转账、基数调整）的交互
• 新颖的曲线逻辑或数学模型
• 时间锁使用情况
• NFT（是/否）
• AMM（是/否）
• 是否分叉了流行项目（是/否，哪个）
• Rollup 使用情况
• 多链（是/否）
• 侧链
• 你希望重点压力测试的特定领域（“请尝试破坏 X”）

最后一个字段使用不足但价值很高。如果你怀疑清算数学是最薄弱的环节，请说出来。审计师会花更多时间在那里，报告也会因此更犀利。

清晰的准备实际能为你带来什么

如果你提交上述七项交付物以及 Code4rena 范围文档，会发生三件事。

报价下降。来自 PixelPlex、Hacken 和 Sherlock 的交叉数据表明，根据初始条件，最终价格可节省 15–30%。对于一个 10 万美元的中等复杂性 DeFi 审计，那就是 1.5万–3万美元——比一次重新审计的成本还多。

审阅者的注意力向上转移。Sherlock 的数据点是，从定位和重新范围界定中节省出一到两天的资深审阅者时间，重新用于对抗性审查。在一个三周的委托中，这大约是整个审计窗口的 10%，从设置阶段转移到攻击面分析阶段。

报告质量提高。已经理解意图的审阅者可以用“这违反了协议不变量，即总债务不能超过总抵押品”这样的表述来撰写发现，而不是“这看起来可疑，请确认预期行为”。具体的发现修复起来更快。

反之亦然。来自 Hacken、Sherlock 和 BlockchainAppFactory 准备指南交叉引用的五种最常见的准备失败：

1. 没有冻结的提交。团队发送仓库链接并说“审计 main 分支”。审计师每次推送都重新界定范围。
2. 未编写的不变量。团队知道必须保持什么但从未写下来。审计师要么从测试中推导出不变量，要么猜测。
3. 隐藏的特权角色。管理功能存在但未列举。Trail of Bits 标记这是架构发现被遗漏的头号原因。
4. 没有已知可接受问题列表。审计师报告了一个团队已经评估并接受的中等发现。浪费的发现，浪费的响应周期。
5. 过时或缺失的图表。唯一的架构产物是原始白皮书中的图表，而它来自三个主要重构之前。

每一项都会给委托增加天数。它们共同解释了在相似规模的代码库上，2.5 万美元报价和 9 万美元报价之间的大部分差异。

应该向审计师发送什么

一份有效的审计前资料包包含：

• 仓库 URL、分支、提交哈希
• 范围内文件列表、范围外文件列表
• 包含一条命令设置的 README
• 测试套件通过、附上覆盖率报告
• 模糊 / 不变量测试文件
• 白皮书或技术规范
• 架构图（当前版本，非过时）
• 每个公共和外部函数的 NatSpec
• 角色和权限表
• 不变量列表
• 已知可接受问题列表
• 部署和升级脚本
• 填写好的 Code4rena 风格范围文档
• 你希望重点压力测试的特定领域

如果你在请求报价时所有这些都已经存在，你就消除了审计师第一天的工作障碍。你得到的报价反映了攻击你的代码的实际难度，而不是理解它的难度。

这就是审计定价与安全风险成正比，而不是与文档债务成正比的版本。

与 Zealynx 合作

在 Zealynx，我们发布的每份报价都基于范围数据——本指南中的七项交付物正是我们在接收阶段要求的内容。准备充分的团队获得更快的周转、更低的报价，以及专注于真实攻击路径而非定位差距的报告。我们还帮助团队在承诺报价之前为高效的审计做准备。

请求有范围的审计报价 →

在请求报价之前，选择正确的下一步

选项 1，使用 Krait 自助检查准备状态

如果要在与任何审计公司交谈之前发现缺失的测试、薄弱的文档或不明确的范围驱动因素，请先使用 Krait。它运行我们接收团队使用的相同准备检查。

在 Krait 中运行免费的审计准备检查 →

• 最适合仍在收紧范围、测试覆盖率或发布时间的团队
• 在第一次销售对话之前减少审计师的适应时间
• 在承诺请求报价之前的具体下一步

选项 2，请求有范围的审计报价

如果你的合约、链和发布时间窗口已经确定，请求有范围的审计报价，我们将根据你的架构和时间表规划审查。

请求有范围的审计报价 →

• 最适合准备预订审计窗口的团队
• 对于已经知道需要专家审查的买家来说，是直接路径

常见问题：智能合约审计范围界定

1. 什么是智能合约审计范围界定，为什么它会在审计开始前决定你的价格？

审计范围界定是审计公司用来定义将审查哪些代码、在哪个确切提交、多长时间以及什么价格的过程。输出是一份范围文档、一份报价和一个时间表。输入是项目提交的材料：仓库细节、冻结的提交哈希、测试套件、文档、角色图和不变量列表。更好的输入产生更快的报价和更低的价格——审计前检查清单涵盖了如何准备它们。

2. 什么是冻结的提交哈希，为什么审计师在报价前要求它？

冻结的提交哈希是审计将针对其执行的确切、不可变的 Git 引用（例如 a3f4c1d...）。每家主要公司——Quantstamp、ConsenSys Diligence、Sherlock、Hacken——都要求它，因为发现只针对代码的固定版本才有意义。如果审计期间代码发生变化，审计师将失去对整个系统进行推理的能力，时间表会延长。像 main 这样的分支名称不是冻结的提交哈希——main 会移动；SHA 不会。

3. 什么是 nSLOC，它如何影响审计定价？

nSLOC 是非注释源代码行数——可执行的 Solidity（或 Rust、Cairo 等）行数，不包括注释和空行。Sherlock 和大多数竞赛平台使用 nSLOC 作为主要定价驱动因素。Sherlock 发布映射：~500 nSLOC = 3 天窗口，~3,000 nSLOC ≈ 18 天，~6,000 nSLOC ≈ 38 天。超过 6,000 时，复杂性呈指数增长，范围常常被拆分。在请求报价前对你的范围运行 Solidity Metrics，以便你可以检查公司返回的数字是否合理。

4. 审计师实际需要什么文档，如果我跳过一层会怎样？

三层：(1) 描述协议应该做什么的高层规范或白皮书，(2) 显示继承、合约交互和价值流动的架构图，(3) 每个公共和外部函数上的 NatSpec 注释，以及风险集中点的内联注释。缺少任何一层都会迫使审计师重构意图，从而增加成本。ConsenSys Diligence 特别将缺少第三层代码注释列为审计范围蔓延的头号原因之一。

5. 什么是智能合约不变量，为什么审计师在范围界定期间要求不变量列表？

不变量是系统必须始终成立以保持安全的陈述——例如，“总存款始终等于总份额乘以份额价格”或“没有用户可以提取超过他们存入的金额加上应计收益”。记录在案的不变量帮助审计师设计对抗性测试用例，精确探测你所关心的边界。它们还让模糊测试工具（Foundry、Echidna、Medusa）直接攻击系统属性。Nascent 的 FREI-PI 模式更进一步，在运行时强制执行不变量，而不仅仅在测试中。

6. 什么是“已知可接受问题”列表，为什么省略它会让你损失发现？

它是你的团队已经评估并选择接受的风险的书面列表——例如，“我们假设所有者多签不是恶意的”或“我们接受 Chainlink 可能不会比每 24 小时更频繁地报告价格”。没有这个列表，审计报告会包含团队已经评估过的发现，浪费审计师和团队的周期。Nascent 的审计准备检查清单将其作为明确的交付物。它还澄清了协议声明的信任边界——这正是审计师随后集中压力测试工作的地方。

7. 如何在不牺牲审查深度的情况下降低审计报价？

内部运行 Rekt 测试，冻结你的提交哈希，提交一个一条命令即可设置的仓库，记录不变量，构建角色表，并填写 Code4rena 风格的范围文档。交叉数据表明准备可节省最终价格的 15–30%。对于一个 10 万美元的审计，那就是 1.5万–3万美元——比一次重新审计的成本还多。我们的指南如何高效准备高效的智能合约审计按顺序介绍了准备步骤。

8. 什么是 Rekt 测试，它与审计准备有何关系？

Rekt 测试是由 Trail of Bits、Fireblocks、Immunefi、Anchorage Digital、Ribbit Capital、Solana Foundation 和 Euler Labs 发布的 12 问题自我评估。它涵盖文档、密钥管理、不变量、监控和事件响应。行业指导是，无法对大多数问题回答“是”的团队尚未准备好审计，应在请求报价前解决差距。自己弥补 Rekt 测试差距比支付审计师发现它更便宜。

术语表

查看完整术语表 →

• 原文链接： zealynx.io/blogs/audit-s...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～