闪电网络、雷电网络和CORDA

比特币闪电网络即将正式发布,闪电网络将带来极致的交易处理能力和近乎瞬时的交易确认,远超目前的VISA系统。以太坊上的相似项目雷电网络也预计将在几个月后发布。本文剖析了它们背后的原理和技术细节,并据此对R3 Corda 的原理做出一番揣测。html

朱立
上交所技术有限责任公司
lzhu@sse.com.cngit

 

1. 闪电网络(Lightning Network)

1.1 闪电网络概述

       比特币自诞生起一直存在若干技术问题:论处理能力,目前全网只有7笔每秒;论时延,是大体10分钟出一个块;论交易最终性,通常建议将等待6个块的确认视做交易最终化,大额交易则建议等待更多;论容量,目前已生成40多万个区块,约60GB数据量,且眼见的将来中只见增长不见减小。github

在闪电网络出现前,虽然比特币社区也试图经过区块扩容、隔离见证等技术在必定程度上增长交易处理能力,但这些方式并不能致使交易处理能力出现数量级的改善。至于前面说起的其余技术难题,现存的PoW机制是万万动不得的,须要等待多个区块的确认也是不能触碰的底线,更麻烦的是:交易处理能力和区块链数据容量彷佛是一对无可调和的矛盾。算法

思路决定出路,常规方法找不到出路,就逼得社区换一个思路考虑这个问题。代码性能调优的经验提示咱们:优化编译、改进算法、调整数据结构等方式虽然很重要也很管用,但怎么能比得上“根本不执行”的强悍?既然在比特币区块链中优化性能如此艰难,为什么不尽量将交易放到链外执行?安全

倚天一出,谁与争锋。以比特币区块链为后盾,在链下实现真正的点对点微支付交易,区块链处理能力的瓶颈被完全打破,时延、最终性、容量甚至隐私问题也迎刃而解,这就是比特币“闪电网络”(Lightning Network)的思路。由于这个缘由,社区甚至认为:“闪电网络”的论文(The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments)对比特币的重要性仅在中本聪的创世论文之下,排名第二。网络

闪电网络提供了一个可扩展的微支付通道网络。交易双方若在区块链上预先设有支付通道,就能够屡次、高频、双向地经过轧差方式实现瞬间确认的微支付;双方若无直接的点对点支付通道,只要网络中存在一条连通双方的、由多个支付通道构成的支付路径,闪电网络也能够利用这条支付路径实现资金在双方之间的可靠转移。数据结构

闪电网络并不试图解决单次支付的银货对付问题,其假设是单次支付的金额足够小,即便一方违约另外一方的损失也很是小,风险能够承受。所以使用时必须注意“微支付”这个前提。多少资金算“微”,显然应该根据业务而定。并发

1.2 闪电网络技术本质

       闪电网络的关键技术有三,后后依赖于前前,依次是:RSMC,HTLC和闪电网络。技术实现虽然复杂,但本质却很简单。ide

1.2.1 RSMC

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

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

假设稍后Bob决定向Alice支付0.1 BTC。双方在链下对最新余额分配方案{Alice:0.5, Bob:0.5} 签字承认,并签字赞成做废前一版本的余额分配方案{Alice:0.4, Bob:0.6},Alice就实际得到了0.5 BTC的控制权。

Snip20160612_90

 

表1 先后两个版本的余额分配方案

若是Alice暂时不须要将通道中如今属于她的0.5 BTC用做支付,她能够无需及时更新区块链上记录的通道余额分配方案,由于极可能一分钟后Alice又须要反过来向Bob支付0.1 BTC,此时他们仍然只需在链下对新的余额分配方案达成一致,并设法做废前一版本的余额分配方案就好了。

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

实际上,前面所说的“做废前一版本的余额分配”,正是经过构建适当的“举证”证据并结合罚没机制实现的。

为了鼓励双方尽量久地利用通道进行交易,RSMC对主动终止通道方给予了必定的惩罚:主动提出方其资金到帐将比对方晚,所以谁发起谁吃亏。这个设计虽然增长了技术复杂度,但应该说是合理的。

通道余额分配方案的本质是结算准备金。在此安排下,由于要彻底控制资金交收风险,每笔交易都不能突破当前结算准备金所施限制。

1.2.2 HTLC

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

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

因为到期时间T、提款条件H(R)、支付金额、支付方向的不一样,同一个通道上能够同时存在多个活动的HTLC合约,加上惟一的经过RSMC协议商定的无条件资金余额,余额分配方式会变得至关复杂。假设双方初始各存入0.5 BTC,一段时间后余额分配可能这样:

Snip20160612_91

表2 一段时间后的余额分配方案

余额分配方案是一种快照,只能总体刷新。接上表,若是Alice下一刻决定无条件向Bob支付0.1 BTC,或者Alice在T1前向Bob出示了符合H(R1)的秘密,双方将在链下交换并共同签字认定新的快照,而后构建适当的“举证”证据,结合罚没机制做废前一版本的快照。这些动做彻底不出如今区块链上。
引入HTLC后,任何一方仍然能经过在区块链上公开最终余额快照的方式终止通道。

1.2.3 闪电网络

       基于HTLC能够实现终极目标“闪电网络”。 Snip20160612_92

图1 闪电网络的支付路径

如上图所示,Alice想给Dave发送0.05 BTC,但Alice和Dave之间并无微支付通道。但这不要紧,Alice找到了一条通过Bob、Carol到达Dave的支付路径,该路径由Alice/Bob, Bob/Carol和Carol/Dave这样三个微支付通道串接而成。

Dave生成一个秘密R并将Hash(R)发送给Alice,Alice不须要知道R。R和Hash(R)的做用就像是古代调兵用的一对虎符。

Alice和Bob商定一个HTLC合约:只要Bob能在3天内向Alice出示哈希正确的R,Alice会支付Bob 0.052 BTC;若是Bob作不到这点,这笔钱3天后自动退还Alice。

一样地,Bob和Carol商定一个HTLC合约:只要Carol能在2天内向Bob出示哈希正确的R,Bob会支付Carol 0.051 BTC;若是Carol作不到这点,这笔钱到期自动退还Bob。

最后,Carol和Dave商定一个HTLC合约:只要Dave能在1天内向Carol出示哈希正确的R,Carol会支付Dave 0.05 BTC;若是Dave作不到这点,这笔钱到期自动退还Carol。

一切就绪后,Dave及时向Carol披露R并拿到0.05 BTC;如今Carol知道了R,她能够向Bob出示密码R并拿到0.051 BTC(差额部分的0.001 BTC成了Carol的佣金);Bob知道R后固然会向Alice出示并拿到他的那份0.052 BTC,差额部分的0.001 BTC成了Bob的佣金。 Snip20160612_93

图2 闪电网络逐级提款

整个过程很容易理解。最终效果是Alice支付了0.052 BTC,Dave安全地拿到0.05 BTC,整个闪电支付网络为此收取的佣金成本是0.002 BTC。上述过程当中的所有动做都发生在比特币区块链以外。

尽管闪电网络自己能够基于任何合适的传统技术构建,闪电网络的支付通道也可能逐渐向少数大型中介集中,变成若干大型中介彼此互联、普通用户直连大型中介的形式,但这种方案仍然具备传统中心化方案不可比拟的优点,由于用户如今并不须要信任中介,不须要在中介处存钱才能转移支付,资金安全受到比特币区块链的充分保护。

比特币闪电网络的实现方式很是复杂,不拟在此展开讲解,有兴趣的读者能够在附录一中找到详细的技术剖析。

 

2. 雷电网络(Raiden Network)

必须认可,虽然在区块链技术蓬勃发展的今天,比特币显得臃肿和老旧,但比特币社区仍然为区块链技术贡献着重要的思想。基于闪电网络的思路,以太坊社区也提出了本身的链下微支付通道解决方案:雷电网络(Raiden Network)。

Raiden项目源码托管在 https://github.com/raiden-network/raiden,开发语言Python,目前还没有完成,其实施原理则是基于“Universal Payment Channels”一文。当咱们将以太坊做为一个侧链导入其余加密货币以后,很容易依托以太坊智能合约为各种加密货币开发微支付通道。

Raiden项目的思路直接继承自比特币闪电网络,但也有所发展。由于以太坊智能合约对报文格式没有特别的字段限制,使得Raiden得觉得通道余额快照引入一个单增序号,极为轻松天然地解决了旧版本快照的识别和做废问题。
首先要在以太坊上建有一个智能合约,由此智能合约处理下文提到的OpenTransaction、UpdateTransaction等指令。 Snip20160612_94

图3 Raiden:创建交易通道

和闪电网络同样,双方须要在以太坊区块链上开设通道并各自锁定以太。这步动做可经过向Raiden智能合约发送一条双方签名承认的报文来实现。报文中的关键信息包括:双方公钥、双方锁定资产数量、双方签名。

此后的任何支付动做均可以发生在以太坊区块链外,参与双方只须要私下传递一系列报文,其中最重要的报文是UpdateTransaction,其形式以下。 Snip20160612_95

图4 Raiden:更新交易通道

此报文的内容几乎就是闪电网络的通道余额分配方案的翻版,只有几处细微的差异:

  • 一是增长了Sequence Number字段和Hold Period字段以便识别做废的报文。A若是向区块链上合约提交一个双方签字的UpdateTransaction报文,合约将等待Hold Period时间。期间若是对手方B可以提交一个Sequence Number更高的UpdateTransaction报文,合约将没收A质押在通道中的所有资产并转移给B。若是直至等待超时B也没有异议,合约将按照报文内容在区块链上完成转移支付并关闭通道。
  • 二是经过Net Transfer Amount隐含余额分配的方式和闪电网络略有不一样,这里的方式是从创建通道时申明的Amount 1中扣减Net Transfer Amount,再将之加到Amount 2上。和直接申明余额比只是形式上的差异。
  • 三是雷电中引入了较HTLC更为通用的“Smart Condition”。Smart Condition表现为一个可在区块链上执行的函数Function(argument),可接受任何格式的报文为参数,执行后返回一个[0, 1]之间的数。将其返回值乘以配套的Condition Transfer Amount,再加到Net Transfer Amount上去,就完成了条件支付引起的余额调整。闪电网络中的所谓hash lock,如今成了Smart Condition的一个特例。Smart Condition可以提供远较哈希校验丰富的功能,好比能够根据某类ORACLE提供的道琼斯指数值完成衍生品合约的自动执行。

当发生争议时,只需向区块链上智能合约出示最新版本的UpdateTransaction报文,并请求智能合约对报文中的Smart Condition予以处理,就能够强制执行合约。若是没有争议,以上这一切都不会出如今以太坊区块链上,加强了隐私,又提高了性能。

其余设计思路,如经过多跳打通微支付通道、接收方提交适当的argument做为提款凭证等都和闪电网络相似。

Vitalik Buterin最近说起的State Channel技术,本质上也和这里同样,欲将区块链做为争议仲裁及强制执行的最后手段,平时则尽力避免信息在链上公开。

3. 带给Corda的启发

       R3 CEV的首席技术官Richard Brown以前在博客中披露了Corda的主要特色:

  1. 没有多余的全局数据共享:只有有合法需求的参与方能够按照协议获取数据;
  2. Corda编写和配置在企业间流转,无中心控制者;
  3. Corda在企业间单个交易水平达成共识,而不是在系统水平上;
  4. 系统设计直接支持监管观察员节点;
  5. 交易直接由交易双方验证,而不是由一大群不相干的验证者进行;
  6. 支持多种共识机制;
  7. 记录了智能合约代码和人类语言法律文件的清晰联系;
  8. 用行业标准工具建立;
  9. 没有原始加密货币。

特征一、三、5至关值得注意。若是相关参与方只有2到3个,根据计算机科学的已知结论,他们要经过远程通讯达成拜占庭容错的共识是不可能的,这也是为什么目前的智能合约须要向足够数量的验证者公开的重要缘由。那么Corda是怎么作到这点的?

Corda固然有可能在其核心只作了特征7,也即经过类XBRL的语言制订了一种电子化的法律文件模板,而后双方对此电子签名后就结束了。但这里的“双方电子签名”就是个两军问题。若是一方拥有了双方签名的电子合同后就再也不继续,让另外一方空有一份只有一方签名的电子合同怎么办?

这些疑惑的产生都很天然,但当咱们见到闪电网络后,Corda的这些特征从何而来也许就再也不使人费解了。

4. 总结

       将交易和智能合约的执行放在链下执行,仅在必要的时候才将其在链上公开并执行,这就是闪电网络带给咱们的绝佳思路。对于合适的业务场景,这种方法能够在吞吐量、确认时延、隐私保护等方面带来质的提高。

附录一 比特币闪电网络技术剖析

1. 重要说明

       相比以太坊而言,为比特币增长特性受到的限制要多得多。对于以太坊开发者是小菜一碟的事情,放在比特币上极可能会成就一篇学术论文。闪电网络的技术本质并不难理解,但要将之付诸实践则至关复杂。

闪电网络的实施创建在若干BIP得以实施的基础上,好比隔离见证等等。随着社区开发工做的持续进行,障碍已被陆续扫清,闪电网络软件目前已接近正式发布状态。

闪电网络的原始论文很是难懂,很大一部分困难可能来自做者使用的图例的形式不够直观,且缺少明确的说明。笔者将尝试使用一套新的图例,但愿可以极大下降理解难度。

本文将详细剖析闪电网络所用交易结构,但不能彻底代替原始论文。

Snip20160612_96

图1 比特币交易图例

图1展现了一个拥有2个输入、3个输出、保存在链下的比特币交易记录,如下逐一说明其中要素。

圆角矩形表明“交易”,用不一样的底色区分交易持有者,本文一概用玫红色表示Alice,浅蓝色表示Bob。圆角矩形的边框用细实线勾勒,表示该笔交易并未公布在区块链上。

论文中每笔交易都有一个名称,虽然比特币交易结构并无这样一个字段。咱们选择将交易名称写在圆角矩形上半部,上图中“txnName”就是这个名称。

闪电网络须要在比特币交易结构中的sequence字段和locktime字段填入适当的值,将其写在圆角矩形的下半部,如上图中的“seq = 1000”。
“0.5五、0.3五、0.三、0.四、0.2”都是交易输出金额。虽然“0.55和0.35”边上的箭头表明交易输入,但交易输入必定是另外一交易的输出,因此这样表达仍然合理。

“0.三、0.四、0.2”边上的箭头表明交易输出。“#0, #1, #2”表明输出序号。

金额为0.3的交易输出旁边写有“(B)”,表示该笔交易输出需用B的私钥解锁。

金额为0.55的交易输入旁边写有“(C)”,意思同样,表示需动用C的私钥解锁对应交易输出。在“(C)”的右上方打有一钩(√),表示对应解锁条件已就绪。此钩颜色是绿色,表示此解锁脚本在交易拥有者拿到手时就已就绪。

“(A, B, H(R))”表明一个特殊的解锁条件,须要同时提供A和B的私钥签名,而且须要提供一个合适的R,令其哈希值等于预设的H(R)值,才能解锁交易输出。图中A、B右上角都打有绿色的钩,代表对应解锁条件已就绪。H(R)右上角没有任何钩,代表合适的R还没有出现。

接下来咱们为这笔交易提供正确的R值,并将就绪后的交易在区块链上公布,对应图例就变成这样: Snip20160612_97

图2 解锁R并公布在区块链上的交易

注意H(R)右上方出现了红色的钩,代表对应解锁条件变为就绪。圆角矩形框的边框变成宽实线,代表这笔交易已公布在区块链上。 Snip20160612_98

图3 互斥的交易

闪电网络容许在链下并存多个消费同一交易输出的不一样交易。若是将这些交易都发布到区块链上,显然只有其中一个交易可以生效,其余交易都由于不能双花被拒绝了。上图用一个带“X”的圆圈表达了C1a、C1b的互斥关系。

HTLC中会使用IF…ELSE…ENDIF结构的加锁脚本,就长这样子: Snip20160612_99

图4 IF…ELSE…ENDIF脚本

其中一个分支经过提供Alice二、Bob2的签名和R解锁,另外一个分支只需提供Alice一、Bob2的签名就能够解锁。为特别代表此处用到了IF结构,在图例中咱们会在表达互斥的带“X”圆圈旁边加注“if”,就像下图同样: Snip20160612_100

图5 if语句带来的互斥交易

2. RSMC剖析

2.1 通道创建

Snip20160612_101

图6 通道创建

通道创建只须要双方在链下准备一套相似上图的交易结构,完成后仅将funding交易发布到区块链上(注意粗实线的边框)。上图中的A表明Alice,B表明Bob。

虽然本例中双方都向通道注资0.5 BTC,但其实各自注入多少都是能够的,不强求相等或大于0。

之因此要彻底准备就绪这套交易结构后才能发布funding交易,是为了不先发布funding交易后一方拒绝配合完成其他交易的准备活动。因为funding交易惟一的输出要求同时使用A/B双方的私钥签字才能提取,一方拒绝配合签名将致使这部分资金永久没法支取。因此合理的顺序是先准备就绪全套交易,再发布funding交易。

上图中,交易C1a虽然为Alice持有(玫红底色),但其输入解锁脚本中B已就绪,所以这条交易记录其实是Bob准备好后给到Alice的,由于除了Bob没人可以作到这一点。C1b的输入解锁脚本中A也已就绪,说明交易记录C1b是Alice准备好后给到Bob的。

图中,交易RD1a和RD1b上都标注了“seq=1000”,这是比特币交易结构的一个最新特性,sequence字段如此设置后,交易RD1a只能在包含其父交易C1a的区块获得1000个确认后才能被收录。

2.2 单方面终止通道

       通道创建后,Alice或Bob随时能够选择单方面终止通道并取回资金,发起方将受到延迟提款的惩罚。 Snip20160612_102

图7 Alice单方面终止通道

Alice单方面终止通道的方式以下:Alice为C1a和RD1a的输入解锁脚本用本身的私钥签名,并在区块链上发布交易C1a。因为RD1a的seq = 1000,他必须等待C1a被收录并获得1000个确认后才能发布交易RD1a,所以他须要等上10,000分钟(约7天)才能经过RD1a取回本身的款。对Bob来讲,他只须要在区块链上看到C1a发布,随时能够用本身的私钥动用C1a的0号输出的资金。最终双方都获得0.5 BTC,funding交易的输出被提取一空,通道终止。

图中用粗黑有向线条表达了区块链上实际的资金流向。

2.3 微支付及旧版本废止

       在双方各占0.5 BTC的基础上,Alice向Bob支付0.1 BTC,双方余额应该调整为Alice 0.4 BTC,Bob 0.6 BTC。

为此须要建立余额的新版本,而后废止余额的旧版本。因为比特币的交易由一个个离散的utxo构成,也没有多余的字段存放“版本号”,因此是迂回地经过经济手段来达到实际废止的效果。 Snip20160612_103

图8 微支付:建立新版本余额

建立余额的新版本很简单,双方彻底不动区块链上的funding交易,在链下按上图另外建立一套反映新余额的交易。很清楚,如今Alice实际控制0.4 BTC而Bob实际控制0.6 BTC,等价于Alice支付Bob 0.1 BTC。注意为便于区分,交易名称都改变了。

做废旧版本的余额很是有技巧,方法是在旧版本交易的基础上增长几个做恶惩戒交易,效果上相似发誓:“我要是拿这个旧版本去区块链上提款,你就把个人那份拿走!”,只不过这个誓言是决定能够生效的。 Snip20160612_104

图9 微支付:做废旧版本余额

C1a, C1b, RD1a, RD1b都是旧版本余额用到的交易。做废这堆交易的方式是构造一对新的交易BR1a和BR1b,并准备就绪其输入解锁脚本所需所有签名。上图中,红色虚线框中的两笔交易是在原来基础上新增构建的。 Snip20160612_105

图10 微支付:惩罚措施

在图9的基础上,若是Alice但愿经过在区块链上经过发布旧版本余额对应的交易来逆转刚才支付给Bob的0.1 BTC,她将受到惩罚,原理见上图。

Alice为C1a的输入解锁脚本补上本身的签名,发布到区块链上。由于交易RD1a有seq=1000的属性设定,因此Alice暂时还不能发布RD1a。但Bob将看到承诺做废的C1a被放出,为保护自身利益,Bob能够马上在区块链上发布交易BR1a,由于BR1a的父交易已被放出,且BR1a的输入解锁脚本早已就绪,因此BR1a能够立刻生效,因而Bob一共能够拿走1.0 BTC,企图做恶的Alice偷鸡不成。

正常状况下,Alice只要不在区块链上发布C1a,虽然Bob拥有输入解锁脚本彻底就绪的BR1a,由于其父交易C1a并未发布,Bob也没法发布BR1a。这说明只要一方安分守己,就无需担忧惩罚措施。

3. HTLC剖析

3.1 初始化HTLC

Snip20160612_106

图11 HTLC的初始化

图11给出的是一个简单的HTLC示例,其所反映的通道余额划分是:有0.9 BTC以无条件余额划分的形式在Alice和Bob之间分割,Alice占0.4 BTC,Bob占0.5 BTC。Alice向Bob有条件支付0.1 BTC,若是Bob能于3天内(实际是以区块链高度表明的将来某时)以前提供合适的R,Bob就能获得这笔钱,反之这笔钱仍然回到Alice帐上。

这里的“> 3 days”是利用locktime字段的最新扩展实现的。和“seq=1000”的区别在于:locktime指定的是一个高度绝对值,而sequence指定的是相对父交易所在区块高度的相对值。

因为要在一个通道上同时反映无条件余额划分和有条件支付,因此交易结构变得至关复杂。图10中,C2a, RD2a, D2a, C2b, RD2b, D2b经过RSMC实现无条件余额划分,最下方的6笔交易专门用于HTLC支付。

3.2 条件支付的两种结果

Snip20160612_107

图12 HTLC:Bob及时提交R

若是Bob可以在3天内及时提交R,他能够如图11所示,准备好一系列交易的输入解锁脚本(注意图中红色的“√”)后将C2b、RD2b、HE1b及HERD1b交易发布到区块链上,拿走0.5+0.1 BTC。Alice此时只能跟着发布交易D2b拿走本身的0.4 BTC,通道终止。
也能够不终止通道,关键在于只要Bob离线告知Alice他拥有适当的R,且双方愿意达成新版本的余额划分,那么只须要新建一个Alice 0.4 BTC、Bob 0.6 BTC的新版本余额并废止旧版本,效果上就等于这0.1 BTC的条件支付已经达成。 Snip20160612_108

图13 HTLC: 超时退款

若是直到超时Bob仍不能提供正确的R值,Alice能够如图12所示,经过用本身的私钥准备各交易的输入解锁脚本并发布交易到区块链上,最终取回这0.1 BTC(注意图中红色的“√”),。在此方式下,最终Alice拿到0.5 BTC,Bob拿到0.5 BTC。和图11彻底相似,也能够采用新建版本余额的方式,无需终止通道。

2.3 做废旧版本与违约惩罚

       创建新版本余额快照后,就应该做废旧版本。和以前做废旧版本的思路相似,在通道中还包含HTLC合约的状况下,依然靠新增若干做恶惩戒交易的方式做废旧版本。 Snip20160612_109

图14 做废旧版本余额

图14中用红色虚线框出的部分就是新增的“做恶惩戒交易”。 Snip20160612_110

图15 惩戒交易示意

在图15中,假设HT1a交易已经超时,但以C2a为根的所有交易都已经过惩戒交易予以做废。若是此时Alice想做恶,她将C2a、RD2a、HT1a及HTRD1a的输入解锁脚本用本身的私钥准备就绪后(注意图中红“√”),将交易C2a和交易HT1a在区块链上公开。因为seq字段的限制,她不能马上公开交易RD2a和HTRD1a,这样就使得Bob有机会发现Alice企图做恶并可以经过公布BR2a和HTBR1a交易的方式予以惩戒。发出这对交易后,通道中的所有资金将都归Bob全部。

图15中虽然没有用上惩戒交易HBR1a,但该交易并很少余。理由是:若是Alice在区块链上公布了交易C2a但故意不公布交易HT1a,假若Bob手头没有HBR1a,也不知道秘密R,Bob将没法得到这0.1 BTC。有了惩戒交易HBR1a以后,即便Alice不公布交易HT1a,只要C2a公布,Bob也能够经过HBR1a顺利提取这0.1 BTC。

只提供HBR1a、不提供HTBR1a也是不行的。由于万一Alice选择的是解锁并公布交易HT1a,而且抢在Bob以前消费了C2a的#2输出,Bob拥有的HBR1a交易就没法生效了,而此时虽然HTRD1a交易要等上1000个确认才能公布,Bob也没有任何手段来利用这1000个块的确认时间来阻止Alice提取这0.1 BTC。