An Overview of Lightning Network Implementations
Summary
This article represents the next installment in our series of publications on the Lightning ecosystem. While in our last publication we have laid the groundwork for understanding the ‘habitat’, this one is meant to provide its keen reader with a more detailed overview of one specific part of the system’s ‘inhabitants’ — the various different Lightning implementations — by showing their key characteristics, usage, development statistics, and features. If you are a developer, product manager, or startup founder planning to work on Bitcoin Lightning Network (or if you simply are a Lightning enthusiast), we hope this article will serve you as a helpful source of information to learn about, assess, and evaluate the clients and libraries available from a product development perspective.
TL;DR
- The landscape of Lightning implementations is steadily evolving, providing improved coverage of multiple use cases and better meeting requirements of differently skilled users.
- Productization paths are becoming more apparent as the main developing organizations solidify their respective strengths and value propositions.
- Stronger user involvement in early adoption has led to formation of user communities around each Lightning implementation.
- It is anticipated that more institutional adoption such as by crypto exchanges will drive growth of the ecosystem in 2021.
In order to make this overview as accurate as possible and add more technical details, we have reached out to developers to gather specific information on various Lightning Network implementations. However, considering the rapid evolution of the ecosystem, some of the information here may soon be outdated. If you find that we missed something or any information became outdated or obsolete, let us know, so we can update the article.
Brief introduction into the Lightning Network
The Lightning Network (LN) is an overlay network that scales Bitcoin. It facilitates trustless instant and privacy preserving payments with negligible fees by keeping transactions off-chain and leveraging the security of the underlying blockchain as an arbitration layer. When working with this technology, it is important to understand the two different network layers:
- Bitcoin Network: It serves as the base layer on which Lightning operates. Lightning uses the underlying blockchain for channel open/close transactions and monitoring relevant events about channel state.
- Lightning Network: This is the peer-to-peer network layer on top of the Bitcoin blockchain where Lightning nodes can connect with each other and share payment channels to engage in transaction activity.
Consequently, the development of an Lightning powered application requires two distinct software components:
- Bitcoin node: there are several node implementations available to establish an interface with the underlying blockchain. Among those, the two most popular and widely used are Bitcoin Core (bitcoind) and btcd.
- Lightning node: a Lightning node/daemon serves as the main application component connecting and interfacing with the Lightning Network. Lightning daemons are local servers that manage a database, connect to peers, open/close channels, generate payment invoices, send or forward payments, etc. Lightning nodes need to be synced with Bitcoin nodes at all times for the node to be operational. For the majority of an application developer scenarios, applications interface just with the Lightning node.
A typical Lightning application would have the following architecture:
Several Lightning Network Node implementations are available providing developers with a choice of core features and programming languages to use.
Lightning Implementation Landscape
This chapter introduces the major Lightning implementations that have recorded significant development activity on GitHub within the last six months as of January 2021. We interviewed their developers to collect specific information for this article. All projects are listed in chronological order, according to the date of the very first release/tag on GitHub¹.
c-lightning
c-lightning is a Lightning Network implementation written in C by Blockstream and available under the BSD-MIT license. It has been in production use on the Bitcoin mainnet since the beginning of 2018. In its software architecture, c-lightning follows a modular and extensible approach with strong backwards compatibility. The implementation provides with low-level access for individual customization and flexible usage of its Lightning daemons.
Eclair
Eclair (French for Lightning) is a Scala implementation of the Lightning Network developed by ACINQ available under the Apache License 2.0. Since its early 2018 mainnet release Eclair provides an implementation library for robust, secure and scalable node that can handle high volumes of transactions and provides a native mobile implementation of the Lightning Network.
lnd
lnd is a Lightning Network node implementation developed by Lightning Labs in Go and available under the MIT license. lnd is designed as a developer-friendly implementation that facilitates on-top application development. It is a stand-alone daemon with an extensive set of features available for mainnet use since Q1'2018.
Rust-Lightning and LDK
Rust-Lightning (RL) is a generic Bitcoin Lightning library developed in Rust by the Rust Bitcoin Community in cooperation with Square Crypto and available under Apache 2.0 or MIT licenses. Released in December 2019, RL intends to provide a full-featured flexible implementation for Lightning with minimal system dependencies. All features are supposed to be exposed via simple, composable APIs. The Rust Bitcoin Community joined forces with Square Crypto, the initiator of the Lightning Development Kit (LDK). Based on Rust-Lightning, the LDK will include an API, language bindings, demo apps, and other features as well as documentation necessary to achieve their design objective of making Lightning integrations easy, safe, and configurable for application developers.
Electrum
Electrum is a privacy and security focused Bitcoin client created in 2011. It supports cold-storage, multi-signature and various hardware wallets. Electrum uses a decentralized infrastructure of public servers, such as ElectrumX. Electrum servers are Bitcoin full nodes that index the blockchain, and allow wallets to efficiently query arbitrary Bitcoin addresses. Electrum users may run their own private server, or connect to public Electrum servers. Electrum developers created a Python implementation of Lightning, that is integrated with the Electrum wallet. Lightning support in Electrum was publicly deployed in July 2020, and the code was released under the MIT license.
LNP Node
In October 2020, LNP/BP Standards Association published v.0.1 — alpha version — of LNP Node, a new Lightning implementation written in Rust and available under the MIT license. LNP Node is going to comprise a suite of daemons capable of running both the Lightning Network Protocol, RGB, a smart contract system, and Generalized Lightning Channels (GLC), a concept created by LNP/BP Standards Association. GLCs are a new way of defining payment channels in a modular and extensible way, allowing for future protocols on top of the Lightning Network (i.e. Layer 3).
Other notable implementations include Node-Lightning (formerly LNTools) by Altangent Labs, Ptarmigan by Nayuata and lit by the Digital Currency Initiative at the MIT Media Lab.
Since the occurrence of the first mainnet releases in early 2018 the ecosystem of implementations has been growing steadily, and it is still evolving: early implementations are in production on mainnet, new ones keep entering the stage.
Usage and Development Statistics
Now that we have taken a brief look at each of the different Lightning implementations and their objectives and design goals, here are some data insights on their usage and development.
Usage Statistics
Whereas the volume of Lightning transactions might actually be the best metric to determine relevant usage activity, reliable information on this is difficult to obtain due to the network’s privacy properties. For an approximate estimate of relative distribution of implementations, we first take a look at the number of public nodes and their activity.
Because there is no public access to information on the client that runs on a node, researchers devised a method to deduce the client type based on the messages transmitted over the gossip protocol. Each of the implementations uses slightly different default values for parameters, some of which are public and can be obtained through inspection of gossip messages. Because users mostly keep default values, it is possible to deduce from those values the distribution of the major LN implementations in operation²’³. The chart above shows a snapshot of the public network graph from September 2020, excluding mobile wallets and non-public channels. However based on his 2019 research⁴ Christian Decker estimates the lower bound for private nodes in the network around 40%. So readers should be aware that implementations focusing on mobile wallets might be underrepresented in this statistic.
To add another dimension to the utilization rate of different Lightning implementations, we refer to a publicly available statistic from Bitrefill. This graph shows the top nodes from which Bitrefill receives transactions over Lightning. It is calculated based on the number of unique payments to Bitrefill in the last 30 days as a percentage of all Lightning payments received⁵.
Overall, this statistic reveals a similar picture of the distribution. However, Eclair in this one takes a bigger share in the distribution of the most active nodes connected to Bitrefill. This means nodes running Eclair contributed 14% to all payments received by Bitrefill over the last 30 days. Note that the graph does not necessarily indicate the origin of the payment if the node connected to Bitrefill was an intermediate routing node.
Development Statistics
To estimate the recent development activity, we included several indicators available from GitHub, such as the number of forks, contributors, or commits (a common approach in existing literature⁶). Unsurprisingly, the three most frequently used implementations — c-lightning, Eclair, and lnd — also record the highest accumulated development activity. Among them, lnd ranks highest in all listed categories. Accordingly, significantly later released LNP Node and Rust-Lightning/ LDK record so far lower levels of activity.⁷
To account for the age of each implementation, we calculated the “average number of commits per month” and the “average number of solved issues per month” since the first activity on GitHub.¹
How to Run and Work with Lightning Nodes
To help you start with the first steps of development, the next section gives you an introduction on how to run, build on, and contribute to each Lightning implementation. For your convenience it also includes hyperlinks to resources and communities where you can receive development support.
c-lightning
Run: c-lightning provides a guide to assist the installation and operation of the daemon on a variety of platforms such as Ubuntu, BSDs, MacOS, Android or Raspberry Pi. Users can choose between different installation options such as docker images, reproducibly built binaries from GitHub, and a Personal Package Archive (PPA) for Ubuntu, which makes it easy to run for Ubuntu users. So far, there is no out-of-the-box support available for Windows. Nevertheless, especially the users of embedded hardware might appreciate c-lightning as a lightweight and highly customizable Lightning daemon.
Build: c-lightning exposes a JSON-RPC 2.0 interface over a Unix Domain socket and is accessible with the lightning-cli tool or the available client libraries in Python, Go, JS or Rust. Since there is no native support for REST or gRPC interfaces, a few projects are currently developing applications servers that provide an API layer on top of c-lightning:
- c-Lightning-REST — an application server written in JS that provides a REST API suite
- Lighter — an application server providing a gRPC client interface for c-lightning, Eclair, lnd, and Electrum
- c-lightning-graphql — a Graphql API library for c-lightning
Contribute: c-lightning is known for its plug-in system, a simple yet powerful way to extend the functionality of the daemon. Plug-ins are sub-processes that are triggered by the main daemon and interact with it in a variety of ways, such as the command line, a JSON-RPC command passthrough, event stream subscriptions, or hooks. A plug-in can be written in any language. A list of community-curated plug-ins for c-lightning is available here. Developers wishing to contribute can start with the developer guide.
Support: IRC #c-lightning channel on Freenode
Eclair
Run: Eclair runs on Linux, Windows, and MacOS for desktop PCs. Since the mainnet launch of Eclair, ACINQ has also been offering a mobile version for Android and is currently working on a native iOS version as well. Being the first provider of a non-custodial Lightning wallet app, mobile development has always been at the center of ACINQ’s efforts, but so has the company’s objective of providing a stable and scalable node implementation for enterprises. A documentation on how to run Eclair is available here.
Based on Scala, a functional programming language, Eclair has a concise code base that facilitates testing and audits. Eclair adopted an actor programming model inspired by Erlang, which is especially suitable for the above-mentioned use case of big routing nodes: operations can be multithreaded, and each channel with its peer is sandboxed and runs stable even in case of malicious traffic.
However, such stability and scalability comes at a cost: this implementation offers the user less features and a lower degree of extensibility in order to minimize possible attack vectors.
Build: nevertheless, Eclair offers developers a JSON API with extensive documentation. The API uses HTTP form data and returns a JSON-encoded object or simple strings. Before running the client, users can customize logging as well as basic and advanced features, such as multipart payments and trampoline payments. In addition to the API, there is a plug-in system available for Scala, Java, or any JVM-compatible language.
Contribute: this document explains the practical procedure and provides guidelines for contributing.
Support: Gitter channel
lnd
Run: the user has the choice to build lnd either from source or Docker and to run it on Linux, MacOS or Windows. lnd supports light client modes (e.g. Neutrino) and offers mobile SDKs for iOS and Android. The installation guide available also includes ARM based systems.
Build: a special Builders Guide helps developers to get started. lnd does not allow to have code run in the binary itself, but provides interfaces to build applications. Two primary RPC interfaces are exported: an HTTP REST API, and a gRPC service as the preferred programmatic way to interact with lnd. Users accustomed to standard RESTful APIs can use the REST proxy; however, REST does not have “full streaming RPC coverage”. The API documentation shows how to communicate with a local lnd instance for Python, JavaScript and the CLI. The following additional client side libraries are available:
- lndclient: a golang native wrapper around lnd’s gRPC API
- Lndgrpc: python grpc client/wrapper around the default grpc interface handling the set-up of credentials
- falafel: mobile SDK for generating native Go wrappers to be used on iOS and Android
Contribute: integration in lnd works through APIs, not plug-ins. A set of developer resources is available from dev.lightning.community. Development practices and the approval process are documented separately.
Support: IRC #lnd channel on Freenode and lnd Slack channel
Rust-Lightning and LDK
Run: Rust-Lightning aims to be a mobile-first Lightning platform. In November 2020, v0.0.12 was released for testnet. Developers operate their node samples on Linux, Windows, Android, iOS, and inside a web browser like Chrome. Cross-platform support even for low-resource and embedded hardware is on top of the agenda. As RL/LDK, with the exception of a few demo implementations, is not a free-standing node, the set up might require more know-how on the user’s part but facilitates Lightning integration into different platforms. A sample node implementation using the LDK is available from the GitHub repository.
Build: unlike an out-of-the-box working Lightning daemon, Rust-Lightning rather is a modular Lightning library. Users must either implement basic networking logic, chain interactions, and disk storage themselves or use pre-existing off-the shelf parts. Currently, Rust-Lightning offers default crates (i.e. code packages) such as C/C++ bindings, a networking stack, and a persistence module. Block-sync utilities as well as Swift, Java and Python bindings on the LDK layer are part of the development roadmap.
The API provides a set of interfaces (e.g. filter, access, or fee estimator), which are used by internal components to talk with the base layer for fundamental LN operations. A second set of interfaces is exposed to drive the basic operations of LN components to open/close channels, send HTLCs, or establish connections. A third set contains the events in themselves, like payment reception, or messages to forward. All sets are directly accessible for customization and adaptation to individual applications. Regarding LDK, this guide provides a good overview and an introduction to its architecture.
Contribute: RL/LDK operates on an open contributor model. The contribution workflow, peer review, and coding conventions are described in the RL GitHub repository. Past meeting minutes offer insight into the ongoing development activities.
Support: IRC #rust-bitcoin channel on Freenode and LDK Slack channel
Electrum
Run: Electrum’s LN implementation is integrated directly in its wallet. Binaries and executables are available for Linux, Windows, and OS X as well as for Android on mobile devices. This documentation describes how to run Lightning with Electrum.
Build: for developers, a set of commands over a JSON RPC interface or the command line is available, alongside the option of running Electrum as a daemon without graphical UI.
Contribute: developers can contribute directly via the GitHub repository. For additional features that require non-python libraries, communication with a remote server, or the introduction of a new dependency, Electrum provides a special plug-in system.
Support: there are several ways to get in contact with the Electrum community, for instance through the subforum on bitcointalk.org or over the IRC #electrum channel on Freenode.
LNP Node
Run: the latest Lightning Network node to have entered the scene is LNP Node by the LNP/BP Standards Association. Developers can install v0.1 Beta 2 on desktops locally with the Rust Cargo manager or with Docker. v0.1 compiles on platforms with ARM, x64 or x86 processors. Future integration of C- and WASM-bindings are going to make LNP Node mobile- & web-ready.
Build: the node consists of multiple microservices designed to run as a single daemon process on a desktop or a server, inside a single mobile app as threads, or as separate nodes combined in a single mobile app, as outlined in the architecture. In order to connect and embed LNP Node, developers can choose between interaction via a ZMQ-based API, an SDK that abstracts away the RPC API, or other API tools. The SDK allows to call functions with languages such as Rust, Python, C, Node.js, Java, Android; or Swift. Wasm and Go are planned as extensions.
Contribute: these guidelines document the contribution process.
Support: IRC #lnp-bp channel on Freenode, weekly community calls, RGB Telegram channel.
The Lightning Implementation Feature Matrix
Now that we have introduced various options and features for running a Lightning daemon and building on it, we would like to point you to the Lightning Implementation Feature Matrix for a deeper dive into the subject matter. This matrix constitutes a dynamic documentation of support information about LN implementation-specific features. To maintain a high degree of completeness and timeliness, contributions are highly appreciated. Read the Contribution Guide to learn how to contribute.
Value Propositions and Development Roadmaps
If the past chapters inspired your interest in any particular implementation or if you want to learn more on their evolution in the coming future, here is a glimpse into the development roadmaps based on information available at the time of writing (January 2021). At the same time we also created a Feature Matrix for implementations covered in the article.
c-lightning
c-lightning aims to be both a highly customizable solution that adapts to users’ needs as well as an experimentational platform for developers to test new features. Researchers working on feature prototypes often utilize such a platform before integrating the new features into the formal specification.
The broad coverage of features, as shown in the Feature Matrix, is achieved through a multitude of plug-ins. Building and operating those plug-ins becomes possible due to a specific architecture without the need to interfere with the underlying C-code. Still, developers have a single interface at their disposal and can add custom (e.g. JSON-RPC) methods without modifying the daemon itself. This makes plug-ins especially efficient because they can access low-level details directly.
Apart from the main daemon, c-lightning consists of various sub-daemons such as a database, a wallet, or a gossip daemon. Developers can change these subsystems and, for example, swap the secret-holding daemon that manages the keys to support a hardware wallet. This high degree of customizability is particularly relevant for embedded hardware devices that run C code as well.
The default backend of c-lightning is sqlite3, a portable, self-contained database . There is PostgreSQL support for highly available data storage in more challenging high uptime environments such as enterprise business.
Recovery from corruption is possible using the backup plug-in. As opposed to static channel backups, c-lightning does not depend on peer cooperation: the restored node can simply pick up where it left off, and — given that restoration is executed before the channels time out or are closed by the peer — channels can remain open even in case of data corruption.
Roadmap of c-lightning for 2021:
- further specification efforts with proposals for onion messaging, dual-funding, and offers
- extension of the feature set and optimization of existing functionality. The multi-part payment implementation, for example, contains several parameters to optimize both time to finalization of a payment and its chance of succeeding. A series of experiments is planned to explore the tradeoffs and find the best possible parameters.
- further extension of interfaces, exposing more internals for developers to build on, and to support them
Eclair
The fact that ACINQ, the development company behind Eclair, operates the biggest public node on the network with a capacity of more than 118 BTC⁹ reveals the focus of this implementation: to establish a stable but scalable routing node suitable for enterprises. This robustness is not only achieved through the functional programming language Scala and the actor programming model, but also through an architecture optimized for that purpose. Eclair allows users to scale up one Lightning node across multiple servers. While front servers take care of CPU- and bandwidth-intensive routing table-related¹⁰ gossip messages and syncing requests from peers, the backend server can focus on core channel management. Front servers are stateless; they can be stopped with the node remaining operational and accessible, as long as there is at least one frontend node available. Through such clusterization, Eclair manages to unburden the Lightning nodes from connection and routing table management.
Furthermore, as a provider of the first non-custodial mobile app on Lightning, with Eclair Mobile, ACINQ has a reputation as being the company focused strongly on mobile wallet development. In the meantime, the company has published Phoenix, another end user wallet. Until recently only available for Android, ACINQ performed another leap in Lightning development for mobile by launching a Kotlin Multiplatform (KMP) implementation¹¹ of Eclair and along with it a Kotlin-based native iOS App. Compared to the enterprise node, the Kotlin-based implementation is optimized for mobile wallet-based user journeys, where users may not be online all the time or relay payments over the network. Therefore, unnecessary features can be omitted. Since certain attacks target the payment-relaying capability¹², wallets without that feature are less susceptible to them.
Roadmap of Eclair for 2021:
- new features: anchor outputs and trampoline payments
- native support for both iOS and Android wallets thanks to Eclair KMP
- scalable enterprise deployments: clustering, DoS protection, key protection
lnd
With Lightning Labs, lnd is backed by arguably the largest full-time development team. It hence does not come as a surprise that Lightning Labs managed to build an extensive range of value-added services around lnd, such as Aperture or the liquidity services Lightning Loop and Pool.
Loop is a non-custodial service offered by Lightning Labs that uses submarine swaps to bridge on-chain and off-chain Bitcoin. In its current iteration the software supports two swap types.
- Loop Out: the client sends funds to an on-chain address using an off-chain channel to acquire inbound channel liquidity, for instance. The Lightning Labs server pays out on-chain.
- Loop In: the client sends funds on-chain to refill depleted channels with funds from external sources; the server pays out off-chain.
The Loop daemon exposes a gRPC API and a REST API. For authentication and DoS protection, Loop uses Aperture, a HTTP 402¹³ reverse proxy¹⁴ that supports proxying requests using the LSAT Protocol Standard. LSAT is short for Lightning Service Authentication Token and combines HTTP 402 macaroons with the Lightning Network. By serving as both authentication and payment mechanism, it allows to unbundle the authentication and payment logic from the application logic. Using a YAML-based configuration, businesses can upgrade an existing web-service to be LSAT-aware and sell their products or services through micro-payments, without the necessity of providing a login, email, or password to users.
Lightning Pool is a non-custodial, peer-to-peer marketplace that allows node operators requiring inbound liquidity to pay node operators with available capital to open channels in their direction while retaining full custody of their funds. Pool’s first product is a Lightning Channel Lease — an inbound channel with a pre-agreed duration.
Except for the server-side of Loop and Pool, all clients are open source and potentially usable by other implementations.
Roadmap for lnd for 2021:
- Atomic Multi-Path Payments: enabling static invoices, recurring subscription payments, and multi-path keysend
- Dynamic Commitments: allowing peers to upgrade their channels without closing and reopening, useful for dynamic flow control, mitigating channel jamming, and upgrading to Taproot
- Error Messages: enhanced communication of unsupported state transitions via TLV extensions
- In-Memory Pathfinding: improved routing performance for mobile clients and delegated pathfinding services
- Replicated Database Support: improving fault tolerance and service availability for large node operators
Rust-Lightning and LDK
Rust-Lightning/ LDK is a generic library that allows developers to build a Lightning node. It is not an out-of-the-box and ready-to-run Lightning daemon, but rather a tool box providing developers with a high degree of customizability: they can, for instance, remove components and only use those that are really necessary to build their own application. This can be especially useful for embedded platforms with less conventional operating systems. All in all, it seems like a very promising and relevant implementation, especially for teams with an existing Bitcoin infrastructure and the requirement to only add Lightning-capabilities without having to duplicate chain/wallet/key/storage management.
The flagship features are the key signing module and the abstract key interface for hardware wallet support. All channel signing operations happen behind an external LDK signer interface, which separates the signing of a funding TX from the main part of the code base and allows developers to implement the signing software on an external device.
The cross-implementation project to be mentioned here is the Lightning Signer project with the goal to shift private key handling for LN transactions to an external signing module. As a consequence, Lightning nodes do not have to be “hot” wallets anymore, which is a big leap forward in terms of security of LN applications.
Roadmap of Rust-Lightning and LDK for 2021:
- work on mitigation of known LN security vulnerabilities (channel jamming, tx-pinning, time-dilation, …)
- enhance the Rust-Lightning/ LDK developer community
- train more Lightning protocol devs to advance protocol/infrastructure development
- LDK should become viable for production deployment
- LDK will provide sample modules and an example node to help developers understand how to integrate LDK and LN into their Bitcoin wallet
- Bitcoin Development Kit (BDK) will mature and provide some of the modules needed for building a wallet using LDK. BDK and LDK will complement each other
Electrum
Electrum developers do not plan to implement a full Lightning node with payment forwarding capabilities. Instead, their goal is to let users make Lightning payments in Electrum, without having to run their own Lightning node, and without having to trust one. The main challenge is to make Lightning accessible instantly and securely, while the Electrum client is not permanently connected to the network. To achieve this, Electrum implemented a watchtower and trampoline payments. A watchtower allows users to go offline without being afraid that their channel counterparties might attempt to steal their funds. Trampoline payments reduce the burden of data for a full network graph and computation by outsourcing the routing procedure to trampoline nodes. Furthermore, users are not bound to one specific counterparty node for channel creation, but can open channels to arbitrary nodes within the network.
Roadmap of Electrum for 2021:
- deploy multi-part payments and trampoline payments (planned for next release, version 4.1)
- integrate the watchtower with the Electrum server (planned for version 4.2 of the client)
- deterministic recovery of channels from seed words
LNP Node
In the open-source project led by the LNP/BP Standards Association, the design goal of a “Generalized Lightning Network’’ is definitely worth mentioning. It is an attempt to define payment channels in a more modular and extensible way to enable users to add new transaction outputs to the commitment transaction, switch from HTLCs to PTLCs payments, and use eltoo and experiment without having to invent new messages and standards. Bidirectional channels, channel factories/multipeer channels, Discreet Log Contracts, RGB smart contracts or Pay-to-elliptic Curve Point Lock Contracts (PTLC) are just a few of the many features and upgrades planned for this new Lightning implementation. Being in early development stage, at this moment is still in a catch up mode to align with other implementations on features.
LNP/BP does not aim to provide consumer products, but rather an API for developers. LNP Node’s main use cases are providing a node for developers to experiment, to build mobile wallets, or to use the smart contract system RGB on top of the Lightning Network. Already in the first version of LNP Node developers should be able to issue and transfer RGB assets on top of LN channels and to transact with other LNP Node operators.
Roadmap of LNP-Node for 2021:
- full LN-compatibility in Bitcoin operations (routing, channel closing)
- initial release with DEX support
- early DLC & channel factory test releases
The Lightning Ecosystem in 2021
What to expect from the Lightning Ecosystem in 2021 as revealed by experts:
Conclusion
Building on the foundation laid by our last article, in which we suggested different categories of projects to describe the Lightning ecosystem as a whole, we continued with the existing Lightning implementations as the ecosystem’s fundamental building blocks and took a closer look at them.
In doing so, we have covered their usage and development statistics, compiled the Lightning Implementation Feature Matrix, and attempted to give you a brief introduction on how to work with and build on them. Based on the above work we can draw the following conclusions:
First, the ecosystem keeps growing. Each of the implementations covers an increasing number of use cases. Developers can now make optimized implementation choices according to their needs. Not only all existing players like Eclair, c-lightning, or lnd keep innovating their implementations, but also new players like Rust-Lightning/ LDK, Electrum, and LNP Node enter the scene and provide additional options for developers.
Second, the path towards productization becomes more evident. Since the first software releases, the main developing organizations have managed to expand and solidify their own strengths and value propositions. After focusing first on covering the basic BOLT specifications, now different and distinct feature sets and architectures become apparent. Starting in late 2019, this trend includes unique positioning of specific products such as ACINQ’s mobile app Phoenix on Eclair and the lnd-based liquidity service Loop from Lightning Labs in 2020.
Third, specific sub-ecosystems emerge. The trend towards more distinct productization, differentiation and stronger community engagement led to new sub-ecosystems being formed around each Lightning implementation. With their recent release of a Kotlin multi-platform implementation, ACINQ may now be able to address the needs of mobile developers directly. On top of that, they will increase their mobile-user base by complementing their wallet portfolio with an iOS app. Driven by the modular architecture, an active and proficient developer community has emerged around c-lightning that has managed to enrich the core daemon with a multitude of plug-ins since its mainnet launch. Lightning Labs released Lightning Terminal, a browser-based dashboard to be used particularly with Lightning Labs products and, as a final example, LNP-Node users are expected to be the first, who can transfer RGB-based digital assets to each other on top of the Lightning Network.
Many of these services and plug-ins are first developed for their specific implementations, making them easier to access from their core daemon. In 2021 we should expect releases of more value-added features further strengthening specialization of core components and facilitating productization on top of them. Both trends are crucial for attracting new developer talent and strengthening the overall ecosystem by providing diverse options and easier choices for new developers entering the community.
As we ourselves have experienced while working on this article, the communities behind each of these implementations are all very welcoming to new developers, product managers, or founders. The learning curve is still a bit steep, but there are more and more options to get involved and getting involved today is a highly rewarding challenge.
Thank you
While writing this article we conducted several interviews with industry veterans and experts. The willingness of both the core infrastructure developers to contribute to it and the app developers to review the result is another indicator of the ecosystem’s supportiveness and its favorable attitude towards anyone wanting to participate. Our special thanks for all the help go to Christian Decker, Oliver Gugger, Bastien Teinturier, Antoine Riard, Matt Corallo, Steve Lee, Thomas Voegtlin, Maxim Orlovsky, Sergej Kotliar, Graham Krizek, Giacomo Zucco, and many many others.
If you have further interest in the subject matter and would like to keep updated: Fulgur Ventures’ Lightning resources web page aggregates statistical data on the Lightning Network and activity in the Lightning ecosystem since early 2019. Check it out on https://fulgur.ventures/lightning.html
Subscribe here if you want us to drop our future research in your inbox.
About the authors: Moritz Kaminski is a business development specialist with years of experience in tech ventures and early stage funding. Suheb Khan is a Technology Product Manager by profession and a Bitcoin/LN enthusiast by inclination and is contributing regularly to RTL Application. Oleg Mikhalsky is a partner at Fulgur Ventures focusing on the Lightning Network and Bitcoin ecosystem.
Footnotes
[1] Release dates of first versions: c-lightning v0.1 on Aug. 8, 2015; Eclair v0.1-alpha.1 on Feb. 17, 2016; lnd v0.1-alpha on Jan. 11, 2017; Rust-Lightning/ LDK v0.0.10 on Dec. 12, 2019; Electrum v4.0.1 on Jul. 3, 2020; lnp-node v0.1 Alpha 1 on Oct. 26, 2020.
[2] Mizrahi, A., Zohar, A. (2020). Congestion Attacks in Payment Channel Networks, arXiv:2002.06564.
[3] Zabka, P., Foerster, K.-T., Schmid, S. & Decker, C. (2020). Node Classification and Geographical Analysis of the [4] Lightning Cryptocurrency Network. https://www.univie.ac.at/ct/stefan/icdcn21ln.pdf
[4] Decker, C. (2019). Of Channels, Flows, and Icebergs. https://cutt.ly/5lwU3AH
[5] Bitrefill, (2021). Top Lightning Nodes sending to Bitrefill. https://www.bitrefill.com/lightning-toplist, [Online; accessed 19-January-2021]
[6] Tonder, van R., Trockman, A. & Le Goues, C. (2019). A Panel Data Set of Cryptocurrency Development Activity on GitHub, IEEE/ACM 16th International Conference on Mining Software Repositories (MSR), Montreal, QC, Canada, pp. 186–190. doi: 10.1109/MSR.2019.00037
[7] Please note: Electrum is not considered in this graphic as there is only one code repository with development metrics for the entire Electrum Bitcoin Wallet, and not a separate one for its Lightning implementation only.
[8] Coininsider (2020). Eclair, the first Lightning Network mobile wallet, touches down on Android. https://www.coininsider.com/eclair-lightning-network-android-app/ [Online; accessed 31-January-2021]
[9] 1ML, (2021). Lightning Network Search and Analysis Engine. https://1ml.com/ [Online; accessed 19-January-2021]
[10] The routing table is a certain subset of channels that are known to exist in the network. Each node updates its knowledge of the network in the form of a routing table. Routing tables are constructed with an aim to find paths to the recipient.
[11] Kotlin Multiplatform (KMP) is a way of writing cross-platform code in Kotlin. KMP is a feature of Kotlin which shares code between an app’s various platforms, so that each platform’s natively programmed UI calls into the common code.
[12] Harris, J., Zohar, A. (2020). Flood & Loot: A Systemic Attack On The Lightning Network. https://arxiv.org/abs/2006.08513
[13] The HTTP 402 Payment Required is a client error status response code that indicates that the request can not be processed until the client makes a payment.
[14] A reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client, appearing as if they originated from the reverse proxy server itself.
