一、先明确审计的对象
区块链审计方法相关术语如何理解，首先取决于检查对象。本文讨论智能合约代码及权限设计，不涉及财务审计，也不据此评价整条区块链的安全性。以太坊开发者安全文档将测试、形式化验证和独立代码审查列为安全保障手段，它们提供的证据各有边界。
二、静态分析与动态分析
静态分析通过代码结构推查潜在问题；动态分析运行代码并观察实际行为。前者适合检查程序路径和结构，后者适合观察特定输入与状态下的执行结果。两者关注角度不同，可以相互补充。
理解相关报告时，应区分“发现可疑路径”和“已经复现错误”。静态分析的提示需要结合执行条件判断；动态分析没有触发异常，也只能说明已执行的场景未发现该异常。
三、单元测试、模糊测试与不变量
单元测试检查选定功能在预设场景下是否符合预期。模糊测试通过生成大量变化的输入探索异常。基于属性的测试关注某条规则是否持续成立；不变量则表示在规定状态或操作边界上应始终成立的条件。
例如，若合约设计规定某项操作仅限管理员，检查正常管理员调用只是一个场景，还需考虑未授权账户及角色变更后的行为。这个例子说明测试目标如何展开，并不代表任何具体合约已经满足这些要求。
require 通常用于检查输入、权限或执行条件，assert 用于检查内部应当成立的断言，revert 用于主动终止并回退相应执行。使用这些语句仍需要正确表达业务规则。
四、形式化验证的适用条件
形式化验证使用明确的规格和数学方法，证明模型满足指定性质。它适合能清楚表达安全要求的场景，例如某种权限限制或状态约束。
常见误解是把“证明某项性质”理解成“证明整个系统绝对安全”。结论受规格、模型和假设约束；遗漏的业务规则或未纳入模型的外部交互，不能自动获得同样的保证。
五、访问控制与独立审查
OpenZeppelin 访问控制文档区分了单一所有者机制 Ownable 与按角色分配权限的 AccessControl。角色管理还涉及谁能授予或撤销角色；DEFAULT_ADMIN_ROLE 默认管理其他角色，也管理自身，因此需要重点检查其权限归属。
角色数量多不等于权限分散。如果同一账户最终控制全部角色，关键权限仍可能集中。多签强调多人共同授权，与按职责划分角色解决的问题不同。
独立审计提供额外审查，漏洞赏金鼓励外部发现并报告问题。阅读审计结论时，应关注所检查的代码范围、采用的方法及问题修复情况；“未发现问题”不能等同于所有可能的缺陷都已排除。