适用范围：先区分通用原则与项目事实
讨论航天云网区块链技术需要注意哪些问题，首先要明确：以太坊智能合约安全文档与OpenZeppelin访问控制文档，不能证明航天云网采用了相同架构、合约语言或权限组件。下文仅解释智能合约系统的通用注意事项，不对该平台是否存在漏洞作判断。
若具体系统并非基于以太坊虚拟机，相关函数与组件不能直接套用，但权限最小化、异常校验和独立复核等原则仍可用于评估安全设计。
权限设计：不仅看谁能操作，还要看谁能授权
OpenZeppelin访问控制文档区分单一所有者与角色授权：前者便于集中管理，后者可细分职责；角色管理员负责授予和撤销权限，因此管理员本身也是关键风险点。所有权交接可以采用接收方确认的两步流程，放弃所有权则可能使受保护功能无法再调用。
在业务设计中，应分别明确操作权限与授权权限。把审核、配置变更、暂停等职责划分给不同角色，并不自动消除风险；若同一账户最终控制全部角色，权限集中问题依然存在。账户交接也应验证接收方是否具备实际管理能力。
异常校验：业务规则需要落实到执行条件
以太坊安全文档强调访问限制、执行条件检查、多种测试与独立审查，并提醒审计不能发现所有缺陷。其介绍的require、assert和revert各有用途，分别可用于前置条件检查、内部不变量验证及异常回退。
对于适用的合约，不能只验证正常业务是否成功，还应检查越权请求、无效输入和不合法的状态变化是否被拒绝。函数可见性也不等于业务授权：允许外部调用的入口，仍需针对敏感操作设置权限检查。
测试与审查：通过测试不等于没有漏洞
单元测试通常围绕预设输入展开，遗漏的边界条件不会自动被覆盖。安全验证应围绕具体业务规则，结合静态分析、模糊测试与独立代码审查，检查异常路径和连续操作造成的状态变化。
形式化验证的结论受所定义的性质、模型及假设约束，不能据此宣称整个系统绝对安全。同样，审计结论应对应明确的代码版本与范围；后续修改仍需重新评估受影响的逻辑。
常见问题：多签和不可变性能否替代安全设计
多签可以降低单个管理密钥失陷造成的风险，但不能修复合约逻辑错误，也不能替代合理的授权边界。部署后难以修改更不意味着代码天然正确，反而要求上线前充分验证，并提前明确异常处置与管理权限交接方式。
评价具体平台时，应核对其实际技术栈、权限配置和对应版本的验证结果，而不能把通用文档中的安全机制直接视为该平台已经具备的能力。