适用范围：先明确业务与技术条件
讨论区块链城市创新项目有哪些常见问题，需要先明确底层网络和参与方式。以下聚焦采用以太坊及相关扩容技术、使用智能合约管理操作权限的场景。其他技术架构需要另行评估，不能直接套用这些机制。
城市业务如果涉及多个机构共同操作，应先说明谁提交记录、谁能执行关键操作，以及何时可以确认处理完成。这些业务边界决定了性能与权限设计的要求。
高峰期能否及时处理，成本是否可控
以太坊扩容文档说明，网络需求增加可能造成拥堵和费用上升；扩容旨在改善处理能力，同时保持安全与去中心化。评估城市应用时，应分别关注提交速度、处理吞吐量和最终确认时间。
例如，界面显示提交成功，并不足以说明记录已获得最终确认。验收条件应明确不同状态的含义，并覆盖集中提交时的等待时间和失败处理。费用评估也应结合业务频率，不能只看单次操作成本。
扩容方案是否具有相同的安全保障
上述文档区分了依托主网安全的二层方案与采用独立共识的侧链；不同方案的数据保存与验证方式也有差异。因此，接入主网并不意味着所有方案都获得相同保障。
选择架构时，需要逐项确认交易由谁处理、验证需要的数据在哪里，以及运营节点停止服务后的处理路径。性能指标只有结合这些条件，才能用于比较；单独追求处理速度容易遗漏运行依赖。
多机构协作时，权限是否划分清楚
OpenZeppelin访问控制文档介绍了单一所有者和按角色授权两种方式，并强调最小权限原则。城市应用可据此区分业务操作与授权管理，避免把所有能力集中到同一账户。
例如，提交记录、审核记录和管理审核人员可设计为不同权限。业务角色能够执行某项操作，不代表其应当有权把该权限授予别人。评估时应同时检查角色职责及其管理员，防止表面分工、实际仍由一个账户控制全部操作。
管理权交接与撤销是否可持续
该访问控制文档还指出，所有权转移出错可能影响管理操作，两步交接可要求接收方确认；放弃所有权则会使受所有者限制的功能无法继续调用。权限变更事件也可用于追踪授权变化。
因此，项目需要明确人员离任后的撤权、机构更换后的交接和历史授权核查流程。不能把删除管理员简单视为完成治理：如果业务仍需维护受限功能，就必须预先确认后续由谁承担责任、通过什么机制执行。