比特币正本 Bitcoin Arche

协议演进 / BIP/比特币改进提案 / BIP-197

BIP-197 哈希时间锁定抵押合约

以两组 P2SH 脚本把比特币锁作抵押，配合另一条链上的借款合约，实现跨链抵押借贷的还款、清算与没收流程。本 BIP 目前处于草案状态。

一、档案卡

档案卡
编号BIP-197
标题Hashed Time-Locked Collateral Contract
作者Matthew Black <[email protected]>, Tony Cai <[email protected]>
指定日期2019-03-19
层级Applications（应用）
类型Specification（规范类）
状态Draft（草案）
阅读版https://bips.dev/197
官方原文https://github.com/bitcoin/bips/blob/master/bip-0197.mediawiki

二、放在哪一族

哈希时间锁合约（HTLC）应用族，定位是把 HTLC 从“跨链原子交换”推进到“跨链抵押借贷”。

原文在摘要里给出它的两条根：其一是 BIP-199（哈希时间锁合约 HTLC）的交易脚本思路；其二是 Atomic Loans 规范（一篇 arXiv 论文，本篇给出链接），本篇是该规范在比特币一侧的抵押合约部分。与之配套的还有另一条链上的哈希时间锁本金合约（HTLPC）：借款本金在那条被原文称为 principal blockchain 的链上发放，比特币这边只负责锁抵押品。

原文兼容性一节称，本篇与以太坊一侧的 ERC-1850（原子借贷）兼容，未来可扩展到其他支持 HTLC 与智能合约的链。

三、它要解决什么

设想一个债务安排：借款人有比特币，出借人有另一条链上的货币。借款人想以比特币作抵押，借出另一条链上的本金；出借人则需要保证：借款人不按期连本带息偿还时，自己能拿到约定比例的抵押品，而不是只能干等。

难点在于两条链互不感知：比特币脚本看不到另一条链上是否已还款。原文给出的办法，是用一组秘密（secret）与超时（timeout）把两条链上的合约状态推进绑在一起——在一条链上揭示某个秘密，既是推进那一侧状态的凭证，也解锁另一侧对应的路径。加上分阶段超时，合作时按约走完，不合作时各方也能按预先锁定的比例收回自己那份。

原文在动机一节概括：HTLCC 交易是一种用揭示秘密来结算债务协议状态的安全方式；面对不合作的对手方，能收回一定比例的抵押资金；面对合作的对手方，能确保本金＋利息＋清算费得到偿付。

四、规则本身

4.1 两组抵押脚本

抵押品不锁进一个脚本，而是拆进两个 P2SH，金额比例在锁定时预先约定，代表还款失败且不走清算时双方各自有权拿回的份额：

两组脚本结构相近，都是多层 OP_IF / OP_ELSE 分支：每条分支或要求揭示某个秘密（先用 OP_SIZE … OP_EQUALVERIFY 钉死秘密长度，再以 [HASHOP] 校验其哈希），或在某个超时之后允许单方签名花费，或要求借贷双方 2-of-2 多签（OP_2 <borrower pubkey> <lender pubkey> OP_2 OP_CHECKMULTISIG）配合秘密揭示。其中 [HASHOP] 可取 OP_SHA256 或 OP_HASH160，[TIMEOUTOP] 可取 OP_CHECKSEQUENCEVERIFY 或 OP_CHECKLOCKTIMEVERIFY。

原文专门解释了为何每处用到秘密都要先 OP_SIZE 校验长度：与以太坊等链上的 HTLPC 配合时，那边 sha256 只取 32 字节，必须保证比特币这一侧的秘密恰好是约定的字节数（原文举例为 32 字节），两边对同一秘密的理解才一致。

4.2 秘密与角色

关键时间点有三个：借款到期（loan expiration，须在此前还清本息）、竞价到期（bidding expiration）、没收到期（seizure expiration）。

4.3 流程五阶段

  1. 批准期：出借人在本金链部署 HTLPC；借款人在比特币链把抵押锁进两组 HTLCC。 出借人满意则揭示 B1，借款人揭示 A1 提取借款；不满意则出借人揭示 B2 退回本金，借款人随之退回抵押。
  2. 借款期：借款人应在到期前偿还本金加利息；出借人接受还款时揭示 B2，借款人即可退回全部抵押。若借款人违约或还款不被接受，进入竞价期。
  3. 竞价期：任一方可发起抵押清算，第三方出价竞标。成交后借贷双方各签一份多签，中标者揭示 C，双方再分别揭示 A2 与 B3，中标者取走抵押品——抵押品与竞标资金由此完成一次原子交换。
  4. 没收期：若任一方不接受竞标结果，出借人可按锁定比例没收可没收抵押那一份；同期借款人可退回可退还抵押那一份。
  5. 退款期：若出借人未在没收期动用可没收抵押，借款人可把那一份也退回给自己。

4.4 向后兼容

原文称这是一个全新的抵押借贷标准，无需考虑向后兼容；成为标准后，某些环节（如两链最大区块大小相同情形下免去秘密长度校验）可在保持兼容的前提下修改。原文实现一栏给出 Atomic Loans 的 chainabstractionlayer 代码库中比特币抵押提供者的实现链接。

五、谁必须动

普通持币人：不直接接触脚本；只有实际参与这类跨链借贷、并使用实现本协议的平台时，才会作为借款人或出借人进入上述流程。

钱包开发者／借贷平台：需构造两组抵押脚本、生成与管理 A／B／C 系列秘密、监控两条链上各阶段的超时与揭示，并按阶段推进花费路径，工程量集中在这里。

全节点与矿工：无特殊要求。链上出现的只是 P2SH 花费，使用的是既有操作码（含 OP_CHECKMULTISIG 与时间锁操作码）。

共识层：无改动。本篇不提任何新操作码或规则变更，是纯应用层脚本组合。

六、现在算不算数，以及一个常见误读

状态为 Draft（草案）。它是一份建立在 BIP-199 与 Atomic Loans 规范之上的应用层设计稿，原文没有声称它已被比特币生态普遍采用或成为事实标准；是否在某平台上真实运行，应查该平台自身材料，不要由本篇推断。读它的价值在于看清：只用哈希锁与时间锁，如何拼出一个带清算与没收分支的跨链债务状态机。

常见误读：

“抵押锁进 HTLCC，就等于比特币协议原生支持借贷了。”

不对。协议层什么都没加：节点看到的只是普通的 P2SH 输出与花费。“借款、清算、没收”这些语义全部来自双方事先约定并锁进脚本的分支条件，以及另一条链上 HTLPC 的配合；任何一环的链下协调（出价、签名、揭示秘密）缺位，流程就只能靠超时分支收场。把应用层合约误读成协议功能，会高估它的强制力与普及程度。

七、延伸

本页内容整理自 bitcoin/bips 仓库与 bips.dev，事实已与仓库核对；解读仅供学习参考。