闪电节点：全时在线 vs. 非全时在线

作者：Anony

关于闪电网络，一种由来已久的误解是，用户必须在某个地方建立一个全天候运行的服务器并运行一个全时在线的节点，否则就无法使用闪电网络；或者，其它用法都是 “托管式的” 或者 “不安全的” 。这种误解显然劝阻了许多人尝试闪电网络，因为，最方便的闪电网络用法 —— 移动端的闪电钱包 —— 在这种误解下，显然会被归作 “不安全的” 。本文将分析闪电网络的使用模式以及在线要求，并凸显全时在线的节点与非全时在线的节点在使用体验上的其它区别。

在线要求：安全性

作为一个传递支付的网络，“闪电网络” 的基本组成单元是 “闪电通道”。闪电通道这套技术规范让两个节点可以把钱存入同一个比特币地址，并在双方协作的前提下不断地改变这个共同账户的内部状态 —— 资金在双方之间的归属 —— 而不需要通知其他人（更不需要区块链的确认）。这种只需双方确认的模式，为闪电网络能够处理巨大吞吐量打下了基础。重要的是，这种不断更新内部状态、令双方都倾向于使用最新状态来结算（退出通道）的机制，其安全性并非来自技术上的截然不可能（即无法用旧状态来结算），而是来自经济激励和使用比特币脚本编程出来的博弈机制：任何一方如果使用旧状态来结算，会导致其在通道中的资金全部被对方没收。

具体来说，当一方单方面退出通道时，结算给该方的钱币会带有一个时间锁，迫使该方只有经过一段时延之后，才能转移资金；而在此时延内，对方可以凭借一个在更新状态时揭晓的秘密值，将资金全部取走。换言之，如果结算的是最新状态，由于该秘密未暴露，该方就只是延后取款；如果结算的是旧状态，由于该秘密已暴露，对方就能把钱都取走 —— 只要对手来得及在这个时延内响应。

这就是从资金安全的角度看，闪电网络用户的在线要求的由来。由于闪电资金已不是用户排他性持有的资金，并且对手盗窃的空间始终存在，因此，用户当然不能像对待排他性持有的资金（即所谓 “比特币钱包”/“比特币链上钱包”）那样一经存入便可置之不理。如果对手尝试欺诈，必须在线才能响应、反击。

但是，是否因此就只有全时在线才能保证安全？显然也不是。因为对手无论什么时候尝试欺诈，己方都有同样长的一段窗口期来反击；只要两次离线的间隔不长于这个窗口期，就可保证即使对手欺诈，自己也总有时间可以反击。当然，离线时间越短，捕捉到对手欺诈尝试的速度就越快，可以发动反击的时间也就越长。而且，这个窗口期，在建立闪电通道时是可以配置的。

在主流的闪电节点实现 LND 中，默认的窗口期会随着投入通道的资金数量的增长而线性增长；在小于 1198372 聪的通道中，都应用 144 个区块（大约为 1 天）的窗口期；详见：https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf#L703。用户可以使用配置文件改变此参数。

此外，用户还可以使用一种叫做 “瞭望塔” 的服务端，代替自己在离线时检测对手的欺诈尝试并相应发动反击。

总之，在移动端使用闪电网络钱包，并不是只能在 “托管钱包” 和 “远程遥控自己专门部署的全时在线节点” 之间二选一；在移动端使用自主保管的闪电钱包，既是可以做到的，也是能够获得令人满意的安全性的。

感兴趣的读者可以尝试下载 “Breez 钱包”，在钱包左侧的 “开发者” 按钮中打开其命令行界面，你会发现，它就是一款复刻的 LND 实现。而当前另一款热门的自主保管闪电钱包 “Zeus”，则使用了 LDK（Lightning Dev Kit）来建立闪电节点。这两款钱包软件都内置了完整的、全功能的闪电节点。使用它们与使用家用服务器或云服务器上的闪电节点，唯一区别只是在线时间。而在线时间（或者说离线间隔）对于资金安全性的影响，是可以在一定程度上通过配置参数来优化的。

在线要求：收款

不过，就目前来说，在 “收款” 上，全时在线的节点相比非全时在线的节点，在用户体验上确实有优势。

作为闪电支付的收款方，收取一笔支付的过程是这样的：

1. 生成一张闪电发票；将该发票（作为信息）传递给支付方；
2. 支付方发送闪电支付；
3. 闪电支付（经由某个通道对手）送达，与该对手更新闪电通道状态并释放支付原像（该原像将回传给支付方作为支付证据）。

在这个过程中，第 3 步是实现支付双方免信任性的关键，而它明确要求收款方（在线）与自己的通道对手更新状态。

设想，如果你有一个全时在线的节点，那就很简单了，把发票传给支付方就可以先干别的事情去了，想起来再检查一下。但如果你只在手机上有个闪电节点，那么你可能需要敦促对方尽快支付，然后打开 app，等待支付送达；支付送达了才能切换去做别的事。

（值得一提的是，BOLT12 Offer 协议的出现，只是便利了获取发票的过程，对于收款的在线性要求并没有什么改善。）

可以说，这就是移动端的闪电钱包一直在解决的难题。目前，主流的解决办法是 LSP（闪电网络服务商）+ 运用移动操作系统的通知系统。假设有一个服务可以知晓支付即将送达（作为用户的通道对手的 LSP，能够满足这个假设），那么它可以调用通知系统向收款方的手机推送一条通知，提醒收款方打开 app 。这种方法的局限性之一是，如果用户的手机无法连接到通知服务端（例如移动网络信号弱），那就无法使用；其次，它还依赖于用户的注意力机制，如果用户不是在那几分钟的窗口里有空，就错过了。

未来，闪电网络也许可以用一套叫做 “异步支付” 的规范来解决这个问题。从原理上来说，是支付方先将支付送达自己的 LSP，再要求收款方的 LSP 在收款方上线时联系自己的 LSP ；当收款方回到线上时，支付方 LSP 再启动支付流程，并获得支付证据；当支付方再回到线上时，LSP 凭支付证据领取资金。这就让支付方和收款方可以完全异步。一个说明性介绍可见 LDK 的博客。

类似地，还有一个场景，全时在线是一种必然要求：为网络的其他用户转发支付。

连接性

综合上述两点，是否意味着，在所有方面，全时在线节点实现都优于非全时在线的节点 实现/产品 ？其实不是。移动端的闪电钱包产品，为适应其具体的使用场景，在许多方面做了长足的优化。当前，如果从一个不参与路由的普通用户角度出发，移动端闪电钱包产品的体验要大大好于用户自己部署的全时在线节点，其中一个关键原因是移动端钱包往往搭配有 LSP，作为用户的通道对手方，可以主动抽象掉闪电通道的许多技术复杂性，为用户提供开箱即用的体验。

但这里还要介绍全时在线节点的另一个具体的困难，就是连接性。

移动端节点就部署在手机上，随使用者一起移动；但全时在线节点做不到。为了随时随地能够使用全时在线节点来支付 —— 显然，这是当代社会的常见需求 —— 用户必须有一种方式能够远程控制自己的节点。

对于公网 IP 并不稀缺的地区，这不是什么难题。因为部署节点的服务器可以获得稳定的公网 IP，用户也就随时能够利用这个 IP 来访问自己的设备、控制自己的节点。许多移动端闪电钱包也都提供了远程控制自己节点的选项（比如前面提到的 Zeus 钱包）。

但在公网 IP 稀缺并且互联网使用有诸多管制的地区，可以说处处是麻烦。远程连接，就成了全时在线节点用户绕不过去但又有一定技术难度的困难（除非用户完全无意于使用它来服务自己的移动支付）。作为一个明确的网络工程问题，这当然有解，但解决方法往往要求用户同时投入精力和金钱。

最近，一种比较有前景的连接方式是 “NWC 协议”，原理是服务端（闪电节点）为用户的 Nostr 客户端分配专用的连接口令，并以本地的 Nostr 客户端监听指令；用户的 Nostr 客户端通过 Nostr relay 向服务端发送指令，以此获得钱包信息并要求执行功能。这种连接方式能够利用现成的 Nostr 基础设施，并且不依赖于某一个中转服务商。

结论

当前，用户自己部署的全时在线节点，与移动端可用的非全时在线节点，在使用体验上各有短长。但是用户无需因为资金安全性的要求而规避使用移动端的闪电钱包，因为基于闪电通道的技术原理和实现，同样有能够适配移动端使用模式的安全参数。实际上，得益于移动端钱包的许多优化，从普通终端用户角度看，移动端节点的体验大大好于用户自己部署的全时节点。

（完）