The Lightning Network protocol is formalized in specification documents called BOLTs (Basis of Lightning Technologies). All organizations that maintain Lightning Network node implementations must follow the specifications described in those technical documents but are free to do it as they prefer. They can use different programming languages, focus on privacy instead of reliability, and so on.
This means that multiple implementations will have differences and tradeoffs between each other. In this post, we’ll dive deep into the differences and tradeoffs between two popular Lightning Network node implementations: Lightning Network Daemon (LND), and Core Lightning (CLN), by Lightning Labs, and Blockstream, respectively.
Project Background and Developer Activity
CLN was the first implementation of the Lightning Network, written in the C programming language. In the last month (October 22, 2022 – November 22, 2022), eight developers contributed to the code, and 11 issues were resolved. LND is written in the Go programming language, with 24 contributors and 43 issues resolved in the same period.
LND is more popular among developers, which could be attributed to different reasons we’ll explore later in this post. Usually, the greater the number of contributors reviewing code, fixing bugs, and adding new features in an open-source project the better.
Network Share
Another metric that we can analyze is the network share that each implementation has. It is important to emphasize that since every node has its particular view of the network, it's impossible to have an exact measure; the best we can do is approximations.
This article from @heisinberg published in stacker news found that approximately 91,67% of the nodes are running LND, against 7,01% running CLN. These numbers are very close to the ones found in a published study from 2020.
Documentation
LND is well known for its easy-to-read documentation. You can find guides, articles, example applications, and community resources there. This makes LND very user-friendly, even for non-technical people. CLN’s docs, on the other hand, are more technical and developer-focused.
This could easily explain why the community usually chooses LND to build projects on top of. The popular node manager, Thunderhub, is only available for LND and is off-the-shelf if you’re running Voltage Nodes.
Modularity
What CLN lacks in user experience it makes up for in modularity: the project provides a simple yet powerful way to extend the functionality provided by Core Lightning. Developers can write and publish their plugins for circular rebalancing, probing, dynamic fee adjusting, and much more. You can even implement your payment logic plugin to overwrite the default one!
LND does not have this same plugin capability, but it has an RPC-API that enables the user to customize some of the abovementioned functionalities. It also has HTLC interceptors that can intercept forwarded HTLCs and gRPC requests and add custom functionality, but you don’t have the same level of modularity enabled by CLN plugins. Some of the things that CLN plugins enable can’t be done without rewriting and recompiling the source code directly.
Payments - Privacy and Reliability
Core Lightning is the way to go if you care for your privacy. The payment logic uses route randomization and shadow routes to preserve users’ privacy. This means that the payment algorithm does not always use the lowest fee or shortest route (route randomization) and will extend the route by adding delays and fees along the path (shadow routes).
Route randomization, shadow routes, and multi-part payments give users more privacy, but no free lunch exists. Using these techniques makes payments more susceptible to failure and also more expensive in terms of fees paid to route a payment.
LND takes a different approach: its payment logic focuses on reliability. It is more efficient than CLN in finding the shortest path between sender and receiver, has a better payment success rate than CLN, and considers recent failures when creating the path from the sender to the receiver. Again, there is no free lunch: with LND you’ll have a better success rate but lose some privacy.
Inbound Liquidity
One of the most challenging aspects when bootstrapping a lightning node is acquiring inbound liquidity. In simple terms, inbound liquidity means your capacity to receive payments. LND and CLN have different approaches to solving this issue.
The team behind LND designed a tool called Pool. This application enables a blind auction marketplace that matches nodes looking for inbound liquidity with nodes willing to provide inbound liquidity for a fee. Conversely, CLN has chosen an approach named “Liquidity Ads”, advertising liquidity over the Lightning Network using the gossip protocol.
But although these tools exist, they are not commonly used by the community. Third-party providers are much more important in providing inbound liquidity in the Lightning Network.
Recovery and Backups
The Lightning Network gets its scalability and privacy by using the opposite approach of the Bitcoin blockchain: keeping users' financial activity to themselves instead of publishing all transaction data to the whole network. This means they cannot rely only on the Bitcoin blockchain and seed words to recover funds locked up on lightning channels. You’ll need to use some backup mechanism to guarantee you can recover your in-channel funds in case of a catastrophic failure
With LND when you create a lightning wallet for the first time, the software will generate a 24-word seed phrase for you. This seed phrase can only recover your on-chain funds but is also needed to recover in-channel funds. For funds locked in channels, LND uses a method called “static channel backups”, also called SCBs. They are called “static” because they are obtained only when the channel is created.
In a catastrophic failure, where a user cannot revive the channels, the SCBs can contact peers and prompt them to force close the channel. This is a simple mechanism, but it has drawbacks: the peers need to be reachable to work. That's why LND docs also recommend that its users keep regular backups of the `channels.db` file and close zombie channels early.
When you create a node in CLN, a `hsm_secret` will be created. The user can also generate a BIP39 seed phrase using any process and derive the secret from the seed phrase. A `hsm_secret` only needs to be written once and it is enough to recover your on-chain funds but is also needed to recover in-channel funds. CLN offers multiple strategies to recover in-channel funds in case of failure. Users are free to choose one or more backup strategies.
The simplest is to choose a location where the database containing the channel information will be replicated. While your node operates, data will be saved on both databases. CLN also recommends using a different storage device, preferably in a different physical location. The data on both databases are not encrypted so cloud services are not recommended. There are also plugins for backups and other methods for “heavy” and experienced users, such as PostgreSQL cluster and filesystem redundancy.
Hardware Performance
As mentioned earlier, CLN is written in the C programming language, well-known in the developer community as a great choice when aiming at hardware performance. On the other hand, LDN is written in GO, a language that is not as “lightweight” on the hardware as C.
If you run your lightning node in a limited hardware computer such as a Raspberry Pi, you should consider this, especially if you plan to be a routing node. The more active your node is, the more it will demand from the hardware.
BOLT #12
One of the biggest issues with user experience in the Lightning Network today is the limitations of how invoices work. Invoices need to remain private between the payer and payee and they can be used only once per payment. Sharing Invoices with other parties or reusing them can result in the loss or theft of funds. Invoices also only work to receive payments and not to send payments, which can create odd user experiences.
BOLT #12, also known as “offers”, tries to address this user experience issue. This specification for static invoices can (and should) be reused. It can also work to send payments: you scan QR codes to receive payments. From a user perspective BOLT #12 is very similar to LNURL, but LNURL requires a web server. With BOLT #12 everything is done “inside” the Lightning Network.
Currently, only CLN has experimental support for BOLT #12. Experimental because BOLT #12 is still a work in progress and the specification can change.
Taro
In April 2022, Lightning Labs announced Taro: a taproot-powered protocol for issuing assets on the Bitcoin blockchain that can be transferred over the Lightning Network. The source code for the protocol is currently being built using LND as a backend.
This means that until Blockstreams decides to implement the protocol as well, LND will be the only option for users, organizations, or companies that want to issue assets on the Bitcoin blockchain using Taro. This can push the network share of LND to even higher numbers.
Concluding
Despite implementing the same protocol, LND and CLN are two pieces of software with different philosophies. LND is currently the most used implementation, which could explain the bigger number of contributors involved in the project. It also has user-friendly documentation for non-technical users, with guides and articles.
On the software side, CLN does provide more modularity with its plugin system. You can write a plugin for basically everything: backups, probing, channel management automation, etc. LND’s payment logic aims at efficiency and reliability. Payments will have a better success rate and cost fewer fees than CLN. CLN takes a different approach and focuses on privacy, using different methods to preserve users' privacy. This does come with a cost: payments will fail more frequently, and you’ll probably pay higher fees.
Regarding solutions for inbound liquidity, CLN designed liquidity ads, which take advantage of the gossip protocol to advertise liquidity to other nodes. Lightning Labs, the team behind LND implemented a blind auction protocol called Pool. Flow makes it easy and fast to get access to inbound liquidity provided in these blind auctions.
LND also chose a different approach to backups and recovery than CLN. LND uses seed phrases and static channel backups, which only update when a channel is created. CLN uses its `hsm_secret` for recovery of on-chain funds and uses redundancy for in-channel recovery: you replicate the entire database in a different location.
CLN is known for being more performant than LND, so if you plan to have an active node and you also have hardware restrictions CLN could suit you best. LND lists its minimum hardware requirements in its docs but lacks a better description for heavy-load users.
Finally, CLN has experimental support for BOLT #12, and LND is used as a backend for the Taro protocol, which is still in the development phase. If you need to choose between CLN or LND, and want to use one of these features, you’ll need to go with the implementation that supports it, at least for now.
Create your own node below, or learn more about our Lightning Enterprise solution today.
Also, enjoy exploring our LSP and receiving inbound liquidity with Flow.
