一、先确定适用范围
智慧城市区块链技术需要注意哪些问题，首先应从业务需求而非技术名称出发。需要多方核对记录的业务，可以进一步评估区块链是否适合；主要依赖实时响应的环节，则应特别关注等待确认的影响。
以太坊扩容机制和预言机请求模型能够帮助理解通用技术边界，但不能直接证明某个智慧城市项目已经具备相应能力。具体方案仍需说明哪些工作在链上完成，哪些依赖链外系统。
二、区分吞吐量、响应速度与最终确认
以太坊扩容文档强调，扩容需要兼顾处理能力、去中心化和安全，而不能只追求速度。网络繁忙也可能影响使用成本。
城市业务选型时，应分别定义请求受理、处理结果返回和最终确认的要求。界面显示操作成功，不应被直接理解为链上记录已经完成最终确认；成本评估也不宜只看低负载时的单次费用。
三、不同扩容路线有不同安全边界
按照以太坊扩容文档的区分，Rollup与侧链不能视为安全机制相同的方案：前者依托主网获得安全保障，后者采用自身的共识规则。Validium还涉及数据不存储在主网的数据可用性边界。
因此，比较方案不能仅看是否兼容现有合约。还应明确由谁处理交易、验证结果依赖什么机制，以及相关运营方不可用时业务如何继续。共享网络与专用部署，也需要分别评估责任分工。
四、链外数据接入不等于真实性认证
Chainlink标注为历史模型的基础请求文档，展示了合约发起请求、链外节点获取并转换数据、再通过回调返回结果的流程。这说明预言机能够连接链上逻辑与外部接口，但该历史流程不应直接当作现行部署指南。
在城市业务中，应把数据传输与数据真实性分开考虑。外部接口的数据如果错误或过时，写入链上并不会自动纠正。适用方案需要说明数据来源、更新时间、异常识别方式和责任归属。
五、提前定义异常处理与验收标准
涉及链外接口和链上确认的业务，不宜只设计正常成功的路径。项目要求中还应明确请求未返回、数据格式不符合要求或确认延迟时，系统应显示何种状态，以及何时需要人工核对。
常见误区是把提高吞吐量等同于提高整个业务系统的可靠性。验收应分别考察处理能力、确认等待、数据质量和故障恢复，而不是用单一性能指标替代全部判断。