先确定审计检查什么
理解区块链审计术语，首先要区分合约安全检查与链上记录验证。以太坊开发者安全文档讨论代码测试、权限控制和独立审查；比特币开发者指南解释交易、区块及共识规则。两类检查可以互补，但交易被链上接受，并不意味着应用的业务设计没有缺陷。
静态分析、动态分析与模糊测试
静态分析不直接运行合约，而是检查代码结构及可能的执行路径。动态分析通过实际执行观察行为；模糊测试属于其中一种方式，利用大量生成的输入寻找异常。单元测试则针对特定功能和预期结果进行检查。
这些方法适合回答不同问题：固定案例能否正确执行，异常输入是否触发缺陷，某条危险路径是否可能到达。测试通过的解释应限于已检查的条件，不能扩展为所有输入和调用顺序都安全。
安全属性、不变量与形式化验证
安全属性是希望程序满足的规则；不变量强调在规定状态或操作过程中持续成立的约束。形式化验证把规则写成明确规格，再证明模型符合规格。其结论依赖规格、模型和假设，不能直接理解为整个系统没有任何错误。
例如，检查某种操作是否只能由授权账户执行，需要先明确谁有权限、权限如何变化。若规则遗漏了关键角色，即使验证通过，也没有回答被遗漏的问题。
访问控制与独立审查
访问控制规定谁能执行敏感操作。所有者模式、角色权限和多签分别涉及权限归属、职责划分及多人批准。审查时既要看限制是否生效，也要看权限配置是否符合设计意图。
独立审计增加了外部检查视角，漏洞赏金则鼓励发现并报告问题。两者都不能保证发现全部漏洞；理解审计结论时，应把结论与实际检查范围对应起来。
UTXO、默克尔证明与常见误区
在比特币中，UTXO是尚未花费的交易输出，交易验证会检查输入引用及相关规则。默克尔证明用于核验交易是否被某个区块收录；区块高度表示位置，分叉时同一高度可能存在不同区块，因此不能单独作为唯一标识。
常见问题是：证明交易被收录，是否就证明交易背后的业务真实？不能。收录证明回答的是数据归属问题，业务真实性需要其他证据。同样，合约审计与共识验证各有对象，不能用其中一种结论替代另一种检查。