第16课 闪电网络(Lightning Network) 之 HTLC

有兴趣朋友也可以进一步关注公众号“架构之道与术”， 获取原文。
或扫描如下二维码：

在第14课 闪电网络(Lightning Network) 之 RSMC 中，我们知道了RSMC实现了买家和卖家之间的双向支付通道。

但这还不够方便，任何时候2个人之间要交易，就得建立支付通道。 有没有更便捷的办法，在买卖双方不建立通道的情况下，也可以实现交易？

闪电网络的基本思路
如下图所示，Alice和Eric之前想进行交易，但没有支付通道。

Alice和Bob之间，Bob和Carol之间、Carol和Diana之间、Diana和Eric之间，已经有了支付通道，那把这些通道串联起来，就相当于建立了Alice和Eric之间的支付通道。

这个过程怎么达成呢？
如下图所示，假设Alice需要付给Eric 1个比特币：

首先，由最终的收款方Eric构建了1个秘钥R和对应的Hash值H，然后他把H给了Alice。

Alice呢，就和Bob之间达成了一个合约：Alice对Bob说，如果你在4天内，可以给我H对应的密钥R，我就给你1.003比特币，超过4天，我就拿回这钱；

在这打个比方，Alice就好像搞了个“谜题悬赏”：Alice抛了一个问题，然后悬赏，谁能给出这个问题的答案，就支付给他1.003比特币。这里的问题，就是H；答案，就是密钥R。

很显然，密钥只有Eric有，Bob没有。那Bob怎么办呢？
Bob和Carol达成1个合约：Bob对Carol说，如果你在3天内，可以给我H对应的密钥R，我就给你1.002比特币，超出3天，我就拿回这钱；

同理，Carol也没公钥，
Carol和Diana达成1个合约：Carol对Diana说，如果你在2天内，可以给我H对应的密钥R，我就给你1.001比特币，超过2天，我就拿回这钱；

同理，Diana也没公钥，
Diana和Eric达成1个合约：Diana对Eric说，如果你在1天内，可以给我H对应密钥R，我就给你1个比特币，超过1天，我就拿回这钱。

所以整个的交易顺序是：Eric把R给了Diana，拿到1.0比特币； Diana把密钥给Carol，拿到1.1比特币；。。。密钥一直传递，最终到Alice那。

最终结果就是：Alice付出了1.3个比特币，Eric收到1.0个比特币，每个中间方，收到0.1个比特币的手续费。

HTLC脚本分析
上面的交易过程中，核心就是“一方用密钥R向另1方换钱，超过时间没有换，钱自动回到打款人的账号”，这个过程就是所谓的HTLC（Hashed Time Lock Contract），通过这几个英文单词，就大概知道其意思。Hashed，就是上面说的Hash值，也就是密钥R； Time Lock，就是这个交易有个时间锁，也就是我们前面所讲的nLockTime。

HTLC的脚本长下面这个样子：
假设buyer要给seller付钱，seller提供了密钥R，就会执行OP_IF后面的statement，seller收到钱；
seller提供不出密钥R，就会执行OP_ELSE后面的statement，钱会返回到buyer的账号。

OP_IF
    [HASHOP]  OP_EQUALVERIFY OP_DUP OP_HASH160             
OP_ELSE
     [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

下面详细分析一下这个脚本的执行过程：

对比上节课所讲的Script Language，这个脚本在OP_IF前面，显然缺了condition，没有condition，怎么执行分支语句呢？

这就涉及到了这里的关键点：这个script，对应在交易里面，也就是scriptPubKey的部分（output里面），交易类型是P2SH（Script Hash）。 下1笔交易要花这个钱，需要scriptSig，也就是私钥签名。
那串私钥签名（也就是上面说的密钥R），拼接在这里的OP_IF前面，也就是condition。

让我们再回到上1节课，仔细看一下OP_IF, OP_ELSE的详细语义：

//OP_IF，表示栈顶元素不为0，就执行接下来的statement。
具体到我们上面的HTLC脚本，栈顶元素是密钥R（也就是condition），肯定不为0，所以就会把statement也入栈。密钥R在下面，OP_IF后面的statement在上面，拼接在一起，进行估值。

//OP_ELSE 当OP_IF后面的stament不执行时，就执行OP_ELSE后面的statement。

所以，知道了OP_IF/OP_ELSE的语义，同时在这个脚本签名拼接上密钥R，我们也就基本知道了这个脚本的执行过程。

借用RSMC通道
在第14课 闪电网络(Lightning Network) 之 RSMC里面，我们知道RSMC建立了Alice和Bob之间的一个双向通道。

对于HTLC呢，会借用这个通道，通俗点，“加塞”。在通常的RSMC交易通道里面，塞进1个HTLC的合约。这样才能达到上面所说的，复用现有的双向支付通道，而不建立新的通道。

具体怎么复用呢，如下图所示：
本来呢，Alice和Bob各有0.5比特币在这个通道里面，现在Alice和Bob建了一个HTLC（Alice向Bob支付0.1元，只要Bob能提供密钥R）

也就是图中红线圈起来的部分，在这个Transaction里面，新加了1个output，也就是HTLC（本来RSMC里面，只有2个output，现在加塞进了1个）

Bob想兑现这0.1比特币呢，就以这个output2为输入，构建左边分支的Delivery Transaction（里面包含了密钥R）；
Alice想拿回这0.1比特币，同样以output2为输入，构建右边分支的Timeout Transaction（时间到了之后，钱就回到Alice账号）。

套上了RSMC的HTLC
在上面，我们说了，HTLC这个合约是作为一个output，加塞在Commitment Transaction里面的，但这有一个问题：

假设这个HTLC的锁定期是3天，超过3天之后，旧的Commitment在网络上出现了，那上图中的左右2个分支，都可能被执行！！！

也就是说，如何保证在Commitment Transaction 3达成之后，因为某种原因，Transaction 2被广播出去了，导致2里面的HTLC被双方同时执行？

答案：为HTLC套上RSMC
也就是下图中的output2（是一个HTLC），也类似RSMC，生成了HED1a和HT1a，用于达成下面的目的：Bob能提供key就拿到0.1元，3天后，Alice拿回这0.1元。

如何在通道不关闭的情况下，结束HTLC

正如上面所讲的，HTLC是加塞在Commitment Transaction里的。但是Commitment Transaction并不会被广播。

那如何可以在不广播Commitment Transaction的情况下，让HTLC的合约得以履行？换句话说，如何在RSMC通道不关闭的情况下，双方完成HTLC交易，让Alice得以成功的把这0.1元，转给Bob?

想想在RSMC里面：我们是如何保证双方在达成Commitment Transaction 3之后，双方都没有人反悔，把Commit 2广播出去的呢？？

答案：为Commitment Transaction2 也生成“把柄Transaction”（也就是BR2a, BR2b），各自攒在对方手上，谁广播，惩罚谁！！！

同样的，借鉴这个思路：我们也需要为HTLC加上“把柄Transaction”，使得1方不能反悔！！

如下图所示，是Commitment Transaction 2 对应的HTLC的处罚交易HBR1a与HTBR1a，如果在Commitment Transaction 3达成之后，有谁广播了Commitment Transaction 2，那么就处罚谁。

总结
HTLC本身的想法并不复杂，但要使用它，需要和RSMC紧密结合，才能形成一个完善的、具有多个中间节点的支付通道。

本文只是粗略分析了HTLC的几个关键点，关于HTLC和RSMC如何结合的详细协议，还是要参考“闪电网络的白皮书”，这个网络上都有，读者可以自行下载。

相关链接：
《第15课 闪电网络之 Script Language与Script Engine》
《第14课 闪电网络(Lightning Network) 之 RSMC》