Bitcoin的闪电网络

2024-02-23 12:50
文章标签 网络 闪电 bitcoin

本文主要是介绍Bitcoin的闪电网络,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1. 引言

区块链中,理想的交易应具有如下特征:

  • 即时支付:闪电般快的区块链支付交易,无需关注区块确认时间。由智能合约来保证安全性,而无需为单笔支付创建一个链上交易。支付速度以秒或毫秒计。
  • 可扩展性:能在网络上每秒进行数百万到数十亿次交易。扩容可大幅减少交易延迟的问题。
  • 低交易费:通过在链下进行交易和结算,可实现极低的交易费用,从而支持即时微支付等用户场景。
  • 跨链:跨链原子交换可 以 异构区块链共识规则的方式在链下即时进行。只要参与跨链的链支持相同的加密哈希函数,则可在无需新人第三方托管的情况下进行跨链交易。

比特币单个区块的容量上限为1MB,tps低于7。而Visa的tps高达47000。仍然假设每10分钟出一个区块,假设比特币每笔交易大小为300字节,则要达到Visa 47000 tps的容量,则区块大小需达到8GB,而每年的区块增量为400TB。这将影响网络的集中化。
比特币网络上的交易确认时间需要1小时左右,才可认为该笔交易是不可逆的。
为此,Thaddeus Dryja 和 Joseph Poon 于2016年论文《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments》,针对比特币,提出了闪电网络(Lightning network)—— 基于比特币网络的Layer2方案:
为 a network of micropayment channels。

闪电网络针对的场景为:
当只有两个参与者关注每天发生的交易,则没必要让整个比特币网络的所有节点都知道每笔具体的交易。仅需在稍后某个时间,将双方多笔交易的净值以一笔交易的方式广播到链上。且双方建立的微支付通道(小额支付通道)不需要信任机制,因为微支付通道本身就是真实的比特币交易。

闪电网络借助智能合约实现的去中心化网络,支持网络参与者之间进行即时、大批量、小额支付。
闪电网络中的费用远低于比特币网络中链上的交易费。闪电网络通道中的多笔交易可打包结算以一笔交易的方式上链。闪电网络中的费用大部分取决于:

  • the time-value of locking up funds for a particular route
  • 以及 paying for the chance of channel close on the blockchain。

具体的闪电网络设计文档见:Lightning Network Specifications (BOLTs) 。该协议主要由ACINQ、Blockstream和Lightning Labs团队共同制定。

主要实现有:

  • https://github.com/ElementsProject/lightning (C语言,BlockStream团队)
  • https://github.com/ACINQ/eclair (Scala语言,ACINQ团队)
  • https://github.com/lightningnetwork/lnd (Go语言,Lightning Labs团队)
  • https://github.com/21isenough/LightningATM (Python语言)
  • https://github.com/rust-bitcoin/rust-lightning (Rust语言,Squaring Crypto团队和Rust Bitcoin社区)
  • https://github.com/LNP-BP/lnp-node(Rust语言,LNP团队)
  • https://github.com/spesmilo/electrum(Python语言,Electrum团队,在其Electrum Bitcoin 钱包中集成了闪电网络)

以上闪电网络实现相互是兼容的,具体见 2017年12月博客 Lightning Protocol 1.0: Compatibility Achieved。

https://explorer.acinq.co/ 为比特币测试网的闪电网络节点状态explorer。在该网络上会显示所有兼容BOLT设计的闪电网络节点。目前比特币测试网上的闪电网络节点有1万+,通道有4万+。

比特币主网的闪电网络节点状态explorer有:【beta版本发布于2019年1月】

  • https://txstats.com/dashboard/db/lightning-network
  • https://1ml.com/

目前比特币主网上的闪电网络节点数为2万+,通道数为5万+,网络容量为1700+BTC,价值五千万美金+。
比特币总量为2100万枚, 1 B t c = 1 0 8 s a t o s h i s = 1 0 8 s a t 1 Btc=10^8 satoshis = 10^8 sat 1Btc=108satoshis=108sat

闪电网络中的交易不会公开广播,是私有的,仅sender和receiver可看到具体的细节。闪电网络中的交易是加密的,并借助类似Tor形式的洋葱路由协议,将加密的交易 由 付款人 路由至 收款人。也就是说相比于链上交易,闪电网络提供了更好的隐私改进。
作为routing node,若在节点安装了 Ride the Lightning ,可看到经由其路由的交易全路径的来源和去处信息,而不仅是与其相邻的来源和去处节点信息。

假想比特币区块链中有大量的通道网络,且所有的比特币用户都参与到通道网络中,每个用户至少在链上开通一个通道,则可能可在该通道网络中创建几乎无限的交易。仅需将与不合作通道参与者相关的交易广播上链。

相比于链上交易,闪电网络交易具有如下优势:

  • 更小的粒度。闪电网络中的支付金额可低至1satoshi。闪电网络中,给中间节点支付的路由费通常为millisatoshis(即msat)。而在比特币链上支付的最小金额为0.00000546 BTC
  • 更好的隐私。每笔闪电网络支付的细节并不会在链上公开记录。闪电网络中的支付可依次跨多个通道路由,每个节点可看到有支付通过其通道,但是无法看到支付的非相邻的源头或终点。【貌似,Ride-The-Lightning 可看到非相邻的源头或终点?】
  • 更快的速度。闪电网络中的交易结算时间低于1分钟,通常为毫秒级。而比特币链上的确认时间,通常为10分钟。
  • 更大的交易吞吐量。闪电网络协议本身对于每秒支付的金额并无上限限制。具体的交易数仅受限于每个节点的capacity和speed。

首笔闪电网络商业应用发生于2017年12月27日:Bitcoin开发者 Alex Bosworth在Bitrefill平台使用Bitcoin来支付电话费。
2019年1月19日,由Twitter用户Hodlonaut 发起了基于闪电网络的火炬传递促销测试,参与者包含了Twitter CEO、Lightning Labs CEO、币安CEO等人,经过292次传递,最终达到了预设的4,390,000 satoshis,火炬传递的最后一棒是在2019年4月13日,将其中的4,290,000捐赠给了一个在委内瑞拉推广比特币的非营利组织。

闪电网络一个很有争议的设计是:要求所有用户定期监控区块链以防欺诈,对此,开发了watchtower,可外包给watchtower节点来监控链上欺诈行为。

尽管闪电网络其本意是解决比特币的扩容问题,但是闪电网络技术本身可用于其它加密货币,特别是那些支持multi-sig钱包和智能合约的加密货币,也可借助闪电网络技术实现扩容。

2. 闪电网络的原理

闪电网络依赖于区块链中的底层技术,通过使用比特币交易和其原生的smart-contract scripting language,可为参与者创建安全的网络,支持以高容量和高速的交易。
比特币中提供了scripting system,用户可为资金编写指令。

微支付通道内的资金可存入一个要求2-of-2 multisignature的地址中,这样只有双方都签名达成共识,相应的资金才能退回到各自的个人账户中。这种退回操作并不会广播到链上。资金到达个人账户后,就可以随时赎回了。

微支付通道中,仅需要2种状态:

  • 当前正确的balance(只有一个)
  • 任意old deprecated的balance(可有很多个)

因此,可设计一个bitcoin脚本:

  • 所有的old交易都是无效的——由bitcoin output脚本和相关交易强制执行的,这些交易会强制另一方将其所有资金交给通道内的交易对手方。这种将所有的钱给对方的惩罚措施,可保证所有的old交易都是无效的。当通道内基于当前ledger states达成共识,则相应的real balance会更新,该balance不会反应在链上。但当有某一方不认可无法达成共识时,该balance会反馈在链上。
  • 只有新交易是有效的。

通过给Bitcoin transaction output附加hashlock和timelock,通道的交易对手方将无法直接窃取资金。同时,使用staggered timeout,可通过多个中间人来发送资金,且无中间人窃取资金的风险。

通过将多个微支付通道链接起来,可创建a network of transaction paths。这些path采用类似BGP的系统进行路由,sender可设计到recipient的特定path。output script会encumber a hash,该hash由recipient创建,通过公开该hash的input,recipient的交易对手方将可以沿着route推动资金。

关键技术有:【核心为:微支付通道(即RSMC) + 具有hashlocks和timelocks的合约(即HTLC,有条件支付)。】

  • 双向支付通道:2个参与者在链上创建一个ledger entry(为a two-party, multisignature “channel” bitcoin address),需要二者在任何资金支出上签字。双方创建的交易对应记录在ledger entry中,而不会广播到区块链上。双方可创建许多交易来花费当前ledger entry的output 来 更新各自在ledger entry中的相应分配。只有最新版本的ledger entry是有效的,具体通过blockchain-parsable smart contract scripting来强制实现。可在无需任何信任或托管的情况下,通过广播最新版本的ledger entry到区块链上,可由任意一方随时关闭该ledger entry。
  • 闪电网络:通过为这些two-party ledger entries创建网络,可发现与因特网中路由包类似的path across the network。无需信任该path(路径)上的节点,通过script来强化支付,具体为通过decrementing time-locks来保证原子性——即要么整笔支付都成功要么都失败。通过嵌入 knowledge of a secure cryptographic hash 这样的有条件支付,可在跨通道支付时无需信任任何一方,从而无需单方的资金监管。
  • 区块链即为仲裁者:可不受限制地进行链下交易,仅需信任链上的enforceability。这与一个人与其他人签订许多法律合同的方式相似,但并不是每次签订合同时都要上法庭。通过使交易和脚本可解析,可以在区块链上实施智能合约。只有在不合作的情况下,法院才参与其中——但通过区块链,结果是确定的。

支付通道允许通道内参与者相互转账而不需要将交易广播上链。其核心是对不合作的参与者进行惩罚。在开通通道时,参与者必须以链上funding transaction的方式存入一定的金额。借助Time-based script extensions,如CheckSequenceVerify(CSV) 或 CheckLockTimeVerify 脚本来实现惩罚操作。【P. S. In this case, we employed the opcode CHECKLOCKTIMEVERIFY, using the absolute value to define the timelock, for instance: “This output cannot be spent before the block #546212.” Within the Lightning Network, there is another opcode, a more ‘flexible’ one, which is also used: CHECKSEQUENCEVERIFY, using the relative values for the timelock, for instance: “This output cannot be spent until 1000 blocks since the moment when the transaction was broadcasted into the network.” ——源自Lightning network in depth, part 2: HTLC and payment routing】
在 BIP 0112 中详细介绍了如何使用CheckSequenceVerify来实现Hash Time-Locked Contracts,并用于闪电网络中。

假设Annie和John是好朋友,其使用闪电网络来相互发送Bitcoin的流程为:

  • 1)创建一个multi-signature (multi-sig) 钱包
    创建过程中,Annie和John双方都必须提供其public addresses和private keys。该钱包可由双方使用各自的私钥来访问。
  • 2)存入一定的Bitcoin到multi-sig钱包中
    Funding Transaction可由双方发起,也可仅由一方发起。
    如Annie存入0.01BTC,John存入0.05BTC。
    在这里插入图片描述
    multi-sig钱包创建后,Annie的lighnting node 和 John的lightning node都可以相互发送资金了。
    在闪电通道中发起的交易统称为Commitment Transactions。
    Commitment Transactions中的总金额不能超过其存入的金额,如,此时Annie Commitment Transactions中的总金额不超过0.01BTC,John Commitment Transactions中的总金额不超过0.05BTC。
    只要Annie和John需要,通道可一直保持开启状态。Commitment Transactions本身并不会影响Annie和John各自的Bitcoin balances。只有当通道关闭时,将触发Settlement Transaction 同时产生交易费。当有Settlement Transaction时,闪电网络钱包中各节点的Bitcoin将同步记录在Bitcoin主网上。
    假设,Annie想发送0.001BTC给Ryan,但是Annie与Ryan中之间未开启通道,而John和Ryan之间已开启通道。则Annie可通过路由的方式给Ryan转账。
    在这里插入图片描述

2.1 Timelock

Timelock为比特币中的智能合约primitive,其用于限制某些比特币的花费,直到未来某个指定的时间或区块高度。
Timelock用途很广,如:

  • 支付通道
  • Hashed Timelock Contract
  • 锁定作为投资持有的比特币数月或数年
  • 使make fee sniping less profitable,以及for trustless precomputed fee bumping

2.2 Hashlock

Hashlock为一种encumbrance(累赘)类型,用于限制某个output的花费,直到某个特定的data被公开。

Hashlock有一个有用的属性:
当某个hashlock被公开,采用相同key hash locked的信息也被公开。因此,可对多个output采用相同的hashlock来encumbrance,然后这些output可同时变得spendable。

Hashlock可独立使用,但常用于Hashed Timelock Contract中。

2.3 staggered timeout

staggered timeout是指:
each channel in the payment path requires to hold coins for a time period longer than the one in the next channel。

即若C->A->B,则要求 “C->A的timeout” > “A->B的timeout” > “B->C的timeout”。

2.4 创建双向支付通道的责任问题

某一方若要加入闪电支付网络中,其需要与网络中的另一个创建者创建一个微支付通道。因此需要明确通道创建过程中的责任问题。
双向支付通道的创建流程为:

  • 创建一个未签名的 Funding transaction
  • spending from该未签名 Funding transaction
  • Commitment transactions:unenforcible construction(非强制建设)
  • Commitment transactions:ascribing blame(归责)

2.4.1 创建未签名的 Funding transaction

可由通道的参与者之一或者两个参与者来创建初始的channel Funding transaction,并将资金存入该交易的inputs中。双方为该交易创建inputs和outputs,但是并不对交易签名。

假设通道的两个参与者分别为Alice和Bob,则该Funding transaction的output为一个单独的对应Alice和Bob的 2-of-2 multisignature script。
Alice和Bob相互并不会为该Funding transaction交换签名,除非他们从该2-of-2 output中将钱返回到各出资方。

不对Funding transaction签名的主要目的是:

  • 允许某人spend from a transaction which does not yet exist。

2.4.2 spending from 未签名交易

闪电网络中使用SIGHASH_NOINUPT transaction来spend from 2.4.1节中创建的 2-of-2 Funding transaction output,因为确实有必要可spend from a transaction for which the signatures are not yet exchanged。

SIGHASH_NOINPUT 采用软分叉的方式,保证交易兼容之前的签名方式,即对于无sighash flag的交易仍需要签名。

若无SIGHASH_NOINPUT,则无法spend from未交换签名的交易,因为spend the Funding transaction需要将Transaction ID作为child input 中签名的一部分。

Transaction ID的要素之一是:
其父交易的签名(即Funding transaction的签名)。

因此,正常需要双方交换父交易的签名之后,才可花费相应的子交易。因为其中的一方或双方必须知道父交易的签名才能花费它,这就意味着一方或双方能在子交易存在之前广播父交易(Funding transaction)。而借助SIGHASH_NOINPUT,支持子交易在不对input签名的情况下进行花费,详细的操作流程为:

  • 1)创建父交易(Funding transaction)
  • 2)创建子交易(Commitment transactions 及 所有spends from the commitment transactions)
  • 3)对子交易进行签名
  • 4)为子交易交换签名
  • 5)对父交易签名
  • 6)为父交易交换签名
  • 7)将父交易广播到区块链上

在前6个步骤完成之前,任何人都无法将7)中的父交易广播到链上。通道内双方直到第7步才将签名给出,以spend from the Funding transaction。若在第6步中某一方失败了,则整个transaction path将失效。

2.4.3 commitment transactions:unenforcible construction(非强制建设)

当未签名(且未广播)Funding transaction创建后,Alice和Bob双方会对一个初始的Commitment transaction进行签名和交换。Commitment transaction可spend from the 2-of-2 output of the Funding transaction(即父交易)。但是只有Funding transaction 会广播到链上。

由于Funding transaction已广播到链上,且其output为a 2-of-2 multisignature transaction,即需要双方同意才能花费,则Commitment transaction用于表示当前的balance。

若双方仅交换了一个2-of-2已签名的Commitment transaction,则Alice和Bob需确保在将Funding transaction上链之后,仍能将各自的钱赎回。双方只在想要将通道内当前的balance close out(结清)时,才将当前的Commitment transaction广播到链上,否则没必要对Commitment transaction广播上链。

Commitment transaction会维护各自的收支平衡。
在这里插入图片描述
Funding transaction的output仅可赎回一次,这就意味着仅有一个Commitment transaction是有效的。
在这里插入图片描述
由于每个Commitment transaction都经过双方签名和交换,因此无法约束哪个Commitment transaction可广播到链上。而且,由于任意一方可在任何时间广播任何一个Commitment transaction到链上,则对于拥有更少金额的一方更有动力广播金额更多的交易到链上。结果是,通道将会立刻关闭资金将会被窃取。这样的支付通道不具备可用性。

2.4.4 Commitment transactions:ascribing blame(归责)

由于任意已签名的Commitment transaction都可广播上链,且仅有一个可成功广播,因此有必要防止old Commitment transaction被广播到链上。而撤销数万笔交易在比特币中是不可能的,因此,相比于主动撤销,有必要以Fidelity Bond(诚实保证)的方式来构建channel——双方都做出承诺,任何违背承诺的一方都将受到强制惩罚。即若某一方违背承诺,其将失去通道内的所有资金。

对于支付通道来说,合同条款是双方都承诺广播最新的交易,任何广播older transaction的行为都违背合同,所有的资金都将作为罚金给交易对手方。

接下来的任务是如何对广播old transaction的行为进行归责,也就是说,应有唯一标识来判断是谁广播了older transaction的。可以让每一方都有一个唯一可表示的Commitment Transaction。双方必须对Commitment transaction的input进行签名,而另一方负责广播。由于每一方都有由另一方签名的Commitment transaction,每一方仅可广播自己版本的Commitment transaction。

在闪电网络中,所有spends from the Funding transaction output、Commitment transactions,都对应有2个半签名的交易。
某个Commitment transaction由Alice签名,并发送个Bob,标记为C1b,而令一个则由Bob签名并发送给Alice,标记为C1a。这两个Commitment transaction都是spend from同一output的(Funding transaction),但是具有不同的内容。因为这一对Commitment transaction spend from 同一Funding transaction,仅有一个可广播上链。任意一方都可广播自己收到的Commitment transaction——在交易对手签名的基础上再自签名。
在这里插入图片描述
至此,仅实现了归责,并没有实现惩罚。且没有将合同强制在比特币网络上。此时,Bob仍然需要信任Alice不会将old Commitment transaction广播上链。而一旦Alice真的将old Commitment transaction广播链的话,Bob是有能力判断出来的。

2.5 创建具有合约撤销功能的通道

为了从实践上加强合同条款,有必要构建 可撤销交易 的Commitment transaction。这种撤销可以通过使用数据来实现,如交易何时进入区块链并使用交易的成熟度以确定验证路径。

2.6 sequence number maturity

Mark Freidenbach指出,可通过软分叉,借助父交易的相对区块成熟度来实现sequence number。可保证某种类型的相对block confirmation time lock on the spending script。
Revocable Sequence Maturity Contract (RSMC) 中会创建2个path,具体的合同条款为:
1)所有参与方都pay into a contract with an output enforcing this contract。
2)两方可达成共识将资金发送给某合约,有一定的等待期限(如1000个确认)。这就是可撤销的output balance。
3)两方或一方可选择直到某个未来时间才广播某些payouts。任意一方在过了等待期之后,可随时将其资金赎回。
4)若任意一方广播了其赎回资金的交易,当且仅当双方都达成共识,才能将以上支出撤销。当合约对外公开且广播上链后,新的交易支出将立即赎回。
5)当合约公开时,新的payout structure将不可赎回,之前撤销的合同条款可由任意一方赎回(即任意一方都可执行新条款)。

2.6.1 Timestop

Timestop可缓解链上的大量恶意攻击问题。
当设置了timestop位时,所有使用nSequence值的交易都将停止计数,直到timestop位设置被取消。这样就有足够的时间和block-space,使当前辅助tiemstop block height中的交易来上链,从而可有效防止系统性攻击。

为了完全兼容SPV(Simple Payment Verification; lightweight clients),在区块头中需要80个字节来存储。

2.6.2 可撤销的Commitment transactions

将归责和可撤销交易结合,一方可在不信任另一方的情况下,判断其是否遵守了合同协议,并对其进行惩罚。
在这里插入图片描述

2.6.3 从通道中赎回资金:合作的交易对手方

任意一方都可从通道中赎回资金。但是,广播Commitment transaction的那方需等待在RSMC中预设的确认数。而未广播Commitment transaction的一方则可迅速将资金赎回。
在这里插入图片描述
当Commitment transaction (C1b) 上链 1000个区块之后,Bob可广播Revocable Delivery transaction 上链。若某方试图在1000个区块之前让Revocable Delivery transaction上链,则该交易会保持失效状态,(若该output未赎回)直到1000个确认过后才会变为有效状态。当Revocable Delivery transaction广播上链后,Alice和Bob之间的通道就完全关闭了。双方也都收到了通道内双方达成共识的current balance中的资金。
在这里插入图片描述

2.6.4 创建新的Commitment transaction并撤销之前的Commitments

当需要将通道内Alice 0.5BTC/Bob 0.5BTC 更新为 Alice 0.4BTC/Bob 0.6BTC,则双方在达成共识的情况下会生产一组新的Commitment transactions——C2a/C2b。
在这里插入图片描述
同时,需要对old Commitment transaction (C1a/C1b) 进行失效操作:

  • 双方对一个Breach Remedy Transaction (违约救济交易,BR1) 进行签名,替代了之前的Revocable Delivery Transaction (RD1)。

Breach Remedy Transaction (违约救济交易)可将通道中的当前balance中的所有金额都发送给交易对手方。即,若Alice和Bob生成了一组新的Commitment Transactions(C2a/C2b),同时使之前的Commitment (C1a/C1b) 失效。若稍后Bob错误地将C1b广播上链,则Alice可获得Bob在该通道内的所有钱——因为Bob已向Alice保证了永远不会广播C1b,一旦其广播了C1b,则Alice可惩罚Bob获得其在通道内的所有资金——具体的实现方式为,为交易对手构建Breach Remedy transaction,使一方可向另一方保证永远不广播之前的commitments。而交易对手将欣然接受,因为一旦对方违背承诺,其将获得通道内的所有资金。
在这里插入图片描述
因此,当将Breach Remedy Transaction发送给对手后,其应删除所有之前的Commitment Transactions,因为一旦其发送了不正确的(deprecated and invalidated Commitment Transaction),其在通道内的所有资金都将作为罚金给对方。
即,若Bob广播了C1b,若在预设的区块数(如1000个区块)内Alice发现了Bob广播了错误的Commitment,此时Alice可通过广播Breach Remedy Transaction BR1b来获取通道内的所有资金。Breach Remedy Transaction 可证明Bob违背了承诺,且可由链上程序判决。
在这里插入图片描述
然而,若Alice未在1000个区块内广播BR1b,则Bob可偷掉一定的资金,因为其Revocable Delivery Transaction (RD1b) 在1000个区块后就有效了。即当广播了不对的Commitment Transaction,在1000个区块内,仅有Breach Remedy Transaction (BR1b) 可广播,而在1000个区块之后,Breach Remedy Transaction (BR1b) 和 Revocable Delivery Transaction (RD1b) 都随时可广播。因此,Alice应定期监测链上,是否其交易对手方广播了失效的Commitment Transaction?可将Breach Remedy transaction委托给第三方,给第三方一定的费用,让其代为监测链上。该第三方没有权限来强制关闭通道。

2.6.5 创建Revocable Commitment Transactions的流程

Commitment Transaction为P2SH交易,第一个Commitment Transaction来源于Funding Transaction,其output为一个单独的 m u l t i s i g ( P A l i c e F , P B o b F ) multisig(P_{AliceF}, P_{BobF}) multisig(PAliceF,PBobF) P A l i c e F , P B o b F P_{AliceF}, P_{BobF} PAliceF,PBobF仅用于make the Funding Transaction (F) spendable,在其它环节均无法使用。
Delivery Transaction为P2PKH交易或P2SH交易,具体由交易对手事先指定,具体output addresses由 P A l i c e D , P B o b D P_{AliceD}, P_{BobD} PAliceD,PBobD生成。为简单起见,这些output addresses 保持不变,如有需要,也可更新 P A l i c e D , P B o b D P_{AliceD}, P_{BobD} PAliceD,PBobD

双方可交换公钥,以便Commitment Transaction中的Revocable Sequence Maturity Contract (RSMC) 和 HTLC使用。
每组Commitment Transactions都应有其专用的公钥,且不可reused复用。可在构建通道时,双方通过BIP 0032 HD Wallet 交换Master Public Keys方式来知悉所有未来可用的公钥组。当需要生成新Commitment Transaction对(C2a/C2b)时,双方使用 ( P A l i c e R S M C 2 , P B o b R S M C 2 ) (P_{AliceRSMC2},P_{BobRSMC2}) (PAliceRSMC2,PBobRSMC2)来生成RSMC output。一旦双方知道Commitment Transactions的output values,则可:

  • 创建Commitment Transactions对,如C2a/C2b,但是此时并不交换对Commitment Transactions的签名。
  • 双方都对Revocable Delivery transaction (RD2a/RD2b) 签名,并交换相应的签名。
  • 当双方都有对方的Revocable Delivery transaction之后,双方会交换对Commitment Transactions的签名。
  • 此时C1a/C1b和C2a/C2b都可广播。为了使C1a/C1b失效,双方会交换对之前commitment C1a/C1b 的Breach Remedy Transaction (BR1a/BR1b) 签名。当Breach Remedy Transaction (BR1a/BR1b) 签名完成交换后,通道状态变为了C2a/C2b,且balance也commit了。【相比于交换签名,直接给对方公开私钥的方式效率会更高。若Bob想要invalidate C1b,则他可将其在C1b中的私钥发给Alice。注意Bob不能暴露其在C1a中的私钥,否则其资金将可被窃取。同时,Alice也可将其C1a outputs中的私钥发给Bob来invalidate C1a。若Bob不小心广播了C1b,由于Alice有C1b outputs中的所有私钥,Alice可拿到所有的资金。为了避免币被盗的风险,Bob应销毁所有的old Commitment Transactions。】

2.7 合作关闭通道

当某一方想要合作关闭通道时,他可以联系另一方,通过spend from the Funding Transaction with an output of the most current Commitment Transaction directly with no script encumbering conditions——发起Exercise Settlement Transaction (ES)。然后,在该通道内就不能发起任何支付行为了。
在这里插入图片描述
合作关闭通道的目的是:

  • 减少链上记录的交易数。
  • 双方均可快速收到相应的资金。(而不需要某一方等待Revocation Delivery transaction为valid)

2.8 Hashed Timelock Contract (HTLC)

双向支付通道仅能保证通道内资金交易的安全。为了实现通道网络中 跨多个hops的资金的安全传输,需要额外借助Hashed Timelock Contract (HTLC)。

HTLC的目的是借助hashes来实现多个节点间的全局状态。该全局状态由以下内容实现:

  • time commitments
  • 以及通过公开preimages 实现的time-based unencumbering of resources。

交易性的"locking"通过commitment 全局发生,某单一的参与者负责给下一参与者公开其have knowledge of the preimage R。这种方式不需要信任某通道内的交易对手,也不需要信任网络中的任意参与方。

为此,HTLC必须:

  • 使用nLockTime,创建在特定时间之后才有效的交易。
  • 公开给通道交易对手的信息。

同时,以上整个过程应为可撤销的,即某人必须能撤回一个HTLC。

2.8.1 构建不可撤销的HTLC

在这里插入图片描述
这种构建方式存在的问题是,当达到nLockTime后,两条path都是valid的,此时Bob可窃取Alice的资金。
若交易对手不配合,以上方式无法在不广播上链的情况下关闭HTLC。

2.8.2 链下可撤销HTLC

为了实现可在不广播上链的情况下在链下关闭HTLC合约,需在output中嵌入RSMCs,具体构建方式与双向通道类似。
在这里插入图片描述
每个HTLC中每个transaction(C2a 和 C2b)有4个key,即对于每个交易对手一共有8个key。

2.8.3 链下关闭HTLC

一旦HTLC创建后,需双方对通道内的状态都认可后,才能链下关闭HTLC。
在这里插入图片描述

2.8.4 HTLC的生成和关闭顺序

在这里插入图片描述

3. 闪电网络中的multi-hop payment

闪电网络的核心技术为:微支付通道(即RSMC) + 具有hashlocks和timelocks的合约(即HTLC,有条件支付)。
借助该核心技术,可使用一系列的decrementing timelocks的方式,在无需中心化清算所的情况下,清算multi-hop payment网络中的交易。【Bitcoin Transaction Scripting,可称为某种意义上的智能合约,允许不需要可信监管清算所或监管服务的。】

在比特币中,仅对不合作的交易才需要在链上自动裁决。
通过链式委托,可将资金传送到最终的接收方。在链式委托路径上的参与者,假定其都有义务传输至一个特定的接收者,具体定义在各自的HTLC中,且后续环节的时间应小于前序环节的时间,从而使每一个参与者都确信当完成传输义务时能获得相应的资金。

在这里插入图片描述
在这里插入图片描述
disclose R 拉取资金的流程为:Step 4、5、6。
当委托路径有人断开时,其交易对手方将负责将当前的Commitment Transaction state广播上链。只有失败的无响应的通道状态才会在链上关闭,而所有其他通道将继续根据通道内novation机制更新其Commitment Transaction。因此,交易费的问题仅发生在直接通道的交易对手方。
当委托路径上的某一节点决定不响应时,不与该节点直接相连的参与者,仅需关注的是在HTLC关闭之前去资金的decreased time-value无法尽快结算。
在这里插入图片描述
推荐对每个HTLC都使用小额支付,不要使用大额支付,以防资金无法完整路由到最终的目的接收方。若资金无法到目的接收方,且路径上的某一参与者不配合,则sender必须等到expiry之后才能拿回资金。就像网络上的包传输一样,传输过程可能会有损,但是应无法在传输过程中窃取资金。

当前需要平衡:

  • 在每个hop的locking up transaction fees
  • 和 使交易量尽可能小(更大的交易量意味着更高的费用)

在更多的中间人中进行更小的传输,意味着给中间人更高比率的闪电网络费用。
当交易无法到达最终的目的地时,receiver可以相同的hash发送等额的支付给sender,但是不公开相应的R。这将有sender来公开该hash而不再由receiver来公开。生成该hash的receiver,应丢弃该R值,且永远不广播R。若路径上的某一通道无法连接,则在path过期后会选举新的通道。path过期时,所有的参与者都将以未结算的方式关闭通道,不再有对应支付的新Commitment Transaction。
在这里插入图片描述
在这里插入图片描述

3.1 支付路由

理论上,可通过观察链上的2-of-2 multisigs来构建路由表。但是,对于P2SH transaction outputs——由第三方路由服务来解决比特币协议中out-of-band,无法获取相应的路由信息。因此,有必要借助大的合作厂商来构建完整的路由表。

但是,不是网络中的所有参与者都有必要拥有一张全量的路由表。核心的Tire-1 routes需保持一直在线,而对于边缘节点(大多数用户),可间歇性连接。

边缘节点的节点发现可通过预选和部分知名节点路由的方式来实现。

3.2 闪电网络的费用

闪电网络的费用不同于区块链的交易费,闪电网络的费用直接支付给通道内的参与者。
闪电网络费用的组成为:

  • pay for the time-value of money for consuming the channel for a determined maximum period of time。而the time-value of fees pay for consuming time (如3天),类似于无保管风险的黄金租赁利率。同时,由于可能特定路径的某一个方向是非常赚钱的,则该fee可能为负数,以吸引赚钱的路径使用本通道。
  • pay for counterparty risk of non-communication。counterparty risk fee仅存在于某人的直接通道交易对手。【占闪电网络费用的大头。】

4. 闪电网络的风险

闪电网络的主要风险来源于timelock过期。此外,对于核心节点和可能路由资金的供应商,其keys需以短延时的方式保持在线。而对于终端用户和节点,可将其私钥保存在冷钱包中。

4.1 不合适的Timelocks

参与者必须选择具有足够time的timelocks。若timelocks不够,则被认为invalid的timelocked transaction会变成valid的,从而使得交易对手可窃取币。
因此,需要在longer timelocks和the time-value of money之间进行权衡。实际应考虑不合作或想作弊的通道参与者。

4.2 强制的expiration spam

闪电网络中的另一个风险是恶意攻击导致的拥堵。若支付通道变得拥堵,参与者可能无法快速将钱取回。
Dryja认为:“闪电网络中,大量交易的强制过期可能会是最大的系统风险”。
若有人恶意创建多个通道,然后使其同时强制过期,这将向区块链广播,造成的拥堵可能会压倒区块链的容量。恶意攻击者可能利用拥堵来窃取由于拥堵而无法提取资金的各方的资金。

大量交易的强制失效是闪电网络中最大的系统风险。
若某个恶意参与方创建了大量通道,且强制其同时失效,则会产生极大的区块数据需广播上链。从而导致比特币上大量的垃圾邮件。这些垃圾邮件将影响当时需处理的其他交易,从而使其他locktimed transaction become valid。
可通过一些反垃圾邮件措施来解决,如允许一个交易来替代所有的pending交易。

4.3 通过Cracking来盗币

由于所有参与者均需保持在线,并使用私钥签名,若某一私钥被盗,则相应的资金也会被盗。
可通过创建Checking Account和Savings Account的方式来提升安全性。

4.4 data loss

当一方丢失数据,则交易对手方可能可窃取资金。可通过将data加密存储在第三方服务的方式,来缓解。同时,在构建通道时,应周期性测试对方的忠诚度。

4.5 忘了及时广播交易上链

若某一方忘了在正确的时间将交易广播上链,则交易对手可能可窃取资金。可委托第三方来发送资金,并额外添加ouput fee鼓励第三方监测网络。

4.6 无法进行必要的软分叉

功能升级,可能需要进行软分叉。软分叉时需保证所有交易者的资金安全。

4.7 矿工串通

如矿工可串通拒绝特定的交易,如Breach Remedy 交易,以助力timeout coin theft。

4.8 未能完全解决比特币交易费用高的问题

闪电网络经常被吹捧为比特币交易费上涨问题的解决方案。它的支持者声称,交易费用是比特币堵塞网络的直接后果之一,在该技术将交易从主要区块链上剥离后,交易费用将下降。但比特币的拥堵是影响其交易费用的诸多因素之一。
引入闪电网络,则有:

  • 开关通道的费用。其费用与比特币交易费相当。尽管闪电网络支持双方支付,但是opening transaction或存款必须通过链上进行,然后双方可进行多笔交易,但一旦账单结算完毕,需要在链上以closing transaction的方式记录结算金额。
  • 路由费用。在不同通道之间传递支付需要单独的路由费。

4.9 要求闪电网络中的节点随时保持在线

为了发送和接收支付,比特币闪电网络中的节点必须随时保持在线。
离线会在闪电网络中产生一系列问题。如支付通道中的一方有可能关闭该通道,并在另一方不在的情况下将资金存入口袋。这就是所谓的欺诈通道关闭。对于关闭通道有一个异议期限,但是若其中一方长期缺席可能导致该期限过期。

5. 闪电网络的未来

闪电网络2021年生态全览:
在这里插入图片描述
根据BitFinex 2020年1月博客 The Lightning Network Journey: an overview,当前闪电网络的相关开发有:

  • 互操作性方面:有Submarine Swaps、Atomic Swaps、Splicing
    – Submarine Swaps:支持从比特币区块链链上直接向闪电网络通道注入资金,从而使得实现Submarine Swaps成为可能。未来也将支持从链外闪电网络通道向链上BTC地址的反向交易。
    – Atomic Swaps:通过允许跨区块链交易,提高了LN跨区块链的互操作性。
    – Splicing:致力于解决闪电网络的低效问题,即——禁止用户提取或增加已分配给通道内的资金,以及需要先关闭通道才能使用资金。Splicing的工作原理是允许相关方直接从渠道注资或提取资金,而无需经过常规程序。
  • 安全和隐私方面:有Watchtowers、Eltoo、Neutrino
    – Watchtowers:为用于监控交易通道而添加的新功能,从而降低不诚实方窃取资金的风险。
    – Eltoo为改进闪电安全的另一解决方案,它通过防止由软件问题引起的错误警报来工作,否则会导致资金损失。
    – Neutrino:为支付验证协议,允许在客户端执行该程序。
  • 效率方面:有Autopilot、Trampoline Payments、Dual-funded channels、Atomic Multipath Payments (AMP)
    – Autopilot:为闪电网络中提出的一种新的路由选择方法,将大大减少当前流程在网络上路由支付所需的计算量和数据量。
    – Dual-funded channels:双资金通道功能允许用户在通道开通后直接发送支付,而无需等待对方发回支付。
    – Atomic Multipath Payments (AMP):AMP将闪电网络上的大型交易划分为较小的交易,从而使LN作为一个支付处理器更加可行。

5.1 更大的通道以支持更大的支付金额

闪电网络早期通道大小设计为最大0.1677BTC,但在2020年,该限制已取消使得用户可拥有更大的通道。这些“Wumbo”通道旨在为消费者和企业提供更高的可用性。

5.2 用于加密货币交易所

2020年12月,Kraken交易所宣布将于2021年开始支持闪电网络。

5.3 使用Watchtower

Watchtower为运行在节点上第三方,用于防止闪电网络中的欺诈行为。
如,萨姆和朱迪正在进行交易,其中一人有恶意,他们可能会从另一个参与者那里偷硬币。假设萨姆和朱迪先存了1万比特币,然后进行了3000英镑的交易,萨姆从朱迪那里购买了商品。如果朱迪注销她的系统,就有可能被诈骗。Sam可以广播初始状态,这意味着他们都可以拿回初始存款,就好像没有进行任何交易一样。换言之,萨姆将免费获得价值3000 BTC的商品。

基于初始状态和完成所有交易的最终状态关闭通道的过程称为欺诈性通道关闭。Watchtower或第三方可以监控交易,帮助防止欺诈性通道关闭。

6. 闪电网络应用

闪电应用的经典架构为:
在这里插入图片描述
目前一些经典的Bitcoin Lightning Network Apps (LApps) 有:

  • Lightnite:为类似Fortnite的在线游戏,在游戏中以可获得比特币奖励。
  • LNTXBOT:为Telegram中集成的闪电钱包。
  • Tippin:为谷歌和火狐浏览器扩展程序。允许通过Twitter的闪电网络来收发 bitcoin tips。
  • ZEBEDEE Infuse:为比特币版的CS:GO游戏。
  • LNSMS.World:通过支付比特币的方式来发送消息。

参考资料

[1] Bitcoin’s Lightning Network: 3 Possible Problems
[2] Lightning Network —— Scalable, Instant Bitcoin/Blockchain Transactions
[3] The Bitcoin Lightning Network
[4] Thaddeus Dryja 和 Joseph Poon 2016年论文 《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments》
[5] Egger等人2019年论文《Atomic Multi-Channel Updates with Constant Collateral in Bitcoin-Compatible Payment-Channel Networks》
[6] Multiparticipant CoinSwap——S6
[7] 闪电网络相关资料库,很全!
[8] 维基百科 Lightning Network
[9] BitFinex 2020年1月博客 The Lightning Network Journey: an overview
[10] BitFinex 2020年2月博客 Understanding the Lightning Network
[11] Ventures medium 2021年3月博客 An Overview of Lightning Network Implementations
[12] 5 Bitcoin Lightning Network Apps (LApps) We Love

这篇关于Bitcoin的闪电网络的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/738698

相关文章

【Altium】查找PCB上未连接的网络

【更多软件使用问题请点击亿道电子官方网站】 1、文档目标: PCB设计后期检查中找出没有连接的网络 应用场景:PCB设计后期,需要检查是否所有网络都已连接布线。虽然未连接的网络会有飞线显示,但是由于布线后期整板布线密度较高,虚连,断连的网络用肉眼难以轻易发现。用DRC检查也可以找出未连接的网络,如果PCB中DRC问题较多,查找起来就不是很方便。使用PCB Filter面板来达成目的相比DRC

通信系统网络架构_2.广域网网络架构

1.概述          通俗来讲,广域网是将分布于相比局域网络更广区域的计算机设备联接起来的网络。广域网由通信子网于资源子网组成。通信子网可以利用公用分组交换网、卫星通信网和无线分组交换网构建,将分布在不同地区的局域网或计算机系统互连起来,实现资源子网的共享。 2.网络组成          广域网属于多级网络,通常由骨干网、分布网、接入网组成。在网络规模较小时,可仅由骨干网和接入网组成

Toolbar+DrawerLayout使用详情结合网络各大神

最近也想搞下toolbar+drawerlayout的使用。结合网络上各大神的杰作,我把大部分的内容效果都完成了遍。现在记录下各个功能效果的实现以及一些细节注意点。 这图弹出两个菜单内容都是仿QQ界面的选项。左边一个是drawerlayout的弹窗。右边是toolbar的popup弹窗。 开始实现步骤详情: 1.创建toolbar布局跟drawerlayout布局 <?xml vers

使用 GoPhish 和 DigitalOcean 进行网络钓鱼

配置环境 数字海洋VPS 我创建的丢弃物被分配了一个 IP 地址68.183.113.176 让我们登录VPS并安装邮件传递代理: ssh root@68.183.113.176apt-get install postfix 后缀配置中的点变量到我们在 DigitalOcean 中分配的 IP:mynetworks nano /etc/postfix/main.cf

Linux网络编程之循环服务器

1.介绍 Linux网络循环服务器是指逐个处理客户端的连接,处理完一个连接后再处理下一个连接,是一个串行处理的方式,比较适合时间服务器,DHCP服务器.对于TCP服务器来说,主要阻塞在accept函数,等待客户端的连接。而对于UDP服务器来说,主要阻塞在recv函数. 2.循环服务器模型 TCP循环服务器: 算法如下:          socket(...);

Linux网络编程之简单并发服务器

1.概念 与前面介绍的循环服务器不同,并发服务器对服务请求并发处理。而循环服务器只能够一个一个的处理客户端的请求,显然效率很低. 并发服务器通过建立多个子进程来实现对请求的并发处理,但是由于不清楚请求客户端的数目,因此很难确定子进程的数目。因此可以动态增加子进程与事先分配的子进程相结合的方法来实现并发服务器。 2. 算法流程 (1)TCP简单并发服务器:     服务器子进程1:

Android 扇形网络控件 - 无网络视图(动画)

前言 一般在APP没有网络的情况下,我们都会用一个无网络的提示图标,在提示方面为了统一app的情况,我们一般使用简单的提示图标,偶尔只需要改变一下图标的颜色就一举两得,而不需要让PS来换一次颜色。当然app有图标特殊要求的就另当别论了。 效果图 当你第一眼看到这样的图,二话不说直接让UI给你切一张图标来的快对吧,我其实开始也是这么想的,但是到了做的app越来越多的时候,你就会发现就算是用

poj 2391 Ombrophobic Bovines (网络流)

这是一道很经典的网络流的题目。首先我们考虑假如我们的时间为无穷大。我们吧每个点拆成2个点 i和i' .。虚拟源点s和汇点t。对于每个点建边(s,i, a[i])  (i‘,t,ib[i]) 。 其中a[i]为给点有多少牛,b[i]为容量。i和j连通 建边 (i,j',inf);如果最大流==所有牛的个数,就可能装下所有的牛。那么现在我们考虑时间。假设最大时间为T.那么如果i到j的的最短时间>T

加载网络图片显示大图

1.将图片的uri列表和下标传给ImagePagerActivity public void imageBrower(int position, ArrayList<String> urls2) {Intent intent = new Intent(this, ImagePagerActivity.class); intent.putExtra(ImagePagerActivity

ESP32使用按键配网并通过LED指示网络状态

前言 上面我们已经可以通过 ESPTOUCH 和 Airkiss 给模块配网,并且存储在 nvs 中,重启后仍然可以联网,只是这样仍然不能满足我们实际的应用,这次我们增加按键作为输入,LED作为输出,实现长按按键配网,并可以通过LED指示网络状态。 添加自己的组件 为了让程序结构更加清晰,所以我们在smart_config例程的基础上做了修改,在main文件夹里新建了main.c 、smar