根源链技术扫盲贴 | 闪电网络导引


#1

昨天我们分享了关于隔离见证的姿势,今天我们再来普及一下有关闪电网络的知识。

闪电网络

软件层面:闪电网络(Lightning Network,LN)是一个去中心化的系统。

应用层面:LN是一个建立在根源链之上的系统,它可以让人们立即发送/接收付款,并通过让他们远离主网络(根源链)来降低交易费。

根源链与LN支付通道

技术层面:LN是基于微支付通道,巧妙地设计出了两种类型的交易合约:序列到期可撤销合约(Revocable Sequence Maturity Contract,RSMC),哈希时间锁定合约(Hashed TimeLock Contract,HTLC)。

RSMC解决了微支付通道单向的缺陷,以及通道两端任何一方耍赖的问题。

HTLC解决了RSMC无法跨节点微支付的问题。

其中RSMC与Transaction的每个Sequence字段有关。HTLC与Transaction的nLockTime字段有关。通过巧妙的利用Sequence与nLockTime构建出来的交易具备了合约的能力。

因此,技术层面上,两个类型的交易组合构成了闪电网络。

为什么要使用闪电网络

问题一

如果频繁的使用主网(根源链网络),不论大小交易,均需要根据流量大小(0.003BSTK/KB)收取交易费(Fee)。

方案:通过构建微支付通道,只有开启通道和关闭通道两次需要与根源链网络接触,其余在通道开启过程中的若干笔交易的增删改与根源链网络无关。

问题二

根源链的交易确认需要一定时间。

方案:LN的通道两端结算是瞬间的,而且LN设计的交易类型具备抵赖行为,因而通道双方去信任(双方不需要信任)

问题三

不开启隔离见证(SW)区块1MB上限,开启隔离见证区块4M WU上限,在业务频繁作用于主网的场景下,区块容量不足的压力仍旧巨大。

方案:因为开启通道和关闭通道两次需要与根源链网络接触,所以海量的微小交易不会对现有区块容量构成压力威胁。

优化

隐私的改善

方案:因为开启通道和关闭通道两次需要与根源链网络接触,所以原本每笔交易都需要上链,现在只有两笔上链,主网追溯概率降低。

微支付通道

为了引出闪电网络(LN),我们无法绕过微支付通道技术,因为这是闪电网络的基础。

场景参与者

  • 支付方Blob

  • 被支付方Alice

  • Blob需要Alice执行某工作,并支付相应酬劳。由于一次性支付总酬劳的信用风险太高,所以酬劳和工作的兑现方式采用小额多次的支付形式。

交易类型

  • Funding Transaction,Blob承诺Alice的务工总酬劳保证金合约交易

  • Refund Transaction,Blob防范Alice抵赖的合约交易

  • Commit Transaction,Alice获取务工酬劳的保障合约,亦是防范Blob抵赖的合约交易

  • Settlement Transaction,Alice获取务工酬劳的最终结算合约,属于Commit Transaction的最终版本

  • 其中,Funding Transaction和Refund Transaction的nLockTime时间需要设定最长。Commit Transaction会不断的被创建,每次被创建的交易对应的nLockTime值逐渐减少。 Settlement Transaction的nLockTime=0。这些交易被发送到根源主网后,只有Settlement Transaction直接被打包到区块,其余交易因为nLockTime时间未消逝殆尽,所以只能呆在内存池中等待。

重点步骤和要素

  • Blob建立Funding Transaction,先不发送给Alice并签名。

  • Blob建立Refund Transaction,交易输出指向Blob。Blob发送该交易给Alice,并让Alice签名,再让Alice把签好名的交易发回给Blob,Blob持有该交易作为防Alice抵赖的合约。

  • Blob再将Funding Transaction签名并发送给Alice,告知Alice对此交易签名并发送到根源链主网。双方都签名(立字为据),签了名的Funding Transaction具备质押性质的合约效力。

  • 务必先让Alice签名Refund Transaction并交回到Blob,然后双方签署Funding Transaction并发送到根源主网(微支付通道打开),避免由于Alice抵赖,Blob无法解除Funding Transaction中锁定的资产。

  • Blob建立每次酬劳发放的交易Commit Transaction,交易输入引用Funding Transaction,交易输出一方指向Blob,一方指向Alice。其中指向Alice的资产数额作为酬劳。Blob先签名该交易,并发送给Alice。Alice可以选择发送到根源主网,也可以选择不发送。如果Alice选择发送到根源主网,那么通道两方完成结算,微支付通道关闭。如果Alice选择不发送,那么务工继续。

  • 每次Blob创建的Commit Transaction都会变更几个交易字段。指向Blob的输出资产逐渐减少,指向Alice的输出资产逐渐增多,而且交易的nLockTime也在逐渐减少。值得注意的是,由于Commit Transaction创建了多次,所以Alice若将它们都发送到根源主网,那么只有最近一次的Commit Transaction会生效,其余Commit Transaction会被丢弃。其根本原因在于nLockTime值越小就会越优先被打包到区块,如果只关注nLockTime一个维度的话,nLockTime=0对应的交易最快被打包到区块。

  • 最终,Settlement Transaction实际是Commit Transaction的特例,该交易一旦被发送到根源链主网,那么通道两方完成结算,微支付通道关闭。通道关闭的同时,Funding Transaction解锁,并根据Settlement Transaction的输出指向和对应资产份额划拨到Alice和Blob的钱包地址。

以上步骤最终实现为类似于LN的根源链上层应用业务功能。最终的端用户并不会感知这些交互和数据结构的变化。

微支付通道的不足

不足1:通道的构建是单向的,如何构建双向的通道呢?
答:使用RMSC技术

不足2:如果通道两方任何一方抵赖,那么剩下的一方发送手里的防抵赖合约交易到根源链主网就能够避免损失,但是需要等待nLockTime的消逝时间窗口。如何避免等待,立即止损,并且相应的给出抵赖一方惩罚?

答:使用RMSC技术

不足3:如果通道多方连接形式为A-B-C-D,那么A需要和C或者D交易,如何跨节点支付?

答:结合RMSC与HTLC技术,也就是闪电网络(LN)

RMSC

闪电网络的基础是交易双方之间的双向微支付通道,RSMC(Recoverable Sequence Maturity Contract)定义了该双向微支付通道的最基本工作方式。

微支付通道中沉淀了一部分资金,也记录有双方对资金的分配方案。通道刚设立时,初始值可能是{Alice: 0.4, Bob: 0.6},这意味着打入通道的资金共有1.0 BSTK,其中Alice拥有0.4 BSTK,Bob拥有0.6 BSTK。通道的设立会记录在比特币区块链上。

假设稍后Bob决定向Alice支付0.1 BSTK。双方在链下对最新余额分配方案{Alice: 0.5, Bob: 0.5}进行签字认可,并签字同意作废前一版本的余额分配方案{Alice: 0.4, Bob: 0.6},Alice实际上就获得了0.5 BSTK的控制权。如图Fig 5.所示。

如果Alice暂时不需要将通道中现在属于她的0.5 BSTK用作支付,那么她可以无须及时更新区块链上记录的通道余额分配方案,因为很可能一分钟后Alice又需要反过来向Bob支付0.1 BSTK,此时他们仍然只需要在链下对新的余额分配方案达成一致,并设法作废前一版本的余额分配方案就行了。

如果Alice打算终止通道并动用她的那份资金,那么她可以向区块链出示双方签字的余额分配方案。如果一段时间之内Bob不提出异议,那么区块链会终止通道并将资金按协议转入各自预先设立的提现地址。如果Bob能在这段时间内提交证据证明Alice企图使用的是一个双方已同意作废的余额分配方案,则Alice的资金将被罚并给到Bob。

由于理论过程过于繁杂,而且本文主要目的是闪电网络相关概念的串联和导引,所以细节请参考

https://en.bitcoin.it/wiki/Lightning_Network

HTLC

RSMC只支持最简单的无条件资金支付,HTLC(Hashed Timelock Contract)则进一步实现了有条件的资金支付,通道余额的分配方式也因此变得更为复杂。

通过HTLC,Alice和Bob可以达成这样一个协议:协议将锁定Alice的0.1 BSTK,在时刻T到来之前(T以未来的某个区块链的高度来表述),如果Bob能够向Alice出示一个适当的R(称为秘密),使得R的Hash值等于事先约定的值H®,Bob就能获得这0.1 BSTK;如果直到时刻T过去Bob仍然未能提供一个正确的R,那么这0.1 BSTK将自动解冻并归还Alice。

由于到期时间T、提款条件H®、支付金额和支付方向的不同,同一个通道上可以同时存在多个活动的HTLC合约,再加上唯一的通过RSMC商定的无条件资金余额,余额分配方式会变得相当复杂。下面以图为例来讲解这一大致流程。

Alice想给Dave发送0.05 BSTK,但Alice和Dave之间并没有微支付通道。Alice找到了一条经过Bob、Carol到达Dave的支付路径,该路径由Alice/Bob、Bob/Carol和Carol/Dave这样三个微支付通道串接而成。

此时,Dave生成了一个秘密R并将Hash®发送给Alice,Alice不需要知道R。

该交易的流程具体如下。

  • Alice和Bob商定一个HTLC合约:只要Bob能在“3”天内向Alice出示Hash正确的R,Alice就会支付Bob 0.052 BSTK;如果Bob做不到,这笔钱将3天后自动退还Alice。

  • 同样地,Bob和Carol商定一个HTLC合约:只要Carol能在“2”天内向Bob出示Hash正确的R,Bob就会支付Carol 0.051 BSTK;如果Carol做不到,这笔钱到期后将自动退还Bob。

  • 最后,Carol和Dave商定一个HTLC合约:只要Dave能在“1”天内向Carol出示Hash正确的R,Carol就会支付Dave 0.05 BSTK;如果Dave做不到,这笔钱到期后将自动退还Carol。

由于理论过程过于繁杂,所以细节请参考

https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts

今天的分享到这里就结束了,如果你有什么疑问的话可以留言告诉我们哦,我们的技术小哥哥是很愿意为大家解答的。