闪电网络:详解比特币Layer 2扩容方案

什么是闪电网络(Lightning Network)

闪电网络是比特币最具讨论度的Layer 2 扩容方案之一,其背后的主要思想是设计一种支付协议,可用于比特币所面临可扩展性问题的链下解决方案。究竟比特币面对的问题是什么?闪电网络又要解决什么问题?这边用一个轻松的例子,简单介绍。

以比特币的交易速度来说,每秒只能处理2~7笔交易,想像一下用比特币进行支付,就像需要去银行排队转帐一样,一但交易量暴增,岂不是要在银行等到白了头?这种支付方式明显难以接受。

而闪电网络就像行动支付,你可以把一部分的钱存到行动支付,与任何支援的商家或个人快速地进行转帐。某一天夜深人静,阿平跟阿菜两人无聊,决定比赛,用行动支付互相转帐,每笔只转一块钱,看谁转的比较多。如果是传统的银行模式,两人可能排队排一夜只能玩个几次,还需要花手续费,根本没办法玩。透过行动支付一个晚上下来可以转上千次,最终结果是阿菜比阿平手速快,一块险胜。

而结算时行动支付会替他们去银行排队,然后跟柜台说: 「阿平帐户余额-1,阿菜帐户余额+1」。读到这就能大致了解闪电网络解决方案的基本逻辑了。

重点来了,「闪电网络」要如何运作才能保证资产能够在无信任的前提之下进行交易,并保障交易能够安全的回到比特币主链上确认呢?以下就来介绍几项闪电网络的关键技术的概念。

单向支付渠道(One-Directional Payment Channel)

在闪电网络出现之前,单向支付渠道的概念已经存在了一段时间了,但应用有限。Alice向Bob开启了一个单向支付渠道,在这渠道中Alice有10BTC,Alice可以向Bob支付链下交易,但这个渠道是单向的,也就是说Bob不能通过相同的渠道支付给Alice。

假如Bob在接收到1颗比特币后:

  • 可以选择关闭渠道,将交易广播至主链,让矿工做确认,即可从Alice那获得1颗比特币。
  • 或者,Bob知道日后Alice会继续支付比特币给他,选择让通道继续开着。

问题来了,Bob拥有最后的签名与广播权,如果Bob是个无赖,让通道一直开着,Alice就永远没办法结算,10BTC就会被被绑架在这个支付渠道中。所以一般而言,支付渠道都会搭配一个配套措施「时间锁」。

时间锁CheckSequenceVerify(CSV)

所谓的时间锁就是,在创建通道时会先约定好一个时间,时间一到,通道就必须强制关闭,有两人签名的交易将会上链做交易确认,没有签名的余额,会被返回给原持有人。

Alice和Bob在创建时,约定好在1000个区块后,通道必须关闭。所以Bob必须要在时间到之前,签名并广播交易,才能拿到Alice给他的1颗比特币。如果Bob迟迟不签名广播,一但约定时间到,Bob将一毛钱也拿不到。

双向支付渠道(Bi-Directional Payment Channel)

单向支付渠道之所以简单,是因为交易是单向的,只允许两个人中的其中一个人发送交易,另一个人广播交易,不会有信任问题,但应用场景相对有限。

有鉴于单向渠道在应用上的不足,闪电网络想要打造的是无信任的双向支付渠道,让渠道的双方能够自由进行交易。那么闪电网络要如何避免交易双方产生信任问题,实现双向支付渠道呢?

所谓的信任问题包括:

  • 双向支付渠道代表双方都必须有部分资金在渠道,那资产会不会被卷款?
  • 如何保证最终结算不会有误?
  • 支付渠道是P2P网络,没有验证机制,谁来保护帐本?

下面我们要介绍的是若要做到双向支付渠道所需的技术同时也是闪电网络的核心技术,RSMC以及HTLCs。

RSMC 可撤销顺序成熟度合约(Revocable Sequence Maturity Contract)

RSMC 其实就是资金池,打开支付渠道时,双方将资产放入这个资金池中,封起来各自用一把钥匙锁上,交易时不会真的动用到该笔资金,而是用合约的方式纪录两人在资金池里的剩余资产,等到关闭通道时,才会打开这个资金池做结算。

双向支付通道如何运作?

从头到尾,涉及的双方只需要与比特币区块链进行两次互动。一次打开支付渠道而另一次是关闭渠道,在这之间发生的所有其他交易都不直接与主链接触,这意味着,只有在双方都同意并签名的状态下,交易才会被确认。

假设Alice 和Bob 打算频繁进行交易,双方同意开辟双向支付通道,并约定好在1000 个区块后强制结算。Alice 和Bob 必须先在链上开启一个多重签名钱包,才能开辟双向支付通道。

此时双方会各自生成一组Secret Key (钥匙)以及Hash (锁头),Hash会交给对方,Secret Key自行保管。在开辟双向支付渠道后,Alice和Bob每次支付都像签一次合约,在签新合约之前会废弃掉旧合约,要注意的是当旧合约作废的同时彼此将取得对方旧合约的Secret Key,而合约的内容就是关于如何重新分配资金池的资产。

共同签名钱包里的钱只能在三个条件下解锁:

  1. 锁定时间到了
  2. 任何一方通过对方的Secret Key 从他们设置的多重签名钱包中解锁资金
  3. 合约有双方签名,且其中一方广播

要注意的是,如果一方决定关闭支付渠道并广播交易,广播的那一方将不得不等待到交易签名时设置的预定时间到,才能收到他那部分的资金。

会不会有人作恶?

例如:闪电网络中的其中一位参与者广播对于自己有利的旧合约来进一步图利,而非依照正常程序广播最新的合约。

此时,上述的两个值得注意的点就派上用场

  • 当旧合约作废的同时彼此将取得对方旧合约的Secret Key
  • 如果一方决定关闭支付渠道并广播交易,广播的那一方将不得不等待到交易签名时设置的预定时间才能收到他那部分的资金

假如Alice企图广播旧合约恶意结算关闭通道,依照上述闪电网络的机制,Bob与Alice都拥有对方旧合约的secret key,且Alice必须等到预定的时间到,才能拿到旧合约中Alice的那份BTC,所以Alice只要广播旧合约,Bob即可在Alice等待的时间中使用旧合约的secret key将Alice的那份BTC取走,这样一来Alice不但没有成功广播对他有利的旧合约,还为他的恶意行为付出代价。

读到这边,我们就把双向支付通道的运作方式全都说完了。接下来要介绍的是,双向支付通道如何编织成为支付网络。

支付网络

现在,除了Alice 和Bob 之间有支付通道之外,Bob 也和Carol 开了支付通道。Alice 如果要向Carol 支付1 颗比特币,该怎么做呢?


Alice 可以选择直接跟Carol,建立一个支付渠道,但是这样做对Alice 跟Carol 来说,必须在主链上建立多重签名钱包还要打币,不仅麻烦而且又需要额外成本。相信大家都想到解决方法了,Alice 只要透过现有的支付通道,先把1 BTC 打给Bob,Bob 在将1 BTC 打给Carol,这样就可以在不用负担额外成本的情况下完成交易了。但是,这同时也存在几个信任问题。

  1. Bob 不老实,拿了Alice 的BTC 之后私吞,不交给Carol。
  2. Carol 拿了钱,却跟Alice 说他没拿到钱。

如何解决这部分的信任问题,就要仰赖闪电网络的另一项核心技术「HTLCs」。

HTLCs 哈希时间锁合约(Hash Time-Locked Contracts)

要解决上述的信任问题就必须做到两点:

  1. Alice 要确定Carol 本人确实有收到比特币
  2. 必须确定Bob 不会拿走这笔比特币

还记得我们之前介绍过的公钥与私钥吧,HTLCs就是用同样的概念下去延伸,我们把钥匙想成私钥,锁头就是公钥。假设Alice需要付给Carol 1个BTC,收款方Carol会创建一个Value (钥匙)和对应的哈希值(锁头),然后把锁头交给Alice。

这里就是这个技术的精华。

” 只要拿得出钥匙就代表他是Carol “

” 只有Carol 拥有钥匙,换言之,只有Carol 能够打开锁头“

在这个前提下,Alice 和Bob 提出一份合约,如果Bob 在3 天内(Lock time = 3 day),提供哈希值对应的Value,Alice 就给Bob 1.0001 BTC,超过3 天,BTC 原路返回给Alice。

Carol 也同样跟Bob 签订一个合约,只要Carol 提供哈希值对应的Value,就必须给Carel 1 BTC。

于是,Carol 向Bob 提供Value,从Bob 那获得了1 BTC。Bob 将这个Value 交给Alice,从Alice 那获得了1.0001 BTC,这当中的价差0.0001 BTC 就给Bob 作为手续费。

闪电网络的优势

闪电网络致力于比特币可扩展性问题的链下解决方案。如果成功,可能会大幅减少比特币区块链的负载,增加比特币的实际应用可能。

通过使用双向支付渠道,闪电网络可以实现近乎即时且极低成本的交易。

闪电网络的局限性

与链上交易不同,如果接收方处于离线状态,没办法做交易确认,无法进行支付。

网络的参与者可能需要定期监控支付渠道,以保证他们的资金安全。

闪电网络较难支援大额付款。闪电网络交易时有时需要仰赖中间人,举个例子,闪电网络中存在Alice、Bob 和Carol 三人,Alice 要发送1 BTC 的交易给Carol ,这中间需要经过Bob,如果Bob 的余额不足1 BTC ,这笔交易便无法顺利完成,因此交易金额会受限于中间人的资产余额。

闪电网络的实用性取决于网络大小,若使用人数不足,闪电网络便难以发挥其价值。越多的人加入,闪电网络才会更加健全且完善,流动性也才能随之提升。

本文链接地址:https://www.wwsww.cn/jishu/3224.html
郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。