一、把“不可篡改”误认为“信息一定正确”
区块链通常通过分布式记录、密码学哈希和共识机制，使已发布的交易记录具有较强的抗篡改性。审计人员可以据此关注记录是否被修改、交易是否按照网络规则写入，以及账本在不同节点之间是否保持一致。
但不可篡改主要说明记录写入后的变化受到限制，并不能证明录入前的数据真实，也不能证明交易内容符合业务事实。例如，错误的业务数据、未经充分核验的外部数据，仍可能被写入链上。因此，审计不能只验证链上记录的连续性，还要追查数据来源、授权过程和业务凭证。
二、忽视共识机制和网络运行条件
不同区块链可能采用不同的共识方式，参与者、验证规则、节点权限和分叉处理方式也可能不同。若审计人员不了解具体网络的运行规则，就可能错误判断交易确认、账本一致性或异常记录的含义。
审计流程应先明确网络属于开放参与还是受许可控制，谁有权提交或验证交易，交易达到何种状态才被视为确认，以及软分叉、硬分叉等变化会如何影响历史记录和审计范围。这里关注的是系统治理和运行环境，而不是简单把区块链视为单一数据库。
三、智能合约代码审查不够充分
智能合约以代码形式执行预设逻辑，并可能控制数据或资产。合约部署后通常具有较强的不可变性，发现缺陷后不一定能够直接修改原有代码，这使得审计不能仅依赖上线后的抽样检查。
常见问题包括敏感函数权限设置过宽、关键操作集中在单一管理账户、输入条件校验不足，以及异常执行时没有正确回滚状态。审计人员应将业务规则与代码实现逐项对应，检查谁可以调用关键函数、哪些条件必须满足，以及失败操作是否会留下不一致状态。
四、过度依赖单一权限账户
如果合约把所有管理权限交给一个所有者账户，账户密钥泄露、误操作或内部控制失效都可能扩大影响范围。单一权限主体还会形成明显的单点故障，降低控制措施的独立性。
审计时应核对权限设计是否与组织职责匹配，关注角色是否分离、敏感操作是否需要多方批准，以及权限变更是否留有可验证记录。对于需要保留管理权限的场景，多角色控制或多签机制可以减少单个账户独立执行关键操作的风险，但其配置和实际使用同样需要审查。
五、测试范围不足，难以发现边界缺陷
仅使用少量正常样例进行单元测试，通常只能说明部分功能在预设条件下能够运行，不能充分覆盖异常输入、极端状态和不同调用顺序。智能合约安全还可能受到执行路径、状态变化和外部调用组合的影响。
较完整的审计准备应结合单元测试、静态分析、动态测试或模糊测试，并针对关键安全属性设计验证条件。对于重要逻辑，还可以考虑形式化验证等方法。需要注意的是，独立审查和审计报告能够增加发现问题的机会，但不能被视为对所有缺陷的绝对保证。
六、只看链上数据，忽略预言机和链下环节
区块链账本记录的是网络接收并确认的数据，而许多业务判断仍依赖链下系统、人工审批、传感器或其他外部数据源。智能合约通过数据接口取得外部信息时，接口内容、更新时点和异常处理都会影响最终结果。
因此，审计范围应覆盖链上交易与链下输入之间的衔接，核对数据传入是否经过授权、是否存在单一来源、异常数据是否能够被识别，以及链上状态能否与原始业务记录相互印证。否则，即使链上执行过程没有被篡改，结论仍可能建立在不准确或不完整的输入之上。
七、建立更适合区块链的审计流程
较稳妥的流程通常包括：先识别网络架构、参与者和共识规则，再确定链上与链下的审计边界；随后核验交易记录、节点或账户权限、智能合约代码及其变更过程；最后结合测试结果、异常交易、外部数据来源和业务凭证进行交叉验证。
在实施过程中，应把“记录是否被改动”“数据最初是否可靠”“代码是否按预期执行”“谁能够改变系统状态”分别作为问题处理。这样可以避免将区块链的技术特征直接等同于内部控制有效性，也能更准确地判断证据的可靠程度和审计结论的适用范围。