区块链与物联网如何结合
物联网设备通常负责感知环境、采集数据或执行动作，区块链则可以记录经过处理的数据、保存状态变化，并通过智能合约按照预先设定的条件执行规则。两者结合后，系统可以形成由设备、链下服务、预言机和智能合约组成的混合架构。
智能合约默认只能使用区块链上的数据，无法直接读取传感器、天气服务或其他外部系统的信息。预言机承担连接链上与链下的作用：它从外部来源获取数据，经过一定处理后提交给链上合约；在某些架构中，也可以把链上事件传递给链下设备或应用，触发后续动作。
常见问题一：链上数据不等于真实数据
区块链能够较好地记录已经写入链上的内容，但不能自动证明这些内容与现实情况一致。传感器可能发生故障，采集位置可能不准确，数据在进入区块链前也可能被篡改。因此，所谓数据不可随意修改，主要描述上链后的记录状态，并不代表源头数据天然正确。
预言机需要关注数据的真实性和完整性。真实性要求数据确实来自预期来源，完整性要求数据在传输和提交过程中没有被改变。如果系统只依赖一个设备、一个接口或一个运营方，外部数据源出现错误时，智能合约可能仍会按照错误信息执行。
常见问题二：预言机形成新的信任环节
区块链节点可以依据链上相同数据执行相同的合约逻辑，但物联网信息通常来自链下环境。预言机把外部结果带入链上后，系统需要回答几个问题：数据由谁提供，如何验证来源，多个报告不一致时如何处理，以及谁需要为错误提交承担责任。
一种常见思路是使用多个数据来源或多个报告节点，并设置数据聚合、阈值和异常处理规则。这样可以降低单点错误的影响，但也会增加通信、维护和验证成本。多来源并不自动保证正确，数据源之间如果共享同一错误来源，仍可能产生一致但错误的结果。
常见问题三：物联网设备资源有限
许多物联网设备属于受限设备，可能受到电池容量、内存、处理能力、代码空间和通信能力的限制。它们通常不适合直接运行复杂的区块链节点，也不适合频繁发送大数据或执行计算量较高的密码学操作。
因此，实际系统往往需要让设备负责采集和初步处理，再由网关、边缘节点或服务器完成协议转换、签名、缓存和上链提交。设计时应减少通信次数和报文大小，并考虑设备无法持续在线、更新困难以及密钥配置能力有限等情况。把所有原始数据直接写入区块链，也可能带来成本、性能和隐私方面的压力。
常见问题四：网络不稳定影响数据可用性
受限网络可能存在低吞吐、高丢包、较大波动、链路不对称和设备周期性休眠等特点。设备即使能够采集数据，也可能无法及时把数据传给网关或预言机。网络中断还可能造成数据延迟、重复提交、顺序错乱或部分设备长期离线。
预言机服务除了保证数据正确，还需要保证数据在请求时可用。应用应明确数据的时间戳、有效期、缺失处理方式和重试规则，并区分“没有新数据”“设备离线”和“数据值确实为零”等不同情况。对需要即时控制的场景，还应评估链上确认时间与现实设备响应时间是否匹配。
常见问题五：安全、隐私与故障恢复
物联网设备常部署在工厂、楼宇、车辆或户外环境，可能面临物理接触、固件漏洞、凭证泄露和通信窃听等风险。设备身份、访问权限和密钥管理如果设计不当，攻击者可能伪造数据，批量控制设备，或利用重复消息触发错误操作。
区块链的公开可验证特性也不意味着所有数据都适合公开上链。传感器数据可能包含位置、生产状态、家庭活动或运营信息。较稳妥的设计通常需要根据业务敏感程度决定上链内容，把必要的摘要、证明或状态记录放在链上，把原始数据保存在具备访问控制的链下系统，并建立数据删除、权限变更和密钥轮换方案。
系统还需要考虑预言机停止服务、设备长期离线、数据源失效和链上合约逻辑错误等情况。应预先定义暂停、回滚、人工复核或降级运行机制，并明确哪些动作可以自动执行，哪些动作必须经过额外确认。
如何判断应用是否适合采用区块链
判断重点不在于是否能够把物联网数据写入区块链，而在于业务是否需要多方共享、可验证的状态记录和预先约定的自动规则。如果系统只有一个可信运营方，数据规模很大且主要需求是实时采集，传统数据库或消息系统可能更符合性能和运维要求。
如果多个参与方需要共同确认设备事件，且各方之间缺少单一可信数据库管理者，区块链可能具有一定适用性。但在实施前，应先明确数据来源、预言机责任、设备能力、网络中断处理、隐私边界和故障恢复流程。只有这些链下环节能够被可靠管理，链上记录和智能合约规则才有实际意义。