作者：Bitcoin Lightning Network
来源：https://voltage.cloud/blog/bitcoin-lightning-network/what-are-the-differences-between-lnd-and-cln/
闪电网络协议在叫做 “BOLT（闪电网络技术基础）” 的规范文档里有正式说明。所有的开发闪电网络节点实现的团队都必须遵循这些技术文档所述的规范，但他们可以用自己喜欢的方式来实现。他们可以使用各异的编程语言，让软件侧重于隐私性而非可靠性，等等。
这意味着，各种实现之间是有区别的，取舍各不相同。在这篇文章中，我们会深入了解两大流行的闪电网络客户端实现 Lightning Network Daemon (LND) 和 Core Lightning (CLN) 之间的区别，它们分别由 Lightning Labs 公司和 Blockstream 公司实现。
项目背景和开发者活动
CLN 是第一种闪电网络实现，是以 C 编程语言编写的。在过去的一个月（2022 年 10 月 22 日至 11 月 22 日）里，8 位开发者为之贡献了代码，解决了 11 个 issue。LND 是以 Go 语言编写的，同期共有 24 位代码贡献者，解决了 43 个 issue。（译者注：issue 是人们针对现有代码提出的优化需求，可能包含了异常反馈，也可能仅是提出需求。）
LND 显然在开发者中更受欢迎，这里面可能有各种原因，这也是我们即将探讨的。通常来说，更多的贡献者参与代码审核、bug 修复和新功能开发，会让一个开源项目变得更好。
网络占有率
另一个我们可以分析的指标是两种客户端的网络占用率。需要着重指出的是，因为每个节点都有自己的视野，想获得整个网络的准确度量是不可能的，我们最多只能估计。
这篇来自 @heisinberg，出版在 stacker news 的文章发现，大约 91.67% 的节点都在使用 LND，而 7.01% 的节点在使用 CLN。这些数字非常接近与 2020 年出版的另一份研究。
说明书
LND 的说明书以简明易读而闻名。在那里你可以找到指南、文章、案例应用以及社区资源。这让 LND 对用户非常友好，即使是不懂技术的人也能读懂。但 CLN 的说明书就正好相反，更加面向开发者。
这就很容易解释为什么社区更常选择 LND、在 LND 上开发项目。例如，流行的节点管理器 Thunderhub 就只支持 LND；如果你运行 Voltage Node，这个管理器是开箱即用的。
模块化
CLN 在用户体验上的不足，它通过模块化补上来了：这个项目提供了一种简单但强大的范式，来延伸 Core Lightning 所提供的功能。开发者可以编写和发布自己的插件，用于环式再平衡、打探、动态的手续费调整，等等。你甚至可以实现自己的支付逻辑插件，覆盖掉默认的支付逻辑！
LND 并不具有同样的插件 negligence，但它也提供了一个 RPC-API，让用户可以定制化上面提到的一些功能。它也有 HTLC 拦截器，可以拦截转发的 HTLC 和 gPRC 请求，并添加定制化的功能；但它不可能达到 CLN 插件那样的模块化水平。CLN 插件所启用的某一些功能，必须重写和重编译源代码才能实现。
支付 —— 隐私和可靠性
如果你更在乎隐私性，那么 Core Lightning 更适合你。它的支付逻辑使用了随机化路由和影子路由（shadow route）来保护用户的隐私。这意味着，支付算法并不总是选择手续费最低或者最短的路径（随机化路由），而且会在沿路添加时延和手续费（影子路由），进一步强化效果。
随机化路由、影子路由和多路径支付，都会给用户带来更多的隐私性，但天下没有免费的午餐。使用这些技术会让支付更容易失败，而且总是更昂贵（需要支付更多手续费）。
LND 使用了不同的方法：其支付逻辑专注于可靠性。它再寻找发送者和接收者之间的最短路径上效率比 CLN 更好，支付成功率也比 CLN 更高；而且，在创建路径时，它会把近期遇到的失败路径也考虑在内。当然，他也不是十全十美：LND 的支付成功率更高，但隐私性也更差。
入账流动性
在冷启动一个闪电节点的时候，最大的挑战之一就是获得入账流动性（inbound liquidity）。简单来说，入账流动性意味着你接受支付的能力。LND 和 CLN 使用不同的方法来解决这个问题。
LND 背后的团队开发了一个叫做 “Pool” 的工具。这款应用带有一个密封拍卖市场，用来匹配寻找入账流动性的节点和愿意有偿提供入账流动性的节点。CLN 则相反，选择了一种叫做 “Liquidity Ads” 的方法，在闪电网络中通过 gossip 协议广告自己具有流动性。
不过，虽然有这些方法，但它们在社区中也不常用。第三方提供者在闪电网络的入账流动性供应中扮演了更重要的角色。
钱包复原和备份
闪电网络通过运用改比特币区块链相反的方法来获得可扩展性和隐私性：保证用户的金融活动只有自己知道，而不是向整个网络公开所有的交易数据。这意味着闪电网络的用户不能只依赖于比特币区块链和种子词来复原锁定在闪电通道内的资本。你将需要一些备份机制，来保证你可以在一些可怕的故障之后复原你的链上资金。
在 LND 上，你在一开始创建一个闪电钱包的时候，软件就会为你生成一个 24 单词的种子词。这个种子词只能复原你的链上资金，不过在你复原通道资金的时候也需要用到。对于锁在通道中的资金，LND 使用了一种叫做 “静态通道备份” 的方法，也叫 SCB。之所以命名为 “静态”，是因为只有在通道创建时才能获得这些备份。
在发生灾难性的故障之后，如果用户无法复原通道，SCB 可以用来联系对等节点并提示他们强制关闭通道。这是一种简单的机制，但它也有缺点：必须先联系上对等节点。这也是为什么 LND 的说明书建议用户定期备份 channels.db 文件，并尽早关闭不活跃的通道。
在 CLN 中，当你创建一个节点时，它会创建一个 hsm_secret。用户还可以使用任意流程创建一个 BIP39 种子词，并从中推导出这样的秘密值。hsm_secret 只需要写入一次，就足以复原你的链上资金；不过，在复原通道内资金时，也需要用到它。CLN 提供了多种策略来回复通道资金。用户可以自由选择一种乃至多种备份策略。
最简单的，就是为你存储通道信息的数据库选择一个备份存储位置。在你的节点运行的时候，数据也会保存到这个备份数据库中。CLN 也建议你使用另一个存储设备，最好放在另一个地方。两个数据库中的数据都没有加密，所以不推荐使用云服务。还有一些备份插件，是为 “重度用户” 和有经验的用户准备的，例如 PostgreSQL 集群和文件系统冗余。
硬件性能
如前所述，CLN 是用 C 语言编写的；在开发者社区中，C 语言众所周知是瞄准性能的上选。相反，LND 是用 Go 语言编写的，它并不像 C 语言那么 “轻量”。
如果你希望在一个底子比较差的计算机（比如树莓派）上运行闪电节点，你应该把这一点也纳入考量，尤其是你想当一个路由节点的话。你的节点越活跃，对硬件的需求就越高。
BOLT 12
当前的闪电网络最大的用户体验问题之一是闪电发票的局限性。发票需要在支付者和接收者之间保持隐私，而且只能使用一次。跟其他人分享发票或者复用发票会导致资金的失盗。发票只能够用来接收支付，不能用来发送支付，这会产生奇怪的用户体验。
BOLT 12，也叫 “offer” 协议，尝试解决这个用户体验问题。这是一种为静态的、可以（也应该）复用的发票撰写的规范。它也可以用来发送支付：你扫描一个 QR 码，就可以收到支付。从用户的角度看，BOLT 12 跟 LNURL 很像，但 LNURL 需要使用一个 web 服务器。有了 BOLT 12，则一切都是在闪电网络 “内部” 完成的。
当前，只有 CLN 具有对 BOLT 12 的实验性支持。依然是实验性功能，因为 BOLT12 还在开发中，其规范还在变更。
Taro
回到 2022 年 4 月，Lightning Labs 推出了 Taro：一种运用了 taproot、在比特币区块链上发行资产，且资产可以在闪电网络中转移的协议。正在开发的源代码使用 LND 作为后端。
这意味着，在 Blockstream 决定实现这个协议之前，LND 将是希望使用 Taro 来发行资产的用户、组织和公司唯一的选择。这可能会让 LND 的网络占有率进一步高涨。
结论
虽然基于相同的协议，LND 和 CLN 具有不同的理念。LND 是当前接受度最广的实现，这可以解释这个项目的参与者的数量。同时，它也有用户友好的说明书，不懂技术的用户也能读得懂。
而 CLN 利用插件系统提供了更强的模块化。你几乎可以为所有的东西编写一个插件：备份、网络侦测、通道管理自动化，等等。LND 的支付逻辑追求效率和可靠性；其支付拥有更好的成功率、更低的费用。CLN 采取了不同的方法，追求隐私性，使用不同的方法保护用户的隐私。这是有代价的：支付更容易失败，而且可能要支付更高的手续费。
在入账流动性的解决方案上，CLN 设计了流动性广告，利用了 gossip 协议为自己的流动性打广告。而 LND 则实现了一种叫做 “Pool” 的密封拍卖协议。Pool 让用户可以容易且快速地获得这些密封拍卖中的入账流动性。
LND 也选择了另一种方法来备份和恢复。LND 使用种子词和静态通道备份，它仅在通道创建时才更新。CLN 使用了 hsm_secret 来复原链上的资金，并使用冗余来处理通道资金复原：将整个数据库复制到另一个地方。
CLN 的性能比 LND 更好，所以如果你希望在较差的硬件上部署一个活跃的节点，CLN 是你的菜。LND 在自己的说明书中列出了最低硬件要求，但缺失了给重度用户的更好指引。
最后，CLN 具有对 BOLT12 的实验性支持；LND 则被用作 Taro 协议的后端，虽然 Taro 也还在开发节点。如果你需要在两者间作出选择，并希望使用其中一种特性，你就需要使用支持这种特性的客户端，至少目前是如此。
（完）