先修区块链（11）：重组时撤销的不是一个确认数字及区块链（31）：通道、侧链与 rollup 把哪些责任移出主链。通道双方先在链上锁入资产，线下签署状态更新；多跳路由可借助哈希锁与到期条件约束各跳，要么在规定窗口内揭示所需原像并结算，要么按超时规则取回。HTLC（哈希时间锁合约）并不是“永不失败的即时支付”：路由、对端在线、手续费、余额和链上退出窗口都影响结果。

sequenceDiagram
  participant A as 买方
  participant R as 路由节点
  participant B as 卖方
  A->>R: 有哈希锁/较晚到期的转发承诺
  R->>B: 同哈希锁/较早到期的承诺
  B-->>R: 揭示满足哈希锁的原像
  R-->>A: 用原像领取上游支付
  Note over A,B: 对手不协作时须能在链上按期限退出

签过旧通道状态不等于对方不会试图提交它，参与者或受托监控方需要在时限内观察底层链并执行争议。若所有跳的到期时间相同，中间节点可能来不及用下游获得的原像领取上游款；设计要考虑差异窗口及链上拥堵。订单系统既要跟踪收款结果，也要跟踪撤销、失败和通道退出，不能用链下支付响应取代实物交付证据。

时间锁需要给中继留出反应时间

设收款人随机选一个原像 preimage，各跳使用同一个哈希 H(preimage) 锁定资金。中继向下游提供的领取期限应早于向上游领取的期限，二者间隔必须足够容纳观察下游披露、构造上游领取交易、链上拥堵及风险策略所需的确认时间。若下游最晚可在时间 T 出示原像，而上游也恰在 T 截止，中继面对诚实但极晚披露的收款人也可能损失；这与哈希算法的抗碰撞性无关。实际参数依网络、实现及协议版本冻结，不能从示意图推断固定块数。

通道双方的余额改变是带双方约束的状态演进，不是给链上某个 UTXO“实时改金额”。遇到旧状态被广播时，正确的争议交易和撤销材料必须仍可获得；依赖受托监控方则增加其在线性、备份与收费假设。订单 API 只看到路由尝试失败，不能判定中继资产是否已经在不同跳的 HTLC 中待释放。重试需保持订单/付款语义一致，链上争议期间不能擅自把商家债权记两遍。

练习一：买方断网但卖方握有旧状态，凭“双方曾经签过”就能保证资金安全？答案：不能，监控与争议时间窗口是必要条件。练习二：下游已揭示原像、上游到期过早，中继人承担什么风险？答案：可能来不及链上领取上游承诺；需按协议检查各跳到期与链上确认预算。真实通道、HTLC、对手不合作退出 NOT_RUN。

可迁移原则：链外加速换取在线监视及可强制退出的责任。参考：Lightning BOLTs、Bitcoin Core（规范/网络参数待核）；导航：区块链（47）：选数据库、签名日志、许可链还是公链 · E01 · 区块链（E02）：SegWit、Schnorr 与 Taproot 的三个升级维度。