闪电网络:技术与用户体验(五):流动性获取

  • BTCStudy
  • 更新于 2024-03-06 11:27
  • 阅读 549

介绍获得入账流动性的方案。

作者:Anony

前篇见此处

在本篇中,我们将介绍让节点获得入账流动性(收款额度)的方案,并介绍这些方案在闪电网络终端用户所用的实现上的演化。

早在本系列第一篇中,我们就提到,出于 “通道(共有资金)” 的特性,“收款额度” 的概念是无法逃避的。而每个用户都有可能遇上想要收款却没有额度的情形。

这个问题因为闪电网络早期实现的一个设计而变得更加严峻 —— 单向注资。

单向注资

虽然在我们之前使用的例子中,都把通道双方都有余额作为通道的初始状态,但实际上,最早实现的通道注资方法是 “单向注资” —— 在参与通道的双方中,仅有一方为通道提供资金。如此一来,在一开始,双方得到的都是不平衡的通道:一方仅有支付能力(而无收款能力),而另一方又仅有收款能力(没有支付能力)。

这种设计有一些优点:易于实现、安全性检查更加简单(双向注资所需的额外安全性检查可见 ^1;尤为重要的是,它更适合网络的启动。在一个新节点要加入网络时,它可能会选择跟一个已知的老节点开设通道,然而,对后者来说,却难以决定要不要在其中锁入流动性:如果这个新节点只是尝试一下,很少在线,那么,锁入其中的资金就无法获得收益。而单向注资使得该节点根本不必有此担忧:新节点会自己锁入资金,而不要求老节点提供任何初始资金。

但是,这也意味着,收款额度的获取成了所有新节点的难题 —— 不论你想做一个转发节点,还是将闪电网络用于日常使用。

截至本文撰写之时(2024 年 2 月),已经有两个闪电网络客户端(Core Lightning 和 Eclair)实现了 “双向注资(dual funding)”,也即在创建通道时,双方都可以为通道提供资金。在一些条件下,这可以节约一个节点要创建平衡的通道的步骤。

“双向注资” 的详细介绍可见这个页面 ^2

接下来我们要介绍的是获得入账流动性的方案。概要来说,这样的方案可以分成两大类:一类的原理是向外支付;另一类的原理是请求他人向自己开设不平衡的通道。

潜水艇互换

“潜水艇互换(submarine swap)” 是第一类方案的代表。其想法是,需要入账流动性的节点将自己在闪电通道中的资金通过 HTLC 置换成链上资金;在向外支付的同时,该节点也就获得了入账流动性。

用户在闪电网络中给互换服务商支付,互换服务商在链上给用户支付,这就是潜水艇互换;而 HTLC 可以保证互换的免信任性。不过,由于这个过程涉及链上支付,它在实现中会遇到一些难题,从而一定程度上需要一些信任。我们用详细的互换流程来分析:

  1. 用户向服务商请求互换;服务商提供自身的闪电网络位置;
  2. 用户生成一个原像及其哈希值,使用该哈希值构造用于闪电支付的 HTLC;当支付转发消息到达服务商时,服务商使用相同的哈希值,在链上创建一个 HTLC 输出;
  3. 用户发现该链上 HTLC 输出得到确认之后,就使用哈希原像申领其中的资金;该原像也就暴露给了服务商;
  4. 服务商使用原像领取闪电网络中的 HTLC。

从第二步开始,服务商需要信任用户,因为 TA 需要创建一个链上输出。如果这时候用户突然反悔,或本来就有意作恶,不在链上释放原像,那么服务商就亏掉了为创建这个链上输出而需支付的手续费。也正因此,在一些服务中,服务商会要求用户预付一定的费用,在完成互换之后退款,但从原理上说,这又变成了用户需要信任服务商。

潜水艇互换在实践中的另一个困难是,它需要用户的钱包也有相应的支持。用于给用户支付的 HTLC 并不是常见的单签名输出,用户的钱包必须能够理解 HTLC 的脚本、懂得为其构造见证数据(witness),才能花费其中的资金。当前,将自身定位为 “比特币钱包” 的钱包软件几乎都无法提供这种支持,但一些 “闪电钱包” 则可以做到。未来,这需要依靠 Miniscript 这样的技术来提供更好的互通性 ^3

潜水艇互换可能是最早出现的入账流动性获取方案,也启发了许多后来者。其中一种是 “PeerSwap”,直接跟你的通道对手实施潜水艇互换 ^4。还有一种叫 “环路支付(circular payment)”,就是规划出一条环状的路径,将自己在 A 通道中的余额转移到 B 通道 ^5

潜水艇互换还有一种有趣的用法:你可以用闪电网络中的资金给他人支付链上比特币。此外,它也可以反向运行:将链上的比特币 “充值” 到自己的闪电通道中,以增加支付能力,无需 关闭通道-重新打开通道。

当前,如果你使用 LND 客户端来运行闪电节点,你可以使用搭配的 Loop 客户端来使用潜水艇互换功能。

通道租赁

获得入账流动性的另一种办法是租赁通道:请求他人用自己的资金与你开设一条通道(当然,你需要支付一些费用)。对方投入的资金即是你立即获得的收款额度。

请注意 —— 你并没有借他的钱,钱依然在他手上,只不过形式从链上资金变成了链下(某一条通道中的)资金;当你在这条通道中收到支付时,他必定在另一条通道中得到了 相同数额+转发费用 的支付。

显然,这种通道租赁需要让通道保持一段时间,否则出租方就可以收钱不办事 —— 在收到租金之后立即关闭通道。但是前面介绍的闪电通道构造似乎并没有对通道存续时间的保证。难道又只能引入信任了?

事实上,如果你了解比特币的脚本,你会发现,有一种很简单的办法可以保证出租方会让通道持续一段时间。假设租赁方 Alice 要求出租方 Bob 与自己开设一条通道,那么,Alice 可以在自己签名的承诺交易中,为所有给 Bob 支付的输出(包括普通的输出和 HTLC 输出的相应花费分支)都加入绝对时间锁,时间锁的过期时间是双方约定的合约结束时间。也即,即使 Bob 拿着最新的承诺交易退出通道,如果未过合约期限,这些资金也会一直锁定、无法动用。这就完全打消了 Bob 提前关闭通道的激励 —— 资金放在通道中还有可能产生收益,但关闭通道会导致字面意义上的 “冷藏”。早在 2018 年,就有开发者提出了这样的想法 ^6

通道租赁的想法简单又直接。甚至移动端的自主保管钱包 Breez 也在 App 中提供了向著名的服务商租赁通道的入口。

最初,提供此类服务的都是著名的公司,而且流程中很可能需要信任。于是,人们想出了更多方法来降低参与的门槛、增加市场的竞争。

Lightning Pool

Lightning Pool 是 Lightning Labs 推出的一种通道租赁拍卖市场。用户可以使用 LND 客户端和搭配的 Pool 客户端来参与。其基本特性是:

  • 市场需要一个中介(或者说拍卖行),来保证各方诚信行事。
  • 流动性的需方和供方,都要各自与拍卖行创建一个 “账户”,并把钱存进去。这样的账户在比特币链上是一个输出,它有两个花费分支:一是户主与拍卖行的 2-of-2 多签名;二是户主单签名 + 绝对时间锁。
    • 这样的输出保证了:拍卖行无法独自转移户主的资金,而且资金的所有行动都要经过户主的同意,并且,在一段时间之后,户主总能单方面转移其中的资金。所以,这样的账户是免信任的。并且,当户主提出自己的订单要求时,拍卖行可通过要求户主的签名,来保证这样的 出价/要价 是诚实的。
  • 拍卖是供方和需方各自叫价、但叫价仅向拍卖行公开的盲拍。拍卖行会在确保供需匹配之后,以区块为时间间隔清算市场;并且,在同一区块中成交的所有订单,每一单位的资金将收到相同的租赁价格。
  • 拍卖行在链上会用一笔交易,批量处理该区块内所有成交的订单。
  • 订单成交之后,供需双方创建闪电通道,并且,将使用上文所述的技巧来保证通道会在合约期内持续存在。

Lightning Pool 是一种有趣的尝试。它用一个半公开的市场解决了流动性供需匹配的问题,还为比特币资金提供了一种按区块计量的利息率(当然,所有的通道租赁解决方案都有这个效果)。

Lightning Pool 的技术详述可见他们的论文 ^7

Liquidity Advertisement

“流动性广告(Liquidity Advertisement)” 是 Blockstream 提出的一种技术,其核心是让流动性的供方可以用闪电节点的 gossip 消息(本来用于宣布新通道、新节点的消息,相当于整个闪电网络的公开频道)来播报自己的要价以及通道的持续时间。接受这个价格的闪电节点可以与之用双向注资方法开启通道、获得入账流动性。租赁方为通道提供的输入会立即用来支付租赁费。

当前,仅有 Core Lightning 客户端为 Liquidity Advertisement 提供了实验性支持。

零确认通道

上述两种方案,显然更适合于网络中的转发节点,以及有经验有技能的用户,却不适合于移动设备的用户(可以操作的界面更为有限),更不适合刚解除闪电网络、对技术了解不多的用户。因此,我们要专门一些适合刚入门用户的方案(并且假设他们会使用移动端 App,而不是电脑软件)。

“零确认通道(Zero-conf channel)”(也称 “零配置通道”、“涡轮通道”)的想法是,通过引入有限的信任,一举解决入门用户的两大问题:(1)创建通道需要等待;(2)新建通道没有入账额度。

办法如下:用户将比特币资金发送给服务商,服务商负责对用户开启通道(单向注资),并在通道内将扣除服务费之后的剩余资金转移给用户;并且,双方都视这条通道为立即可用,而无需等待通道注资交易得到区块确认。

显然,这个过程需要用户信任服务商:假定用户将资金转移给服务商之后,服务商拒绝执行后续步骤,那么用户并没有什么办法(只能到社交媒体上哭诉);其次,在通道注资交易获得区块确认之前,用户在通道内获得的支付都是不可靠的,因为服务商可以重复花费注资交易的输入。

但是,它解决了刚进入闪电通道的用户的一些痛点:首先,常规的闪电通道,在创建时需要让注资交易获得 3 次区块确认,用户才能开始支付,而零确认通道可以让用户立即开始闪电支付(用户的闪电支付,只要能获得收据,是可靠的);其次,这种通道由服务商创建(可能还加入了服务商自己的资金),所以用户从一开始就可以获得收款额度。因此,还是可以给用户带来显著的便利的。

而且,一旦零确认通道的注资交易获得区块确认,它就会逐渐转变成常规的闪电通道:用户拥有承诺交易所提供的保护,不再需要信任服务商。

显然,要求用户先将资金交给服务商,是双向注资技术缺位之时的无奈之举。有了双向注资之后,我们就可以优化它,让服务商和用户直接执行双向注资程序。这并不能缩减用户创建闪电钱包的时延,只是降低了所需的信任。至于 “零确认” 这段时间所要求的信任,则是无法消除的 —— 但我们都知道,这个环节所要求的信任,是有限的。

更富细节的描述可见此篇 ^8

许多移动端的闪电钱包都实现过零确认通道。不过现在,它已逐渐让位于一种更精致的零确认通道 —— JIT 通道。

JIT 通道与闪电网络服务商(LSP)

“JIT 通道”,顾名思义,是一种 “按需开设的通道”,它在零确认通道的基础上更进一步,但又可以说更加简单。

其思想是:仅当用户要接收支付、现有的收款额度又不够时,由服务商向用户开设新的通道,用户在新的通道里领取支付;并且,这条新通道也是 “零确认通道”,可以立即使用。

其技术实现也非常直接:当一个 HTLC 即将经由服务商到达用户,而用户的收款额度不够时;服务商就跟用户创建一个新通道,并用这个新通道内的资金来创建所需的 HTLC;此外,服务商还可以要求用户在某一条通道中创建一个使用相同哈希值的 HTLC,以支付服务费。一旦用户在新通道中用原像领取支付,服务商就不仅能获得该笔支付的转发费(像常规的闪电通道一样),还能获得用户支付的服务费。

相比于原本的零确认通道,JIT 通道的流程大大减少,但又保留了零确认通道对服务商的好处:甄别用户。因为需要在通道中锁定资金、为用户提供收款额度,服务商最担心的就是遇上试水的、不真实的用户。或者说,服务商需要甄别用户,以决定自己锁定的流动性的数量。而用户预先付出的资金数量、即将收取的资金数量,都为服务商提供了重要的参考。

除去 “零确认” 过程中的信任,JIT 通道也未完全消除信任需要,但它跟潜水艇互换一样,更偏向要求服务商信任用户:服务商必须垫付创建通道的区块确认费,但如果这笔支付是虚假的、用户不会放出原像,服务商就面临亏损。

在业内,有一个 “闪电网络服务商(LSP)” 的概念。其意思是,当用户与这样的服务商建立通道时,服务商可以自动地帮助用户管理通道(包括备份)和流动性,无需用户为之烦恼;此外,由于 LSP 时刻在线,也能为用户异步接收支付提供帮助 ^9 。即使这个概念不是由 JIT 通道激发的,JIT 通道也必定极大地完善了这个概念。

当前,许多自主保管钱包都提供了 LSP,包括 Phoenix 钱包和 Breez 钱包。其中,Phoenix 钱包还有专门的一个页面,让用户自己配置为接收一笔支付而愿意支付的服务费上限。当开设通道所需的实际费用超过这个限度时,LSP 将不会行动。

现如今,人们已经在讨论为 LSP 制定一套技术规范 ^10,从而允许人们使用相同的软件来获取不同 LSP 的服务,以强化 LSP 的市场竞争、保证用户的体验。

结语

目前,大部分移动端闪电网络用户的选择依然是托管钱包 —— 用户不掌握私钥,资金也得不到真实通道的保护,但无需关心收款额度、定期在线要求以及通道资料备份等所有事情的,闪电支付服务。显然,自主保管钱包的体验还没有说服足够多的人。但是,我们有理由相信它会继续进步。上一篇文章所述的收款码的进化是一个例子。本篇所述的零确认通道的进化也是一个例子。

在下一篇文章,我们将介绍让用户能够更自由地应对支付和收款需要,不必关心资金形式的技术。它们改善了用户的支付能力,并且直观地展现了形式不同、本质相同的资金的深层一致性 —— 只有一种比特币。

(未完)

脚注

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
BTCStudy
BTCStudy
江湖只有他的大名,没有他的介绍。