原子性问题搬到通道里
比特币脚本历史上最有名的用法之一，就是让两笔支出“要么都成、要么都不成”的原子交换：用哈希锁锁定接收条件，用时间锁保证任一方都能全身而退，思路与链上绝对时间锁同源，见 OP_CHECKLOCKTIMEVERIFY 怎么用？比特币绝对时间锁的脚本与陷阱。闪电网络把同一结构原样搬进通道，解决一个更棘手的问题：付款要穿过若干互不信任的中转节点，任何一跳都不能先垫付后赖账。HTLC（哈希时间锁合约）于是成了闪电每笔支付的原子单元：每一跳的资金都锁在“持有原像者可得，超时则退还”的双路脚本里。
哈希锁：认原像不认人
发起方生成随机数作为原像，取其哈希写进发票与路由指令，见 BOLT11闪电发票字段怎么读？。中转节点收到一个 HTLC 时并不付款，只是在自己与下一跳的通道里挂上同样哈希条件的镜像合约：若最终收款人出示原像，原像沿路径反向传播，每一跳据此花掉自己那笔镜像 HTLC；若任何环节失败或超时，每一跳各自走退款分支。哈希锁保证了同一把“钥匙”在整条路径上唯一有效，也保证了信息先于资金流动。
时间锁：阶梯递减的倒计时
退款靠相对时间锁实现，机制就是通道脚本里最常用的 OP_CHECKSEQUENCEVERIFY，见 OP_CHECKSEQUENCEVERIFY 相对时间锁：延迟从何时起算。关键设计是阶梯：每一跳给下一跳设定的超时都必须比自己的到期时间更早若干个块，这段差值就是清算缓冲。只有当下游节点确实拿到资金（或原像）时，上游才在自己的时钟走完前收到确认信号；否则倒计时归零，上游单方面花掉退款分支，把资金收回通道余额。差值必须覆盖“发现失败—链上落定—察觉欺诈并惩罚”的最坏情况，因此实现默认值通常给得相当保守，具体数字随实现版本变化，以所连接节点的策略公告为准。
链上形态：当支付撞上关闭
正常在线的支付全程不碰区块链，通道里的 HTLC 只是一张张双方签好、随时可兑现的更新承诺。但通道一旦走向链上，未结清的 HTLC 必须逐条出现在关闭交易的输出里：超时分支的退款交易与收款分支的支出交易各自排队进块。这里费用与拥堵会真实咬人——HTLC 输出的兑现费率取决于关闭时刻的内存池状况，机制与锚定输出的费用归属问题在 闪电网络通道链上关闭的手续费谁来付？Anchor Outputs 锚定输出怎么起作用 已有专文。大量小额支付同时卡在关闭时，通道会呈现“链上输出成串”的独特形态，这是排查支付失败时最有用的链上指纹。
小结与风险提示
HTLC 把“先验货后付钱”的信任问题折叠成一个原像和两个倒计时：哈希锁决定谁能拿钱，时间锁阶梯决定何时退回。它让闪电在不引入可信中转的前提下维持了链上级的原子性，代价是路径每一跳都要多付超时保险。理解它，你就理解了闪电对拥堵、费率与节点在线率的敏感从何而来。通道资金存在关闭延迟与对手方风险，使用前请阅读运行手册，本文不构成投资建议。
失败路径的两种体面结局
想象最普通的一次失败：路由中途某跳下线。HTLC 的超时阶梯此时显效——失败点之后的镜像合约在各自倒计时结束后逐跳退回，每一跳都不需要信任上游的口头承诺，钱沿原路安静撤回，发起方视角表现为发票超时未付。第二种结局更常见也更容易被误读：你的付款其实成功了，但确认消息在你这一跳丢失，钱包显示“不确定”。切勿立刻重付——发票与支付哈希的唯一性保证重复提交要么命中同一原像被识别为已付，要么走全新路径产生双付，正确动作是等待发票状态查询给出终局，或在超时后用链上原像反查，发票字段见 BOLT11闪电发票字段怎么读？。理解这两条失败剧本，你就能解释闪电文档里反复出现的那句设计哲学：一切异常最终都由超时安全收敛。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。