13.1 区块链与物联网融合概述
13.1.1 物联网中心化架构的信任困境
设想一条由制造商、物流商和客户共同参与的冷链：三方各自保存温度记录，却在货损后给出不同版本。此时问题不是“数据库能不能扩容”，而是没有任何一方愿意把另一方的数据库当作最终证据。这个假设案例用于说明多信任域争议；若所有参与者同属一个企业并接受统一审计，中心化日志与签名存证通常已经足够。
多数物联网平台采用中心化或分层架构，但“中心化”不等于所有通信必须上公有云：设备可以在现场总线、边缘网关和本地控制器之间直接交互，平台服务也可以做集群、跨地域容灾和独立审计。中心化架构成熟、性能可预测，只有当多个独立主体对同一事实具有共同写入或验证需求时，单一运营方的信任才会成为业务约束。
可用性与控制权集中是第一类风险。未经冗余设计的中心服务会形成故障域，过宽的管理权限也会扩大攻击影响面；但集群、备份、最小权限、独立日志和灾难恢复可以显著降低风险。分布式账本会把单一运营方故障转化为多节点治理与共识风险，并不会“从根本上消除”停机、漏洞或密钥失窃。
数据互操作与可验证性是第二类风险。不同平台的数据模型和授权策略会形成孤岛；高权限人员也可能修改数据库与同域日志。应先采用开放接口、数据签名、只追加日志、WORM 存储、跨账户备份和第三方时间戳等较轻方案。只有这些措施仍无法满足多方独立验证时，才需要评估共同维护的账本。
跨主体互信成本高则是影响物联网规模化部署的深层阻力。一条供应链从上到下的参与方可能包括原料供应商、制造商、物流商、分销商、零售商和终端用户，每个主体都运行着自己的信息系统。要让这些系统对同一批数据达成共识，传统做法是引入权威的第三方平台或监管机构，由它来做数据的集中核对和分发。这种方案带来的结果就是每个参与方都得付出高昂的对接成本、审计成本和法务成本，而且整个流程的响应速度会明显下降。当一个环节出现问题——比如某批次的冷藏车温度异常——各方要花大量时间确认“谁的数据可信”，而不是“数据本身是不是真的”。信任的传递依赖层层合约和事后追责，缺乏一种让所有参与者都能实时独立验证的技术基座。
这三类问题不是“中心化必然失败”，而是信任边界与治理结构是否匹配。技术不能取代合同、监管和责任追究，分布式系统同样需要运营规则。图13-1应被理解为多组织场景下的风险检查表，而不是对所有中心化平台的判决。
当多方确实需要共同维护一份可验证记录时，分布式账本是一种候选实现；签名日志、透明日志和受监管的第三方存证也是候选。选型起点应是信任假设，而不是先决定“上链”。
13.1.2 分布式账本能提供什么、不能提供什么
回到开篇的冷链争议：如果各方在交接时共同确认温度摘要、签名与时间戳，事后就更容易识别哪一份记录发生了变化。分布式账本可以承载这份共同记录，但它只证明某个摘要按规则被接受，不能证明传感器没有漂移、私钥未被盗用或货物实际状态与上报一致。
区块链是一类分布式账本技术（Distributed Ledger Technology, DLT）。不同系统在数据结构、节点角色、状态裁剪和共识方式上差异很大，并非每个节点都保存完整副本，也并非所有 DLT 都以区块组织数据。其共同价值是让多个参与者按约定规则验证状态变更，并通过密码学链接提高历史篡改的可发现性。
维度一：分布式账本实现数据全局一致性
许可链可以让若干组织运行验证节点，并对约定状态达成一致；设备通常只经网关提交摘要，不直接向所有节点广播高频遥测。共识确认的是“交易符合链上规则并被接受”，不是对温度真实性的全网背书。系统能否提供不可抵赖性，还取决于密钥归属、最终性模型、节点串谋假设和链下证据保存。
维度二：数字签名与共识机制确保设备身份可信
设备身份通常基于非对称密钥：私钥应保存在安全元件或受保护的软件环境中，验证方根据受信任的公钥材料校验签名。公钥可以由 CA 证书、DID 文档、平台注册表或其他目录分发，账本不是数字签名成立的前提。签名证明的是“持有该私钥的一方签过这段字节”，设备归属与当前授权仍要由注册、轮换和撤销流程保证。
若多个组织不接受同一个目录运营方，可以共同治理公钥状态或 DID 方法对应的可验证数据注册表。此时共识负责记录状态变更，不必参与每一次设备报文认证。是否采用 PoA、BFT 类协议或其他机制，要由节点准入、故障假设和最终性要求决定。
维度三：智能合约自动化执行信任规则
物联网大量业务逻辑涉及“如果条件满足，就自动执行某个动作”——比如“温度超过阈值并持续一段时间就启动冷却系统”，或“物流车进入仓库范围就开启卸货平台”。中心化架构下这些规则由后端业务逻辑服务器执行，一旦服务器被攻击或配置出错，规则就可能被绕过或篡改。
智能合约（Smart Contract）把可重复验证的状态转换部署到账本执行环境中。合约可被审计，但升级权限、管理员密钥、预言机输入和链下执行仍是风险来源。对工业设备，合约适合登记授权、资产转移或审批结果，不应越过本地策略与安全控制直接驱动阀门。典型链路是：链上产生已确认事件，受控网关验证最终性、权限和工况，再把候选动作交给确定性控制系统或人工确认。
三个维度——一致状态、可验证身份材料和可审计状态转换——共同说明了分布式账本可能提供的能力。它能在既定共识、密钥和治理假设下提高历史改写的可发现性，但不提供绝对不可篡改，也不自动证明来源真实。传感器校准、设备身份、网关处理、时间来源和人工抽检必须分别建立证据，AI 异常检测只能补充线索，不能充当真实性证明。
区块链并非万能银弹。它的引入也带来新的工程挑战：存储和计算资源消耗远高于中心化方案，交易吞吐量受限（尤其在PoW链上），私钥丢失即丧失所有权等。这些问题将在本章后续小节逐一讨论并给出缓解策略。但从信任构建机制看，区块链通过在数据层、身份层和业务执行层重构规则，为物联网系统的跨组织协作提供了可验证的信任基础。
13.1.3 融合架构的演进趋势与工程挑战
信任不是免费的。一台传感器上报一条数据，区块链确认一笔交易，两者在频率、体积和延迟容忍度上的差距，决定了“所有数据上链”是一个工程上不可行的起点。融合架构因此演化出三个折中阶段，每个阶段都是在资源开销与可信强度之间的权衡。
阶段一：链下存储 + 链上哈希。 原始数据（高频温度序列、视频流、大文件）存于本地或数据湖，只将摘要（如 SHA-256）提交到账本。验证时重算哈希，可以判断当前副本是否与当时承诺的字节一致；它不能证明采集真实性，也不能单独证明是谁、在何时生成了数据。签名、可信时间、设备校准和链下原件保全仍然不可缺少（见第 8 章）。
阶段二：终端或网关部分参与账本。 资源受限终端通常不保存完整历史，也不承担验证者职责，而是通过轻客户端、受信任网关或远程 RPC 查询证明并提交签名交易。不同协议的轻客户端可能验证区块头、委员会签名、状态证明或只信任服务端，安全边界差异很大。离线事务还需要本地缓存、重放保护和时钟策略。该阶段以额外的网关或全节点信任换取存储、带宽和能耗节省，是否适合 MCU 必须按 SDK、密码算法、内存和网络实测。
阶段三：业务状态主要由账本协调。 这不要求每个传感器都直接参与共识；常见做法仍是组织节点或网关验证，终端只签名和提交。此阶段适用于多方结算、共同授权等少数场景，并把最终性、费用、隐私、合约升级、桥接和离线可用性带入主链路。海量高频遥测通常仍应链下聚合，只把必要状态或摘要提交账本。
关键的工程挑战与应对路线
- 分片（Sharding）：把状态与执行划分到并行域，可能提高总吞吐，但收益受负载均衡、跨片通信、数据可用性和安全模型限制，不能预设线性扩展。终端是否保存分片状态取决于协议角色。
- 侧链与Layer2扩展：高频交易在链下通道完成，仅将最终状态哈希提交主链。例如状态通道允许设备在链下交换小额资源，但需要预先锁定资金并承担结算风险。状态通道更适合低频次结算的物联网场景；Plasma 作为早期 Layer2 扩容方案现已被 Rollup（尤其是 zk-Rollup）路线主流取代，新选型应优先考虑后者。
- 候选账本平台：项目架构会随版本发生根本变化。IOTA 就从早期 Tangle 叙事演进为当前基于验证者、Starfish 共识和 Move 的架构。IoTeX、VeChain 与 Hyperledger Fabric 也各有不同的准入、最终性、隐私和运维边界。表 13-1 不再给出易过期的 TPS 或“适合场景”标签，而列出选型时必须重新核验的事实。
表13-1 候选账本平台的版本化核验重点
| 候选平台 | 首先核验 | 设备接入问题 | 上线前证据 |
|---|---|---|---|
| IOTA | 当前验证者、Starfish、Move、费用与最终性；不要沿用历史 Tangle 结论 | 是否有适配目标硬件的 SDK、轻客户端或网关代理 | 当前版本官方规范、独立吞吐/故障测试、升级与密钥方案 |
| IoTeX | 当前共识、身份、数据可用性和网络治理 | 终端签名、代理提交、离线缓存与撤销 | 目标网络实测、隐私与费用评估、运维责任 |
| VeChain | 当前验证者与治理、交易费用和企业工具链 | 设备身份如何绑定实体资产与责任方 | 最终性、密钥托管、合约升级和跨组织验收 |
| Hyperledger Fabric | 排序、背书、通道/PDC 与组织准入模型 | 终端通常经应用或网关调用，Peer 不等于传感器 | 节点拓扑、策略、私有数据可用性、负载与恢复演练 |
隐蔽的成本与设计约束
存储膨胀：每个参与方保存完整账本，几十GB大小对ARM Cortex-M完全不可行。产业常见做法是设备端只保留自身交易索引，全账本委托云端节点——这本质上部分回退了去中心化。
隐私公开化：区块链的透明性与企业商业数据隐私矛盾。部分许可链平台通过通道（Channel）机制隔离私密账本；少数公链方案提供屏蔽通道。
融合架构不会短期走向“完全链上”，而会按资产价值、数据敏感度与延迟容忍度分层。接下来的小节将从设备身份、数据可信与供应链溯源展开具体方案。