卖家给托管合约一个签名过的交付凭证，链上能验证凭证格式、签名和有效期，仍不能从这些字节推导包裹真的抵达。区块链（28）：索引器怎样在断线与重组后重算订单解决观察可靠性，本篇要说明“观察的到底是不是外部事实”。预言机将外部数据带入合约；其数据采集、发布权限、时间窗口与争议处理构成另一层信任。

flowchart LR
  F[链外交付或报价来源] --> C[采集与多源核对]
  C --> O[预言机报告: 值/时间/签名]
  O --> V[合约: 身份、序号、时效和范围]
  V --> D[托管释放或拒绝/暂停]
  A[作假、延迟或数据源故障] --> C

“多签名报告”不是“多个独立事实来源”：若签名节点都读同一错误 API，汇聚仍不正确。超时策略要区分“没有新数据，冻结领取”与“使用最后一次旧数据”；用旧价结算时必须定义最大可接受陈旧时长、极端波动或冲突报告如何处理。对于订单交付，链外争议机制可比自动放款更诚实；不要把真实世界结果简单命名 verifiedDelivery 就当作已核验。

将“交付”拆成可判的几条谓词

一份报告可以包含订单 ID、上游物流单号、收件事件、来源、签发者、观察时间与过期时间。合约最多据已冻结的规则核对报告格式、签名者名单、单调递增的序号、来源是否属于允许集合，以及时间是否落在交付窗口；收件人的本人签收、包裹内容与实际商家履约不能从这些字节本身得到。若五名签发者都只调用同一物流接口，共识仅能证明“五份报告同源地复述了一个数据源”，并不能消除该接口出错或串谋。隐瞒数据、发布冲突数据、发布正确但太旧的数据都需要不同的拒绝/暂停策略。

假设预言机最后报告“已送达”，发布时间晚于订单退款期限；合约若仍按先到先付的规则放款，买家已启动的退款会与卖家领款竞争。应用应在创建订单时约定快照点、报告接受时限、争议期和冲突仲裁权，不能事后把赢家选择交给未公开的管理员。真实测试至少同时提交正常、过期、冲突和中断恢复数据，并核对在网络重组后报告所触发的释放是否仍成立。本环境无实际预言机或外部履约证据，因而只保留机制规格和失败例。

练习一：报告签名正确但时间戳早于订单创建，会放款吗？答案：应拒绝或按冻结规则处理，签名不代表时效。练习二：所有报告者都依赖同一个物流 API，新增五个签名能消除 API 单点错误吗？答案：不能，需明确来源独立性与失败策略。实际预言机、故障注入和托管确认 NOT_RUN。

可迁移原则：验证数据来源与验证事实本身不是一项工作。参考：Chainlink Data Feeds、Chainlink 文档（具体网络与权限待核）；导航：区块链（28）：索引器怎样在断线与重组后重算订单 · 29 · 区块链（30）：同一组有效交易也能产生不同经济结果。