闪电网络:技术与用户体验(六):只有一种比特币

  • BTCStudy
  • 更新于 2024-03-06 11:33
  • 阅读 1481

介绍一系列的技术和解决方案,允许闪电钱包只保留一种形式的资金、只展示一种余额,同时保留跟一切钱包交互的能力。

作者:Anony

前篇见此处

在前面的文章中,我们一直在讨论,如何优化闪电网络,并通过技术的进步来为用户提供更好的体验。但有一个 “简单的” 问题我们一直没有触及:在闪电钱包用户的日常生活中,可能既需要发起闪电支付,也需要发起 “链上支付” —— 具体来说,就是让一笔交易获得区块确认,或者说,在比特币网络中创建一个新的 UTXO;既需要利用闪电网络来收款,也需要接收链上支付。

最初的闪电网络客户端实现(包括:Eclair、Core Lightning 和 LND)都同时管理链上资金和闪电通道资金。而且那时候,“链上资金” 与 “闪电通道资金” 是泾渭分明的,互相不能直接用于对方的支付:如果你要发起一笔链上支付,你无法直接动用闪电通道内的资金,你必须先退出通道,然后再发起链上支付(这其中的时延高得令人发指)。链上资金自然更无法直接用于闪电支付。也正因此,当时的用户界面(第三方的钱包软件以及操作工具)也往往将链上余额与通道内余额分开展示。

显然,这很不便利,是不理想的。它会在用户的同一个钱包(使用同一批私钥可控制的资金)内部形成流动性的分割、影响用户的支付能力,并且制造很大的困惑 —— 这世界上难道存在两种比特币吗?为什么它们都在我的钱包里,我却不能用它们来支付?

但是,如何打破这种区隔呢?如何让闪电通道内的资金也能发起链上支付?如何用链上资金触发闪电网络内的支付?

在本文中,我们会介绍一系列的技术和解决方案,它们改变了 “两种资金有区隔” 的不完善状态,有力地证明了闪电钱包不必因为这种认识上的人为区别而裹足不前。最终,它们允许闪电钱包只保留一种形式的资金、只展示一种余额,同时保留跟一切钱包交互的能力。

潜水艇互换

第一种使我们可以不必顾虑资金的形式、径直发起支付的技术就是上一篇文章里我们介绍过的 “潜水艇互换”。正向的潜水艇互换使我们可以用通道内的资金创建链上输出(也即发起链上支付),而反向的潜水艇互换使我们可以用链上输出换取闪电支付的能力。

不过它也有些不便利之处。在潜水艇互换中,接收者的钱包软件必须支持这种脚本,而且必须在一段时间内领取支付。这都会对接收方提出一些要求。

Splicing(通道拼接)

“通道拼接” 则比潜水艇互换更进一步。它利用了一种根本上的洞见:所谓的 “链上资金”,不过是 “放在只有自己能控制的 UTXO 中的资金”;而 “通道资金”,不过是 “放在与其他人共同分享的 UTXO 中的资金” —— 它们只是操作方法不同,本质并没有什么分别。只要通道双方达成一致意见,他们就能以通道 UTXO 作为输入,发起链上交易(“拼出”),并在同一笔交易中创建一条新的通道,不必先关闭通道、完成支付之后又开启;同样地,只要双方遵循一定的程序,同样能将当前的 UTXO 以及其它资金作为输入,形成新的通道(“拼入”),而不必先关闭通道然后再开启。

并且,通道拼接还能保证,在等待拼出或拼入交易获得区块确认的过程中,通道的功能可以不受影响,依然能即使确认支付。这是怎么做到的呢?

以通道拼出为例,我们假设双方要用通道资金发起一笔链上支付,其输入和输出如下:

当前通道 UTXO(前身 UTXO) --------- 新通道 UTXO
                              |
                               —--- 接收者 UTXO

在这笔交易等待区块确认期间,双方可以对 “前身 UTXO” 和 “新通道 UTXO” 同步签名意义相同的承诺交易,区别只在于对 “前身 UTXO” 签名的交易将始终有一个交给接收者的输出。也即,如果拼出交易得到了确认,这些对前身 UTXO 签名的承诺交易就自动作废,而基于新通道 UTXO 的承诺交易如实地反映了双方的交互;如果拼出交易得不到确认,基于前身 UTXO 的承诺交易也如实地反映了双方的余额变化,将最新的承诺交易广播到比特币网络中依然会触发对接收者的链上支付,而不会允许通道任何一方占便宜。拼入交易也是同样的道理。

通道拼接大大改变了闪电通道发起链上支付的能力和体验。并且,它使我们可以在维持闪电支付能力的同时调整通道的大小,而不必经历关闭又开启的繁琐操作。甚至有人提出可以让通道也参与 coinjoin(一种混淆支付真正收发者的交易) ^1。可想而知它有多么强大。

相比于潜水艇互换,通道拼接不会对接受者的钱包提出任何要求,最普通、最常见的钱包软件就可以用来收款。不过,通道拼接无法用来获得入账流动性。

截至本文撰写之时,Eclair 客户端已经支持通道拼接,Core Lightning 客户端也提供了实验性的支持。详细解释和支持进度可见这个页面 ^2

Swap-in Potentiam

除了优化通道资金发起链上支付的能力,人们也在思考如何加快链上资金进入闪电网络的速度。上一篇文章介绍的 “零确认通道”,也是这方面的努力。“Swap-in Potentiam” 则提议闪电网络的用户应该用这样一种脚本来接收链上支付:该脚本有两种花费分支,一是用户与某个闪电网络服务商(LSP)的 2-of-2 多签名;二是用户单签名 + 一个相对时间锁。

这种脚本有非常有趣的特性:(1)时间锁分支决定了其中的资金的最终归属;假设其双签名分支不被动用,在相对时间锁过期后,用户就可以单凭自己的公钥和签名来花费它;(2)在时间锁还未解锁的时候,不论 LSP 还是用户都无法单方面使用其中的资金;当用户使用其中的资金给 LSP 支付(以承诺交易的形式),LSP 是可以立即就确认的。—— 没错,在时间锁解锁之前,可以把它当成是用户对 LSP 的单向支付通道。在这样的单向通道内,用户给 LSP 的支付,与闪电通道内的支付没有什么区别 —— 所以它可以立即用来闪电支付。

对用户来说,这是一种免信任,但又可以获得 LSP 服务的资金形式。在收到链上支付之后,只需资金得到区块确认,立即就可以进入闪电网络,而无需再经历开启通道的流程。

“Swap-in Potentiam” 提议的原始文本可见这里 ^3

截至本文撰写之时,移动端钱包 Phoenix 已经实现了 Swap-in Potentiam。

Swap-in Potentiam 已经走到这条路的终点了吗?不。从通道拼接的角度看,最佳效率的做法是支付者、闪电钱包用户、LSP 三方一起构造、签名交易,使得支付者的链上支付在单笔交易中直接拼入通道,而不是进入 Swap-in Potentiam 脚本之后再拼入。

显然,这需要支付者的钱包采用一种更为抽象的支付的概念 —— 为一笔交易贡献一定数量的输入,然后确保该交易有一个归属于自己的找零输出,并且输入和输出的差额恰为(支付额 - 应负担的手续费额) —— 而不再要求交易完全由自身来构造、不再要求交易的输入仅有自身可控制的资金。在这种情况下,接收者仅提供自己的收款脚本是不足够的,两方可能要经过多次通信往返,才能安全地构造出最终的交易并广播出去。

当前,以 payjoin 为名的技术,最契合我们这里谈到的概念 ^4

接下来,我们要分析两种钱包的用户体验。它们各自使用上述的技术,达成了 “向用户展示一个余额” 的目标。

Muun vs. Phoenix

Muun 钱包可能是最早尝试克服 “两套余额” 问题的钱包。它的做法是只维护链上资金,然后以潜水艇互换来获得 闪电支付/闪电收款 的能力。

这样做的结果是简洁得惊人的架构和用户体验 —— 它将 闪电通道/闪电网络 完全抽象掉了。软件无需实现完整的闪电网络协议、钱包里没有通道、没有流动性问题,也没有在线要求。用户也完全不必了解闪电通道。无论是常规的链上支付还是闪电支付,体验都相当一致。而且,其安全保管操作与常规的 “比特币钱包” 没有什么区别。

但这样做也有一个明显的缺点:它并不能享受到闪电网络的所有好处,主要体现在手续费上。即使在支付闪电发票,实际上其操作也是在链上发起交易,也要支付链上确认的手续费;反之,接收闪电支付的时候也是如此,同样涉及链上交易。一旦比特币网络的交易确认需求高涨、手续费率提高,用户就会发现自己要支付的手续费高得可怕,一点也不像在使用闪电钱包。

Phoenix 则跟 Muun 钱包朝着完全相反的方向走 —— 它激进地要让用户的钱包里只有通道资金,并且只有一笔。它是这样做的:

  • JIT 通道。当用户要接收闪电支付而无足够的收款额度时,就由 LSP 向用户开启通道,让用户获得收款额度;
  • 通道拼接。当用户要发起链上支付时,就发起通道拼出交易。结合 JIT 通道,意味着在 LSP 提供收款额度时,也会采用通道拼入的形式,以维持仅有一条通道的状态;
    • 此外,用户也可以提前请求收款额度,LSP 会在后台完成操作;
  • Swap-in Potentiam。当用户要接收链上支付时,就使用 Swap-in Potentiam 这样的脚本;一旦资金得到 3 次确认,此时的区块确认手续费又低于用户设定的限值,钱包会自动与 LSP 合作,将资金拼入通道;并且,它是 “零确认的拼入”,也即,即使拼入交易尚未获得网络确认,双方也将新通道中的资金视为立即可用。

Phoenix 综合了我们在这两篇里提到的许多技术,持之以恒地打造了最友好的移动端自主保管钱包体验。

不论是 Muun 钱包,还是 Phoenix 钱包,它们所应用的技术并没有抹去 “区块确认” 和 “通道确认” 在速度(和经济开销)上的区别,也不可能抹除,但它们已经是两个容易解释得多的概念 ^5,而且只要保证了支付能力,这些细节就不会太让用户困扰。它们都为钱包软件的设计提供了许多启发和应该思考的问题。Muun 基于跟常规的 “比特币钱包” 完全相同的架构,提供了支付闪电发票的能力;Phoenix 则激进到让用户所有的资金都进入通道,但完全不影响用户的链上支付能力与体验。它们都在抹除 “比特币钱包” 和 “闪电钱包” 的界限,逼迫所有人正视技术和基础设施的进步所带来的潜能,并要求钱包的开发者们为用户释放这种潜能。

最终,用户也会知道,世界上有且只有一种比特币,它每一天都会比昨天更容易在网络中穿梭。

脚注

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

0 条评论

请先 登录 后评论
BTCStudy
BTCStudy
https://www.btcstudy.org/