适用范围：先明确项目采用什么技术
区块链宁波项目需要注意哪些问题，需要结合技术架构讨论。以下内容适用于涉及智能合约的项目，尤其是采用以太坊兼容合约的系统；不能据此认定某个宁波项目存在漏洞、通过审计或符合当地政策要求。
项目评估首先要说明哪些业务由合约执行、哪些依赖链下系统，以及谁能修改关键规则。技术名称相同，并不意味着权限安排和安全水平相同。
权限分配与管理员交接
OpenZeppelin的访问控制文档区分了单一所有者管理与角色管理，并强调最小权限原则。权限交接可以采用两步确认；默认管理员能够管理其他角色，需要重点保护。
对应到项目，应明确业务操作、暂停、升级和授权分别由谁负责。角色名称分开后，还要核对实际持有人：如果所有角色仍由同一个账户控制，风险仍然集中。人员离岗和合作方退出时，也应有撤销权限的安排。
异常处理与测试审查
以太坊开发者安全文档强调访问限制、运行条件检查、多种测试方法和独立代码审查。审计能够增加发现问题的机会，但不能保证合约不存在漏洞。
验收不能只展示正常操作成功，还应检查未授权调用、无效输入和不允许的状态变化是否被拒绝。测试应围绕业务规则展开，例如只有获授权的主体能够变更关键记录，并确认失败操作不会留下错误状态。
部署后的维护责任
合约部署后的修复方式需要提前明确。不可直接修改的代码与可升级架构有不同的维护约束；能够升级的系统还要解释谁批准升级、谁执行操作，以及如何审查新版本。
多方签名可以增加关键操作的批准门槛，但其效果取决于签名人的独立性和密钥管理。项目交付应包含权限清单、代码版本、部署信息和异常处置责任，便于后续核对实际运行情况。
常见问题与判断边界
采用成熟合约库是否就足够安全？仍需检查初始化、角色配置和业务逻辑是否正确。基础组件的安全设计不能替代对整个系统的审查。
形式化验证是否代表没有任何风险？它验证的是特定模型与规格下的性质，结论受到验证范围和假设限制。技术审查同样不能替代对项目主体、业务真实性或当地适用要求的核实。