In general, the Lightning protocol itself still has a long way to go in terms of solving existing issues and becoming robust and scalable enough to serve as a global transactional network on top of Bitcoin.
Different implementations are starting to take advantage of this greater freedom than the base layer of Bitcoin, and some members of the Core Lightning teams participated in a very interesting panel at Bitcoin 2022 to discuss some of the different priorities each team is taking in terms of expanding the feature set of their Lightning clients.
LND, run by Lightning Labs, is the most widely adopted Lightning implementation on the network, currently the backend to popular wallets like Breez, Blixt, Zap and Lightning Lab’s own Lightning App before it ceased development on it.
The Lightning Labs team has generally focused on providing its own monetized services to help address shortcomings inherent to the Lightning protocol as the core of its business model.
PTLCs accomplish the same thing using adapter signatures instead of hashes, which means that every hop along the path does not have the same hash which could identify a single payment across multiple hops if one person is running multiple nodes along the payment path.
With close to the most efficient use of blockspace containing around 3,300 transactions, it would take 25 blocks of just channel closures to close them all out, and another 25 to reopen them as Taproot channels.
LND is planning to implement a feature called “on the fly channel updates,” where instead of closing existing channels and opening new ones, you simply spend the existing channel state into a new one instead of into outputs that would close the channel on chain.
There are a large catalog of plugins available, from automated node management with CLBOSS, watchtower plugins and automated probing logic, to dynamic pruning of Bitcoin Core to ensure CLN always has the blocks it needs to stay synced.
Greenlight will further separate the functionality of different parts of the node to the point that users will be able to store and manage their keys and signing operations on different devices from where the actual node backend handling channels and other data can run somewhere else, either in the cloud or even a device hosted at home.
CLN currently supports dual-funding where both sides of the channel can contribute UTXOs in the funding transaction, allowing the channel to start off in a balanced state where both sides have funds.
Splicing would allow you to open and close a channel in a single transaction to add more funds or remove some but not all of the funds in the channel.
Lightning Dev Kit is not so much a Lightning node implementation and more of a library that can be used to construct a Lightning node.
When it began looking at Lightning integration, it wanted to deeply integrate the behavior of its Lightning nodes with the backend handling Cash App’s user balances.
LDK’s goal is to widely support all standard functionality of the Lightning protocol and allow builders to make use of any standardized features in whatever way they choose to in their own applications, or not.
LND and LDK both have WASM binaries for their nodes, and CLN is planning on implementing key management tools to run in WASM that can connect to a Lightning node remotely, building on its Greenlight work.
Lightning as a protocol and network still has a long road ahead in terms of solving open problems and figuring out how to craft applications that are easy and intuitive for end users, but work is moving forward.