蓑衣网详解最近大热的闪电网络、雷电网络和CORDA
比特币闪电网即将正式发布。闪电网络将带来极致的交易处理能力和近乎即时的交易确认，远超目前的VISA系统。以太坊上的一个类似项目，闪电网络，也有望在几个月后发布。本文对其背后的原理和技术细节进行了分析，并据此推测了R3 Corda的原理。
朱丽SSE科技有限公司lzhu@sse.com.cn
1。闪电网
1.1闪电网概述
？比特币自诞生以来，一直存在一些技术问题：在处理能力上，目前全网只有每秒7笔；论延时，大概是10分钟产生一个块；关于交易的终结性，一般建议等待六块确认视为交易终结，而对于大额交易建议等待更多；容量方面，目前已经产生了40多万块，约60GB的数据，未来只增不减。
在闪电网出现之前，虽然比特币社区也试图通过分块扩展、隔离见证等技术在一定程度上提高交易处理能力，但这些方法并不能带来交易处理能力的数量级提升。至于上面提到的其他技术问题，现有的PoW机制是绝对不能动的，等待多块的确认也是不能碰的底线。更麻烦的是，交易处理能力和区块链数据能力似乎是一个不可调和的矛盾。
思路决定出路。如果常规方法找不到出路，就迫使社区用另一种方式思考这个问题。代码性能调优的经历提醒我们：优化编译、改进算法、调整数据结构虽然很重要，也很有用，但怎么可能强大到“根本不执行”呢？既然在比特币区块链中优化性能如此困难，为什么不尽可能地将交易排除在外呢？
天出来，谁跟你比？背靠比特币区块链，链下可实现真正的点对点小额支付交易，彻底打破了区块链处理能力的瓶颈，解决了时延、终局性、容量甚至隐私等问题。这就是比特币的“闪电网”的想法。正因如此，社区甚至认为《比特币闪电网络：可扩展的链外即时支付》这篇论文仅次于中本聪的创世论文。
闪电网提供可扩展的微支付通道网络。如果交易双方事先在区块链有支付通道，可以多次、高频、双向实现差额滚动方式即时确认的小额支付；如果双方之间没有直接的点对点支付通道，只要网络中有连接双方的、由多个支付通道组成的支付路径，闪电网络也可以利用该支付路径实现双方资金的可靠转移。
闪电网不尝试解决单笔支付中的银货处理问题。它的假设是单笔支付的金额足够小，即使一方违约，另一方的损失也很小，风险可以承担。所以在使用时一定要注意“微支付”的前提。多少钱算“微”，显然要看商家。
1.2闪电网的技术本质
？雷电网的关键技术有三个，后面靠前面，依次是RSMC、HTLC和雷电网。技术虽然复杂，本质却很简单。RSMC
？闪电网的基础是交易双方之间的双向微支付通道，RSMC(可恢复序列到期合约)定义了双向微支付通道最基本的工作模式。
部分资金存放在微支付通道，通道还记录了双方资金的分配方案。通道刚建立的时候，初始值可能是{爱丽丝：0.4，鲍勃：0.6}，也就是说进入通道的资金是1.0 BTC，其中爱丽丝拥有0.4 BTC，鲍勃拥有0.6 BTC。该通道的建立将被记录在比特币区块链上。
假设
表1中两个版本的余额分配方案
如果爱丽丝暂时不需要在渠道中使用属于她的0.5 BTC进行支付，她可能不需要及时更新区块链上记录的渠道余额分配方案，因为很可能一分钟后爱丽丝就需要依次向鲍勃再支付0.1 BTC。此时，他们仍然只需要在链下商定一个新的余额分配方案，并尝试使之前的方案无效。
如果爱丽丝打算终止渠道，动用自己的资金份额，可以向区块链出示双方签署的余额分配方案。如果鲍勃在一段时间内没有提出异议，区块链将终止该通道，并根据协议将资金转移到他们预先设定的取款地址。如果Bob能在这段时间内提交证据，证明Alice试图使用双方都同意废除的余额分配方案，Alice的资金将被没收，交给Bob。
实际上，前面提到的“废止上一版本的余额分配”是通过构建适当的“证明”证据并结合没收机制来实现的。
为了鼓励双方尽可能长时间的利用通道进行交易，RSMC对主动终止通道的一方给予了一定的惩罚：主动提出的一方的钱会比另一方晚到，所以谁发起谁吃亏。这种设计虽然增加了技术复杂度，但应该说是合理的。
渠道余额分配方案的本质是结算准备金。在这种安排下，蓑衣网小编2022为了完全控制资金结算风险，每笔交易都不能突破现行结算准备金的限制。HTLC
？RSMC只支持最简单的无条件资金支付，HTLC(Hashed Timelock Contract)进一步实现了有条件的资金支付，使得渠道余额的分配更加复杂。
通过HTLC，爱丽丝和鲍勃可以达成这样一个协议：协议将锁定爱丽丝的0.1 BTC，在时间T (T用某个未来的区块链高度表示)到来之前，如果鲍勃可以向爱丽丝展示一个合适的R(称为秘密)使得R的哈希值等于预先约定的值H(R)，鲍勃就可以得到这个0.1的BTC；如果直到时间T过去，鲍勃仍然不能提供正确的R，0.1 BTC将被自动解冻并返回给爱丽丝。
由于到期时间T、提款条件H(R)、支付金额、支付方向的不同，同一渠道可以同时存在多个活跃的HTLC合约。再加上通过RSMC协议约定的唯一无条件资金余额，余额分配方法将变得相当复杂。假设双方初始存入0.5 BTC，一段蓑衣网小编2022时间后的余额分配可能如下：
表2一段时间后的余额分配方案余额分配方案是快照，只能整体刷新。接上表，如果爱丽丝决定在下一刻无条件支付鲍勃0.1 BTC，或者爱丽丝在T1之前向鲍勃展示一个符合H(R1)的秘密，双方将在链下交换并共同签署新的快照，然后构造适当的“证明”证据，并结合没收机制使之前版本的快照无效。这些动作根本不会出现在区块链上。引入HTLC后，任何一方仍然可以通过在区块链上发布最终余额的快照来终止频道。
1.2.3闪电网
？最终目标“闪电网络”可以在HTLC的基础上实现。
图1闪电网的支付路径
如上图所示，爱丽丝想给戴夫汇0.05 BTC，但是爱丽丝和戴夫之间没有微支付通道。不过没关系。爱丽丝通过鲍勃和卡罗尔找到了一条支付给戴夫的路径，这条路径由爱丽丝/鲍勃、鲍勃/卡罗尔和卡罗尔/戴夫微支付通道串联而成。
Dave生成一个秘密R并将散列(R)发送给Alice。爱丽丝不需要知道R，r Hash(R)的作用就像古代用来转移士兵的一对虎符。
爱丽丝和鲍勃约定了一份HTLC合同：爱丽丝将付给鲍勃0.052 BTC；只要鲍勃能在3天内给爱丽丝看正确的R；如果鲍勃做不到这一点，这笔钱将在3天后自动退还给爱丽丝。
同样，鲍勃和卡罗尔达成一项HTLC合同：鲍勃将付给卡罗尔0.051 BTC；只要Carol能在2天内给Bob看正确的R；如果卡罗尔做不到这一点，这笔钱将在到期时自动退还给鲍勃。
最后，卡罗尔和戴夫商定了一份HTLC合同：卡罗尔将付给戴夫0.05 BTC；只要戴夫能在一天之内给卡罗尔看正确的散列；如果戴夫做不到这一点，这笔钱到期时会自动退还给卡罗尔。
一切准备就绪后，戴夫及时向卡萝尔披露R，得到0.05 BTC；现在卡罗尔知道了R，她可以给鲍勃看密码R，得到0.051 BTC(0.001 BTC的差额就成了卡罗尔的佣金)；认识鲍勃R，当然会给爱丽丝看，得到他那份0.052 BTC，0.001 BTC的差价就成了鲍勃的提成。
图2闪电网一步步取钱的全过程
很好理解。最终爱丽丝支付了0.052 BTC，戴夫安全得到0.05 BTC，整个闪电支付网收取的佣金成本为0.002 BTC。上述过程中的所有操作都发生在比特币区块链之外。
虽然闪电网本身可以基于任何合适的传统技术来构建，但闪电网的支付渠道也可能逐渐向少数几家大型中介集中，成为几家大型中介相互互联，普通用户直接连接大型中介的形式。但这种方案仍然具有传统集中式方案无法比拟的优势，因为用户现在不需要信任中介机构，也不需要在中介机构存钱进行转账支付。资金安全受到比特币区块链的全面保护。
比特币闪电网的实现非常复杂，这里不打算解释。感兴趣的读者可以在附录一.
2中找到详细的技术分析。迅雷网
必须承认，尽管比特币在如今蓬勃发展的区块链科技中显得臃肿而陈旧，但比特币社区仍然为区块链科技贡献了重要的思想。基于闪电网的思路，以太坊社区也提出了自己的链下小额支付渠道解决方案：闪电网。
雷电项目源代码托管在？https://github.com/raiden-network/raiden,的开发语言Python，还没有完成，其实现原理是基于“通用支付渠道”一文。当我们以邰方为侧链进口其他加密货币时，依托邰方的智能合约，很容易开发出各种加密货币的微支付通道。
雷电计划的思想直接继承自比特币闪电网，但也有所发展。由于以太坊智能合约对消息格式没有特殊的字段限制，因此Raiden可以为通道平衡快照引入单增量序列号，非常轻松自然地解决了旧版本快照的识别和失效问题。首先要在以太坊上建立一个智能合约，让智能合约可以处理下面提到的OpenTransaction、UpdateTransaction等指令。
图3雷电：建立交易通道
就像雷电网一样，双方都需要在以太坊区块链上打开通道，并分别锁定以太坊。这一步可以通过向雷电智能合约发送双方签字认可的消息来实现。消息中的关键信息包括：双方的公钥、双方锁定的资产数量、双方的签名。
任何后续的支付行为都可以在以太坊区块链之外发生，参与的双方只需要私下传递一系列消息，其中最重要的是UpdateTransaction，形式如下。
图4雷电：更新交易渠道
此消息内容几乎是雷电网渠道余额分配方案的翻版，仅有少许细微差别：
当存在争议时，只有通过向区块链上的智能合约显示最新版本的UpdateTransaction消息，并请求智能合约处理消息中的智能条件，才能执行合约。如果没有争议，以上都不会出现在以太坊区块链上，增强了私密性，提高了性能。
其他设计思路，如通过多跳开通微支付通道，接收方提交适当的自变量作为取款凭证，与闪电网类似。
Vitalik Buterin最近提到了国家通道技术，本质上和这里是一样的。它希望将区块链作为争端仲裁和执行的最后手段，通常会尽力避免链上的信息披露。
3。Corda
的灵感？R3 CEV首席技术官理查德布朗(Richard Brown)此前在博客中披露了Corda的主要特点：
没有冗余的全球数据共享：只有有正当需求的参与者才能根据协议获取数据；Corda被编写和配置为在没有中央控制的企业之间流通；Corda在企业间单个交易层面达成共识，而不是在系统层面；系统设计直接支持监督观察节点；交易由双方直接验证，而不是由一大群不相关的验证者验证；支持多重共识机制；记录了智能合同代码与人类语言法律文件之间的清晰联系；使用行业标准工具创建；没有原始的加密货币。功能1、3、5相当值得注意。如果只有两到三个参与方，根据计算机科学的已知结论，他们不可能通过远距离通信达成拜占庭式的容错共识，这也是当前智能合同需要向足够数量的验证者公开的重要原因。那么科达是如何做到这一点的呢？
当然有可能Corda只在核心里做了feature 7。，也即通过类XBRL的语言制订了一种电子化的法律文件模板，然后双方对此电子签名后就结束了。但这里的“双方电子签名”就是个两军问题。如果一方拥有了双方签名的电子合同后就不再继续，让另一方空有一份只有一方签名的电子合同怎么办？
这些疑惑的产生都很自然，但当我们见到闪电网络后，Corda的这些特征从何而来也许就不再令人费解了。
4. 总结
???????将交易和智能合约的执行放在链下执行，仅在必要的时候才将其在链上公开并执行，这就是闪电网络带给我们的绝佳思路。对于合适的业务场景，这种方法可以在吞吐量、确认时延、隐私保护等方面带来质的提升。
附录一 比特币闪电网络技术剖析1. 重要说明
???????相比以太坊而言，为比特币增加特性受到的限制要多得多。对于以太坊开发者是小菜一碟的事情，放在比特币上很可能会成就一篇学术论文。闪电网络的技术本质并不难理解，但要将之付诸实践则相当复杂。
闪电网络的实施建立在若干BIP得以实施的基础上，比如隔离见证等等。随着社区开发工作的持续进行，障碍已被陆续扫清，闪电网络软件目前已接近正式发布状态。
闪电网络的原始论文非常难懂，很大一部分困难可能来自作者使用的图例的形式不够直观，且缺乏明确的说明。笔者将尝试使用一套新的图例，希望能够极大降低理解难度。
本文将详细剖析闪电网络所用交易结构，但不能完全代替原始论文。
图1 比特币交易图例
图1展示了一个拥有2个输入、3个输出、保存在链下的比特币交易记录，以下逐一说明其中要素。
圆角矩形代表“交易”，用不同的底色区分交易持有者，本文一律用玫红色表示Alice，浅蓝色表示Bob。圆角矩形的边框用细实线勾勒，表示该笔交易并未公布在区块链上。
论文中每笔交易都有一个名称，虽然比特币交易结构并没有这样一个字段。我们选择将交易名称写在圆角矩形上半部，上图中“txnName”就是这个名称。
闪电网络需要在比特币交易结构中的sequence字段和locktime字段填入适当的值，将其写在圆角矩形的下半部，如上图中的“seq = 1000”。“0.55、0.35、0.3、0.4、0.2”都是交易输出金额。虽然“0.55和0.35”边上的箭头代表交易输入，但交易输入一定是另一交易的输出，所以这样表达仍然合理。
“0.3、0.4、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值，并将就绪后的交易在区块链上公布，对应图例就变成这样：?
图2 解锁R并公布在区块链上的交易
注意H(R)右上方出现了红色的钩，表明对应解锁条件变为就绪。圆角矩形框的边框变成宽实线，表明这笔交易已公布在区块链上。?
闪电网络允许在链下并存多个消费同一交易输出的不同交易。如果将这些交易都发布到区块链上，显然只有其中一个交易能够生效，其他交易都因为不能双花被拒绝了。上图用一个带“X”的圆圈表达了C1a、C1b的互斥关系。
HTLC中会使用IF…ELSE…ENDIF结构的加锁脚本，就长这样子：?
图4 IF…ELSE…ENDIF脚本
其中一个分支通过提供Alice2、Bob2的签名和R解锁，另一个分支只需提供Alice1、Bob2的签名就可以解锁。为特别表明此处用到了IF结构，在图例中我们会在表达互斥的带“X”圆圈旁边加注“if”，就像下图一样：?
2. RSMC剖析
2.1 通道建立
图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随时可以选择单方面终止通道并取回资金，发起方将受到延迟提款的惩罚。?
图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构成，也没有多余的字段存放“版本号”，所以是迂回地通过经济手段来达到实际废止的效果。?
图8 微支付：创建新版本余额
创建余额的新版本很简单，双方完全不动区块链上的funding交易，在链下按上图另外创建一套反映新余额的交易。很清楚，现在Alice实际控制0.4 BTC而Bob实际控制0.6 BTC，等价于Alice支付Bob 0.1 BTC。注意为便于区分，交易名称都改变了。
作废旧版本的余额非常有技巧，方法是在旧版本交易的基础上增加几个作恶惩戒交易，效果上类似发誓：“我要是拿这个旧版本去区块链上提款，你就把我的那份拿走！”，只不过这个誓言是决定可以生效的。?
图9 微支付：作废旧版本余额
C1a, C1b, RD1a, RD1b都是旧版本余额用到的交易。作废这堆交易的方式是构造一对新的交易BR1a和BR1b，并准备就绪其输入解锁脚本所需全部签名。上图中，红色虚线框中的两笔交易是在原来基础上新增构建的。?
在图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
图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的条件支付已经达成。?
如果直到超时Bob仍不能提供正确的R值，Alice可以如图12所示，通过用自己的私钥准备各交易的输入解锁脚本并发布交易到区块链上，最终取回这0.1 BTC（注意图中红色的“√”），。在此方式下，最终Alice拿到0.5 BTC，Bob拿到0.5 BTC。和图11完全类似，也可以采用新建版本余额的方式，无需终止通道。
2.3 作废旧版本与违约惩罚
???????建立新版本余额快照后，就应该作废旧版本。和之前作废旧版本的思路类似，在通道中还包含HTLC合约的情况下，依然靠新增若干作恶惩戒交易的方式作废旧版本。?
图14 作废旧版本余额
图14中用红色虚线框出的部分就是新增的“作恶惩戒交易”。?
在图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。