原文来源:BitcoinMagazine 原文作者:AARONVANWIRDUM 原文编译:闵敏&阿剑
在上一篇文章中,Alice和Bob建立了一个双向的支付通道。现在,Alice想要给一个第三方Carol支付1btc。
一般来说,Alice和Carol需要在彼此之间开设一个支付通道。但实际上并不需要。因为Bob和Carol之间已经有了一个通道,所以Alice可以通过Bob给Carol支付。
具体来说,Alice可以给Bob支付1btc,而Bob再支付1btc给Carol。
但是,Alice实际上并不信任Bob,或者Carol并不信任Bob。她担心把钱给Bob之后,Bob不会给Carol;又或者,他把钱给了Carol,但Carol谎称自己压根没见到钱,而Alice也不知道该找哪个来追责。
因此,Alice希望能保证,仅当Bob给了Carol1btc,自己才需要给Bob支付1btc。
当Alice要给Carol支付1btc时,她让Carol先生成一个秘密值(一个随机的数字串)并把对应的哈希值发给她。Alice也告诉Carol可以用这个秘密值跟Bob交换1btc。
与此同时,Alice把从Carol处得到的哈希值发给Bob,并告诉Bob如果Bob能提供对应于这个哈希值的原始值,她就会给Bob1btc(这个原始值当然只有Carol拥有)。
所以Bob找到Carol,用1btc换来了Carol的初始值。
然后,Bob找回Alice,提供这个初始值。Alice因此知道了Bob一定给过钱了,也就是Carol肯定已经收到了1btc,于是就把钱给了Bob。
皆大欢喜。
几乎,啊,几乎是皆大欢喜。
在这种「过家家」的情形下,中间人Bob还是需要新人Alice和Carol。Bob必须相信Carol给他的是一个真正有用的值(不然钱都给了就拿不回来了),而且要相信Alice真的会给他1btc,假如他能提供对应于哈希值的原像的话。
这时候,我们就需要哈希时间锁合约(HTLC)啦。
哈希时间锁合约
哈希时间锁可以让Alice和Bob用秘密值来交换btc(当然Bob和Carol也需要这个,但我们先按下不提)。
为了使用哈希时间锁,Alice要将1btc发送至一个新的多签地址,而非直接发送给Bob。这个地址中锁定的btc可以通过两种方式解锁。
第一种方式是Bob将自己的签名和秘密值一起发送至该地址。
第二种方式是Alice将自己的签名发送至该地址。但是,这个方式存在CLTV时间锁限制:Alice必须等待一段时间(例如两周)才能签署并广播交易取走这个btc。
也就是说,Bob有两周时间来创建一个包含签名和秘密值的交易,并广播该交易,将多签地址上的btc发送给自己。这样一来,这笔交易就有了保证。只要Bob能提供秘密值,他就能取走Alice的btc:在比特币网络公开广播该交易可以让Alice看到它。
如果Bob没有在规定时限内提供秘密值,Alice就可以取回她的btc。就这么简单。
再说回网络,因为这是哈希时间锁合约真正发挥作用的地方。
如上文所述,不仅Alice和Bob之间有哈希时间锁合约,Bob和Carol之间也有。因此,如果Carol向Bob索要btc,Bob也可以从Carol那里取得秘密值。这些在区块链上都是可见的。
因此,如果发生这种情况,Bob也一定可以从Alice那里拿到1btc。Bob可以将从Carol那里拿到的秘密值在链上公开,发送至他与Alice的哈希时间锁合约,然后取走多签地址上的1btc。这两个状态通道有效地关联了起来。
最后要强调的一点是,Bob必须在有效期内从Carol那里拿到秘密值,否则Alice就有可能取回多签地址上的1btc。如果等Alice取回1btc之后Bob才从Carol那里拿到了秘密值,Bob就会被卡在中间进退两难。因此,Bob和Carol的哈希时间锁合约必须比Alice和Bob的先到期(例如,前者的时限可以设成10天,而非两周)。这就是为什么哈希时间锁合约需要CheckLockTimeVerify(绝对时间锁)而非CheckSequenceVerify(相对时间锁)。
最后还有一个问题需要解决:要保证闪电网络的可用性,所有这些必须在链下完成。具体是如何实现的将在本系列第三篇文章中揭晓。
来源:以太坊爱好者