适用范围与基本边界
本文讨论以太坊及类似智能合约系统中的账户与权限管理。ethereum.org 的账户说明区分了由私钥控制的外部账户和由代码控制的合约账户；钱包则是与账户交互的工具。OpenZeppelin 的访问控制文档介绍了所有者和角色授权机制。这些机制可以限制操作权限，但完整的用户管理还需要明确业务身份与账户之间的关系。
地址能否直接代表一个用户
签名可以用于证明对相应账户的控制，不能单独证明现实身份。设计用户体系时，需要分别回答“请求由哪个账户发出”和“该账户在业务中代表谁”。如果业务涉及身份审核，仅登记地址或授予角色，不能替代审核流程本身。
密钥丢失与权限集中怎么办
外部账户依赖私钥完成签名，因此普通网站的密码重置思路不能直接套用到链上账户。用户账户的控制权和应用赋予它的权限也应分开考虑：撤销某个角色可以限制其应用操作，却不能恢复丢失的私钥。
如果关键管理权集中在单个账户，该账户失控会影响权限管理。多签合约可以作为所有者，让管理操作依赖多方确认；其适用前提是参与者与确认规则符合业务需求。
有业务角色是否就能管理其他用户
OpenZeppelin 的角色机制将执行权限与角色管理权限分开。拥有某项业务角色，通常不意味着可以把它授予别人。设计时应分别明确谁能执行操作、谁能授权以及谁能撤权，避免把管理权限误当成业务权限。
默认管理员具有较广的角色管理能力，因此应检查其管理范围。按职责拆分权限有助于限制单个账户可执行的操作，但仍需检查同一账户兼任多个角色后的实际权限。
权限移交和退出有哪些容易忽略的问题
所有权转给无法操作合约的地址，可能使管理功能失去可用的控制者；两步移交通过接收方确认降低此类风险。放弃所有权则会使仅限所有者调用的功能无法继续调用。人员退出或账户更换时，需要逐项检查相关权限，而不能只更新网站上的用户记录。
如何确认当前有哪些特权账户
基础 AccessControl 不提供链上角色成员枚举，可通过授权与撤销事件在链下跟踪；需要链上枚举时，可使用相应扩展。用户管理页面应区分历史授权记录与当前有效权限，成员查询也应覆盖撤权变化，否则容易把曾经拥有权限的账户继续显示为有效成员。