What are the differences between LND and CLN? – Voltage

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 they 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 do a deep dive 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 and it is written in the C programming language. In the last month (October 22, 2022 – November 22, 2022), it had 8 developers contributing to the code and 11 issues resolved. LND is written in the Go programming language and it had 24 contributors and 43 issues resolved in the same period. 

LND is definitely more popular among developers and this could be attributed to different reasons that 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. There you can find guides, articles, example applications, and community resources. 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, for instance, is only available for LND and it’s available 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 own plugins for circular rebalancing, probing, dynamic fee adjusting, and much more. You can even implement your own payment logic plugin to overwrite the default one!

LND does not have this same plugin capability, but it does have an RPC-API that enables the user to customize some of these functionalities mentioned above. 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

If you care for your privacy then Core Lightning is the way to go. 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 is also going to extend the route by adding delays and fees along the path (shadow routes). 

Route randomization, shadow routes, and multi-part payments do bring more privacy to the user, but there is no free lunch. 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, it has a better payment success rate than CLN, and it takes recent failures into consideration 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 you’ll 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 is an application that enables a blind auction marketplace that matches nodes looking for inbound liquidity with nodes willing to provide inbound liquidity for a fee. CLN, on the other hand, 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 play a much more important role 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 that 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 sort of 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 case of a catastrophic failure, where a user is unable to revive the channels, the SCBs can be used to contact peers and prompt them to force close the channel. This is a simple mechanism, but it has drawbacks: in order to work, the peers need to be reachable. That’s why LND docs also recommend that its users keep regular backups of the `channels.db` file and close zombie channels early.

In CLN, when you create a node, 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 that you use 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, which is well-known in the developer community to be 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’re going to run your lightning node in a limited hardware computer such as a Raspberry Pi, you should take this into consideration, 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 is a specification for static invoices that 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 to be used. 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 still change.

Taro

Back in April of 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, packed 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, and so on. LND’s payment logic aims at efficiency and reliability. Payments will have a better success rate and cost fewer fees than with 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.

In terms of solutions for inbound liquidity, CLN designed liquidity ads, which takes 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 are only updated 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 does list its minimum hardware requirements in its docs, but it’s lacking 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 receive inbound liquidity with Flow.