Core Lightning v0.11.0: Channel Multiplexing, a New API, and Much More

by Christian Decker

It took a bit longer than expected, but it’s finally here: Core Lightning v0.11.0 (codename Simon’s Carefully Chosen Release Name) brings new features, fixes, and performance enhancements. Over the last five months, a record number of 36 developers, half of whom are first-time contributors, have spent countless hours writing code, debugging, and triaging issues. While we can’t enumerate every single contribution here, we’re grateful for the community that has formed around this project.

So without further ado, let’s answer the question on everyone’s mind, “what’s new?”:

• Channel multiplexing: while previously CLN would only support a single active channel with a peer, we now added support for channel multiplexing, allowing any number of parallel channels running over a single peer-to-peer connection.
• Networked RPC interface: a gRPC interface enables secure remote access to the API exposed by CLN.

On top of these, we had many other features, large and small, some of which we’ll touch on below.

Channel Multiplexing

You asked for it, and we listened! You can now open multiple parallel channels to a single peer, and they can be managed completely independently. This, alongside our existing dual-funding and the upcoming splicing support, gives node operators yet another option to optimally allocate funds to channels. This meant rearchitecting a lot of the internals of CLN, but Rusty managed to pull it off in record time.

Reworking the way that we handle communication internally also gave us a chance to rethink and correct inefficiencies, avoid duplicate work, and address corner cases, resulting in a much leaner, more efficient implementation overall.

There’s even slightly intelligent use of redundant channels: if a payment requests one channel, we’ll see if there’s an alternative to that same peer which has identical fees but more capacity, and use that instead.

cln-grpc: Secure Networked RPC Interface

Another big feature users have been asking for is a standardized API that apps, plugins, and other tools could use to interact with CLN. We always had a JSON-RPC, with a very exhaustive API, but it was exposed only locally over a Unix-domain socket. Some plugins chose to re-expose the API over a variety of protocols, ranging from REST to gRPC, but it was additional work to install them.

So with v0.11.0, we released a new interface: cln-grpc, a Rust-based plugin that exposes the existing interface over the network in a secure manner. The gRPC API is automatically generated from our existing JSON-RPC API, so it has the same low-level and high-level access that app devs are accustomed to but uses a more efficient binary encoding where possible and is secured via mutual TLS authentication.

To use it, just add the --grpc-port option, and it’ll automatically start alongside CLN and generate the appropriate mTLS certificates. To use the gRPC interface, copy the client key and certificate, generate your client bindings from the protobuf definition and connect to the port you specified earlier.

While all previous built-in plugins were written in C, the cln-grpc plugin is written in Rust, a language that will be much more prominent in the project going forward. In order to kick off the use of Rust, we also built a number of crates:

• cln-rpc: native bindings to the JSON-RPC interface, used for things running on the same system as CLN.
• cln-plugin: a library that facilitates the creation of plugins in Rust, with async/await support, for low-footprint plugins.
• cln-grpc: of course, the library used to create the gRPC plugin can also be used directly as a client library.

All of these crates are published on crates.io and will be maintained as part of the project moving forward.

Other Features

As mentioned earlier, there are far too many changes to highlight them all here. However, we do have some other exciting features that are worth sharing now.

As part of the onion messages proposal, CLN now implements both the second and third draft of the proposal, with v3 being used for our own messages, and v2 being supported for backward compatibility when forwarding and receiving. We’d like to thank the other teams for participating in the discussion and moving the proposal forward.

After almost two years, we are finally retiring the old legacypay command. This command implemented the old non-MPP pay behavior and was introduced in v0.9.0. Not having to support this old command, allowed us to simplify the codebase and start working on more advanced implementations. More on this soon.

And finally, we’ve had support for backup plugins and replicated databases via the postgresql driver for a long time, but this release adds yet another option: native sqlite3 replication. By specifying --wallet=sqlite3://dbA.db:/second/drive/dbB.db CLN will now write to both dbA.db and /second/drive/dbB.db in parallel, ensuring that if one drive crashes, the other one has a perfect copy to recover from.

To Be Continued…

We’ve managed to squeeze a lot into this release, but we’re just getting started. As you read through the details, know that we’re already regrouping for the next release, and have quite a few more features in the works.

To update to the latest version of CLN, head over to the release page, or if you want to dig into the finer points, check out the changelog, and tell us what you like or what we could improve.

And as always, a huge thanks to the many contributors and volunteers that continue to help us improve CLN over time. We’re grateful for your contributions and look forward to continuing to partner with you in building Lightning.

Core Lightning v0.11.0: Channel Multiplexing, a New API, and Much More was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.