一、适用范围：以智能合约型通证为中心
区块链通证安全涉及哪些技术概念，需要先明确讨论对象。这里主要讨论以太坊智能合约型通证的权限与代码安全，不覆盖所有区块链架构。通证规则由合约执行，因此安全既要检查功能是否正确，也要检查敏感功能能被谁调用。
二、访问控制与最小权限
OpenZeppelin 的访问控制文档区分了所有者模式与基于角色的权限控制。前者适合管理职责简单的系统；后者可把增发、销毁等职责分开。最小权限原则要求每个角色只拥有完成职责所必需的能力。
理解权限时，应分别问“谁能执行操作”和“谁能授予这种能力”。角色持有人不一定能给别人分配角色；反过来，能分配角色的管理员，即使暂时没有增发权限，也可能有能力获得该权限。
三、多重签名与管理权交接
多重签名要求达到约定数量的签名才能执行操作，可用于共同管理合约。两步所有权转移则要求新所有者确认接收，有助于降低管理权转错地址的风险。
这些机制解决的问题不同：多签约束操作的批准过程，两步转移约束权力交接过程。把职责拆成多个角色，也不等于消除了单点风险；如果角色实际由同一控制方掌握，权限仍可能集中。
四、输入校验与状态不变量
以太坊智能合约安全文档介绍了 require、assert 和 revert：它们分别常用于条件检查、内部不变量检查及显式触发回退。不变量是系统按设计应持续满足的规则，例如设有供应上限的通证不应突破该上限。
检查“本次操作是否允许”与检查“操作后整体状态是否正确”不能互相替代。前者关注调用者、输入和前置条件，后者关注规则是否始终成立。只有明确写入设计的上限，才能作为相应验证的依据。
五、测试、形式化验证与独立审计
安全验证可结合单元测试、静态分析、模糊测试和形式化验证。它们从预设案例、代码路径、变化输入或数学规格等角度检查问题；独立审计与漏洞赏金则补充外部审查。
方法越多不代表结论无限扩大。测试通过只说明已检查的情况符合预期；形式化验证依赖规格、模型与假设，不能据此宣称整个系统没有任何漏洞。审计也不是安全担保。
六、常见问题：哪些判断容易误导
公开函数是否意味着任何人都能增发？不一定，关键在于函数内部是否执行授权检查。放弃所有权是否意味着风险消失？也不一定，它会使依赖该所有者权限的管理功能无法调用，却不能证明其他角色或代码逻辑没有问题。理解通证安全，应同时核对权限关系、状态规则和验证边界。