2021-08-17 22:51 | 出处: EthFans
几个星期以来,比特币社区的很多人一直在讨论闪电网络(Lightning Network)的 inbound capacity 问题。越来越难以收到闪电火炬,加上 Bitrefill 启动了 Thor,还有 LND 放出了 Lightning Loop,都让人们更加关注这个问题。在本文中,我会解释这个问题的形式及其根源。我们也会分享一些很容易被忽略的洞见。
要理解入账容量,我们得先深入了解闪电网络的第一个基本模块:支付通道。这个概念可能你在之前也听过了,所以我们直接跳到跟入账容量有关的部分。
我们先考虑一个单独的通道,然后慢慢提高思考的复杂度。
一个支付通道开通后,它就锁住了恒定数量的一些 btc,这个数量叫做 “ 通道容量 ”。参与支付通道的双方各自拥有这个容量的一部分。在你自己这边的余额,我们叫 “ 本地余额 ”,而在你的交易对手那边的余额,叫 “远端余额 ”。你的本地余额和远端余额在关闭通道之前可以更新任意次,但通道容量,如果你不关闭通道或者拼接通道,是无法改变的。
每次支付,都是把你的本地余额转一些给你的交易对手,也就是减少本地余额,增加远端余额。类似地,当你收到一笔支付时,你的本地余额增加,数额恰好等于你的远端余额减少的数额。
现在,我们更清楚地理解了什么决定了通道的容量,以及本地和远端余额是怎么更新的,现在来想想,如果你是一个闪电网络的节点,是网络的一部分,将有何区别。
两个交易方并没有直接相连的支付通道。但是,他们可以通过 路由节点 来支付。在整个支付路径上,每一次中转都要用到一个双向的支付通道。因此,我们刚刚讲到的支付通道特性适用于每一次中转。
假设你想通过闪电网络来卖贴纸。那么,你需要与至少一个闪电网络节点建立连接。你仔细挑选了一个节点,保证这个节点可能跟你的潜在客户 Sophie 和 Angela 相连。我们把这个节点叫做 “lnTop”。
现在,Angela 想要买一些你的贴纸,并通过 lnTop 来支付。但是,你跟 lnTop 的通道中,你的远端余额是 0 呀,lnTop 并不能给你支付。因此,lnTop 无法路由这笔交易。
在一个时间点上,你可以收到的 btc 数量(也就是 “入账容量”),是由你的远端余额决定的。很简单嘛,如果你相连的节点只能发送 1 btc 给你,你是没法收到比 1 btc 更大的数额的。类似地,你可以发送的 btc 数量(“出账容量”)是由你的本地余额决定的。
在你决定跟 lnTop 开启一个通道时,你需要确定自己想锁定多少 btc 进去,也即你初始的本地余额是多少。lnTop 也一样,他们的选择决定了你初始的远端余额。这就有了一个重要影响。虽然你能够决定自己的初始本地余额(自己的初始出账容量),但你没法控制自己的初始远端余额(和入账容量)。
如果你今天要启动一个自己的闪电网络节点,并且只是随随便便地选了一个节点来开启通道,你可能会发现,你根本没有入账容量可用,即,你压根没法通过闪电网络来收到支付。听起来对商人很不友好,对不对?
好消息是,你有很多办法来提高自己的入账容量,比如自己先发起支付,或者请求其他节点提供容量(并付钱给他们)。这篇文章讲解了入账容量问题的不同解决方案。
嗯 …… 也不是。即使你知道了自己如何能提高远端余额,可能也没法解决入账容量问题。关键在于:并非所有通道的入账容量都相同。要理解这一点,你要先理解,在支付路由的过程中,闪电网络的其它部分,发生了什么事情。我们把上图所示网络的通道容量都划出来,这样更好理解了。
你从 lnTop 那里获得一些入账容量之后,Angela 最多也只能给你发 2 btc,因为你在 lnTop 那里的入账容量超过了 2 btc,但 lnTop 在 Angela 处的入账容量只有 2 btc。
原文链接:
https://blog.muun.com/the-inbound-capacity-problem-in-the-lightning-network/
作者: Florencia Ravenna