先明确审计对象与适用范围
讨论区块链审计应用时，需要先区分智能合约安全审查与业务真实性审计。本文聚焦以太坊智能合约及其权限配置。合约代码通过审查，并不意味着相关业务数据、链下流程或整个应用均已获得验证。
审查前应明确合约范围、代码版本、预期功能与管理权限。比如，暂停功能是否属于设计要求、谁可以触发，应先形成清楚的规则，才能判断代码行为是否符合预期。
权限检查要追溯到管理者
OpenZeppelin的访问控制文档区分了单一所有者与角色权限机制。检查时既要确认谁能执行敏感操作，也要追溯谁能授予或撤销这些权限；默认管理员通常拥有广泛的角色管理能力。
按角色分工适用于存在不同职责的系统，但角色名称不同不代表控制权已经分散。如果同一账户持有多个角色，或某个管理员能够重新分配全部权限，仍需评估其实际控制范围。多签可以提高操作授权门槛，但效果取决于签名方配置和密钥管理。
权限交接与退出是否可用
权限审查还应覆盖所有权转移和放弃。两步交接要求新所有者主动接受，有助于降低转错账户的风险；放弃所有权则可能使受所有者保护的管理功能无法再调用。
因此，不能简单把移除管理员视为安全改进。应先确认系统是否仍需维护、暂停或其他管理操作，再核对交接后的账户能否执行必要职责。
测试应检查异常与持续约束
以太坊智能合约安全文档强调，单元测试应与其他检查手段结合。正常输入下执行成功，只能说明已覆盖的场景符合预期，不能证明所有边界情况均安全。
审查可以围绕明确的安全要求展开：未授权账户调用是否失败，非法输入是否被拒绝，操作前后的关键状态是否满足约束。静态分析、模糊测试和人工检查各有侧重；形式化验证的结论也受所写规范、模型和假设限制，不能扩大为整个应用不存在任何漏洞。
如何理解审计结论
独立审计能补充开发团队的检查，但无法保证发现全部缺陷。阅读报告时，应关注审查范围、问题成立条件、修复状态及复核结果，而不是仅看是否标注“已审计”。
审计结论还需要对应具体版本。若后续修改代码或权限配置，应判断原有结论是否仍然适用。对于实际部署的应用，核对受审代码与运行配置之间的关系，是理解报告适用边界的必要步骤。