跳到正文
Financial Context Wiki

哈希时间锁合约（HTLC）

哈希时间锁合约允许收款方在到期前用原像领取付款，并允许付款方在到期后通过另一条支出路径退款。了解 HTLC 如何协调支付通道与原子交换，以及它仍可能在哪里失效。

更新于

仅供教育参考，不构成投资、法律或安全建议。HTLC 的安全性取决于具体脚本或合约、链规则、确认策略、费用、监控和及时操作。

直接答案

哈希时间锁合约（HTLC）是一种有两条竞争性支出路径的条件付款。到期前，收款方可公开一个值 x，使其哈希与已承诺值 h = H(x) 相符，并满足所需签名或授权来领取资金。到期后，付款方可使用退款路径。临界点上的准确先后顺序由链和合约决定，不能只按自然语言中的“之前”理解。

哈希锁把动作关联起来：参与者在付出一笔下游款项后，获知同一原像便可能结算相关的上游付款。时间锁限制资金保持条件状态的时长。支付通道协议用这些性质转发付款，原子交换协议则可用它们协调不同系统上的转移。

HTLC 并不会自动带来无需信任、原子性、隐私或自动执行。安全还取决于脚本或合约正确、哈希与原像编码兼容、到期时间错开、最终性假设、手续费可用、持续监控，以及交易能在截止前确认。Lightning 的 HTLC 是一种有明确规范的比特币设计；其他链上的合约语义可能有实质差异。

  • 哈希分支： 在该路径仍有效时公开所需原像，并满足成功路径的授权。
  • 超时分支： 在适用的绝对或相对时间锁成熟后，满足退款路径的授权。

工作原理

以单笔条件付款为例，假设 Bob 选择一个全新且不可预测的原像 x，计算 h = H(x)，并把 h 交给 Alice。Alice 按一组承诺 h、指定授权参与方并定义到期点 T 的规则锁定资金。

  • Alice 在出资前核对哈希算法、字节编码、金额、资产、收款方、退款目的地、链和到期点。
  • Bob 核对实际获得资金的输出或已部署合约，而不是相信交易草稿或界面显示。
  • 若 Bob 走成功分支领取，他提供 x；支出逻辑检查 H(x) = h 以及所需授权。
  • x 在链上公布或通过协议传递后，Alice 或中间节点可能据此结算另一笔使用相同付款哈希的 HTLC。
  • 若成功分支未及时使用，退款分支在 T 时具备资格；具备资格并不会自行广播或确认退款。
  • 参与者仍须构造或保留正确交易、支付足够费用、提交交易、监控替换与冲突，并取得所需确认深度。
  • 一旦 x 已向对手方或公链公开，就应视为已经泄露，不要把它复用于无关条件。

比特币区分绝对锁与相对锁。BIP 65 的 OP_CHECKLOCKTIMEVERIFY 通过交易锁定时间，将支出限制到指定区块高度或区块时间之后；BIP 112 的 OP_CHECKSEQUENCEVERIFY 将支出限制到输入达到足够相对年龄之后。脚本还必须搭配兼容的交易字段。因此，时间锁是验证规则，不是定时调度器。

在 Lightning 中，update_add_htlc 携带金额、payment_hash 和 cltv_expiry。每个转发节点给下游 HTLC 设置的到期点早于对应上游 HTLC，使其在获知原像后仍有时间向上游领取。BOLT 3 定义了承诺输出、HTLC-success 与 HTLC-timeout 路径，包括签名、撤销处理、尘埃裁剪和附加延迟；只有两分支示意图并不能构成完整的 Lightning 通道实现。

示例

设想一个 Alice 用 1 BTC 交换 Bob 的 20 ETH 的教学示例。它只说明操作顺序；生产环境中的比特币与以太坊实现需要针对各自链审查代码，不应照搬这些名义期限。

  • Alice 生成全新的 x 和 h = H(x)，随后锁定 1 BTC，使 Bob 可凭原像领取，而 Alice 在 48 hours 后有退款路径。
  • Bob 检查比特币交易及所选确认策略后，按兼容的哈希与编码规则锁定 20 ETH；Alice 的成功路径在 24 hours 后结束，Bob 的退款路径随后生效。
  • Alice 在公开 x 领取 20 ETH 前，核对以太坊链 ID、合约字节码与地址、代币或原生资产、金额、参与方、h 以及两条可调用路径。
  • Bob 从成功领取或约定的协议消息中获知 x，并在较晚的截止点前尝试比特币成功路径。
  • 如果交换在原像公开前停止，每笔退款都只能按各自链规则取得资格；双方都必须提交相应退款交易并等待确认。

48 hours 与 24 hours 的间隔是响应缓冲，并非普适安全参数。必须同时为两套系统建模重组、出块时间波动、最终性、合约执行、中继假设、内存池策略、手续费激增、审查和操作延迟。后行动的一方不能仅因界面显示“已确认”就继续。

风险

  • 承诺错误： 两边的哈希算法、原像长度或编码不同，导致同一个 x 无法同时满足两边条件。
  • 对象错误： 实际出资的输出、链 ID、合约地址、字节码、资产、金额、收款方或退款目的地与界面声称的不符。
  • 到期顺序不安全： 截止点相同或间隔不足，使中间节点或交换对手在付出下游资金后无法向上游领取。
  • 边界理解错误： 区块高度、区块时间、时间戳、相对年龄，以及 < 与 <= 等合约比较并不等价。
  • 不会自动退款： 成熟只会让一笔支出变得有效；钱包、节点、用户或监控服务仍须采取行动。
  • 费用与尘埃失败： 领取可能不经济、从 Lightning 承诺中被裁剪、因费率太低而卡住，或因没有链的原生费用资产而无法执行。
  • 确认与重组风险： 看到交易或原像不等于任一链上的结算已不可逆。
  • 竞争与拥堵风险： 成功支出、超时支出、替换、冲突或恶意拖延都可能耗尽响应窗口。
  • 实现风险： 脚本、智能合约、钱包、签名、nonce、RPC 或客户端缺陷可能破坏预期路径。
  • 监控风险： 离线参与者可能错过原像公开、到期、强制关闭、交易替换或最后实际广播时点。
  • 隐私泄露： 复用的付款哈希、公开原像、金额、时间和通道事件可能帮助关联转账或路径。
  • 选择权与拖延： 一方可锁住对方流动性后放弃；条件结算不保证完成，也不补偿延迟。

在投入有意义的价值前，应以可忽略金额测试成功与退款两条路径，记录准确对象和截止点，保留手续费储备，并明确故障时由谁监控和广播。

常见误区

  • “超时后资金会自动退回。” 通常超时只会启用退款支出；仍须有人广播并等待确认。
  • “满足 H(x) = h 就是全部合约。” 签名、脚本分支、交易字段、链规则、撤销逻辑和合约授权同样重要。
  • “两边使用相同到期点最公平。” 转发节点或后行动方在获知 x 后需要有意保留的上游缓冲。
  • “看到原像就保证来得及领取。” 确认延迟、重组、拥堵、费用和审查都可能耗尽剩余窗口。
  • “原子意味着两条链在一笔不可分交易中同时改变。” 跨链交换协调的是分开的状态转换；中止与退款路径仍存在，也可能暂时出现单边状态。
  • “HTLC 匿名并消除了所有信任。” 它可能泄露关联信号，仍依赖协议代码、链行为、密钥、监控和操作假设。

相关主题

来源

导航

搜索知识库...