适用范围与审计起点
区块链审计流程涉及哪些技术概念，取决于审计对象。本文聚焦以太坊智能合约的代码与权限审查，不覆盖共识协议或整条区块链的安全评估。审查首先需要理解合约预期行为、敏感操作及调用者权限，才能判断实现是否符合设计。
Ethereum.org的智能合约安全说明强调，应结合权限保护、测试与独立审查；任何单一方法都不足以发现全部缺陷。这意味着审计需要围绕明确的安全目标组织证据。
访问控制：谁能执行敏感操作
访问控制区分函数可以被调用与调用者获准执行操作。公开函数仍可在执行敏感逻辑前检查身份。Ownable适合单一管理主体，基于角色的访问控制则适合拆分不同职责。
OpenZeppelin的访问控制文档说明，角色持有者与角色管理员具有不同权限；所有权转移、放弃以及默认管理员配置都影响管理能力。多签和两步所有权转移可用于加强相应控制。
因此，权限审查既要查看谁能执行操作，也要追查谁能授予这种权限。设置多个角色并不自动消除权力集中：若同一账户控制所有角色的分配，核心管理权限仍然集中。
状态不变量与异常回退
状态不变量是合约运行过程中应持续成立的约束，例如设计要求中的供应量上限。它将抽象的安全目标转成可检查的条件。
require通常用于校验输入、权限或前置条件，assert用于检查内部逻辑应当成立的性质，revert用于主动触发异常回退。审计需要判断条件是否完整、检查位置是否合适，以及异常是否按预期处理；写有断言本身并不能证明逻辑安全。
静态分析、动态测试与形式化验证
静态分析不直接执行合约，而是借助抽象语法树、控制流图等表示检查代码结构与执行路径。动态分析通过运行代码观察行为；模糊测试生成大量变化的输入，寻找违反安全性质的情况。
单元测试适合验证已知场景，性质测试关注不同输入下约束是否持续成立。形式化验证进一步把目标写成数学规格，并证明模型满足这些规格。其结论受规格、模型和假设约束，不能扩展成对所有风险的保证。
常见问题：审计通过是否等于安全
审计是额外的独立检查，不能保证发现所有漏洞。阅读结论时，应关注被检查的代码版本、安全目标以及尚未解决的问题。代码修改后，原结论也不能自动覆盖新增行为。
工具未报告异常同样不等于没有缺陷。工具检查、人工理解与测试各有覆盖范围；让每项安全目标对应具体检查证据，才能使审计结果更容易解释和复核。