Ownable和AccessControl怎么选？ 图 1
Ownable和AccessControl怎么选？ · 图 1

权限设计不从“哪个合约更高级”开始，而从“系统有多少种能力、谁能授予它们、出错后怎样恢复”开始。只有一个管理员动作时，Ownable清楚直接；铸币、暂停、升级、参数调整由不同主体负责时，AccessControl更能表达最小权限。

Ownable的简单是一种优势

onlyOwner使调用路径容易审计，owner也可以是多签或治理合约，而不必是个人EOA。风险在于所有能力集中：密钥泄露、误调用renounceOwnership或把owner转给无法操作的地址，都可能影响整个系统。

权限模型的选择起点

  1. Ownable适合单一管理员，所有onlyOwner能力集中到一个owner地址；owner也可以是多签或治理合约。
  2. Ownable2Step要求新owner主动接受转移，可降低把所有权转给错误或不可用地址的风险。
  3. AccessControl支持多角色及各自管理员；DEFAULT_ADMIN_ROLE默认管理所有角色且管理自身，属于需要重点保护的高风险权限。

Ownable2Step解决的是交接错误

旧owner先提出新地址，新owner再acceptOwnership。第二步能发现拼错地址或不具备操作能力的合约，但不会自动限制新owner的权限，也不提供撤销延迟。交接期间谁仍可操作、提议能否取消，应由版本行为和业务流程明确。

模型适合场景主要风险推荐补强
Ownable单一管理面owner单点失陷或误转多签、监控
Ownable2Step单一管理面且重视交接新owner迟迟不接受交接流程和超时方案
AccessControl多角色、多职责admin关系复杂、默认管理员过强角色图、延迟与多签

AccessControl先画角色管理图

角色成员负责业务，角色admin负责grant和revoke。DEFAULT_ADMIN_ROLE默认是所有角色的admin，同时也是自己的admin，权限极高。生产系统可使用AccessControlDefaultAdminRules、延迟、多签或AccessManager收紧它，但复杂度也随之增加。

把管理员关系画成图

  1. 列出每个受限函数及最小角色
  2. 画出角色成员与admin关系
  3. 让最高管理员由多签和延迟保护
  4. 演练grant、revoke、交接和密钥丢失
  5. 监控OwnershipTransferred与RoleGranted事件

角色多不代表权力分散

renounceOwnership不等于项目去中心化：代理admin、其他角色、暂停器和升级治理仍可能存在。角色多也不等于更安全，若所有角色最终由同一个DEFAULT_ADMIN_ROLE即时控制，只是把同一风险换了名字。

权限事件可用事件日志topics与data追踪，调用前按智能合约连接检查核对目标；账户和存储证据可结合eth_getProof。