闪电网络 HTLC 的三把钥匙：原像、倒计时与撤销密钥怎么配合

多跳支付需要一把公共钥匙

闪电网络要把一笔付款沿 Alice、Bob、Carol 的通道链传递，既没有清算中心，也不能出现”中间人转发成功却收不到钱”。解法是把收款条件做成密码学合约：付款方生成一个秘密（preimage），对其取哈希，每一跳都用同一个哈希挂一个有条件的转账——交出秘密就能取钱，到期没人交出就退款。BIP199 给出的脚本形状一目了然：OP_IF 分支用哈希等于校验加收款人签名放币，OP_ELSE 分支用时间锁加付款人签名退款。秘密的披露本身就是转账动作：谁在链上花这笔钱，谁就必须把钥匙公开，钥匙随即沿路径逐跳回传，形成”要么全链成交、要么全链退回”的原子性。

通道内部的 HTLC 输出

在单条通道里，HTLC 不是独立链上合约，而是承诺交易（commitment transaction）里的特殊输出，用 P2WSH 封装。发送方用 update_add_htlc 提议挂一笔：金额 amount_msat、到期高度 cltv_expiry、哈希 payment_hash。承诺交易上的脚本给了三种出口：撤销密钥分支（惩罚旧状态）、双方两秒签的协作分支，以及条件分支——对发送方（offered 侧）是”对方出示原像取钱，或到期后用 HTLC-timeout 退款”；对接收方（received 侧）是”出示原像走 HTLC-success，或超时后对方直接取款”。条件分支都要求双方签名参与，付款方因此无法提前退款。

为什么强制关闭要两段式

如果通道直接上链关闭，每个 HTLC 输出还会再多一层：需要第二阶段的 HTLC-success 或 HTLC-timeout 交易才能兑现。协议故意这样设计有两个原因。其一是惩罚窗口：承诺交易把回到自己名下的输出锁在 to_self_delay 之后，给对方留出发现旧状态并用撤销密钥全额罚没的时间；HTLC 若要绕过这段延迟各自兑现，就必须拆成单独交易。其二是全局时钟：如果 HTLC 也被 to_self_delay 拖着，整条路由所有跳的最小超时要相应拉长。于是 timeout 交易的 locktime 正好取 cltv_expiry，success 交易则公开原像。

倒计时沿路径递减

发起付款时，发送方给第一跳一个较高的到期高度；每个转发节点检查上游的 cltv_expiry，给下游的必须减去自己广告过的 cltv_expiry_delta，最后一跳再受发票里 min_final_cltv_expiry_delta 的约束。这种逐级递减保证链条尾端先到期、链头后退款，中间没人能靠拖延双吃：如果下游迟迟不转发也不退回，上游在自己的到期高度前把承诺交易与 HTLC-timeout 一起搬上链即可按退款分支取回资金——这就是卡住的付款”最终总会链上退钱”的机制来源。反向看，接收方若要保证不被”先到期被退回”，就必须让自己的兑现交易在倒计时归零前上链，这也是发票强制最后一段留出安全区块数的原因。路径越长，逐级扣减消耗的安全余量越多，发送方必须相应抬高起始 cltv_expiry，否则链条尾端可能来不及兑现；路由选择时这些 delta 是硬约束而不是可调参数。

风险边界与排查视角

对使用者而言，HTLC 把信任从对手方转移到两件事上：秘密的保密性和区块链对时间锁的执行。发票过期时间、最小 CLTV 增量都直接影响资金被锁的时长；链上关闭期间，惩罚路径依赖双方此前签好的撤销密钥，一旦本节点把旧状态连同撤销密钥一起泄露，理论上存在资金被对方按惩罚分支取走的风险——这正是各家节点实现强调备份与密钥隔离的原因。需要说明的是，这套结构只保证资金不被中间人吞没，不保证服务可用性：通道对侧离线、通道余额一边倒、链上拥堵导致费率上涨、超时竞争都可能让兑现变慢甚至改道。排查一笔卡住的付款时，有意义的动作是查承诺交易与两阶段交易是否出现在链上、cltv_expiry 对应的高度是否已过、原像是否已被公开，而不是轻信任何声称能”代操作退款”的第三方服务；任何要求提供助记词或私钥来加速退款的说法都属于典型诈骗话术，与协议机制无关。