闪电网络:详解比特币Layer2扩容方案_ICE:LIC

什么是闪电网络?(Lightning Network)

闪电网络是比特币最具讨论度的Layer2扩容方案之一,其背后的主要思想是设计一种支付协议,可用于比特币所面临可扩展性问题的链下解决方案。

究竟比特币面对的问题是什么?闪电网络又要解决什么问题?

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

而闪电网络就像行动支付,你可以把一部分的钱存到行动支付,与任何支援的商家或个人快速地进行转帐。

某一天夜深人静,阿平跟阿菜两人无聊,决定比赛,用行动支付互相转帐,每笔只转一块钱,看谁转的比较多。

如果是传统的银行模式,两人可能排队排一夜只能玩个几次,还需要花手续费,根本没办法玩。

透过行动支付一个晚上下来可以转上千次,最终结果是阿菜比阿平手速快,一块险胜。

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

重点来了,“闪电网络”要如何运作才能保证资产能够在无信任的前提之下进行交易,并保障交易能够安全的回到比特币主链上确认呢?

以下就来介绍几项闪电网络的关键技术的概念。

单向支付渠道

闪电网络节点数量已达31910个:金色财经报道,据1ML.com数据,目前,支撑网络的节点数量达到31910个,相较30天前数据,环比上涨4.92%;通道数量为83605,相较30天前数据,环比上涨3%;闪电网络承载能力目前为3312.69BTC,约合1.61亿美元。[2021/12/22 7:57:11]

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

在闪电网络出现之前,单向支付渠道的概念已经存在了一段时间了,但应用有限。

Alice向Bob开启了一个单向支付渠道,在这渠道中Alice有10BTC,Alice可以向Bob支付链下交易,但这个渠道是单向的,也就是说Bob不能通过相同的渠道支付给Alice。

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

可以选择关闭渠道,将交易广播至主链,让矿工做确认,即可从Alice那获得1个比特币。

或者,Bob知道日后Alice会继续支付比特币给他,选择让通道继续开着。

问题来了,Bob拥有最后的签名与广播权,如果Bob是个无赖,让通道一直开着,Alice就永远没办法结算,10BTC就会被被绑架在这个支付渠道中。

所以一般而言,支付渠道都会搭配一个配套措施“时间锁”。

时间锁 CheckSequenceVerify(CSV)

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

马斯克:狗狗币有望比闪电网络更高效:10月25日消息,马斯克发推谈到狗狗币时表示:重要的是降低费用,降低区块时间,提升区块大小。单一的一层网络,搭配发挥二层网络作用的交易所,似乎是作为交易媒介的最简单的解决方案。对此,狗狗币支持者/img/2022812171508/0.jpg">

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

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

双向支付通道如何运作?

从头到尾,涉及的双方只需要与比特币区块链进行两次互动。

一次打开支付渠道而另一次是关闭渠道,在这之间发生的所有其他交易都不直接与主链接触,这意味著,只有在双方都同意并签名的状态下,交易才会被确认。

假设Alice和Bob打算频繁进行交易,双方同意开开双向支付通道,并约定好在1000个区块后强制结算。

Alice和Bob必须先在链上开启一个多重签名钱包,才能开开双向支付通道。

动态 | OpenNode发布Shopify闪电网络插件:据Ethereum World News消息,比特币支付处理器OpenNode发布Shopify闪电网络插件,为Shopify商家和用户提供更易于使用的电子商务和零售插件解决方案,以帮助推动比特币支付。ShopifyShopify为加拿大电子商务公司,于2013年初成为接受比特币的公司之一。[2019/3/27]

此时双方会各自生成一组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如果要向arol支付1个比特币,该怎么做呢?

Alice可以选择直接跟Carol,建立一个支付渠道,但是这样做对Alice跟Carol来说,必须在主链上建立多重签名钱包还要打币,不仅麻烦而且又需要额外成本。

相信大家都想到解决方法了,Alice只要透过现有的支付通道,先把1BTC打给Bob,Bob在将1BTC打给Carol,这样就可以在不用负担额外成本的情况下完成交易了。

但是,这同时也存在几个信任问题。

Bob不老实,拿了Alice的BTC之后私吞,不交给Carol。

Carol拿了钱,却跟Alice说他没拿到钱。

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

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

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

1.?Alice要确定Carol本人确实有收到比特币

2.?必须确定Bob不会拿走这笔比特币

这里又一个公钥与私钥的概念,HTLCs就是用同样的概念下去延伸,我们把钥匙想成私钥,锁头就是公钥。

假设Alice需要付给Carol1个BTC,收款方Carol会创建一个Value (钥匙) 和对应的哈希值 (锁头),然后把锁头交给Alice。

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

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

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

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

于是,Carol向Bob提供Value,从Bob那获得了1BTC。

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

闪电网络的优势

闪电网络致力于比特币可扩展性问题的链下解决方案。

如果成功,可能会大幅减少比特币区块链的负载,增加比特币的实际应用可能。

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

闪电网络的局限性

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

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

闪电网络较难支援大额付款。

闪电网络交易时有时需要仰赖中间人,举个例子,闪电网络中存在Alice、Bob和Carol三人,Alice要发送1BTC的交易给Carol ,这中间需要经过Bob。

如果Bob的余额不足1BTC ,这笔交易便无法顺利完成,因此交易金额会受限于中间人的资产余额。

闪电网络的实用性取决于网络大小,若使用人数不足,闪电网络便难以发挥其价值。

越多的人加入,闪电网络才会更加健全且完善,流动性也才能随之提升。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

水星链

[0:15ms0-1:40ms