解读闪电网络丨链下交易的安全怎么破？

2008年比特币诞生以来热度渐增，每个区块1MB大小，每秒可处理的交易7笔，是无法满足激增的需求，社区也是一直积极讨论扩容的解决方案，链下扩容就是其中之一。链下扩容是相对于链上（On-chain）扩容而言，链上扩容指的是直接发生在区块链上，通过改变区块大小或数据结构从而达到提高处理交易能力的解决方案，比如分片技术（Sharding）、隔离见证（Segregated Witness，简称SegWit）和增加区块容量。而链下扩容则指的是在主链之外，建立外围或第二层交易网络，比如状态通道（States Channels）、侧链（SideChains）和DAG（Directed Acyclic Graph）。今天的故事从状态通道讲起。

状态通道（States Channels）
状态通道的总体思路是将本来在链上结算的交易放在链下，交易方通过状态通道维护中间态，并将最终结果上链。若发生纠纷时回到链上仲裁，链上仲裁的公平性和安全性在博弈论上保证了交易对手不会作恶。

状态通道也分几个层级，对应着不同程度的链上功能替代度，概括如下图：

状态通道是更通用的支付通道形式，它不仅可以用于支付，还可以用于状态更新。状态通道在2015年由Ledger 实验室的创始人杰夫·科尔曼（Jeff Coleman）首次详细描述。状态通道在比特币上的实现称为闪电网络（Lightning network），用来实现区块链上的小额支付。以太坊网络上的相关技术叫雷电网络（Raiden network），它允许用户通过状态通道和另一个连接更大通道网络的实体相关联，从而用很低的成本和区块链网络上的任何人做交易。

而具体技术上，*哈希时间锁（Hashed-Time Lock Contract，简称HTLC）是闪电网络支付路径得以实现的关键，而雷电网络利用以太坊支持智能合约的条件，引入了更为通用的 “智能条件（Smart Condition）”，实现智能转账（Smart Transfers）。智能条件可接受任何格式的报文为参数，执行后对支付通道上的余额进行调整。智能转账能够根据链上智能合约可读取的条件进行结算，提供较哈希时间锁更为丰富的功能，如支持预测市场、期货等条件，实现更多应用。闪电网络中的哈希时间锁，是智能转账可实现的条件之一。

闪电网络（Lightning network）
闪电网络和雷电网络所使用的技术统称为状态通道，都属于链下扩容。历史进程上，闪电网络概念的出现和中本聪发布的比特币一样古老。经不断讨论优化，2015年一篇题为《比特币闪电网络：可扩展的链下即时支付》（The Bitcoin Lightning Network： Scalable Off-Chain Instant Payments）的白皮书最终成为规则的制定者。江湖号称仅次于比特币白皮书的【闪电网络白皮书】，该文作者原是智能合约交易平台 Mirror 首席技术官——约瑟夫·朴恩（Joseph Poon）和萨帝厄斯·追亚（Thaddeus Dryja），两人同年秋天成立了美国旧金山闪电支付实验室Lightning Labs，创始成员还有伊丽莎白·斯塔克（Elizabeth Stark）。2018年3月发布了第一个比特币主流网络闪电网络（LN），该公司称这是一个“重要的里程碑”。

同年开始致力于闪电网络的还有另外两家公司：澳大利亚区块链流公司Blockstream，是一家区块链软硬件解决方案的服务商，公司联合创始人兼首席执行官 Adam Back 博士是英国的密码学家，也是哈希现金机制的发明者，是被中本聪的比特币白皮书引用之一。联合创始人 Pieter Wuille 是比特币核心开发者之一，基础架构师罗斯迪·罗素（Rusty Russell） 擅长 Linux 内核的网络子系统和文件系统层次标准方面的工作，并起草了闪电网络协议规范的大部分内容。另一家，法国巴黎的初创公司阿斯安可Acinq，首席执行官是皮埃尔-玛丽·帕迪欧（Pierre-Marie Padiou），原从事硬件钱包业务，受到比特币矿业巨头Bitfury倡议Flare的启发，开始闪电支付项目Eclair。

从比特币容量的问题思考，若交易双方频繁交易，是否可一段时间后只将最终结果全网广播？又或者建立一个双方交易通道，无需信任第三方中介也可确保资金安全？闪电网络白皮书详细讲解双向支付通道、可撤销的顺序成熟度合同（Recoverable Sequence Maturity Contract，简称RSMC）、哈希时间锁HTLC等解决方式，试图逐一解决链下支付通道的交易问题。接下来重点解读这个三个技术。

1. 双向支付通道
交易双方彼此熟悉相互信任，即可链下通道内完成多次交易，最后交易余额上链广播。这样众多微小支付变成交易集，他们可能会选择在未来某一日期上链公布。通过推迟交易的公布，将大大降低最终被公布的主链交易数量，达到扩容效果。

问题来了，如果双方第一次交易，怎么建立支付通道呢？

引入“2-of-2双重签名地址”，指需要双方的签名才能进行转账的地址。2-of-2 是指总签名数为 2 个，一笔交易得拿到 2 个签名后生效。对应地， 2-of-3 多重签名地址就是指总签名数为 3 个，一笔交易得拿到其中 2 个签名后就可以生效。

基本规则：
Alice 和 Bob 有一个2-of-2双重签名认证的地址，然后各自把资金存到这个地址;
任何一方都能单独地把这个地址上的属于自己资金转回；
如果是交易，则需要双方的签名达成共识。

栗子：Alice 和 Bob分别往一个2-of-2双重签名地址转入一定数量比特币，比如（A: 1 BTC; B: 2 BTC），1 BTC属于Alice，2 BTC属于Bob。这个2-of-2签名地址及这个余额分配状态就是一个双向支付通道。如果在通道里Alice要向Bob支付0.5 BTC，那Alice 和 Bob就要对这个2-of-2签名地址进行签名，调整余额状态为（A: 0.5 BTC；B: 2.5 BTC）。

2. RSMC
RSMC是基于“支付通道”技术而开发的新型合约，解决了在支付通道环境下币的单向流动问题，使撤销上一个交易成为可能，并由此奠定了双向支付的基本工作方式。

问题来了，如果其中一方想要撤销交易，应该怎么办呢？

引入“FT= Funding Transaction 资金交易，CT= Commitment Transaction 承诺交易，序列数Sequence”。

资金交易FT，由交易方提供资金形成一个初始通道 FT，双方均为此交易创建 inputs 和 outputs，但不签署交易。

承诺交易CT，可以表示当前双方余额。如果双方仅交换一份2-of-2双重签名的CT，那么双方确定能在 FT 上主链后收回资金。

序列数sequence是合约的一个确定参数。比如说一个RSMC的序列数为1000，如果其父交易所在区块是10000，那么如果这个RSMC被写在了区块10999上，则这个RSMC不会被执行（相当于自动作废了）。为了确保该RSMC能被执行，我们等到当前区块为11000时，再在比特币网络中广播这个RSMC。这样，RSMC所在区块的高度一定会大于11000，该RSMC才能执行。

 
基本规则：
1.交易双方将协议的资金放入资金交易FT中，并在互相签署合约后，将其广播记入主链；
2.交易双方在不超过总金额的前提下，在链下进行交易，次数无限制；
3.每一次交易都必须签署全新的合约，即承诺交易CT，仅在支付通道中流转，并未广播记入主链区块；
4.当最后双方协议不再进行新交易，准备取回各自资金时，将由其中一方发起广播请求；
5.如果其中一方发现交易结果不正确，可以根据双方交易合约中的前置协议条件，在有效时间内提出真假合约验证请求；广播虚假交易合约一经证实，作假方在资金池内所有的自持资金将会作为赔偿支付给另一方。
6.在签署资金交易FT之前先签署一份承诺交易CT并交给对方。因为CT可以保证自己放到FT中的资金可以赎回，所以双方可以放心地签署 FT 并广播。

栗子：Alice 和 Bob建立一个通道FT，相当于资金池，存放着Alice和Bob的资金。这个FT有两个输出，分别是承诺交易C1a和C1b。这两个合约是互斥的（只有一个能在比特币网络上广播），即Alice只能广播C1a，Bob只能广播C1b。每个CT又有两个输出，一个是普通输出，一个是RSMC合约。

Alice将C1a广播到比特币网络上，根据C1a的普通输出D1a，Bob立即可以使用0.5个比特币。RD1a是RSMC合约，当C1a被广播到主链后的1000个区块之后，Alice可以广播这个RSMC (RD1a)，从而可以使用另外0.5个比特币。

问题来了，如果资金分配状态更新后，一方在主网上广播错误的CT，怎么办呢？

引入“违规补偿交易（breach remedy transaction）”， 防止在新确认交易达成后一方仍然广播旧交易，违规补偿交易用来代替旧CT中的RSMC，其规定交易对手方可以立即获得所有剩余资金。

栗子：Alice 和 Bob产生新交易C2a，C2b的同时，生成违规补偿交易BR1a和BR1b，违规补偿交易有效废止了上一个CT中的RSMC合约。若Alice将C1a广播到主链上，C1a普通输出D1a，Bob立即获取0.5个比特币。而C1a的RSMC合约输出RD1a被违规补偿交易BR1a替代，Bob又获得了剩余0.5个比特币。至此，RD1a已经无效。通过设计这样的违规补偿交易，保证了双方只能广播最新的承诺交易CT。

按常理，下一个部分应该进入第三点哈希时间锁 HTLC，非常重要的技术点，但是苦于知识消化能力有限，产出效率较低，该部分无法在本周完成，只能放一放，找个时间，看心情再补上。

（作者：数字门徒，内容来自链得得内容开放平台“得得号”；本文仅代表作者观点，不代表链得得官方立场）