适用范围与问题核心
区块链智能合约架构有哪些常见问题，可以从谁能操作、状态如何变化、管理权如何交接以及正确性如何验证四个方面理解。以下主要讨论以太坊与 Solidity 合约，具体权限组件以 OpenZeppelin Contracts 的机制为例，其他平台需结合自身执行规则判断。
ethereum.org 的安全文档强调访问控制、运行条件校验、测试和独立审查；OpenZeppelin 的访问控制文档则说明所有权、角色管理及权限交接机制。这些机制共同指向一个架构要求：业务规则与管理规则都需要明确的执行边界。
敏感操作缺少权限边界
函数能够被外部调用，不代表调用者应当获得管理权限。若修改关键参数等操作没有授权检查，外部账户便可能触发本应受限的行为。设计时应先区分普通业务入口与管理入口，再为每个敏感入口明确授权条件。
单一所有者模式适合管理关系简单的系统；职责较多时，角色划分更便于限制权限范围。不过，多个角色若仍由同一账户控制，并不会自然消除单点风险。多签能够增加共同批准的要求，其效果仍取决于签名方是否独立。
角色分工清楚，管理链却不清楚
业务权限与授予权限的权力需要分别检查。例如，负责某项操作的账户，不一定应当有权把该权限授予其他账户。架构评审既要查看角色能做什么，也要追踪谁能够授予或撤销角色。
OpenZeppelin 的默认管理员角色具有较广的角色管理权。若忽略这层关系，表面上的职责拆分可能仍受单一管理入口控制。权限交接也需要考虑接收方是否可用；两步交接通过接收方确认降低误转风险，而放弃所有权可能使受所有者保护的功能无法再调用。
输入检查与状态约束不完整
身份正确只是操作合法的一个条件，还需要检查输入、当前状态及业务前提。例如，即使调用者有管理权限，也可能提交违反系统约束的参数。授权检查不能替代业务条件检查。
Solidity 中，require 和 revert 可用于拒绝不满足条件的操作，assert 用于检查内部不变量。架构层面应先明确哪些关系必须始终成立，再检查各入口是否维护这些关系；增加检查语句本身并不等于规则已经完整。
把测试通过或审计完成当作安全保证
单元测试通常围绕预设场景展开，容易遗漏边界输入和操作顺序的组合。验证方案应围绕关键性质补充模糊测试、静态分析与独立审查，并关注跨函数调用后的整体状态。
形式化验证的结论受规格、模型与假设范围限制，审计也不能保证发现所有缺陷。由于部署后的合约代码通常难以直接修改，权限配置、异常路径和管理交接应在部署前纳入验证范围。