哈希时间锁机制

Posted 云灬沙

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了哈希时间锁机制相关的知识,希望对你有一定的参考价值。

特别好的一篇文章,之前收藏过好几次,,但是都没了,所以复制了一篇过来看

撰文:钱柏均,就职于 HashKey Capital Research
审校:邹传伟,万向区块链、PlatON 首席经济学家

结合最新的文章添加一点东西:

闪电网络最近提出了PTLC(Point Time Locked
Contracts),去掉了HTLC中对哈希的使用,更保护交易的隐私和安全。PTLC以标量和支付点取代了原像和哈希值的设置,之后的节点都要求不同的随机数,因此难以识别具体路径上的节点【来源于HashKey2021年数字资产行业年终回顾】。

本文研究哈希时间锁的合约机制、主要特点、应用瓶颈以及改进方向

哈希时间锁是去中心化和去信任化环境中进行条件支付的基础,是理解数字货币和数字资产的可编程性的基础。除了对密码学的应用,哈希时间锁的核心是序贯博弈。多个哈希时间锁可以组成多跳支付,是比特币闪电网络支付通道的基础,也在用央行数字货币进行跨境支付有广泛应用,被很多中央银行所关注。相向而行的哈希时间锁可以组成原子交换,在区块链应用于证券结算以及去中心化交易所中有应用。

哈希时间锁(Hash Time Locked Contract,HTLC) 起源于闪电网络,而后应用到 Interledger、雷电网络、Sprites 通道等。哈希时间锁使多个用户之间「条件支付」(Conditional Payment)能以去中心化、无需第三方受信任中介的方式完成,这些用户不一定在同一条区块链上。哈希时间锁可以组成多跳支付 (即双方在交易过程中可藉助多个中间节点来完成交易)和原子交换(Atomic Swap),是链下支付通道和跨链交易的基础,并在央行数字货币跨境支付、证券结算以及去中心化交易所中有广泛应用。

本文共分三部分:第一部分介绍 HTLC 合约机制,提出对 HTLC 的序贯博弈分析方法,并分析 HTLC 在应用中遇到的瓶颈;第二部分以 Interledger 的 HTLAs(哈希时间锁定协议) 和雷电网络为例,分析 HTLC 的改进方向;第三部分讨论 HTLC 的两个重要应用案例:跨境转账,以及证券结算和去中心化交易所。

HTLC 合约机制

HTLC 支持「条件支付」:通过多个首尾相连的支付通道串联起来形成的支付路径,支持首尾双方通过支付路径完成支付。HTLC 的核心是时间锁和哈希锁
时间锁指,交易双方约定在某个时间内提交才有效,超时则承诺方案失效(无论是提出方或接受方)。
哈希锁指,对一个哈希值 H,如果提供原像 R 使得 Hash® = H,则承诺有效,否则失效。
如果交易因为各种原因未能成功,时间锁能够让交易参与各方拿回自己资金,避免因欺诈或交易失败造成的损失。
接下来,我们用一个例子说明 HTLC 工作流程。

假设 Alice 想开启一个与 Bob 的交易,交易金额为 0.5 BTC,但 Alice 需要通过 Carol 才能与 Bob 建立通道进行交易(图 1):


图 1: HTLC 与支付路径

第一步:Bob 设定原像 R (也被称为暗示数),把哈希值 H=Hash® 告诉 Alice。

第二步:Alice 通过 HTLC 向 Carol 进行条件支付:当且仅当 Carol 在 T 时刻前提供与哈希值 H 对应的原像 R,Alice 才向 Carol 支付 0.5 BTC。类似地,Carol 通过 HTLC 向 Bob 进行条件支付:当且仅当 Bob 在 t 时刻前提供与哈希值 H 对应的原像 R,Carol 才向 Bob 支付 0.5 BTC,其中 t<T。

第三步:Bob 如果在 t 时刻前向 Carol 提供 R,获得 0.5 BTC,此时 Carol 知悉 R。反之,0.5 BTC 会返回给 Carol,Carol 不会遭受任何损失。

第四步:Carol 如果在 T 时刻前向 Alice 提供 R,获得 0.5 BTC。反之,0.5 BTC 会返回给 Alice,Alice 不会遭受任何损失。

可以看出两点:第一,在参与者理性前提下,HTLC 中所有「条件支付」要么全部完成,要么全不完成但所有参与者都能拿回自己的资金,因此是原子式的(Atomic)。这是序贯博弈均衡的结果(见下节)。第二,原像 R (信息)和资金相向流动,原像 R 可以被视为收据(Receipt)。在 HTLC 中原像和哈希值的传输可以全部在链下完成,链上只做相关内容的检验,因此可以有效保护客户隐私信息。

对 HTLC 的序贯博弈分析

在上节 HTLC 例子中,存在 Bob、Carol 和 Alice 3 人的序贯博弈 (图 2)。图 2 采取博弈树形式。博弈树的每个节点都代表一个参与者,从每节点出来的每条边都表示该参与者可选择的一个行动。在博弈树的每一个末端节点上,都有一个 3 维支付向量。支付向量中的元素依次表示在不同策略组合下 Bob、Carol 和 Alice 的净收益。

图 2: HTLC 序贯博弈分析 (1)

序贯博弈程序如下:

  1. Bob 行动,他有两个可选行动:「在 t 时刻前提供正确原像」,「在 t 时刻前不提供或提供错误原像」。
  2. Carol 行动。如果 Bob 选择「在 t 时刻前提供正确原像」,那么 Carol 有两个可选行动:「向 Bob 支付,并在 T 时刻前提供正确原像」,「向 Bob 支付,并在 T 时刻前不提供或提供错误原像」。如果 Bob 选择「在 t 时刻前不提供或提供错误原像」,那么 Carol 只有一个可选行动:「不向 Bob 支付,并在 T 时刻前不提供或提供错误原像」。
    3.Alice 行动。在 Carol 选择「在 T 时刻前提供正确原像」时,Alice 只有一个可选行动:「向 Carol 支付」。在其他场景下,Alice 只有一个可选行动:「不向 Carol 支付」。显然,Alice 实际上没有选择的自由。

我们用倒推法求解序贯博弈的纳什均衡:从最后阶段开始分析(实际是从 Carol 开始分析,因为 Alice 并无选择行动的自由),每一阶段分析该阶段局中人行动选择和路径,再确定前一阶段局中人行动选择和路径。

首先(图 3,用 X 表示被排除掉的策略路径,下同),在 Bob 选择「在 t 时刻前提供正确原像」的情况下,Carol 选择「向 Bob 支付,并在 T 时刻前提供正确原像」的净收益是 0,选择「向 Bob 支付,并在 T 时刻前不提供或提供错误原像」的净收益是-0.5BTC。因此,Carol 的理性选择是「向 Bob 支付,并在 T 时刻前提供正确原像」。

图 3: HTLC 序贯博弈分析 (2)
其次 (图 4),Bob 如果选择「在 t 时刻前提供正确原像」,他的净收益为 0.5BTC;反之,他的净收益为 0。因此,Bob 的理性选择是「在 t 时刻前提供正确原像」。

图 4: HTLC 序贯博弈分析 (3)
因此,序贯博弈的纳什均衡策略是:Bob「在 t 时刻前提供正确原像」,Carol「向 Bob 支付,并在 T 时刻前提供正确原像」,Alice「向 Carol 支付」。序贯博弈也为分析其他形式的 HTLC 提供了合适工具。

HTLC 主要特点

  • 时间敏感性

HTLC 机制对交易时间的敏感性使得交易发起者不必浪费时间持续等待以确定他们的付款是否通过。如果设定时间已过,资金将被退回交易发起者,能够有效避免恶意拖延交易,降低交易对手风险。

  • 去信任化

HTLC 的最大优势是去信任化。HTLC 消除了对中心化交易和受信任中介的依赖。交易可以经由两方或多方执行而不需要它们彼此信任。由于用户不需要将资金提供给第三方托管机构,安全性也会相对提高。交易可以直接从用户的个人钱包发起,大幅地降低了第三方参与的风险。

  • 跨资产交互性

在 HTLC 中,资金锁定实现了质押效果,为不同资产之间的交易提供了信任基础。而原像及哈希秘钥的传递,则保证了交易的原子性。

HTLC 应用瓶颈

  • 协议兼容性较低

HTLC 实施需要满足一些必要条件:一是用户资产所在区块链需要基于相同哈希算法(比如都使用比特币的 SHA-256 哈希算法);二是区块链需要兼容 HTLC 和其他可编程功能;三是交易双方需要在同一区块链上有交易账户。这些条件可能会成为 HTLC 推广应用的主要障碍。

  • 时间锁机制造成退款时间过长

时间锁有效降低了交易对手风险。但如果有中间节点因故无法进行交易,则必须等时间锁设定时间结束才能退款。如果发送者在设定时间结束前改变路径,将会承担极大风险。

例如图 1 中, Alice 利用 HTLC 通道,通过节点 Carol 给 Bob 转账,但现在由于某些原因,Carol 出现故障,无法在时间锁设定时间内在线,从而 Alice 无法通过 Carol 转账。如果原来的 HTLC 没有到期,Alice 要换路径的话,会面临很大风险。原因是,Bob 可以与 Carol 共谋,Bob 在通过新路径拿到支付金额后,再向 Carol 透露原 HTLC 的原像,从而 Alice 在原来那条路径锁定的资金也就会被 Carol 解锁取走,Alice 就相当于支付了两次。因此,一旦有节点掉线,等待时间锁解锁成为唯一选项。

HTLC 改进方向

Interledger 的 HTLAs(哈希时间锁定协议)
HTLAs (Hashed Time-Lock Agreements)是 Interledger 提出的基于 HTLC 的泛化协议,目标是不管区块链账本是否支持 HTLC 协议,不管其是分布式区块链还是中心化账本,系统和系统之间都能使用 HTLAs 实现跨链交换,并且支持多个系统之间的多跳跨链互换。在 HTLAs 下,不同用户节点可以根据交易所需通过不同种类的 HTLAs 完成交易,而 Interledger 协议可以确保每个 HTLAs 拥有独立的安全性,不会受其他区块链交易失败的影响。

HTLAs 根据系统支持的功能性主要可区分成四种:条件支付通道(Conditional Payment Channels with HTLC)、链上持有 / 托管 (On-Ledger Holds/Escrow with HTLC)、简单支付通道 (Simple Payment Channels) 以及信任线 (Trustlines)。

图 5: Interledger 跨链交易过程

  • 条件支付通道

此种协议需要区块链账本支持 HTLC 条件支付通道,并可以在交易结束后更新通道余额。闪电网络的 HTLC 机制属于这类。交易参与者需要在区块链上预先支付一笔资金至双方共有的临时账户中 (即通道余额)。当交易开始时,发送者会发送一个带有哈希锁和时间锁以及附带签名的更新到接收者。若接收者能在约定时间内告知哈希锁的原像,则可从账户中获取资金,并且发送者与接收者需要同时签名确认共有账户的余额变动。由于交易的传输和处理时间会被计算在交易时间范围内,所以该种协议更适合支持高速交易的区块链系统。

  • 链上持有 / 托管

此种协议需要区块链支持 HTLC 协议,并且费率低、交易速度快、吞吐量高。以太坊和 Ripple 第三方托管合约属于此类。交易参与者可以直接通过 HTLC 协议发起跨链交易。交易发起者将要传输的资金先放到区块链提供的特定持有账户中,并且附带哈希锁和时间锁。只有当接收者在约定时间前能提供正确的哈希原像,区块链才将资金发送给接收者,否则区块链会把资金退回给发送者。只要区块链是可信赖的,这种方式可由区块链全权控制交易状态,交易双方没有额外风险。它与条件支付通道的差异是,交易参与者是将资金存放在区块链账户,而非双方共有账户。

  • 简单支付通道

简单支付通道的特点是交易双方可以合并多个交易而只清算最终账户的净轧差。简单支付通道交易发生在区块链之外而非链上,且双方需要在同一区块链上拥有账户。交易分为以下三个阶段 : 设立阶段、状态更新阶段以及清算阶段。

(1) 设立阶段 : 假设 Alice 和 Bob 进行交易准备,其中一方或双方需要将一定数量的资金托管在一个暂时性且共享的支付通道中。

(2) 状态更新阶段 : 在交易开始前,双方先签署一个状态声明,用以表示支付通道中双方资金占比。Alice 会传送一个签署过后带有哈希锁及时间锁的状态声明给 Bob(而非区块链)。该更新后的状态声明呈现了交易结束后双方在支付通道的资金占比分配。唯有当 Bob 在时间锁设定的时间内传送哈希值的原像,状态声明才会更新。交易通道并无方向限制,只要双方余额为正值便可持续双向交易。

(3) 清算阶段:一旦有一方参与者想停止使用支付通道,可以执行退出操作——将最后的状态声明更新提交至区块链,结算后的余额会退给发起支付通道的两方。主链可以通过核实签名和最后结余来验证状态更新的有效性,从而防止参与者使用无效状态来退出支付通道。

简单支付通道与闪电网络所使用的条件支付最大差异在于是否有强制性。在两个方法下,双方同样是通过链外协议交换签署过的状态声明进行交易。但在条件支付下,一旦在设定时间内 HTLC 条件满足,区块链会强制执行转账。而在简单支付通道下,即使在设定时间内 HTLC 条件满足,链上转账与否仍是双方操作,并无强制性,因此较依赖双方之间的信任程度。

  • 信任线

信任线是交易双方凭借信任基础进行的一种交易方式。信任线交易发生在链下而非链上,只有最后清算在链上发生。交易可以分为以下三个阶段 : 设立阶段、状态更新阶段以及清算阶段。

(1) 设立阶段 : 假设交易发送者 Alice 及交易接收者 Bob 在同一个区块链上拥有账户,想要开始一个信任线交易。Alice 首先需要设定 Bob 的信任线额度,这个信任线额度关系到 Bob 可以在双方的信任线做的交易额度而无须清算。同样,Bob 也需要设定 Alice 的信任线额度。

(2) 状态更新阶段 : 在交易开始时,Alice 会传送一道带有哈希锁及时间锁的交易讯息给 Bob。当 Bob 在时间锁设定的时间内传送哈希值的原像至 Alice 后,双方的信任线状态会更新,一方余额增加而另一方余额减少。此阶段尚未清算。信任线为双向通道,只要交易总金额并未超过双方信任线额度便可一直进行交易,而无须在链上进行清算。

(3) 清算阶段 : 交易双方将总净额在区块链上清算以结束交易。
信任线和简单支付通道的主要有两个差异 : 一是在信任线机制下,交易双方无须存一笔保证金至通道,可以以最初设定的余额进行逐笔交易,相当于信用交易。二是一旦交易总金额超过双方信任线额度,或是双方同意清算,便可以直接进行一笔链上转账结束交易。而在简单支付通道机制下,任何一方均可主动结束交易,不需双方同意。
表 1 为四种 HTLAs 支付方式的比较。可以看出,区块链功能复杂程度与风险程度反向变化:支付方式越复杂,交易风险越低,反之亦然。

表 1:四种 HTLAs 支付方式比较
表 2:不同支付方式的比较 日本银行和欧央行的 Stella 项目 在第三阶段进行了类似试验。他们比较了四种 HTLAs 支付方式和第三方托管的安全性(表 2)。


Stella 项目发现,条件支付通道、链上持有 / 托管和第三方托管都是安全的,而信任线的安全性最差。

以太坊的雷电网络

雷电网络是以太坊的一个链下交易方案。据官网开发路线图,目前方案尚未完备,还在测试阶段。2017 年 11 月底,µRaide(微雷电) 正式在以太坊主链上线,可以支持每秒 100 万笔交易。2018 年 3 月,Liquidity.Network 正式加入了雷电网络。雷电网络目标是将交易场景从以太坊转移到支付通道上,期望解决以太坊两大问题——通道拥堵及交易费用高。雷电网络的 HTLC 机制大多承袭闪电网络,但也有部分技术创新。以下介绍两个新增机制 : 智能条件及重试哈希锁。

智能条件
雷电网络引入「智能条件」(Smart Condition) ,比闪电网络的 HTLC 机制更为通用。闪电网络的 HTLC 机制是以哈希函数的原像作为秘钥,但在雷电网络中,用户可以设定基于任何函数的秘钥作为智能条件。这种设计能够让雷电网络的交易更加智能化,但同时也增大了交易风险与变数。

重试哈希锁
在闪电网络中,HTLC 的原像一般由收款人设置,然后将原像的哈希值提供给付款人。但这种设计存在一定问题:如果付款人想在原先 HTLC 时间锁解锁前发起另一个相同交易,中间人与收款人将有合谋的可能性,导致付款人重复付款(见前文)。为了缓解这个问题,雷电网络设置了重试哈希锁 (Retry Hashlock)。为区分两个哈希锁,下文把闪电网络的哈希锁改称为收据哈希锁 (Receipt Hashlock)。

假设 Alice 在雷电网络上支付一笔款项给 Bob,并且 Alice 需要通过 Carol 建立通道才能与 Bob 进行交易。以下为重试哈希锁机制 :

第一步:Bob 设定原像 R (收据哈希锁),把哈希值 H=Hash® 告诉 Alice。

第二步:Alice 设定原像 R*(重试哈希锁),其哈希值为 H*=Hash®*。Alice 通过 HTLC 向 Carol 进行条件支付:当且仅当 Carol 在 T 时刻前提供分别与哈希值 H、H对应的原像R,Alice 才向 Carol 支付资金。

第三步 : Carol 通过 HTLC 向 Bob 进行条件支付:当且仅当 Bob 在 t 时刻前提供分别与哈希值 H、H*对应的原像,Carol 才向 Bob 支付。其中,t<T。

第四步:当 Alice 确认 Carol 发起交易并成功设定与 Bob 的 HTLC 后,Alice 才会向 Bob 提供哈希值 H对应的原像 R

第五步:Bob 已知 R 和 R*。Bob 在 t 时刻前向 Carol 提供 R、R*,获得资金,此时 Carol 知悉 R、R*。反之,资金会返回给 Carol,Carol 不会遭受任何损失。

第六步:Carol 在 T 时刻前向 Alice 提供 R、R*,获得资金。反之,资金会返回给 Alice,Alice 不会遭受任何损失。

在上述机制中,如果在交易途中 Carol 因故无法向 Bob 进行条件支付(第三步),Alice 可以重新设置重试哈希锁,改以另外途径进行支付。Bob 因为不掌握 R*,不能与 Carol 共谋进行双重支付攻击。

重试哈希锁也适用序贯博弈分析法。因篇幅限制,本文就不展开阐述了。感兴趣的读者可以参考图 2-4 的做法。

HTLC 应用案例

跨境转账
目前,跨境转账依赖于 SWIFT 网络,存在手续费高、无法实时收款等问题。区块链在跨境转账中的应用一直备受关注,集中体现为央行数字货币和以 Libra 项目为代表的全球稳定币,目标是通过区块链替代代理行模式,以降低交易费用和所需时间。如果两个央行数字货币使用不同的区块链网络,那么两个货币区之间跨境转账就涉及跨链操作和交易对手信用风险管理。这本质上是涉及多个条件支付的多跳支付,是 HTLC 能发挥作用的地方。

2019 年中,加拿大银行与新加坡金管局成功利用 HTLC 技术完成一笔跨境转账(图 6)。加拿大银行和新加坡银行分别利用 Corda 和 Quorum 区块链平台进行合作。试验使用 HTLC (具体来说,前文介绍的 Interledger 的 HTLAs 协议)来连结两个区块链平台,以提升跨链交易的安全性和清算同步率,提高跨境转账效率。尽管转账过程仍然离不开中间银行(Intermediary Bank),但位于新加坡和加拿大的中间银行是同一家。

图6: 加拿大银行与新加坡金管局跨境转账试验

Stella 项目特别分析了以下情形:如果付款人破产,托管资金是否安全?具体而言,就是图 7 的多个条件支付中:如果在第 4 步完成后,Connector 1 破产,Connector 2 能否执行第 5 步以拿到资金?

图 7:多跳支付中有中间机构破产的情形
证券结算和去中心化交易所 在跨境转账,资金是单向流动。如果除了资金流动,还涉及另一种经济资源的反向流动,比如证券结算中的券款对付 (DvP,Delivery vs Payment)。这就涉及原子交换。原子交换也是去中心化交易所的基础。
  • 原子交换介绍

原子交换是一种能实现资产在不同网络间进行点对点交换的智能合约,由多重签名及 HTLC 构成。原子交换具有三个特性 : 第一,交易具有原子性;第二,如果交易中出现恶意节点作恶,其他节点不会遭受损失 ; 第三,根据序贯博弈分析,理性节点无作恶动机。HTLC 是原子交换中最核心的概念,确保了原子交换过程中的去中介化。基于 HTLC 的原子交换是跨链解决方案的一种。相对于其他跨链方案,原子交换不需要通过生成新的映像资产完成跨链,交易双方的资产还是通过原有的区块链进行确认,资产的安全性不会发生本质性变化,因此不具备资产托管的金融属性。

原子交换有两种类型 : 链上原子交换 (On-chain Atomic Swap) 和链下原子交换 (Off-chain Atomic Swap)。链上原子交换顾名思义就是发生在两个不同区块链系统的交易。例如,莱特币和比特币都是基于比特币协议的区块链网络,可以进行链上原子交换。链上原子交换需要相当长时间进行交易验证,因此并不适合作为常规交易使用,较适合应用在大型且频率低的场景。链下原子交换发生在 Layer 2 ,利用链下支付通道来进行原子交换。闪电网络是其中一个例子。链下原子交换支持同构或异构的区块链系统,可以实现不同协议的加密资产转换,交易速度较快。

  • 原子交换在去中心化交易所的应用

去中心化交易所是由区块链上的智能合约构筑的交易平台。用户资金由自身钱包或去中心化的方式储存,且用户在区块链上能实现自动点对点撮合交易。在整个交易处理过程中,用户保留对私钥唯一保管权。去中心化交易所有多种实现方式,原子交换是其中一种。原子交换在去中心化交易所最核心的功用有三个 : 第一,用户可以控制自己的私钥,而非由第三方托管 ; 第二,实现实时且全额的链上结算 ; 第三,用户可以跨链进行多种加密资产交易,过程无须通过中心化机构。

Komodo 交易所是原子交换领域先驱。目前,Komodo 交易所超过 95% 的加密资产交易基于原子交换技术实现。其跨链功能兼容比特币协议网络和以太坊、ERC20 代币。

币安 DEX 与 TrustToken 合作,利用 HTLC 实现稳定币跨链交易。TrustToken 之前发行的稳定币都是 ERC20 版。在币安链主网使用 HTLC 后,这些稳定币可以实现 ERC20 和币安链 BEP2 两个标准之间的跨链转换,为用户在加密货币和银行账户之间进行资产转移提供更多选择。

原子交换在证券结算的应用
目前,证券结算采用中心化机构的「限制交付」方法实现 DvP。而在去中心化环境下,DvP 可以基于原子交换来实现。日本银行和欧州央行的 Stella 项目在第二阶段进行了类似试验,分为单链 DvP (Single-ledger DvP) 以及基于 HTLC 的跨链 DvP(Cross-ledger DvP with HTLC)。基于 HTLC 的跨链 DvP 并不依赖证券结算网络的连结,可以通过链下原子交换进行,因此较有可扩展性及可交互性,应用场景较广。

目前基于 HTLC 的跨链只是概念上的实现,具体技术实现有两个主要的风险 : 第一,当双方并未在时间锁时间内完成交易时,现金和证券会被退回买方及卖方,双方会承受流动性风险。第二,基于 HTLC 的跨链 DvP 的实现需要现金方及证券方两个哈希时间锁条件同时满足。当其中一个哈希时间锁条件(假设为现金)满足而另一个条件(假设为证券)不满足时,现金交易结算上链,证券交易退回,证券卖方会获得交易对手的现金并拿回自身的证券,造成证券买方的实质损失。因此,原子交换要成为跨资产交易和结算的金融底层结构,还需要解决许多技术上的问题。

以上是关于哈希时间锁机制的主要内容,如果未能解决你的问题,请参考以下文章

自旋锁

自旋锁

mongodb官方文档中没有专门讲锁机制的章节吗

多线程编程之自旋锁

多线程编程之自旋锁

holmMySQL锁机制