适用范围与核心问题
“区块链特性内合约需要注意哪些问题”可以理解为：区块链的运行特点会给智能合约带来哪些安全要求。以下讨论主要适用于以太坊及 Solidity 合约，具体权限机制以 OpenZeppelin Contracts 的相关设计为例。
以太坊智能合约安全文档强调，部署后的代码通常难以直接修改，公开交互环境也会扩大攻击面，因此需要结合访问控制、条件检查、测试和独立审查。设计时应提前回答：哪些操作能执行、谁能执行、异常出现后如何限制影响。
敏感操作需要明确授权
公开函数允许外部调用，是否能完成敏感操作还取决于权限检查。例如，普通交互与管理操作应分别定义授权条件，不能仅凭函数名称或前端入口限制访问。
OpenZeppelin 访问控制文档区分了单一所有者和按角色授权，并说明了权限移交及默认管理员的风险。管理职责简单时可以采用所有者模式；职责不同、需要分别授权时，角色模式更便于落实最小权限。
角色数量多并不自然代表管理分散。如果同一个账户既能执行敏感操作，又能任意授予其他权限，风险仍可能集中。检查权限时，需要同时检查执行者和授权者。
移交和退出管理同样需要设计
权限管理应覆盖初始分配、后续变更和退出。两步移交通过接收方确认，降低错误转交带来的风险；放弃所有权则可能使依赖所有者授权的功能无法再调用，必须先确认这些功能是否仍然必要。
多签适合需要多人共同批准的重要管理操作，但它主要改变批准条件。合约业务逻辑是否正确、各签名方是否独立，仍需分别评估。
异常检查与安全验证如何配合
输入条件、调用身份和业务状态应在执行过程中受到检查。require 和 revert 可用于拒绝不符合条件的操作；assert 适合检查内部应始终成立的性质。异常回退能限制错误执行造成的状态变化，但无法弥补遗漏的规则。
验证应同时覆盖正常流程、越权调用和边界状态。例如，除了确认授权账户可以操作，还应验证权限撤销后无法继续操作，以及错误状态下请求会被拒绝。测试目标应来自业务约束，而不只是现有代码路径。
常见问题：审计通过是否代表安全
审计能增加发现缺陷的机会，但不能保证没有漏洞。形式化验证的结论也受规格、模型和假设限制，不能直接推广为整个系统绝对安全。
评价安全性时，应将代码、权限配置和管理流程一起考虑。代码检查通过后，如果权限分配不当或移交失误，系统仍可能偏离预期；持续核对管理权限与业务需求是否一致，是合约维护的重要部分。