先明确审计对象与适用范围
理解区块链审计流程涉及哪些技术概念，首先要区分账本验证与智能合约安全审查。前者关注记录是否符合协议规则，后者关注程序能否按照预期处理调用与状态变化。比特币的交易模型与以太坊的合约执行环境不同，检查标准需要对应具体对象。
账本检查：哈希、默克尔树与共识
比特币开发者指南介绍了区块哈希链接、默克尔树、未花费交易输出（UTXO）及工作量证明。哈希链接关联前后区块，默克尔树支持核验交易是否被某个区块收录；UTXO规则约束输出的重复花费。发生分叉时，节点在有效候选链中依据累计工作量选择链，区块高度不能充当全局唯一标识。
这些概念对应不同证据边界。交易收录证明回答的是“记录是否在该区块中”，完整交易验证还需要检查其是否满足协议规则。因此，确认数据归属与确认交易有效性应分别理解。
合约检查：权限与状态约束
以太坊智能合约安全文档强调访问控制、条件检查、测试及独立审查。所有者模式、角色权限和多签用于约束敏感操作；require、assert与revert用于检查条件或触发回退；静态分析、模糊测试和形式化验证从不同角度检查程序属性。
审查权限时，需要把“谁能调用”与“调用后能改变什么”连起来理解。角色分工涉及授权范围，多签涉及执行所需的共同批准条件。设置多个角色并不自动消除关键权限集中或密钥失陷带来的风险。
代码验证：测试与证明各有边界
单元测试检查选定案例，静态分析在不实际执行程序的情况下分析代码，模糊测试通过生成输入探索异常行为。审计中的不变量，是预期在相关状态变化中持续成立的约束，能够为测试提供明确的判断标准。
形式化验证把安全要求表达为规格，并检查模型是否满足规格。其结论受规格、模型与假设限制；遗漏的业务要求不会因为证明通过而自动得到保障。不同方法适合相互补充。
常见问题：审计通过是否等于绝对安全
审计可以增加发现缺陷的机会，无法保证发现所有问题。解读结论时，需要对应受审代码、检查范围和验证条件。账本遵守共识规则，也不意味着运行其上的应用逻辑必然正确；同样，某些测试通过，只能支持这些测试实际覆盖的行为。