作者：朱立@上交所技术有限责任公司，lzhu@sse.com.cn
原文：http://istock.stocom.net/wiki/tradetech:blockchain:corda

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

1. 闪电网络（Lightning Network）

1.1 闪电网络概述

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

在闪电网络出现前，虽然比特币社区也试图通过区块扩容、隔离见证等技术在一定程度上增加交易处理能力，但这些方式并不能导致交易处理能力出现数量级的改善。至于前面提及的其他技术难题，现存的PoW机制是万万动不得的，需要等待多个区块的确认也是不能触碰的底线，更麻烦的是：交易处理能力和区块链数据容量似乎是一对无可调和的矛盾。

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

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

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

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

1.2 闪电网络技术本质

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

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的控制权。

| 类型 | 冻结 | Alice | Bob
--|--|--|--|--|
分配前 | 无条件 | 1.0 | 0.4 | 0.6
分配后 | 无条件 | 1.0 | 0.5 | 0.5

表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，一段时间后余额分配可能这样：

类型 | 冻结 | Alice | Bob | 附注
--|--|--|--|
无条件 | 0.5 | 0.3 | 0.2 |
有条件（HTLC）| 0.1 | 如果Alice 在T1前能向Bob出示符合H(R1)的值：0.1，否则：0.0 | 如果Alice在T1前能向Bob出示符合H(R1)的值：0.0，否则: 0.1 | 0.1 BTC
有条件（HTLC） | 0.2 | 如果Bob在T2前能向 Alice出示符合H(R2)的值：0.0，否则：0.2 | 如果Bob在T2前能向Alice出示符合H(R2)的值：0.2，否则：0.0 | Alice→Bob 0.2 BTC
有条件（HTLC） | 0.2 | 如果Alice 在T3前能向 Bob出示符合H(R3)的值：0.2，否则：0.0 | 如果Alice在T3前能向Bob出示符合H(R3)的值: 0.0，否则: 0.2 | Bob→Alice 0.2 BTC

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

余额分配方案是一种快照，只能整体刷新。接上表，如果Alice下一刻决定无条件向Bob支付0.1 BTC，或者Alice在T1前向Bob出示了符合H(R1)的秘密，双方将在链下交换并共同签字认定新的快照，然后构建适当的“举证”证据，结合罚没机制作废前一版本的快照。这些动作完全不出现在区块链上。

引入HTLC后，任何一方仍然能通过在区块链上公开最终余额快照的方式终止通道。

1.2.3 闪电网络

基于HTLC可以实现终极目标“闪电网络”。

图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构成，也没有多余的字段存放“版本号”，所以是迂回地通过经济手段来达到实际废止的效果。

图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 条件支付的两种结果

图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的条件支付已经达成。

图13 HTLC: 超时退款

如果直到超时Bob仍不能提供正确的R值，Alice可以如图12所示，通过用自己的私钥准备各交易的输入解锁脚本并发布交易到区块链上，最终取回这0.1 BTC（注意图中红色的“√”），。在此方式下，最终Alice拿到0.5 BTC，Bob拿到0.5 BTC。和图11完全类似，也可以采用新建版本余额的方式，无需终止通道。

2.3 作废旧版本与违约惩罚

建立新版本余额快照后，就应该作废旧版本。和之前作废旧版本的思路类似，在通道中还包含HTLC合约的情况下，依然靠新增若干作恶惩戒交易的方式作废旧版本。

图14 作废旧版本余额

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

图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。