闪电网络实现概览

作者：Fulgur Ventures
来源：https://medium.com/@fulgur.ventures/an-overview-of-lightning-network-implementations-d670255a6cfa
本文首发于 2021 年 3 月 15 日。

本文是我们关于闪电网络生态系统系列的第二弹。虽然在上一篇文章中，我们已经就如何理解 “生态环境” 打下了基础，本文旨在从关键特征、使用情况、开发活动统计和功能等方面，为读者更详尽地展示栖息在这个生态内的一部分 “物种” —— 各种不同的闪电网络实现。如果你是计划在比特币闪电网络上进行构建的开发者、产品经理或创业公司创始人（或者说你只是闪电网络爱好者），我们希望这篇文章能够帮助你从产品开发的角度了解并评估可获得的客户端和库。

太长不看

闪电网络实现的生态正在稳步发展中，不仅扩大了应用场景的覆盖面，而且更好地满足了不同技能客户的需求。
随着主要开发组织开始形成各自的优势和价值主张，产品化路径变得更加明显。
由于早期采用者的参与度较强，每个闪电网络实现周围都形成了用户社区。
预计到 2021 年，更多机构采用（例如，交易所）将推动生态环境的发展。

为了尽可能增强这篇概述的准确性并增添更多技术细节，我们已经向开发者收集了不同闪电网络实现的具体信息。然而，考虑到整个生态的飞速发展，文中提到部分信息可能很快就会过时。如果你发现我们有任何遗漏之处或任何信息过时失效，请告诉我们，我们会更新本文。

闪电网络简介

闪电网络是叠加在比特币网络之上的网络，旨在增强比特币网络的可扩展性。通过在链下处理交易和利用安全的底层网络作为仲裁层，闪电网络实现了免信任的即时私密支付，而且手续费极低。在使用这项技术时，我们需要理解两个不同的网络层：

比特币网络：作为闪电网络运行的基础层。闪电网络使用底层区块链执行开启/关闭通道的交易并监控通道状态的相关事件。
闪电网络：构建在比特币区块链上的点对点网络层，可以让闪电网络节点相互连接并共享支付通道来参与交易活动。

因此，基于闪电网络开发应用需要用到两个不同的软件组件：

比特币节点：一些节点实现可以用来与底层区块链创建接口。其中，最受欢迎且应用最广泛的是 Bitcoin Core（bitcoind）和 btcd。
闪电网络节点：闪电网络节点/后台进程（daemon）是与闪电网络连接和交互的主要应用组件。闪电网络后台进程是本地服务器，负责管理数据库、连接对等节点、开启/关闭通道、生成付款发票（payment invoices，用于请求支付）、发送付款等。闪电网络节点需要一直与比特币节点保持同步才能运行。在大多数应用开发场景中，应用只与闪电网络节点交互。

闪电网络应用的典型架构如下所示：

闪电网络节点有多种实现，所以开发者可以根据自己心仪的功能和编程语言来选择。

闪电网络实现的生态

本章节介绍了截至 2021 年 1 月以前的 6 个月内在 Github 上有重要开发活动的主要闪电网络实现。为了收集一些特定信息，我们采访了这些项目的开发者。下列项目均根据 GitHub ¹ 上首个版本标记的日期按时间顺序排序。

c-lightning

c-lightning 是 Blockstream 用 C 语言编写的闪电网络实现，受到 BSD-MIT 许可证的保护。该项目自 2018 年初以来就在比特币主网上运行。c-lightning 的软件架构赋予了其模块化和可延展（extensible）特性，以及较强的向后兼容性。该项目提供底层的个性化定制，让开发者可以灵活使用闪电网络后台进程。

Eclair

Eclair（法语词，意为闪电）是 ACINQ 用 Scala 语言编写的闪电网络实现，受 Apache License 2.0 的保护。自 2018 年初在主网上线以来，Eclair 提供了一个节点实现库，用来打造健壮、安全且可扩展（能够处理大量交易）的节点。另外，Eclair 还提供了一个原生的移动端闪电网络实现。

Ind

lnd 是 Lightning Labs 使用 Go 语言开发的闪电网络节点实现，受 MIT 许可证保护。Ind 被设计成了一个用户友好型实现，用来促进基于闪电网络的应用开发。它是一个独立的后台进程，自 2018 年第一季度以来提供了大量主网可用功能。

Rust-Lightning 和 LDK

Rust-Lightning（RL）是 Rust 比特币社区联合 Square Crypto 使用 Rust 开发的通用闪电网络库，受 Apache 2.0 或 MIT 许可证的保护。RL 于 2019 年 12 月上线，旨在为闪电网络提供功能完备的灵活实现，并在最大程度上减少系统依赖项。它的设计理念是，所有功能都应该通过简单、可组合的 API 公开。Square Crypto 创建了闪电网络开发工具包（Lightning Development Kit，LDK）项目后，Rust 比特币社区参与了进来。LDK 以 RL 为基础，包含了一个 API、语言绑定、demo app 等以及必要的文档；其设计目标是，让应用开发者可以轻松、安全、灵活地整合闪电网络。

Electrum

Electrum 是 2011 年创建的比特币客户端，聚焦于隐私性和安全性。它支持冷存储、多重签名和各种硬件钱包。Electrum 采用由公开服务组成的去中心化的基础设施，例如，ElectrumX。Electrum 服务器是能够索引比特币区块链的比特币全节点，可以让钱包高效查询任意比特币地址。Electrum 用户既能运行自己的私人服务器，也能连接到公开的 Electrum 服务器。Electrum 开发者使用 Python 创建了一个闪电网络实现，并整合了 Electrum 钱包。Electrum 于 2020 年 7 月公开部署了支持闪电网络的实现，其代码受 MIT 许可证保护。

LNP Node

2020 年 10 月，LNP/BP 标准协会发布了 LNP Node v.0.1（alpha 版本），一个使用 Rust 编写的新型闪电网络实现，受 MIT 许可证保护。LNP Node 将包含一组能够运行 Lightning Network Protocol（闪电网络协议）、智能合约系统 RGB 和广义闪电网络通道（GLC）的后台进程。GLC 是 LNP/BP 标准协会提出的概念，是一种以模块化和可延展的方式（extensible）定义支付通道的新方法，以便未来将协议构建在闪电网络之上（即，Layer 3）。

其它重要实现有 Altangent Labs 开发的 Node-Lightning（前身为 LNTools）、由 Nayuata 开发、MIT Media Lab 的 Digital Currency Initiative 支持的 Ptarmigan。

自首批闪电网络实现于 2018 年初在主网上线以来，闪电网络实现的生态一直在稳步壮大，并且保持发展态势：早期实现已经在主网投入生产，新的实现也在陆续登台亮相。

使用情况和开发活动统计

现在我们已经简要了解了每个闪电网络实现及其目的和设计目标，接着从数据的角度来分析它们的使用情况和开发活动情况。

使用情况统计

虽然闪电网络的交易量可能是判断其使用活动的最佳指标，但是由于网络的隐私性，我们很难获得可靠的信息。为了大致估计各个实现的相对分布情况，我们先来看看公开节点的数量及其活动情况。

- 2020 年 9 月公开节点数量的分布情况 -

由于无法公开访问节点上运行的客户端的信息，研究者专门设计了一种方法，可以根据通过 Gossip 协议传输的消息来推断客户端类型。每个实现使用的参数默认值都略有不同，其中一些是公开的，可以通过检查 gossip 消息获取。由于用户大多保留默认值，我们可以根据这些值来推断出主要闪电网络实现的分布情况 ^2,3。上图是 2020 年 9 月以来公共网络图的快照，不包括移动钱包和非公开的通道。然而，基于他在 2019 年的研究结果 ⁴，克里斯汀•戴可（Christian Decker）估计网络中私有节点的比例至少在 40% 左右。因此，要注意的是，聚焦于移动钱包的实现在上述统计数据中可能没有得到充分体现。

为了增加另一个维度来反映不同闪电网络实现的使用情况，我们还参考了 Bitrefill 的公开统计数据。下图显示了通过闪电网络向 Bitrefill 发送交易最多的节点的分布情况。图中所示数据是根据过去 30 天来向 Bitrefill 支付的独立支付（unique payment）的数量与其收到的所有闪电网络支付的占比计算得来的。

- 2021 年 1 月向 Bitrefill 发送交易最多的节点 -

总的来说，上图所示的统计数据体现了相似的分布情况。然而，在这幅反映了连接到 Bitrefill 的最活跃节点的分布情况的图中，Eclair 的占比变大了一些。这意味着，运行 Eclair 的节点贡献了 Bitrefill 过去 30 天内收到的所有付款的 14%。请注意，上图不一定会表明付款来源，因为连接到 Bitrefill 的节点可能是中间路由节点，。

开发活动统计

为了估计最近的开发活动，我们纳入几个可以从 GitHub 获得的指标，例如，复制数量、贡献者人数和提交数量（现有文献中的常用方法 ⁶）。不出所料的是，最常用的三个实现 c-lightning、Eclair 和 lnd 在开发活跃度方面也是最高的。其中，就下图列出的每项指标而言，Ind 都独占鳌头。相比之下，较晚上线的 LNP Node 和 Rust-Lightning/ LDK 在开发活跃度上要落后不少。⁷

- 总体开发活动情况 -

- 月均开发活动情况 -

考虑到每个实现并非同期上线，我们计算了各个实现在 GitHub 上首次进行开发活动以来的 “月均提交数量” 和 “月均已处理问题数量”。¹