闪电通道 “拼接” 的原理

作者：Dusty Daemon

来源：<https://lightningsplice.com/splicing_explained.html>

简单解释通道拼接

就其核心而言，“拼接（splicing）” 是一个简单的概念，就是指重设闪电通道大小的能力。但随着时间推移，越来越显而易见的是，这种重设闪电通道大小的能力，将给我们带来许多额外的好处，这些好处往往在意料之外，而且从根本上提高了闪电网络的可用性。

通道拼接带来了两个方面的提升：

• 面向用户的提升
• 后台的流动性提升

面向用户的提升

第一方面是相对容易解释的：现在有许多的比特币钱包 app —— 这当然很好。但在这些开发者开发自己的 app 时，就会遇上一个问题：这个 app 到底做成比特币钱包呢，还是闪电钱包呢？

大部分钱包会选择其中之一，但一些更有雄心的钱包会选择两者都做！从更加根本的视角来看，当然两者都做是最好的解决方案。

但这就带来了一个问题。这些钱包将拥有 “两套余额” —— 一套是（“链上的”）比特币余额，另一套是闪电通道中的比特币余额。我不知道你有没有引导过新人了解比特币，我可以告诉你：两套余额会让新用户很困惑。对于资深的、 “老炮儿” 比特币人来说，这不是什么问题，但是，我们希望每个人都能用上比特币。

这个 “两套余额” 问题并不是一个设计问题，而且因为这两种模式（链上资金 vs. 闪电通道）根本不同，所以无法变成 “一套”，不然就会产生新的用户问题：更长的支付时延 以及/或者 高不可攀的手续费。

而通道拼接，如果能在网络中实现，就会成为一个秘密武器，让 “一套余额” 的钱包成为可能。因为通道拼接让这两种余额可以低成本地互通（互相转换）。

后端流动性提升

第二方面，后端的流动性提升，可能更难理解，但（相比于 “一套余额” 的 app）对闪电网络有更加重大的影响。

闪电网络的运行靠的是分散在网络中的许多 “微型” 银行。这些银行只提供一种服务：往某个方向移动资金。

传统的银行业需要一个巨型的 “中心” 银行批准少量 “真正” 的银行进入一个受信任的网络。但闪电网络反其道而行之：我们为什么不让每个人都自己开银行呢？许许多多可以互通的小银行，能不能变成一个 “去中心化的银行”？只要足够多人这么做，我们最终就能创造跟中心银行一样可靠 —— 甚至更可靠的东西！

这在事实上已经发生了。闪电网络中的 “微型银行” 的数量一直在增长，而且很快我们将拥有 10 万个微型银行 —— 远远超过美国境内的 5000 家。

这些微型银行将为了路由你的交易而相互竞争，因此会提供最便宜的服务。这样的银行为了路由一笔支付，必须已经在比特币的某个 “闪电账户” 里面存储了一些资金。

再给你提供一些具体的数字：一个成功的闪电银行一般要维护 100 个闪电账户；TA 要在这些账户之间不断移动资金、预测下一个用户需要向哪个方向发起支付。如果他们恰巧在通往 “Sally 的三明治商店” 的路径上有 10 0000 聪的账户余额，那么，当你要跟 Sally 买一个三明治的时候，他们可能就被你选中来路由你的支付。

现在，想象其中一个管理着 100 个账户的微型银行，持续地在账户间转移资金，以猜测消费者的行为。这是相当难的事情！因为事实上，人们的行为都是非常难以预测的，而且你还有很多竞争者，想跟你做一样的事情。

那么，通道拼接跟这个有什么关系呢？嗯哼，在这些账户之间移动资金是很贵的 —— 现实中，这些闪电银行需要不停地关闭和开启账户。他们还需要保留一笔资金作为 “储备”，以备在意外需求出现的时候可以部署到闪电网络中。

通道拼接既消除了昂贵的关闭和开启账户的必要，也消除了保留闲置的 “储备” 资金的必要。这将极大地降低这些微型银行的运营成本、复杂性，以及闲置资本挑战。通道拼接是通过允许直接在 “闪电账户” 之间转移资金（同时是尽可能地成本的）来做到这一切的。更棒的事情是，通道拼接也通过让这些微型银行可以保持独立 —— 不再需要依赖于所谓的 “中心化的流动性提供者” —— 让整个网络更加强壮。

这个事情对于运行闪电微型银行的人来说是非常令人振奋的，当然，对你这样的闪电网络用户来说应该也一样。如果这些微型银行能够更加高效地运行，那么，节约的成本自然也能以惠及用户，其表现是更加便宜的手续费和更加可靠的支付。

通道拼接技术概述

通道拼接指的是将一条闪电通道中的资金（这个通道的注资 UTXO）移动到一个新的 “拼接后” 的 UTXO 中。具体的操作非常简单 —— 签名 2-of-2 的多签名交易，将资金移动到一个新的位置。但是，想要让这个过程保持免信任性，就不是那么简单了

在实际移动原注资 UTXO 以及任何子 HTLC 交易之前，必须为新的 “拼接后” 的 UTXO 重新构造承诺交易。

但是，在我们为新通道重新创建一个复制的承诺状态之前，我们需要保证当前通道中的状态不会在工作中被改变。所以，我们引入了一种新的闪电状态，称为 “SomeThing Fundamental is Underway”，缩写为 “STFU”。

STFU 将在一段时间内禁止改变当前通道的承诺状态。

然后，参与通道的两个节点使用 interactive-tx 协议开始交易协商：每一方在轮到自己时都可以同时添加输入和输出。当前通道的注资 UTXO 会被添加作为被协商的交易的一个输入。

双方都可以任意为不相关的活动添加额外的输入和输出，比如开启另一条通道，甚至处理另一次通道拼接。所有这些活动都会被合并到一笔交易中。

完成交易协商和构造之后，双方都验证最终的交易，确认交易的余额符合预期，并为矿工支付了合理数量的手续费。然后，他们签名交易，并将自己的签名交给对方。

交易广播之后，双方都等待这笔交易获得 6 次区块确认，然后这次拼接就被认为 “完成” 了。这时候，他们就可以删掉原来那条通道的状态，只关心拼接之后的通道的状态了。这样可以节约许多的数据库空间。

（译者注：此处的描述还嫌太粗糙了一些。假定双方现有的通道 UTXO 为 UTXO A；而他们希望形成的拼接后的通道 UTXO 为 UTXO B。首先，双方要为 UTXO B 构造一笔承诺交易作为新通道内的第一个状态，这也是免信任性的保证；然后双方签名产生 UTXO B 的交易并广播出去。在 UTXO B 获得足够区块确认之前，原通道继续运行，双方每在原通道内更新一次状态，也要相应在新通道内更新一次状态。当 UTXO B 获得足够多区块确认之后，就可以不再为原通道更新状态，也可以删掉原通道相关的数据了。这就实现了在改变通道大小的同时不影响通道的正常运行。）

如何实现通道拼接

让一个闪电实现从不支持拼接到支持拼接，有许多步骤。

首先，你必须决定，你的通道状态是否支持其注资详情被覆写，或是将拼接后的通道的状态视作一个完全新的状态。两种办法都可以工作，至于哪一个更理想，则取决于你的实现是如何构造通道状态的。

两套复制通道状态的好处：

• 通道状态（基本上）不必理会拼接

两套复制通道状态的坏处：

• 你的承诺码（commitment code）必须在两套状态中复制，这就打破了一条通道在管理其状态时候的 “黑盒子” 特性

只有一个通道状态的好处：

• 承诺的结构保持不变，只有承诺状态需要少许调整
• 通道状态更接近于根本上发生的事情

只有一个通道状态的缺点：

• 所有预设或者缓存了一条通道的注资详情和余额信息的代码，都必须 “理解” 通道拼接

无论采取哪一种方法，都需要额外的工作来管理通道 id 以及短通道 id，尤其是把它们当作 key 的时候，需要在整个代码基础上处理。

对于给定的代码基础，你应该考虑每一种方法的优点和缺点 —— 既要考虑重构的难度，又要考虑引入 bug 的风险。

下一步，你将需要一个可以复用的交互式交易构造模块。这个模块要处理所有的 TX_ADD_INPUT/TX_ADD_OUTPUT 类型的消息。你也需要这个模块来支持双向注资（dual funding），也正因此，许多实现都是为双向注资而开发这样的模块的。

这个模块在未来的 “splice to close” 中也会很有用，可能也对其它的闪电网络规范附加项有帮助。

交互式交易协议非常类似于双向注资的变种，但也有一些区别。在开发的时候请记住这些区别，以便这样的模块可以运行在不同的场景中。

下一个自然而然的步骤是实现 “STFU” 逻辑。许多人都发现 STFU 协议比想象中更加复杂。这是因为 STFU 消息实际上是对 STFU 模式的一次请求。除非收到回传的 “STFU”，否则它就不会激活。

如果对方忙于别的事情，比如添加一个 HTLC 并更新承诺交易，它就不会回复 STFU，直至它做完手上的操作。

截至本文撰写之时，只有通道拼接使用 STFU 模式，但以后很有可能会发生变化。所以，在开发你的 STFU 模块时，想想未来有什么用途，是很好的注意。

关于 STFU 模式，还有一些特殊的考量。是一种罕见情形，就是双方同时都想初始化一次通道拼接。请记得正确地处理这些打结的情形。

在初始化中，一般来说，你需要处理一个由输入和输出组成的 PSBT（部分签名的比特币交易）。你的用户可能想要给这笔交易添加输入和输出，以及一个相对的通道大小变化数量。你将需要发送相对数量变更，以发送 splice 以及 splice_ack。请记住，双方都可以提供变化数量，所以，一定要为接收的一方开发一个插件程序、提示他们 PSBT 的变化。

更新信息

更多关于如何实现通道拼接的信息会在这里披露。同时，如果你想给自己的实现加入通道拼接功能，你可以在 Twitter 上联系 Dusty Daemon 以获得帮助。

你也可以看看 Dusty Daemon 的一些视频讲解。

（完）