状态通道、支付通道、闪电网络概述
- 状态通道:是指在链外状态变化的虚拟channel,这里的状态在支付通道的场景中特指质押余额的改变。
- 支付通道:支付通道是状态通道的特例,在比特币中指双方交易的无信任机制。中间的承诺交易都是offchain的,只有后面的结算交易最终上链,从而达到提高交易的吞吐量、低延迟和精细粒度的效果。
- 闪电网络:是双向、可路由、无信任支付通道的一种具体实现方式。由Joseph Poon和Thadeus Dryja于2015年2月首次提出,其基础是前面的支付通道。目前闪电网络原型以及由几个团队发布,现在只在比特币的testnet上运行,因为它们使用segwit,还没放到mainnet上激活。
支付通道基本概念和术语
支付通道中有三种交易类型,资金交易、承诺交易、结算交易。
(这里通道是虚拟的概念,类比TCP 链接。首先,状态通道是由一个叫做“共享状态”的交易创建的,这个交易被称为funding transaction或anchor transaction,锁定了链上的共享状态。
这个交易必须得发送到网络中,并且通过挖矿,状态通道才能成功创建。
在payment channel中,上述的“锁定共享状态”指的是channel的初始余额。)
承诺交易用于彼此的小额支付,每个承诺交易都改变通道的状态,每个prior state是双方共同废止的。后面会详细介绍废止prior state的各种机制。(timelock,HTLC,非对称可撤销密钥?)
结算交易可以关闭通道,也需要发到网络中,经过挖矿,最终上链结算。结算交易是通道的最终状态。
任意一方提交最新的承诺交易到链上,也可以单方面关闭通道。
简单支付通道
简单支付通道是广义的状态通道中的一种。其实闪电网络是可路由的、多跳的,双向支付通道。
下面我们以一个最简单的支付通道场景为例来声明状态通道的一些关键点。
单向支付通道示例:
1)2-2 multisig 地址,提交最多1h的押金。(36毫比/1h为例)
2)注资时可能多个输入,一个找零输出。
3)资金交易得到确认后,开始看视频,Emma的软件创建并签署一笔承诺交易,改变通道余额,创建两个输出,将0.01毫比归入Fabian的地址,并退回给Emma35.99毫比。
4)Fabian服务器接收到此交易,添加第二个签名(2-2输入),将其返回给Emma并附带1s的视频。现在双方谁都可以兑换完全签署的承诺交易,代表此时通道的正确余额,正常情况下谁都不会将此交易广播到网络中。
5)最后,Emma点击停止观看视频,现在可以发送最终状态交易进行结算,即结算交易,余额两清。
最后,只有两个交易记录在块上:资金交易和结算交易。
无信任通道
TimeLock
上面是理想的交易场景,不存在任何主观欺骗和网络异常、宕机等意外情况。
接下来列举一些“意外”的场景,并考虑如何解决这些问题,使支付通道可以成为受信任的。
- 创建funding通道后的找零问题:如果fabian消失前没给funding transaction签名,这笔钱就退不回来了。
- 建立起通道后的commitment transaction金额丢失的问题:比如fabian掉线,没获得双方签名。
-
比如Emma看了10分钟视频,但却把看第1s后的commitment transaction传到网络中,上链,结束通道。
以上问题都可以通过n-lock time解决。
- 第一个commitment transaction是refund transaction,并设置一个较长的locktime,比如30天或4000个block(通道生命周期上限)。其余的commitment transaction的locktime要比这个短,以便在退款找零前作承兑。
- 每一笔承诺交易都会被时间锁锁进未来时间点,广播承诺交易的话必须要等待时间到期。由于nLocktime,任何一方都只有其时间到期后才能成功传播任何承诺交易。
- 最新的承诺可以在他的前一承诺被废止前赎回。(如果最新交易双方签名了就废止了)
时间锁是倒计时的,最新的交易可以先执行并广播,正常情况下的终止,只有退款交易和清算交易,中间的承诺交易不会上链。只有一方断线而另一方不得不单方面关闭通道时才使用。
状态通道使用时间锁在时间维度中执行智能合约。最新的承诺交易可以消费输入、废止此前的承诺交易、在网络中广播传输。此实现只需要绝对的交易级时间锁(nLocktime).
接下来,我们将看到如何使用脚本级时间锁,来构建更灵活、复杂、实用的状态通道。
但是缺点也很明显:
- timelock限制了channel的lifetime。
- 如果其中一方消失,另一方必须等待timelock到期才能退款。
- 如果设置timelock为4320个块(30days),之间的commitment tx间隔为1个block(10分钟),这样无形增加了channel参与方的压力,因为他需要时刻在线,盯着进度,随时准备着广播相应的commitment tx。
幸好时间锁并不是废止先前承诺交易的唯一方法,下面将介绍通过撤销密钥来实现相同的结果。
小结:
1)时间锁就是为了有效废止旧的承诺交易和资金交易的退款风险,避免交易中一方为了广播对自己有利的此前承诺交易。通过时间锁定确保最新承诺交易在此前承诺交易生效前被花费。
2)时间锁保障交易双方利益,正常合作关闭通道不会有任何问题,但是意外情况发生时可能导致退款周期长,并且有诸多限制。
不对称可撤销承诺
处理之前的承诺交易更好的方法是明确的撤销他们。但是却不容易实现,因为对交易进行时间排序本身就很难实现。
实现方法是实现给予交易参与方一个撤销密钥,如果对方试图作弊,就用其来对对方进行惩罚。撤销先前承诺的这种机制最初是作为闪电网络的一部分被提出来的。
不对称
此方案第一个要素--不对称,如上图所示,任何一方广播2-2签名的承诺交易后,余额都会立即支付给对方,而自己却要等待一段时间。
但是单靠延迟支付并不足以防止作弊,因此有方案的第二个关键词:撤销密钥,允许被欺骗的一方占有通道的所有余额来惩罚作弊方。
每个承诺交易有一个延迟输出,这个延迟输出允许持有方在1000个块后兑换,或者另一方用撤销密钥(如果有)兑换。例如Hitesh构建并签署承诺交易时,把第二个输出(第一个输出是不对称)定义为1000个块后支付给自己,或者任何拥有撤销密钥的人,当他想创建下一笔承诺交易,撤销此前承诺交易时才会把撤销密钥交给Irene。
撤销是双边的,反之亦然。
带有相对时间锁(CSV)的不对称可撤销承诺是实现支付通道的更好方法,也是区块链技术非常重要的创新。通过这种结构,通道可以无限期地保持开放,并且可以承载大量中间承诺交易。
在闪电网络的原型实现中,承诺状态是由48bit index标识,允许在任何单个通道中有超过281M个状态转换。
哈希时间锁合约(HTLC)
支付通道可以通过HTLC这种智能合约进行扩展,允许参与者在限定过期时间内将资金提交到可撤回密钥。用于双向可路由的支付通道中。
RSMC只支持最简单的无条件资金支付,HTLC(Hashed Timelock Contract)进一步实现了有条件的资金支付,通道余额的分配方式也因此变得更为复杂。
H = Hash\(R\)
R是一个密钥,H是密钥哈希值,这步可以包含在输出的锁定脚本中,任何知道R的人都可以兑换输出。
闪电网络
广义闪电网络的关键技术有三个,依次是:RSMC(Recoverable Sequence Maturity Contract),HTLC和闪电网络。后面依赖于前面。
如果Alice打算终止通道并动用她的那份资金,她可以向区块链出示双方签字的余额分配方案。如果一段时间之内Bob不提出异议,区块链会终止通道并将资金按协议转入各自预先设立的提现地址。如果Bob能在这段时间内提交证据证明Alice企图使用的是一个双方已同意作废的余额分配方案,则Alice的资金将被罚没并给到Bob。
实际上,前面所说的“作废前一版本的余额分配”,正是通过构建适当的“举证”证据并结合罚没机制实现的。
为了鼓励双方尽可能久地利用通道进行交易,RSMC对主动终止通道方给予了一定的惩罚:主动提出方其资金到账将比对方晚,因此谁发起谁吃亏。这个设计虽然增加了技术复杂度,但应该说是合理的。
通道余额分配方案的本质是结算准备金。在此安排下,因为要完全控制资金交收风险,每笔交易都不能突破当前结算准备金所施限制。
基于HTLC可实现闪电网络。
如上图所示,Alice想给Dave发送0.05 BTC,但Alice和Dave之间并没有微支付通道。但这没关系,Alice找到了一条经过Bob、Carol到达Dave的支付路径,该路径由Alice/Bob, Bob/Carol和Carol/Dave这样三个微支付通道串接而成。
Dave生成一个秘密R并将Hash(R)发送给Alice,Alice不需要知道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的佣金。
尽管闪电网络本身可以基于任何合适的传统技术构建,闪电网络的支付通道也可能逐渐向少数大型中介集中,变成若干大型中介彼此互联、普通用户直连大型中介的形式,但这种方案仍然具有传统中心化方案不可比拟的优势,因为用户现在并不需要信任中介,不需要在中介处存钱才能转移支付,资金安全受到比特币区块链的充分保护。
闪电网络的技术本质并不难理解,但要将之付诸实践则相当复杂。
闪电网络路由
LN节点之间通信是点对点加密的,节点间通过公钥作为标识符彼此认证对方。
节点支付前先建立具有足够容量的支付通道来构建网络路径。节点广播路由信息,包括打开了哪些通道,通道的容量,以及收取的路由费用,实现方式目前主要包括以下三种:
- IRC协议。
- P2P模型。通过flooding的方式将通道信息传播给他们的对等体,类似于比特币传播交易的方式。
3.Flare。未来计划,它是一种具有本地节点和远端信标节点的混合路由模型。
在前面的例子中,Alice节点使用这些路由发现机制之一来查找将她的节点连接到Dave节点的一个或多个路径。构建完路径后,经过初始化,传播一些加密和嵌套的指令来连接每个相邻的支付通道。
匿名网络路径
在闪电网络的“路由部分”另一个重要特性是匿名网络路径。上栗中只有Alice节点知道付款路线,其他节点只找到上一跳和下一跳节点。具体实现是通过Sphinx方案的洋葱路由协议。
闪电网络优势
- 无信任操作。
- 速度。 以毫秒为单位。
- 隐私和流动性。都是匿名网络特性决定的。流动性是因为很难应用监视和黑名单。
- 粒度。支付最小金额单位粒度可以很小。
- 吞吐量。
闪电网络实践分析
闪电网络是实现可路由双向微支付通道方案的一种,还有其他实现类似目标的设计,如Teechan和Tumblebit。
现由至少五个开源团队实施。这些独立实施是由“闪电网络技术基础”论文中描述的一组互通性标准进行协作。
[1]:闪电网络wiki
[2]:雷电网络源码
[3]:闪电网络路由方案flare
雷电网络
雷电网络VS闪电网络
闪电网络是基于比特的UTXO模型,雷电网络是基于以太坊的约模型,雷电网络借鉴了闪电网络的技术理念,关键技术也和闪电网络一致,包括RSMC、HTLC等技术。但雷电网络结合以太坊的特点也有一些自身的设计特色,下文就雷电网络的特点、存在的问题以及项目现状方面展开描述。
雷电网络设计特色
- 智能合约
闪电网络是通过2-2的多重签名地址建立channel,雷电的支付通道通过智能合约,此处智能合约的作用是:
1)为通道建立指定参与方可共识的共享规则;
2)以托管形式持有代币,以支持链下支付;
3)使用防止一方滥用规则的仲裁协议;
智能合约也负责在通道关闭时,根据链下双方签名的余额证明,进行链上的余额结算。
智能合约对比闪电网络中的多重签名脚本实现更简单,条件盘点也更灵活。
- 智能转账(smart transfers)
HTLC是闪电网络实现支付路径的关键,雷电网络利用了以太坊支持智能合约的特点,发明了更为通用的智能条件(smart condition),实现智能转账。
智能条件可接受任何格式的报文为参数,执行后对通道上的余额进行调整。而HTLC是smart condition中可实现的条件之一。
智能转账能够根据链上智能合约可读取的条件进行结算,提供比HTLC更为丰富的功能,如支持预测市场、期货等条件,实现更为丰富的应用。
- 组合锁
闪电网络中,HTLC的解锁取决于到期时间和收款人能否出示符合哈希值的secret两个条件。
HTLC的secret一般由收款人设置,将secret的哈希值提供给付款人。但是这样做存在一定问题,即转账中,如果Alice临时改变路径,不想通过C转账。或者C离线,无法转账,Alice需要更改路径。更改路径后,在上次的HTLC没有到期之前,Bob和C有合谋的可能,在Bob从新路径拿到代币后,Bob向C透露secret,使Alice在旧路径被锁定的代币损失。
而雷电网络开发者考虑为锁设置由三个锁组成的组合锁,解决此问题。包括:
(1)重试哈希锁(retry hashlock)。重试哈希锁的secret由付款人提供,可能会被付款人重新生成。重新生成一般发生付款人想改变路径的情况。
(2)收据哈希锁(receipt hashlock)。收据哈希锁的secret由收款人提供。
(3)时间锁(time lock),用于由付款人控制的锁到期时间。
在到期前要解锁这笔转账,就需要重试哈希锁和收据哈希锁的两个secret,可称之为secretR和secretE。
改造后,以Alice通过C中介转账给Bob为例,新的转账方式是:
(1)收款人Bob发送收据哈希锁给Alice,自己保留收据哈希锁的secretE。
(2)付款人Alice使用收据哈希锁和自己的重试哈希锁构造给C的转账,Alice自己保留secretR。
(3)C按照同样的锁向Bob构建转账。
(4)Alice确认以上转账构造完毕后,向Bob提供secretR。
(5)Bob拥有secretR和secretE,向C出示,解锁转账,获得代币。C也获知了两个secret,向Alice出示,解锁转账,获得代币。
这样做的好处是,只要Alice不提供secretR,Bob不能在转账中途向转账中介C提供secret,使Alice遭受资金损失。
- 其他
雷电网络在设计细节方面与闪电网络也有一定不同。
其中,用来更新通道余额分配的报文,增加了序号字段和等待期字段用来识别作废的报文。
如果A向链上提交更新余额的报文后存在等待期,在等待期中,如果有序号更新的报文提交,A将受到惩罚。惩罚一般是罚没A在通道中锁定的代币。
另外,在余额分配中,申明新余额分配的方式是出示余额分配的净增减,而不是重新申明余额,和闪电网络有形式上的差别。由于这个缘故,雷电网络的通道称之为“The Netting Channel(净通道)”。
雷电网络一些待解决的问题
- 通道设立成本
- 中介在线激励:不同于转账激励
- 中介转账撤回
- 中介路径查找
- 离线风险
-
总结
雷电网络待解决的问题,最突出的有两个:
一是离线问题。离线造成中介转账的路径不能顺畅地搭建,也造成了通道关闭和中介转账中,离线节点代币损失的风险。
二是路径查找问题。也许通过高级视图,可以快速实现最短中介转账路径的查找。但同步通道的最新链下交易状态,仍是一个难点。
当然,以上两个问题也有比较方便的解决办法,那就是支付中心。通过若干个和大量节点保持通道的支付中心,可以大量节省路径查找的问题,以及减少转账中介离线的可能,因为支付中心处于经济激励考虑会时常在线。但是仍无法解决支付中心在普通节点离线时,关闭通道的风险。此外,也有支付中心的管理风险。因为如果支付中心在同一时刻因为某种原因,关闭所有通道,对链上区块的GAS消耗是很大的,可能造成拥堵。