适用范围与基础认识
以下讨论适用于传感器、网关、链下服务与智能合约协作的通用架构。RFC 7228说明，受限设备可能同时面临计算、内存、电力和通信限制。以太坊预言机文档说明，合约使用外部信息需要链上与链下组件衔接，并需考虑数据正确性和可用性。这两类边界决定了系统不能只围绕链上逻辑设计。
误区一：每台设备都应承担完整链上任务
设备能够联网，并不意味着它能承担持续通信、复杂计算和大量状态维护。对于电池供电、内存有限或周期性休眠的节点，应先明确采集与通信负担，再分配设备、网关和后端职责。能力较强的节点可以承担更多处理工作，但增加中间组件后，也需要明确其故障影响与数据处理权限。
误区二：数据上链就证明测量真实
链上记录与物理世界的真实性属于不同问题。温度读数即使完整传入合约，也可能来自故障传感器。架构评审应分别检查数据来自哪里、传输是否被改动，以及测量本身是否可靠。来源可追溯能够帮助定位责任，却不能替代设备校验与异常检查。
误区三：合约可以随时直接读取设备
以太坊合约默认不能直接访问链外信息，通常需要预言机将外部数据提交到链上。设计时必须明确采集、处理、提交和消费数据的责任。还应区分采集时间与提交时间：一条刚提交的记录可能对应较早的测量，业务规则需要说明它在什么条件下仍然有效。
误区四：多个预言机天然消除信任风险
增加报告节点并不自动增加独立证据。如果多个节点读取同一个故障来源，它们仍可能一致地报告错误结果。需要分别审视数据源和运营主体是否独立，并定义报告冲突、缺失或更新中断时的处理方式。节点数量不能单独证明数据可靠。
常见问题：链上成功是否代表设备执行成功
不一定。链上结果传递到物理设备仍涉及链下通信与执行组件；设备休眠或链路丢包都可能影响动作完成。因此，系统应区分指令形成、指令送达和动作完成，并根据业务需要设置反馈与超时处理。对于时间敏感的控制，应先验证整条路径能否满足时限，不能仅凭合约执行成功作出判断。