累计案例从 00 篇的 SQLite 幂等订单，到 Bitcoin 付款观察、Ethereum 教学托管、链下待发送账本、可恢复索引，最后须把钱和业务状态对齐。Bitcoin 的已确认支付与 Ethereum 合约债权是两个独立实验阶段，不能将一条链上的支付哈希偷换为另一条链的托管资产；Fabric 则在独立多组织环境对照许可成员。区块链（37）：比较吞吐之前先定义哪一种完成的“业务完成”只有在对账谓词明确后才可度量。

flowchart TD
  O[订单 ID + 合成交付凭证] --> P[API: 幂等与待发送记录]
  P --> T[合约: 资金/订单状态]
  T --> C[回执 + 块哈希 + 终局策略]
  C --> I[索引: 回填/回滚/重放]
  I --> R[对账: 合约资产/债权/业务状态]
  P --> R

验收应从全新环境开始：一笔订单正常创建、交付确认、领取，另造一笔超时/拒绝；在数据库提交前后和 RPC 应答丢失时停止进程，重启后按订单 ID 找回唯一意图；重复事件不多计资产，分支被撤则旧确认状态撤销；最后核对合约资产余额、每笔卖家/买家待领取额与数据库状态一致。所有凭证必须为合成数据，不提交私钥、生产订单或可再生链数据。

反例：两次广播同一个订单，一个因重试返回哈希 A，另一个因调费返回哈希 B，应用只存 B 却曾按 A 发货；如果 A 已执行、B 因 nonce 失败，被动订阅将无法自动修复链下交付。必须把所有候选交易归于单一订单意图，再从规范链和现实履约系统做最终对账。

对账的有限模型判据

只检验链下撤销逻辑时，可在 examples/blockchain/models/recovery.py 构造合成块：金额 70 的事件进入 a1，后继 a2 使它满足玩具深度 2；独立交付标记也成立后，reconcile 输出 business_complete=true。换成以 a0 为共同祖先、没有付款的新分支，finalized_value 从 70 降到 0，完成状态变回 false；在 b3 重新输入付款并积累后继 b4 才再次恢复。若两个不同交易各输入 70，总额 140 不等于订单 70，同样返回 false。

这里的完成只对三项模型输入成立：合成交付标记、人工输入的事件、深度参数。事件真实性、支付意图、链选择与真实终局均未受检。真实验收须补合约余额、债权求和、提现后回执，以及订单 ID 与交付凭证的可审计映射。两条链的付款不能自动视为一次原子跨链托管。

练习一：合约显示债权合计 70，实际余额 68，订单表却标 70 已付，能判通过吗？答案：不能，资产不变量与业务兑现均不一致。练习二：订阅恢复后收到旧事件两次，如何不重复增加卖家债权？答案：以网络/块/交易/日志定位与合约当前状态核对，并用数据库唯一约束事务化更新。链下有限模型的原始断言见 examples/blockchain/evidence/27-28-38/；没有可运行合约/私网/索引端到端工程，综合验收 NOT_RUN。

可迁移原则：交易标识、事件和业务完成各有独立证据和恢复路径。参考：Ethereum JSON-RPC、Fabric 交易流程（对应网络待冻结）；导航：区块链（37）：比较吞吐之前先定义哪一种完成 · 38 · 区块链（39）：按证明对象分类，而非排列“新一代共识”。