术语的适用范围
理解“区块链审计教程相关术语如何理解”，可以从权限与验证两条线入手：谁能改变合约状态，以及怎样检查这些改变是否符合规则。这里主要讨论以太坊智能合约代码审计，不涵盖所有区块链系统或财务审计。
ethereum.org 的智能合约安全文档强调，内部检查、测试与独立审查应当配合使用。审计能够增加发现问题的机会，但不能保证发现全部漏洞。
访问控制、所有权与角色
访问控制回答“谁有权执行某项操作”。public、external 表示函数可被外部调用，是否允许调用者完成敏感操作，还取决于函数中的权限检查。private 限制代码层面的访问，不代表链上信息保密。
OpenZeppelin 的访问控制文档区分 Ownable 与基于角色的访问控制。前者通过所有者身份管理操作，后者按职责分配权限；角色管理员负责授予或撤销角色。所有权转移、放弃所有权及默认管理员权限，都需要单独理解。
单一管理职责适合用所有权模型描述；铸造、暂停等职责需要分离时，角色模型更便于表达。最小权限原则意味着只授予完成职责所需的权限。审计时既要看谁能执行操作，也要看谁能改变权限分配。
多签与权限分散
多签要求达到设定的签名门槛才能执行操作，可用于管理合约。它与角色分工解决的问题不同：角色决定可做哪些事，多签决定一项操作需要多少方同意。
常见误解是角色数量越多，权限就越分散。如果所有角色仍由同一主体控制，或某个管理员能重新授予全部权限，角色名称的拆分并不能证明控制权已经分散。
条件检查与不变量
require 通常检查输入、调用权限或执行前提；revert 主动终止当前执行并报告错误；assert 用于检查内部逻辑应当成立的条件。检查是否有效，取决于条件是否准确覆盖业务要求。
不变量是系统在规定状态或操作边界上应始终满足的性质。例如，设计明确设有供应上限时，“总供应量不超过上限”可成为检查目标。并非所有代币都具有这一约束，审计需要先确认设计规则。
测试、分析与形式化验证
单元测试检查选定案例；静态分析在不实际执行合约的情况下分析代码；动态分析通过运行代码观察行为。模糊测试属于动态方法，通过大量变化的输入寻找违反预期性质的情况。
形式化验证围绕明确的规格和模型进行证明。其结论受证明范围与假设限制：证明某项权限规则成立，不能直接推出整个系统不存在漏洞。阅读审计结论时，应把检查对象、验证性质与适用条件联系起来理解。